Subject: Re: New Consensus call on RH0 Deprecation

From: Tim Enos <[email-masked]>
Date: Mon, 27 Aug 2007 11:29:22 -0500 (CDT)

>> > We would like to get your comments on the following two choices:
>> > 
>> > 1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-rh0-01.txt>.
>> > 
>> > 2) Revising the draft to restrict the usage of RH0.  This would  
>> > continue to require RH0 to be implemented but would restrict the  
>> > functionality of RH0.  For example, require nodes to have support for  
>> > RH0 turned off by default, limit the number of RH0 headers in a  
>> > packet to one, limit the number of addresses in the RH0 to a smaller  
>> > number (e.g., 6), and and a requirement that addresses can only be in  
>> > the header once.
>> > 
>> I am in favor of option 2.
>> 
>> With regard to RH0 and source routing in general I do not believe the best
>> approach is to deprecate this functionality.  
>> 
>> Feature parity between IPv4 and IPv6 is important to ease transition and
>> transition concerns.  I wonder how much support there would be to
>> deprecate IPv4 source routing.  
>> 
>> Also, if source routing in some sort of new and limited form turns out to
>> be useful, RHx could be specified and implemented in new extension header,
>> but the same is not true for IPv4.
>
> see the text carefully.  (1) says "deprecate *RH0*", (2) says "restrict the usage of *RH0*". 

> It is not about RHx. Will your choice change because of this?

Exactly. It (option (1), adopting the draft) is not about RHx. Strictly speaking it isn't about firewall policy either. It's merely about deprecating RH0.

RHx providing similar functionality to that of RH0 could be addressed in another draft (might be already?)

Also FWIW, I'm not sure if there's a more comprehensive treatment of IPv6 firewall policy (that has made it to RFC form). RFC 4890 recommends how to handle filtering of ICMPv6 packets. Perhaps a similar RFC could be written to address RHx (excluding type 0 of course).

>
> and for what it's worth, IPv4 options entirely deprecated in reality.
> packets with any IPv4 options could not go through JP-US link at least since 1992 or so.  therefore, IPv4 equivalent of RH0 has been dead	for 15 years.
>

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.

> i'm, of course, in favor of (1), and the document has to be shipped as soon as possible.

I'm still also in favor of (1).

> there are huge vendors which holding up the release of security advisory until RFC gets published!
>

Here's a recent security advisory from one such huge vendor:

http://www.cisco.com/warp/public/707/cisco-sa-20070808-IOS-IPv6-leak.shtml

> itojun

Best Regards,

Tim Enos
Rom 8:28

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Dow Street <[email-masked]>
Date: Mon, 27 Aug 2007 11:27:54 -0700

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?

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.

Is DOS protection / mitigation an assumed (or explicit) service  
provided by ISPs to customers?

Thanks,
Dow

---

From: [email-masked]
Date: Mon, 27 Aug 2007 14:44:11 -0400 (EDT)

> 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. :-)

> 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.

> 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.

> 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

---

From: Dow Street <[email-masked]>
Date: Mon, 27 Aug 2007 13:35:39 -0700

Thanks much, Brian - comments inline:

> but generates *no* revenue.

I assumed it was something like this, but thought it better to ask  
than to guess myself :-)

Is it correct to say, then, that the real problem with RH0 is that it  
creates the potential for traffic (trends) to be less predictable,  
which in turn breaks the current ISP pricing / billing model?  Is it  
also correct to say that the oscillation-DOS case is just one example  
(if perhaps, an extreme one) of how RH0 could make traffic prediction  
more difficult, and that other "legitimate" uses of loose source  
routing (whether RH0 or RHx) present similar risks to the current  
pricing / billing model?

Thanks,
Dow

---

From: Jason Schiller <[email-masked]>
Date: Mon, 27 Aug 2007 16:49:30 -0400 (EDT)

> 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. 

> 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