Re: SYN floods (was: does history repeat itself?)
At 09:08 PM 9/9/96 -0400, Avi Freedman wrote:
This is *exactly* the right thing to do; every provider which does not provide complicated transit (which excludes even certain regionals, alas) should do this at their borders if they don't do it at each customer connect.
And everyone should at least filter on each customer 56k/t1/etc... I know router cycles are tight but it might *really* become imperative...
Am I missing something.... If I am announcing a network via BGP I am more or less agreeing to carry traffic for it. If I am not I am not. Therefore, if I filter based on my outbound BGP announcements and do not allow any packets which have a source address not originating from a network in my BGP announcements then I should not be causing any harm to the networks which I am providing connectivity to. This has the added benefit of stopping people from defaulting into me at exchange points as I will not carry that traffic across my backbone. I'd love to hear the holes in this theory. Justin Newton Internet Architect Erol's Internet Services
"Justin W. Newton" <justin@erols.com> wrote:
At 09:08 PM 9/9/96 -0400, Avi Freedman wrote:
This is *exactly* the right thing to do; every provider which does not provide complicated transit (which excludes even certain regionals, alas) should do this at their borders if they don't do it at each customer connect.
And everyone should at least filter on each customer 56k/t1/etc... I know router cycles are tight but it might *really* become imperative...
Am I missing something....
If I am announcing a network via BGP I am more or less agreeing to carry traffic for it. If I am not I am not. Therefore, if I filter based on my outbound BGP announcements and do not allow any packets which have a source address not originating from a network in my BGP announcements then I should not be causing any harm to the networks which I am providing connectivity to. This has the added benefit of stopping people from defaulting into me at exchange points as I will not carry that traffic across my backbone. I'd love to hear the holes in this theory.
I think you are talking about filtering inbound packets to your router and restricting them to BGP announcements (I don't think Avi was - see below). This would be done on the destination address (checking it was within your announced route set) and thus doesn't help protect against spoofed source addresses. I *think* what Avi was talking about was filtering outbound packets by source address and checking these are within announced routes. This has additional problems to those listed below where, for instance, there are deliberately asymmetrical announcements. Here's some complications with both schemes. Suppose you have an exhange point where providers peer, but A and B exchange full routing for backup transit purposes (we do this with another provider over LINX for example). The if A wants to filter (say) inbound packets based on whether or not they are for networks A announces, I have to find out who they are coming from as A announces full routing to some people (B) and not normal peers such as C. Incoming packets don't have the IP address of the last hop router, though I suppose this could be obtained through ARP, then matched against the IP addresses of BGP neighbours. But suppose B is giving transit to some networks not within B's normal announcement to D, without setting next-hop-self. Then in a backup transit situation I will blackhole packets from D, as I will be announcing the nets to B who will in turn announce them to D, who's arp address I don't correlate to an IP address of a BGP neighbour which I announce those routes to. Route servers make the entire process even more complex as here you are getting incoming packets from (or sending outgoing packets to) IP addresses with whom you have no BGP session. May be I'm missing something, but I think any non-trivial transit arrangements make this difficult to say the least. Alex Bligh Xara Networks
Alex.Bligh writes:
"Justin W. Newton" <justin@erols.com> wrote:
At 09:08 PM 9/9/96 -0400, Avi Freedman wrote:
This is *exactly* the right thing to do; every provider which does not provide complicated transit (which excludes even certain regionals, alas) should do this at their borders if they don't do it at each customer connect.
And everyone should at least filter on each customer 56k/t1/etc... I know router cycles are tight but it might *really* become imperative...
Am I missing something....
If I am announcing a network via BGP I am more or less agreeing to carry traffic for it. If I am not I am not. Therefore, if I filter based on my outbound BGP announcements and do not allow any packets which have a source address not originating from a network in my BGP announcements then I should not be causing any harm to the networks which I am providing connectivity to. This has the added benefit of stopping people from defaulting into me at exchange points as I will not carry that traffic across my backbone. I'd love to hear the holes in this theory.
I think you are talking about filtering inbound packets to your router and restricting them to BGP announcements (I don't think Avi was - see below). This would be done on the destination address (checking it was within your announced route set) and thus doesn't help protect against spoofed source addresses.
No, Justin's talking about filtering _customers'_ packets at Justin's border with the customer. No BGP involved. This assumes customers that are not providers (ie, no transit for other nets through the customer). Good enough if all providers do the right thing (or if almost all do). What Justin meant about his BGP announcements was that a customer's packet is legal IFF Justin's announcing that packet's net by BGP (on _behalf_ of the customer, not _to_ the customer). Again, customer means a site that's not a BGP peer.
I *think* what Avi was talking about was filtering outbound packets by source address and checking these are within announced routes.
Taht was one thing Avi mentioned (he showed access lists for that). But he was also talking about the stuff Justin did, which was his (and my) main point.
This has additional problems to those listed below where, for instance, there are deliberately asymmetrical announcements.
Here's some complications with both schemes. Suppose you [...]
Yes, all these schemes fail between peers. The point is that they protect against rogue customers. If an attack happens anyway, we discover the provider that has failed to guard against it's own customers' malfeasance, and we shun that provider. That'll bring it around fast enough, once most providers are doing the Right Thing. /a
participants (3)
-
Alex.Bligh -
Alexis Rosen -
Justin W. Newton