Re: SYN floods (was: does history repeat itself?)

[Vadim Antonov <avg () quake net>]

Jeremy Hall <jhall () rex isdn net> wrote:

> You may not have said it, but I remember someone said the route had to be
> in the routing table. I would agree with you if it looked up the source
> in the BGP table and if it considered history or dampened paths valid. If
> your asymetry runs over multiple interfaces, then the best path might not
> be on the interface the packet is arriving on.

Ok, i assume that was clarified.

> I am referring to end-user problems. When a line flaps, especially a
> backbone line, lots of destinations suddenly become unreachable.

You don't do any filtering on backbone lines.  Particularly because
they belong to transit routing domains, where the reverse-routing
filters cannot work.

When a tail circuit flaps you lose connectivity in both directions,
so that's also not a problem.

Finally, if a multi-homed non-transit AS loses an access circuit there's
no problem because all interfaces on remote ends of those circuits allow
incoming packets, because their BGPs have reverse routes in their RIBs.

(As a side note -- in cases when something is screwed up _not_ allowing
packets through is a definite plus.  It can prevent nasty routing loops
and resulting BGP session flaps due to router overload.)

-->The fact that source identification works, and works well enough even
-->to do billing is beyond any doubt.  RELCOM does that on large scale.

> Do they deny packets because you aren't a relcom customer? This is a nice
> idea on a sunny day, don't get me wrong, but I am wondering how the
> routers would react when an unusual condition occurs. Are you certain
> relcom bills its customers for *EVERY* source packet, or can account for
> them at least?

Yes, they do, and bill differently for interior traffic (which is cheaper)
and much more expensive capacity of international circuits.  Nobody cares
about tracing every packets, just counting them on per-customer basis.

> Please explain. If your router does not know how to get back to the
> source in the split second it got the packet, it might know how to get to
> the destination and could send the packet on its way.

Communication requires bidirectional connectivity.  So routers _must_ have
both routes or you can't talk.

> Maybe by the time
> the web server responded, traffic could resume a normal route, or perhaps
> outbound traffic for the web server is unimpared because you chose to
> implement asymetry.

Throwing packets aways (and reducing traffic in other ways) during periods
of instability is a Good Thing; as most of the nastiness in instabilities
is caused by the surges of load on the routers.  Having the boxes to process
traffic going in strange ways (often resulting in expensive things like
sending out ICMPs) does not help for network to stabilize.

--vadim
- - - - - - - - - - - - - - - - -