On 08/28/2010 01:52 PM, Thomas Mangin wrote:
My point was not about crafted bgp message to test border cases - this is what one would expect in a regression suite. It is about the use of a fuzzer to corrupt packet when you then do not know if the router is then behaving correctly or not.
I wasn't saying you should use both at the same time, but I thought it might be a good idea to add a fuzzer so that it could be run seperately. Any bugs we can find before it is in production causing problems is useful. Although most code I've seen which deals with the BGP-protocol directly seemed to be pretty simple/smart about it.
--- 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:
Those tools are not suitable for regression testing ( I know I wrote exabgp ) not saying they could not be adapted though.
Fizzing may return crashes or issues with the daemon but it is unlikely. You need predictable input for regression testing and in our particular case how do you detect a corruption without knowing what the behaviour of the router should be on that particular input.
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 build whole infrastructure.
-- ++ytti