On Mon, 27 Aug 2007, Dow Street wrote: > On Aug 27, 2007, at 9:29 AM, Tim Enos wrote: > > > Good point. This would be true even in the face of a company on the > > JP side and a company on the US side (of the JP-US link) agreed > > together to accept source-routed traffic from each other. > > > > Just having the RH0 traffic transit the intervening ISP(s) would > > make the link susceptible to the attacks outlined in the draft. > > Can you (and others) clarify your position on what you consider to be > valid traffic? I do not work for a commercial ISP, so I'm trying to > understand the current thinking / policy on this. > > Suppose you have 4 providers, where A and B are in the US and C and D > are in Japan (the B -- C link is the US-JP link). > > A - B - - C - D > > Assume A and D are interested in supporting source routing, but B and > C are not. Further assume that, due to A and D's support for source > routing, they are susceptible to the kind of oscillation DOS attack > we have been discussing. The B - - C link is managed / protected by > B and C - that is, they have ultimate control over what traffic > transits this US - JP link. > > In the event of an oscillation DOS attack between A and D, do B and C > care that the traffic they are transiting is DOS traffic vs. other > traffic? In other words, hasn't the capacity available to A (from B) > and the capacity available to D (from C) already been arranged? If > this capacity is consumed due to DOS, is it not A and D (and their > customers) who pay the cost?
In most cases yes. A is a customer of ISP B and D is a customer of ISP C. Customer A pays ISP B to transit its traffic. Same for customer D and ISP C. If customer A and customer D desire to support source routing, and both customer A and customer D desire to allow a large amount of traffic to loop bettween them then so be it. If customer A or customer D exhausts their bandwidth and the wish to upgrade then so be it. If customer A or customer D consider this bandwidth exhaustive traffic to be a DoS atack, but desire to permit some source routing, then they can contcat their upsteam ISP and have the traffic filtered or black holed just like any other DoS attack. Or If customer A or customer D consider this bandwidth exhaustive traffic to be a DoS atack, and do not require permitting source routing, then then can turn off source routing. If the traffic consumes all the capasity on backbone link within ISP B or ISP C or the peering point between ISP B and C, then that ISP should treat the traffic like any other DoS attack and filter or blackhole the traffic. Certainly there are other packet amplifers that are far worse that RH0. There is nothing special about RH0 packets that make them any harder to filter or blackhole than other DoS traffic. > > This is not to say we shouldn't think about the global aspects of > resource use and DOS - I'm just trying to understand whether the > approach to source routing requires a global consensus. Several > recent comments seem to imply that it is unacceptable even to transit > RH0 traffic (rather than simply choose not to act on RH0 headers) - > have I interpreted this position correctly? If so, it would seem to > have implications for both RH0 (as is being discussed) and any new > source routing approach RHx. I have concerns about transiting RH0 (or IPv4 source routed) packets in the current implementation as many routers treat this traffic differently and forward this traffic via software which has a greater impact of the router than normal traffic using hardware based forwarding. It would be nice if a router could ignore the source routing, and simply forward in hardware. This way each network could protect itself, and leave other networks free to make their own security decesions. Currently the only options are to allow source routing, or discard all source routed packets. Thus the transit providers of the Internet have decided that no one can use source routing. __Jason > > Is DOS protection / mitigation an assumed (or explicit) service > provided by ISPs to customers? > > Thanks, > Dow > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
