[129178] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Did your BGP crash today?

daemon@ATHENA.MIT.EDU (Thomas Mangin)
Sat Aug 28 07:53:24 2010

In-Reply-To: <20100828113652.GA30160@mx.ytti.net>
From: Thomas Mangin <thomas.mangin@exa-networks.co.uk>
Date: Sat, 28 Aug 2010 13:52:28 +0200
To: Saku Ytti <saku@ytti.fi>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

My point was not about crafted bgp message to test border cases - this is wh=
at one would expect in a regression suite.
It is about the use of a fuzzer to corrupt packet when you then do not know i=
f the router is then behaving correctly or not.

---
from my iPhone

On 28 Aug 2010, at 13:36, Saku Ytti <saku@ytti.fi> wrote:

> On (2010-08-28 13:23 +0200), Thomas Mangin wrote:
>=20
>> Those tools are not suitable for regression testing ( I know I wrote exab=
gp ) not saying they could not be adapted though.
>>=20
>> Fizzing may return crashes or issues with the daemon but it is unlikely. Y=
ou need predictable input for regression testing and in our particular case h=
ow do you detect a corruption without knowing what the behaviour of the rout=
er should be on that particular input.
>=20
> It doesn't actually matter how likely or unlikely one expect such tool to
> be finding new issues. There is already value, that researchers like RIPE
> in this case, could simply write new test case, instead of needing to buil=
d
> whole infrastructure.
>=20
> --=20
>  ++ytti
>=20


home help back first fref pref prev next nref lref last post