On BB, so top posting. Apologies.
It seems that creating a worst case BGP test suite for all kinds of nastiness
(in light of the recent RIPE thing) might not be a bad idea - so that we can
all test the implementation ourselves before we deploy new code.
Like all funky attributes, all funky AS S
On Sat, Aug 28, 2010 at 6:14 AM, Florian Weimer wrote:
> * Christopher Morrow:
>
>> (you are asking your vendors to run full bit sweeps of each protocol
>> in a regimented manner checking for all possible edge cases and
>> properly handling them, right?)
>
> The real issue is that both spec and cu
These are good news.
However, if Comcast provides native IPv6 to their customers, then the IPv6
native customers don't need these 6to4 relays?
Airport Extreme, Linksys and other user equipment, enable IPv6 by doing 6to4
tunnels, so what this press release says, is that there are many users who
FYI - thought this would be of interest to some of you, there will be more
news on this front shortly.
http://www.comcast6.net/
6to4 Relays Activated
Tuesday, August 17, 2010
As we started our IPv6 trials, we began to observe an increase in 6to4 relay
traffic. 6to4 is a transition mechanism buil
On Fri, Aug 27, 2010 at 2:33 PM, Dave Israel wrote:
> On 8/27/2010 3:22 PM, Jared Mauch wrote:
[snip]
> an MD5 hash that can be added to the packet. If the TCP hash checks
Hello, layering violation.If the TCP MD5 option was used, the
MD5 checksum was probably correct.
Malformed BGP Protoc
On Sat, Aug 28, 2010 at 02:19:28PM +0200, Florian Weimer wrote:
> * Claudio Jeker:
>
> > I think you blame the wrong people. The vendor should make sure that
> > their implementation does not violate the very basics of the BGP
> > protocol.
>
> The curious thing here is that the peer that resets
On Sat, Aug 28, 2010 at 02:51:17PM +0200, Thomas Mangin wrote:
> We had ASN4, AS-PATH and this one. More or less we hit this session
> reset problem once a year but nothing was done yet to change the RFC.
You are mixing up three totaly different problems. Sure the result was the
same (session dro
> I agree correctly framed invalid packet should be discarded without tearing
> the session down.
This statement is way to simplistic.
I would be interested if anyone has pointers toward any work which was done to
sort this issue.
Thanks.
Thomas
http://docs.google.com/viewer?url=http://www.hyperchip.com/H40GPresentation.pdf
--- ober...@es.net wrote:
From: "Kevin Oberman"
To: na...@shankland.org
Cc: nanog@nanog.org
Subject: Re: PacketShader
Date: Mon, 23 Aug 2010 11:56:29 -0700
> Date: Mon, 23 Aug 2010 06:27:00 -0700
> From: Jim Shank
We had ASN4, AS-PATH and this one. More or less we hit this session reset
problem once a year but nothing was done yet to change the RFC.
So I am to blame as much as every network engineer to not have pushed for a
change or at least a comprehensive explanation on the session teardown
behaviour
Hi!
Cisco posts their advisories to the NANOG list.
'The vulnerability manifests itself when a BGP peer announces a prefix
with a specific, valid but unrecognized transitive attribute. On
receipt of this prefix, the Cisco IOS XR device will corrupt the
attribute before sending it to the neigh
* Randy Bush:
>> To carry out such experiments responsibly, you have to conduct so much
>> testing beforehand that the live test on the actual Internet will not
>> yield new insights (assuming you did your pre-experiment testing
>> properly).
>
> you seem to assume the purpose of the test was to s
* Raymond Dijkxhoorn:
> Not sure if the link was posted allready ...
>
> http://www.cisco.com/en/US/products/products_security_advisory09186a0080b4411f.shtml
Cisco posts their advisories to the NANOG list.
> 'The vulnerability manifests itself when a BGP peer announces a prefix
> with a specific
Hi!
I think you blame the wrong people. The vendor should make sure that
their implementation does not violate the very basics of the BGP
protocol.
The curious thing here is that the peer that resets the session, as
required by the spec, causes the actual damage (the session reset),
and not t
Am I the only one on the list which saw the sentence in Cisco's
Advisory "Before sending the the unknown attribute to peers, the IOS XR
corrupted it" which clearly states this was a bug?!
* Claudio Jeker:
> I think you blame the wrong people. The vendor should make sure that
> their implementation does not violate the very basics of the BGP
> protocol.
The curious thing here is that the peer that resets the session, as
required by the spec, causes the actual damage (the session re
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.
> To carry out such experiments responsibly, you have to conduct so much
> testing beforehand that the live test on the actual Internet will not
> yield new insights (assuming you did your pre-experiment testing
> properly).
you seem to assume the purpose of the test was to see if routers
crashed.
On Sat, Aug 28, 2010 at 01:09:47PM +0200, Leen Besselink wrote:
> On 08/28/2010 11:39 AM, Saku Ytti wrote:
> > On (2010-08-28 18:20 +0900), Randy Bush wrote:
> >
> >
> >> a bgp regression suite would not have caught this as it was not a
> >> repeat. but it sure would be useful to implementors.
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.
---
from my iPhone
On 28 Aug 2010, at 13:36, Saku Y
I think that focusing on researchers (who we assume are good-intentioned)
misses the point. Any connected BGP speaker can inject any form of ugliness.
The routers that mishandled these updates were bounded by routers that were
able to 'properly' handle corrupted updates.
The question of aggr
On Sat, Aug 28, 2010 at 04:56:05PM +0900, Randy Bush wrote:
> imiho, researchers injecting data into the control plane are responsible
> to have tested it at least against major bgp speakers. and, considering
> its placement in the net (big core), i consider ios xr to be a major
> speaker.
>
> i
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 regressi
* Randy Bush:
> a bgp regression suite would not have caught this as it was not a
> repeat.
Eh, it was just another corrupt-and-propagate issue combined with the
broken (but RFC-required) session reset policy on malformed updates.
* Randy Bush:
> imiho, researchers injecting data into the control plane are
> responsible to have tested it at least against major bgp speakers.
Practically, this boils down to "don't do that", which is certainly
fine by me.
To carry out such experiments responsibly, you have to conduct so much
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 co
On 08/28/2010 11:39 AM, Saku Ytti wrote:
> On (2010-08-28 18:20 +0900), Randy Bush wrote:
>
>
>> a bgp regression suite would not have caught this as it was not a
>> repeat. but it sure would be useful to implementors.
>>
> Naturally 'proving' that non-trivial software works is practically
* Christopher Morrow:
> (you are asking your vendors to run full bit sweeps of each protocol
> in a regimented manner checking for all possible edge cases and
> properly handling them, right?)
The real issue is that both spec and current practice say you need to
drop the session as soon as you en
> Quagga is even worse that Cisco when it comes to packet validation but it
> should not surprise anyone :p
To substantiate my claim, my mercurial log tells me that for MPRNLRI and
MPURNLRI having the flag set as Transitive instead of Optional did not cause
Quagga to complain. It just took the
> I am really surprised by these attitudes. Guys (and gals), these
> incidents simply go to reinforce that the software we depend on, has
> not received sufficient testing and that we all have gigantic
> exposures due to things outside of our direct control
nice anti-vendor rant. but over the las
On (2010-08-28 18:20 +0900), Randy Bush wrote:
> a bgp regression suite would not have caught this as it was not a
> repeat. but it sure would be useful to implementors.
Naturally 'proving' that non-trivial software works is practically
impossible. But stating what non-existing test-suite would
while this is undoubtedly true for hobbiest researchers, there are
pretty good relationships between vendors and some research facilities
with a strong interst in ensuring there is external review of the
code base(es).
(I am personally aware of at least five such faci
>>> i suspect that these folk will test better next time. i sure hope
>>> so.
>> Not sure the researcher can afford to buy a ios xr and may not have
>> access to one !
> Also testing is hard
so is cleaning up the mess when you screw up enough of the internet to
make the international press.
> Ma
On Sat, Aug 28, 2010 at 09:22:34AM +0100, Thomas Mangin wrote:
> On 28 Aug 2010, at 08:56, Randy Bush wrote:
>
> > imiho, researchers injecting data into the control plane are responsible
> > to have tested it at least against major bgp speakers. and, considering
> > its placement in the net (big
On (2010-08-28 09:22 +0100), Thomas Mangin wrote:
> > i suspect that these folk will test better next time. i sure hope so.
>
> Not sure the researcher can afford to buy a ios xr and may not have access to
> one !
Indeed.
Also testing is hard, especially so, when you essentially need to reinv
>> i suspect that these folk will test better next time. i sure hope so.
> Not sure the researcher can afford to buy a ios xr and may not have
> access to one !
then ask on *nog for someone against whom they can test.
randy
On 28 Aug 2010, at 08:56, Randy Bush wrote:
> imiho, researchers injecting data into the control plane are responsible
> to have tested it at least against major bgp speakers. and, considering
> its placement in the net (big core), i consider ios xr to be a major
> speaker.
>
> i suspect that th
imiho, researchers injecting data into the control plane are responsible
to have tested it at least against major bgp speakers. and, considering
its placement in the net (big core), i consider ios xr to be a major
speaker.
i suspect that these folk will test better next time. i sure hope so.
ra
> I'm assuming that they weren't really expecting this to cause issues... Where
> does one draw the line? I'm planning on announcing x.y.z.0/20 later in the
> week -- x, y and z are all prime and the sum of all 3 is also a prime. There
> is a non-zero chance that something somewhere will go floo
39 matches
Mail list logo
