SYN flood messages flooding my mailbox

Mon Sep 23 15:07:55 UTC 1996

In message <199609180045.RAA00207 at quest.quake.net>, Vadim Antonov writes:
> Curtis Villamizar <curtis at ans.net> wrote:
> 
> >> If you relax criteria for reverse-route filtering to "known route" instead
> >> of "best route" then any customer (non-transit) AS can be filtered safely
> >> at border routers.
> 
> >And if the "known route" is know by another router but suppressed from
> >IBGP advertisement because there is a better route ..
> 
> But you still have the exterior route in the RIB.  So you know it.

I guess a picture would help:

     AS X R1  ------  AS Y R3
        |                |
	|		 |
     AS X R2  ------  AS Y R4

If the route learned at AS Y R4 is preferred, AS Y R3 may get packets
although the forwarding entry (Fib) points toward AS Y R4, the LocRib
does not contain the entry (no preferred), only the AdjRibIn contains
the entry.  If the filter must be set according to AdjRibIn, you now
have a filter list **in the forwarding path** considerably longer than
the current routing table.  Won't scale at the very least.

> >Or if the "known route" goes through an AS that uses YOU as their best
> >route but the reverse traffic goes a different way..
> 
> So what?  The assumption is that multi-homed AS announces all its
> routes to all exits (maybe with different "metrics").

In this case:

     AS a R1  ------  AS b R2  ------  AS d R4
        |                |		  |
	|		 |		  |
	+-----------  AS c R3  -----------+

In this case AS c prefers AS a.  AS d prefers AS c.  AS b prefers the
routes it hears from AS b.  AS a prefers some route through AS d that
it hears from AS b over the route it hears from AS c.  Therefore AS d
has no Fib, LocRib, or even AdjRibIn from AS b R2, but will get
legitimate traffic from R2 that is dstined for places that is
reachable through AS d but for which AS d uses AS c for the return path.

> Is there any practical example of _properly configured_ multihomed
> non-transit AS which advertises more routes at one exit than another?
> 
> >Both of these cases and other cause a blackhole.
> 
> Not at all.

The first case is clearly less scalable than the current routing table
(consider putting all AdjRibIn entries at a NAP into your filters on
the forwarding card).  The second just plain doesn't work.

Curtis