Re: SYN flood messages flooding my mailbox
Curtis Villamizar <curtis@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'm talking about filtering on borders, not within backbones utilizing the BGP hack.
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"). 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.
Of course, if by "known route" you mean known because it is in the IRR, and the IRR is known to be reliable, then I accept your argument but caution that the IRR is not always reliable, but this is yet another reason to make it more reliable.
IRR. I always held an opinion that the kludge got to die as soon as somebody comes with real way to authenticate routing information. It is silly to build centralized databases for anything. They by definition cannot be reliable. (Note that address allocation does not have to be centralized -- in fact, TWD is the direct result of such centralization).
We've had providers shut down sites because they were slow to address hacking launched from their site...
Do you enjoy playing a cop? I don't. To me, the real solution is to make sure attacks are not feasible in the first place. Or at least make sure that the victim can easily obtain the identity of perpetrator and pursue the legal action on his own. ISPs are not in business of catching criminals. Their business is to deliver bits.
In one case an NSFNET regional shut down a large university because their CS department just said "security is a hard problem" and refused to do anything. After 4 days of no Internet access they had things quite thoroughly cleaned up.
The times of the Big Bro^H^H^HNSFNET are long gone. Good riddance, i certainly have no nostalgia. If people want to have no locks on their doors it is certainly completely within their rights, ok?
Shutting down the source is a lot easier if you know the source.
I do not want to shut down anyone, if possible. Internet made a very good device to support right of speach. Now the question is how to equip it to provide the right not to listen. The authentication is very instrumental to enforce the right not to listen. At least, then you can explicitly say: "I don't want to listen to anything from such and such". Essentially, source address filtering is the non-cryptographic form of authentication. In reality approach like that works surprisingly well. --vadim
In message <199609180045.RAA00207@quest.quake.net>, Vadim Antonov writes:
Curtis Villamizar <curtis@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
participants (2)
-
Curtis Villamizar
-
Vadim Antonov