Re: In case anyone hadn't seen this
The solution to this problem is filtering, which has been known for a long time. The provoders that have been filtering on the customer edge seem to have done much better in terms of providing sanitized routes. I am wondering how many such major outages need to occur in order to convince some providers to do customer filtering? -- Enke
* To: nanog@merit.edu * Subject: In case anyone hadn't seen this * From: "Alex.Bligh" <amb@xara.net> * Date: Fri, 25 Apr 1997 17:41:43 +0100 * cc: amb@xara.net * Content-Type: text/plain; charset=us-ascii * Sender: owner-nanog@merit.edu
----------------------------------------------------------------------
I haven't yet seen this on NANOG - Apologies if it's been there 3 times by the time you read this or are one of those who doesn't like NANOG used for large scale outage notification.
Date: Fri, 25 Apr 1997 11:44:11 -0400 (EDT) Reply-To: jun@wolfox.gsl.net Originator: bulletin@gsl.net Sender: bulletin@gsl.net Precedence: bulk From: Jun (John) Wu <jun@wolfox.gsl.net> To: Multiple recipients of list <bulletin@gsl.net> Subject: internet currently is partially down X-Comment: Global IP Operational Bulletin MIME-Version: 1.0 Status: RO
There seems to be a major problem on the whole internet at this moment. A network called FLIX (AS7007) is having a major routing malfunctioning, and seems to have announced all major provider's blocks as more speficics. (probably because of a classic mistake of redistricute BGP into IGP and then IGP into BGP while the IGP does not know VLSM)
This has currently brought SprintLink and UUNET to non-operating status, perhaps other networks as well that I can not verify without connectivity. (at the time this email is sent). I just called FLIX and they have shut down al their peering sessions. The network should stablized in a few hours.
Jun -- Jun (John) Wu | Voice: (703)689-5325 Supervisor - Global IP Systems & Services | Fax: (703)478-7852 Global One Communications L.L.C. | Email: jun@gsl.net Reston, VA 20196 | URL: http://wolfox.gsl.net/jun
------- End of Forwarded Message
The solution to this problem is filtering, which has been known for a long time.
The provoders that have been filtering on the customer edge seem to have done much better in terms of providing sanitized routes. I am wondering how many such major outages need to occur in order to convince some providers to do customer filtering?
i'd argue that filtering is protection against misconfigurations. in practice, the way that filtering is done, it does not protect us from malice; hopefully such attacks would be short-lived because the immediate provider(s) would cut the person off, but even short problems on the scale we're talking about are serious. fortunately most of the wide-scale attacks we've seen have not been within the routing system itself (though some have pounded its infrastructure .. e.g., the low UDP port number attack), but there's always that possibility. in order for filtering to protect us from malicious attacks within the routing system we need a lot more in the way of authentication for registries and tools built on top of them of course that means a lot of work, so people have to first recognize how fragile some of this stuff is. today's excitement is a very good example of that fragility to be clear, i am a fan of registries and filtering as they are currently used .. there is no alternative other than chaos. i just think it's a mistake to think that filtering as we know it now is equivalent to a necessarily robust routing system /jws
On Fri, 25 Apr 1997, John W. Stewart III wrote:
> The solution to this problem is filtering, which has been known for > a long time. > > The provoders that have been filtering on the customer edge seem to > have done much better in terms of providing sanitized routes. I am > wondering how many such major outages need to occur in order to > convince some providers to do customer filtering?
i'd argue that filtering is protection against misconfigurations. in practice, the way that filtering is done, it does not protect us from malice; hopefully such attacks would be short-lived because the immediate provider(s) would cut the person off, but even short problems on the scale we're talking about are serious. fortunately most of the wide-scale attacks we've seen have not been within the routing system itself (though some have pounded its infrastructure .. e.g., the low UDP port number attack), but there's always that possibility. in order for filtering to protect us from malicious attacks within the routing system we need a lot more in the way of authentication for registries and tools built on top of them
Using the of RAWhoisd extended queries(*) it is very easy to build an accurate access list and an as-path filter as well. (*) see http://www.ra.net/RADB.tools.docs/rawhoisd.8.html It is equally simple for anyone having access to a router receiving the full BGP table to check the consistency of informations found in routing registries with the actual BGP entries *before* putting a new access list in action. Nothing else is required to inject sound routing information in the BGP mesh.
of course that means a lot of work, so people have to first recognize how fragile some of this stuff is. today's excitement is a very good example of that fragility
to be clear, i am a fan of registries and filtering as they are currently used .. there is no alternative other than chaos. i just think it's a mistake to think that filtering as we know it now is equivalent to a necessarily robust routing system
All sorts of malicious attacks can give us headaches, but BGP annoucements, is just like crossing the street: carefully watch for what is already there and you will be safe.
/jws
__ Pierre Thibaudeau | e-mail: <prt@Teleglobe.CA> TELEGLOBE CANADA | 1000, rue de La Gauchetiere ouest | Tel: +1-514-868-7257 Montreal, QC H3B 4X5 | Canada | fax: +1-514-868-8446
my point is that right now authentication is mntner-based and most access-list generation depends on an as-macro. so what's to stop me from changing my as-macro to contain a few thousand ASs and then config'ing my router to announce a zillion prefixes? filtering as we know it today doesn't protect against this .. the upstream provider would have to manually intervene. even if the access-list generation depended on as-in/as-out policy instead of just as-macros, and the tools had some knowledge of what ASs were downstream to allow for AS-path filtering as well as prefix-based, then i could still just register zillions of prefixes with appropriate origins and config my router to announce those zillions of prefixes with appropriate AS-paths all i'm saying is that parts of the system are fragile and registries can't be viewed as a silver bullet /jws
On Fri, 25 Apr 1997, John W. Stewart III wrote:
> The solution to this problem is filtering, which has been known for > a long time. > > The provoders that have been filtering on the customer edge seem to > have done much better in terms of providing sanitized routes. I am > wondering how many such major outages need to occur in order to > convince some providers to do customer filtering?
i'd argue that filtering is protection against misconfigurations. in practice, the way that filtering is done, it does not protect us from malice; hopefully such attacks would be short-lived because the immediate provider(s) would cut the person off, but even short problems on the scale we're talking about are serious. fortunately most of the wide-scale attacks we've seen have not been within the routing system itself (though some have pounded its infrastructure .. e.g., the low UDP port number attack), but there's always that possibility. in order for filtering to protect us from malicious attacks within the routing system we need a lot more in the way of authentication for registries and tools built on top of them
Using the of RAWhoisd extended queries(*) it is very easy to build an accurate access list and an as-path filter as well.
(*) see http://www.ra.net/RADB.tools.docs/rawhoisd.8.html
It is equally simple for anyone having access to a router receiving the full BGP table to check the consistency of informations found in routing registries with the actual BGP entries *before* putting a new access list in action.
Nothing else is required to inject sound routing information in the BGP mesh.
of course that means a lot of work, so people have to first recognize how fragile some of this stuff is. today's excitement is a very good example of that fragility
to be clear, i am a fan of registries and filtering as they are currently used .. there is no alternative other than chaos. i just think it's a mistake to think that filtering as we know it now is equivalent to a necessarily robust routing system
All sorts of malicious attacks can give us headaches, but BGP annoucements, is just like crossing the street: carefully watch for what is already there and you will be safe.
/jws
__
Pierre Thibaudeau | e-mail: <prt@Teleglobe.CA> TELEGLOBE CANADA | 1000, rue de La Gauchetiere ouest | Tel: +1-514-868-7257 Montreal, QC H3B 4X5 | Canada | fax: +1-514-868-8446
participants (3)
-
Enke Chen -
John W. Stewart III -
Pierre Thibaudeau