That pesky AS path corruption bug...
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
When you say the router crashes I assume you are talking the whole box crashing and not just the BGP session. 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. pete On Tue, May 23, 2000 at 12:40:00PM -0400, Blaine Christian wrote:
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
On Tue, May 23, 2000 at 12:40:00PM -0400, Blaine Christian wrote:
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.
Just a note that this breaks route servers. Caveat programmer. And how do you mean "corrupted"? If the packet is syntacically invalid, its perfectly legal to send a NOTIFY and drop the session. GateD did this to Proteon for years. :-)
Blaine
-- Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu
On Tue, 23 May 2000, Blaine Christian wrote:
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
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. /vijay
On Tue, 23 May 2000, Vijay Gill wrote:
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
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.
/vijay
Come on people. It's VERY easy to do one of the following: (1) NOT implement AS-path filtering on route-server connections (2) Apply filtering on RS sessions with an as-path access-list that includes those AS's that you will see via that RS. Am I the only RA that notifies the peering contacts of all other RS peers when someone new joins? I certainly hope not. John Fraizer EnterZone, Inc
On Wed, May 24, 2000 at 12:23:05AM -0400, John Fraizer wrote:
Come on people. It's VERY easy to do one of the following:
(1) NOT implement AS-path filtering on route-server connections
AS-path filtering is a perfectly reasonable thing to do. The route server software can either prepend the RS AS, or not. RSng peers have full control over this via their registered inet-rtr policy. http://www.rsng.net/peering.html#rs-in options: aspath-trans
Am I the only RA that notifies the peering contacts of all other RS peers when someone new joins? I certainly hope not.
Unless your policy (not specifically you, John) is promiscuous, its necessary for both "the new guy" and existing RS peers to update their aut-num policy (and possibly import() policy in their inet-rtr:rs-in) in order for the new routes to be proxied via the route servers.
John Fraizer EnterZone, Inc
-- Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu
looking for some more details about what the malformed aspath looks like. I took a router in my lab and started sending it some bogus as_paths. It seemed to accept everything I would send. Here is one aspath which doesn't include the remote-as and loops all over the place. It was happily accepted. BGP routing table entry for 10.1.2.3/32, version 414648 Paths: (1 available, best #1) Advertised to non peer-group peers: 10.254.254.1 1 2 3 4 3 2 1 2 3 4 3 2 129.237.125.185 from 129.237.125.185 (0.0.0.120) Origin EGP, localpref 100, valid, external, best Dampinfo: penalty 980, flapped 2 times in 00:00:57 pete On Tue, May 23, 2000 at 12:40:00PM -0400, Blaine Christian wrote:
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
participants (5)
-
Blaine Christian -
Jeff Haas -
John Fraizer -
Peter T. Whiting -
Vijay Gill