> 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.
I have, in the past, handed just such situations and the planning/costing and billing-model stuff, and can address your questions with a great level of certainty and authority. If I sound like a know-it-all in this area, it's because, well, I am. :-) > 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? Absolutely not. The pricing/billing model on transit ISPs, involves some presumptions and/or projections on usage patterns. The transit providers, in this case B and C, need to ensure peak usage is covered by their capacity. And they bill their customers, A and D, based on the observed patterns of the aggregates of their customer base, and on A and D in particular. DOS breaks the trends, and exceeds the limits of the billing model, by any of several methods. Bottom line is, when traffic is DOS, the cost exceeds revenue, since all capacity *on the transit upstream* is eaten. Traffic that exceeds the link capacity on the respective tail sections, A-B and C-D, that crosses B-C, is traffic that must be discarded, has costs, but generates *no* revenue. > 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 think that while there may be some value in supporting multi-hop, return path semantic diagnostic traffic tools, I don't believe we live in a world where the transport layer itself (IP) is the right place for it to exist. Having higher-level protocols, or even applications/libraries, that do what has previously been done in the IPv4 or IPv6 headers, would achieve the desired goals, without placing a risk or burden on the infrastructure itself. So, having "beacon" hosts, on the networks of A and D, who speak a special application protocol, that allows a sequence of beacon IPs in the "data" portion of the packet to be semantically interpreted as "send a new packet to the next IP", etc., similar to either RH0 or LSRR/SSRR, but which would only do so for packets specific to that protocol (and possibly protected by, for instance, some kind of key or other ID method or even ACLs), would allow interested cooperating parties to do their testing, without exposing the network(s) involved to DOS, or requiring the IPv4/IPv6 stacks to support special behaviour. > Is DOS protection / mitigation an assumed (or explicit) service > provided by ISPs to customers? It is something akin to a differentiator and/or self-selector. Some provide proactive detection of DOS, and semiautomatic mitigation. Most, if not all, respond to requests for filtering of DOS traffic. Not filtering DOS traffic, even after a customer requests, is very bad for an ISP's reputation and long-term business survival. Hope this helps your understanding, and everyone to reach the consensus required, which is that "RH0 must go." Brian Dickson -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
