Vern Paxson <vern@ee.lbl.gov> wrote:
In my Internet end-to-end routing study I found that fully 50% of the pairs of paths through the Internet had a major asymmetry at the end of 1995.
Sure, but where the asymmetry is? Certainly not on tail circuits of single-homed customers :) Moreover, multi-homed non-transit networks still announce all routes to all places; i.e. the filtering i was talking about will still work. It breaks on transit networks, i.e. the backbones; but people who run backbones are presumeably clueful enough to disable the filtering on backbone links, and leave it on on customer tail links.
"Major" meaning: visited at least one different city in the two directions. (30% visited at least one different AS.) This was a significant increase over the same figure for the end of 1994, 30%. So it may be quite hard to make and keep Internet routing symmetric.
Routing *must* be symmetrical within IGP only networks if metrics in different directions are symmetrical. When the packets leave the routing domain, that's another story. Again, the rule is "dont accept packets from an interface if there's no route for their source addresses pointing back to the same interface". Note that that route does not have to be the best one -- just that the router gets it from somewhere. --vadim
Again, the rule is "dont accept packets from an interface if there's no route for their source addresses pointing back to the same interface". Note that that route does not have to be the best one -- just that the router gets it from somewhere.
Without discussing it with the right folks here ahead of time, I suspect we could do this at good speed in some, but not all routers, in our product line. The solution I have in mind would not be suitable for some places in the net. We'd put the extra checks in the slow path which Curtis hates so much, and then use our 'flow-switching' cache, which is keyed by src/dest adresses & ports. So packets which fail the source address scrutiny in the slow path aren't put in the flow-switching cache. I can't recall if we cache negatives there, but in any event apparently the attacks involve SYN flows on the order of 100's of PPS, which might go through the slow path OK. BTW, I believe the criterion Vadim suggest is similar to that used in RPF Multicast flooding. Now the big question: is this useful in routers carrying a default route? -- Jim
Jim Forster writes:
Again, the rule is "dont accept packets from an interface if there's no route for their source addresses pointing back to the same interface". Note that that route does not have to be the best one -- just that the router gets it from somewhere.
Without discussing it with the right folks here ahead of time, I suspect we could do this at good speed in some, but not all routers, in our product line. [...] Now the big question: is this useful in routers carrying a default route?
I'm not entirely sure about what you mean, but I'd envision that the best place to do this filtering would be in routers attached to "end" customers, which frequently use default routes. Perry
participants (3)
-
Jim Forster -
Perry E. Metzger -
Vadim Antonov