- NANOG - lists.nanog.org

UUNet?
by Jeff Wheat 24 May '00

24 May '00

Does anyone know what happened on Monday? Seems like it has been hushed up as I can find no information about it anywhere. Contacting UUNet results in them telling us that their legal department is working on a press release... Thanks, Jeff

2 1

[OT] Seeking T1 switch 96 port [trunk]
by Henry R. Linneweh 24 May '00

24 May '00

I need this for testing, it can be passive, basically to untangle the wire jungle. So if anyone has some laying around that you don't want, email me privately. -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

1 0

That pesky AS path corruption bug...
by Blaine Christian 24 May '00

24 May '00

Hello all, After observing a recent issue regarding a router that sent corrupted AS path (all names are witheld to protect the guilty). I took a look at the path information that was being received and have a possible solution. Since the corrupted AS-path does not include the AS that the route is coming from (at least in the corruption that I saw) it seems to me that a simple solution for all is to filter on AS i.e. only allow routes that have the AS of your EBGP neighbor prepended to them. I realize this does not cover all cases of wacky AS corruption problems but it may fix some of them. I would suggest that those of you running mixed vendor EBGP (again names witheld) should implement a version of this strategy for your own self protection. It can certainly be implemented as part of an overall customer access functionality. This may be obvious to some of you but I do not believe that everyone is at this level yet. Of course the tirade part of this email is for all vendors involved in this travesty. If you do not understand or dislike a route that you have received don't just CRASH. Anyone ever thought of checking the route and throwing it out with an error message if you don't like it? I, of course, have heard and seen that several vendors have fixed this in the more recent releases. This type of bug is something that everyone who writes software has to deal with. If you raise an exception for bad input it is bad form to crash or reset your application. BTW, I am sure all have heard this argument before. I just wanted to get this topic renewed. Regards, Blaine

5 6

Re: That pesky AS path corruption bug...
by Sean Donelan 24 May '00

24 May '00

On Tue, 23 May 2000, Jeff Haas wrote: > The only valid defense against such mucking that I can think of > is verifying AS adjacencies against some registry and flagging > unknown paths. This is not a cheap thing to do. This, however, > is far saner than cryptographically signing all routing updates > which is one solution I've heard proposed. :-P You can cryptographically sign bad information as well as good information. Cryptography is good for detecting alterations, not if the information was correct in the first place.

3 2

OT List Questions
by Dennis L. Shreve 24 May '00

24 May '00

Pardon the OT bandwitdh. I'm new to the nanog list and have a couple quick questions: Is this a low volume list? I am not receiving any posts. Should I not get copies of all messages to the list including my own? Where can I get instructions on list usage and options? Joe was kind enough to reply to my test (which I never saw cross the list), but the reply was to me directly, instead of to the list so I cannot tell if I'm receiving from the list? Sorry for the intrusion, your assistance is appreciated!! Thanks, Dennis ... ------------------> > -----Original Message----- > From: Joe St Sauver [mailto:JOE@OREGON.UOREGON.EDU] > Sent: Tuesday, May 23, 2000 6:55 PM > To: d_shreve(a)nvbell.net > Subject: Re: test > > > It works. > > Joe

3 2

[OT] Seeking T1 switch, 96 port [trunk]
by Henry R. Linneweh 24 May '00

24 May '00

Please answer me privately, I need this for testing purposes, and I am hoping someone has an old one laying around -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

1 0

test
by Dennis L. Shreve 24 May '00

24 May '00

testing

2 1

Re: That pesky AS path corruption bug...
by Vadim Antonov 23 May '00

23 May '00

Peter T. Whiting <pwhiting(a)fury.ittc.ukans.edu> wrote: > As I understand the current spec, a router, upon receiving a malformed > as_path is supposed to respond with a notification message (3.11) and > drop the BGP connection. Your suggestion to maintain the connection > and drop the announcement is a practical one, but doesn't put as much > pressure on vendors to fix the bug. This is not only practical, but, in fact, the only sane way to do things. Dropping BGP session causes withdrawal of hundreds or thousands of acceptable routes. When the BGP session is reestablished, these routes will be acquired again, causing a wave of announcements. When the invalid route shows up, the cycle is repeated. What a perfect way to kill the Internet :) --vadim

5 5

Re: That pesky AS path corruption bug...
by Vadim Antonov 23 May '00

23 May '00

Vijay Gill <wrath(a)cs.umbc.edu> wrote: > This is what BGP dampening is for. Dropping a few prefixes here and there > is a good way to make operational debugging of a network of any size, > hell. Dampening reduces negative effects, but there's still a potential for serious service disruption: processing a ton of new updates ties up CPU resources which in case of OFRV software can easily cause timer expiration on BGP sessions of peers border routers. > With a NOTIFY and a drop, there is a definite positive feedback that > something is majorly wrong and allows people to open top level cases with > vendors. I do not think that deliberately breaking things just to attract attention of the management is a good idea. If some vendor ignores bug reports, go to a different vendor :) --vadim

2 1

Re: That pesky AS path corruption bug...
by Kai Schlichting 23 May '00

23 May '00

At Tuesday 01:26 PM 5/23/00 , Vijay Gill wrote: >This is a hack. We do not need more cruft added on, rather, what we need >is correct behavior. The correct behavior being - if you see a corrupt/ a >malformed update from a peer, send a notify and drop the session. Seems >fairly simple to me. > >The above suggestion of your fails in case of route servers. > >Insist on correct behavior, not on cruftery. ...reading the host requirements RFC and its definition of the robustness principle: Why was the behavior above chosen over the more conceivable and robust "ignore (log) corrupted message, continue with regular operation" ? Given route flap dampening, dropping the BGP session is hardly the desirable outcome here. On that note: under what circumstances should or shouldn't the BGP session come back up without mnual intervention? bye,Kai

3 2