Subject: problems with draft-ietf-ipv6-deprecate-rh0-00.txt

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 18 May 2007 01:17:01 +0200

After reading draft-ietf-ipv6-deprecate-rh0-00.txt, I found several  
problems:

- the draft mentions "serious security implications" that can be  
"exploited"
   without explaining what those are
- the draft "deprecates" the routing header type 0 without explaining
   what deprecation entails
- the document forbids origination or processing of packets with a
   routing header type 0, which is contrary to my interpretation of the
   meaning of "deprecate"
- although listed as an informative reference, the draft exclusively  
relies
   on http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf to explain
   the problems the draft endeavors to solve

In short: the draft uses undefined terminology, does more than it is  
supposed to do, provides no explanation of any kind but rather refers  
to an external document that is high on rhetoric ("Type 0 : the evil  
mechanism we describe in this presentation") and grandiose claims  
("Defeating Root DNS servers anycast architecture") and low on useful  
technical description.

To fix this, we should explain the problems that source routing and/ 
or the routing header type 0 can cause, define what "deprecate" means  
and then what deprecation of the routing header type 0 means in  
practice, and how this solves the problems explained earlier. Or we  
simply forego use of the word "deprecate".

I would also like to see a discussion of source routing in IPv4  
included here, contrary to popular belief source routing for IPv4 is  
enabled on a good number of routers, and relatively recent software  
from one popular vendor still has IPv4 source routing enabled by  
default.

See text below.

Both IPv4 and IPv6 provide the option for the source of an IP packet  
to influence routing decisions by listing a number of intermediate  
hops that the packet must pass through on its way to its ultimate  
destination. This is called source routing. In IPv4, two forms of  
source routing are defined as IP options that increase the length of  
the IPv4 header, see RFC 791. In IPv6, source routing is accomplished  
by placing a "routing header" directly behind the IPv6 header.  
Multiple forms of source routing are possible, but generic loose  
source routing is provided by a routing header type 0 (RH0). The only  
other type in use is 2, for Mobile IPv6. See RFC 2460 for a detailed  
description of RH0.

Although source routing has been possible with IP for a very long  
time, the mechanism is rarely used. The only known use of the  
mechanism is for troubleshooting: by having diagnostic packets (such  
as those generated by the traceroute utility) flow through a  
designated router using the source route mechanism, it is possible to  
evaluate connectivity of that router. There are, however, undesirable  
uses of the source route mechanism in general and RH0 in particular.

When a router or other device is configured to filter out certain IP  
packets, a naive implementation or configuration of such a filter may  
let source routed packets through even though otherwise identical  
packets that aren't source routed would have been rejected. When a  
packet with the routing header type 0 hasn't been processed by the  
last source routed hop yet, the destination address in the IPv6  
header is different from the the final destination of the packet. So  
a filter that ignores the RH0 specification in RFC 2460 and only  
evaluates the IPv6 header without considering the RH0 may arrive at  
an undesired conclusion. Use of RH0 may also provide reachability to  
nodes that have a global IPv6 address but no direct global IPv6  
connectivity.

Source routing also allows a single packet to traverse a given link  
more than once, using up unnecessary capacity in the process.  
Fortunately, this ability is limited by the filtering that is common  
on the boundaries between networks, so the impact of potential abuse  
of this type is limited. Although the RH0 makes the destination field  
in the IPv6 header change after each source routed hop, the source  
address remains the same throughout the lifetime of the packet. This  
means that when a packet originating at network A with network D, as  
its destination and intermediate networks B and C listed several  
times as source routed hops, will appear to come from A when it goes  
from A to B and from B to C, which is expected and, presumably,  
allowed. However, when the packet is then forwarded back from C to B,  
BCP38-style ingress filtering will discard the packet. The same  
happens if C employs egress filtering by checking whether packets  
leaving the network have source addresses that belong to the local  
network or its customers. This means that using the source routing  
mechanism to use up bandwidth can only be successful on inter-domain  
links where no filtering is deployed on either side, or within a  
single administrative domain. In other words, a network that faces  
malicious source routed packets can limit the flow of these packets  
by either implementing ingress or egress filters, and stop it by  
disabling source routing on its routers.

With IPv4, the presence of any options in the IP header is  
problematic, because this makes efficient processing of the packet in  
question impossible. This means that a relatively low number of  
source routed packets (or other packets with options) can use up a  
much of a router's processing capacity. With IPv6 RH0 is problem is  
less pronounced because the option only needs to be evaluated when  
the packet arrives at the node indicated by the IPv6 destination  
address in the packet.

Since source routing can be used in ways that are undesirable, the  
IETF has reached the following consensus:

1. Implementation of source routing as defined in RFCs 791 and 2460  
is optional. An IP implementation MAY omit the source routing  
capability and is then still considered in full compliance with RFC  
791 or 2460, respectively.

2. IP implementations that support source routing, MUST provide an  
administrative mechanism for disabling the source routing functionality.

3. IP implementations that support source routing, SHOULD have source  
routing administratively disabled by default.

4. IP implementations that do not implement source routing or have  
source routing disabled, SHOULD return an ICMP error appropriate for  
encountering an unknown option as per RFC 791 and RFC 2460,  
respectively.

The IETF does not recommend blanket filtering of all packets that  
contain a source routing option; if any filtering of source routed  
packets is performed, the filter should only reject packets with the  
routing header type 0, in order to avoid breaking the Mobile IPv6  
protocol and future protocols that may use similar mechanisms.

IP implementers who want to retain the source routing mechanism are  
encouraged to implement additional constraints to avoid misuse of the  
mechanism. For instance, the number of source routed hops may be  
limited, only a single RH0 option per packet may be allowed, and/or  
source routed packets that visit the same hop multiple times may be  
rejected.

There has been some confusion over the correct interpretation of some  
of the text pertaining to RH0 in RFC 2460. Some implementers have  
implemented RH0 such that when a host is listed as an intermediate  
hop in a routing header, the host executes the source routing  
algorithm and forwards the packet to the next source routed hop. This  
interpretation of RFC 2460 should be considered incorrect: if, after  
processing a routing header, a host determines that the packet is not  
addressed to one of the addresses the host currently holds, the host  
MUST NOT forward the packet, but it SHOULD send back the ICMP error  
appropriate for encountering an unknown option.

Iljitsch van Beijnum

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

---

From: Joe Abley <[email-masked]>
Date: Fri, 18 May 2007 08:08:50 -0400

>   without explaining what those are

I see some value in producing a companion draft which gives concrete  
examples of problems with source routing in general -- such a  
document might cover more than just RH0 functionality (e.g. it might  
include discussion on IPv4 loose source routing). I see your attached  
text, which seems like it would be right at home in such a document;  
I also have some summaries of the issues packaged in the CanSecWest  
presentation that I had previously intended for section 5 that might  
be of some use.

> - the draft "deprecates" the routing header type 0 without explaining

I thought sections 3.1 and 3.2 were fairly clear. If you'd like to  
propose text to make them clearer, I'd gladly read it.

>   routing header type 0, which is contrary to my interpretation of the

What is your interpretation, then?

> - although listed as an informative reference, the draft  
> exclusively relies

No, there are other references.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 May 2007 19:20:00 +0300 (EEST)

On Fri, 18 May 2007, Iljitsch van Beijnum wrote:
> To fix this, we should explain the problems that source routing and/or the 
> routing header type 0 can cause, define what "deprecate" means and then what 
> deprecation of the routing header type 0 means in practice, and how this 
> solves the problems explained earlier. Or we simply forego use of the word 
> "deprecate".

IMHO, the key point is to make a decision how to go forward.  The WG 
chairs have read the consensus as 'deprecate' (mail on Mon, 14 May 
2007 16:12:04 -0400).

It is not clear to me whether you're arguing against the result of 
that consensus call, or arguing about the lack of clarity in this 
draft (in general or specific to section 3).

I do not think it's very productive to rathole over argument which 
underlying problems are critical, which of them are "security" versus 
something else, etc.  While it would likely be beneficial to put this 
on the written record, getting consensus on these underlying problems 
would take much longer than getting consensus for which action to 
take.

As such, I'd be supportive of having the source routing issues 
documented in a separate (non-normative) I-D, but that should not 
block advancing this I-D.  (On the other hand, I don't think such a 
document is strictly necessary, either.)

I'm supportive of your concern that the interpretation of the word 
"deprecate" may have different meanings and more explicit language 
might be warranted; Section 3 defines its result without an explicit 
definition.  I'm also supportive of your concern that the draft should 
tone down "serious security implications" that can be "exploited" -- 
even if these were true, I don't feel it's necessary to have such 
(potentially) contentious words in this draft; the key point is the 
deprecation, not getting perfect consensus on why we deprecate and how 
exactly we write it down.

However, as I think the draft shouldn't spend words in enumerating the 
various attacks, it shouldn't discuss the mitigations either. (Both of 
these are potential ratholes that we should avoid.)

With regard to IPv4, ADs seemed to feel that it should be addressed in 
a separate document.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Joe Abley <[email-masked]>
Date: Fri, 18 May 2007 12:34:12 -0400

On 18-May-2007, at 12:20, Pekka Savola wrote:

> I'm also supportive of your concern that the draft should tone down  
> "serious security implications" that can be "exploited" -- even if  
> these were true, I don't feel it's necessary to have such  
> deprecation, not getting perfect consensus on why we deprecate and  
> how exactly we write it down.

The draft contains this sentence in the abstract:

    The functionality provided by IPv6's Type 0 Routing Header can be
    exploited in order to perform remote network discovery, to bypass
    firewalls and to achieve packet amplification for the purposes of
    generating denial-of-service traffic.

and this sentence in section 5:

    The purpose of this document is to deprecate a feature of IPv6 which
    has been shown to have serious security implications.

The word "exploit" (or derivatives) and the word "serious" do not  
otherwise exist in the document. If people have concerns with those  
two sentences above, I would welcome suggested improvements to the text.

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 18 May 2007 18:44:28 +0200

On 18-mei-2007, at 18:20, Pekka Savola wrote:

> IMHO, the key point is to make a decision how to go forward.  The  
> WG chairs have read the consensus as 'deprecate' (mail on Mon, 14  
> May 2007 16:12:04 -0400).

> draft (in general or specific to section 3).

It's the draft.

Let me start by quoting a dictionary definition of "deprecate":

deprecate |ˈdepriˌkāt| |ˌdɛprəˈkeɪt| |ˌdɛprɪkeɪt|
verb [ trans. ]
1 express disapproval of : [as adj. ] ( deprecating) he sniffed in a  
deprecating way.
2 another term for depreciate (sense 2): : he deprecates the value of  
children's television.

Second sense of depreciate would be: disparage or belittle (something)

In other words: what this means in a technical context is extremely  
unclear. I'm not aware of any IETF document that specifies what  
"deprecate" means.

What I envision when deprecating a feature that until that moment has  
been a mandatory part of a standard, is that it is no longer a  
mandatory part of that standard. Apparently, others have the  
interpretation that the feature is now forbidden from being used. I  
can see how the chairs observed consensus on the former, but not on  
the latter. Also, telling people they are no longer allowed to use  
this feature is an exercise in futility: there are tens of millions  
of systems out there that implement this feature, it will take very  
many years for all these systems to be upgraded or removed from service.

> underlying problems are critical, which of them are "security"  
> versus something else, etc.

Terminology is important.

> While it would likely be beneficial to put this on the written  
> record, getting consensus on these underlying problems would take  
> much longer than getting consensus for which action to take.

The action follows from the problem, so I'm not sure if this is the  
case. But if you know of a way forward that is compatible with the  
different views expressed so far, that would certainly be a time saver.

> block advancing this I-D.

One of my objections is that this draft doesn't explain what it does  
or why. This is an integral part of what we're trying to do here, we  
can't relegate that part to some third order draft. And why the rush?  
Implementers are going to do what they're going to do regardless of  
the publication date of the resulting RFC. And it's not like we  
didn't know the implications of source routing before this.

> However, as I think the draft shouldn't spend words in enumerating  
> the various attacks, it shouldn't discuss the mitigations either.  
> (Both of these are potential ratholes that we should avoid.)

No, these are central to the issue.

> With regard to IPv4, ADs seemed to feel that it should be addressed  
> in a separate document.

Why? Are we going to have separate documents for IPv4 and IPv6 until  
the end of time, even if the issues overlap 80%?

Iljitsch

---

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Fri, 18 May 2007 12:01:50 -0500

See Standard 58 (ftp://ftp.rfc-editor.org/in-notes/std/std58.txt) which
defines deprecate (as it is used for IETF MIBs at least) numerous times.

More general (and less pejorative) definitions than the one you offer
can be found in many places...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Friday, May 18, 2007 12:44 PM
> To: Pekka Savola
> Cc: IETF IPv6 Mailing List
> Subject: Re: problems with draft-ietf-ipv6-deprecate-rh0-00.txt
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 18 May 2007 19:07:40 +0200

> defines deprecate (as it is used for IETF MIBs at least) numerous  

   "While the value "deprecated" also indicates an obsolete definition,
    it permits new/continued implementation in order to foster
    interoperability with older/existing implementations."

Sounds about right to me...

---

From: Dow Street <[email-masked]>
Date: Fri, 18 May 2007 12:27:57 -0700

On May 18, 2007, at 9:44 AM, Iljitsch van Beijnum wrote:

> One of my objections is that this draft doesn't explain what it  
> does or why. This is an integral part of what we're trying to do  
> here, we can't relegate that part to some third order draft. And  
> why the rush? Implementers are going to do what they're going to do  
> regardless of the publication date of the resulting RFC. And it's  
> not like we didn't know the implications of source routing before  
> this.

I agree.  If this I-D is to deprecate a significant part of such a  
key RFC, it should explain why.  The current text is exceeding sparse  
in this regard, and the relevant refs are mostly non-archival documents.

---

From: Joe Abley <[email-masked]>
Date: Fri, 18 May 2007 21:01:14 -0400

On 18-May-2007, at 15:27, Dow Street wrote:

>> why the rush? Implementers are going to do what they're going to  
>> do regardless of the publication date of the resulting RFC. And  
>> it's not like we didn't know the implications of source routing  
>> before this.
>
> key RFC, it should explain why.  The current text is exceeding  
> sparse in this regard, and the relevant refs are mostly non- 
> archival documents.

So would work on a companion document outlining the problems with  
source routing in general and RH0 in particular fill that gap  
satisfactorily, in your opinion?

Joe

---

From: "George V. Neville-Neil" <[email-masked]>
Date: Fri, 18 May 2007 23:23:21 -0400

At Fri, 18 May 2007 21:01:14 -0400,
> satisfactorily, in your opinion?

I believe that a separate document is best, because I prefer the
current, shorter, draft we have now.

Best,
George

---

From: Dow Street <[email-masked]>
Date: Sun, 20 May 2007 21:08:00 -0700

> satisfactorily, in your opinion?

That might work, provided there was a degree of fate-sharing between  
the two documents (i.e. of they were developed and submitted  
together).  I think sending up the action document without the  
corresponding justification document would be a bad idea.  Of course,  
putting all the material in one draft also solves that problem.

R,
Dow

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 May 2007 15:32:54 +0300

Iljitsch,

> the end of time, even if the issues overlap 80%?

I have found that its management-wise easier to deal with small
documents and small steps. Delay in one part does not cause
delay in another. Updates: -header will look simpler. Normative
references point only to the things that you need to implement.
Etc.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 May 2007 15:48:41 +0300

Iljitsch,

> to an external document that is high on rhetoric

If there is rhetoric, lets get rid of it. Please suggest specific changes.

> - the draft "deprecates" the routing header type 0 without explaining
...
> ... define what "deprecate" means and then what deprecation of the
> routing header type 0 means in practice, and how this solves the
> problems explained earlier. Or we simply forego use of the word
> "deprecate".
>

Its a good question what deprecation means. I have personally taken it
to mean "act as if it didn't exist in the first place". As the draft
explains,
nodes should behave as if they did not recognize type 0 at all.

I think that is a good starting point, for both receiving and sending.
(The current draft goes a bit beyond this, however, in having the
two MUST NOTs in Section 3. I'm not sure this is a problem -- the
formulation is up to the WG.)

> from one popular vendor still has IPv4 source routing enabled by default.

Yes - we need to do this, too. RFC 1812 still requires processing to
be by default on for routers...

(But lets do it in another document.)

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 May 2007 12:41:01 +0200

> current, shorter, draft we have now.

Ditto. Let's not complicate the normative text with rationale.

     Brian
-- 
NEW: Preferred email for non-IBM matters: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Tue, 22 May 2007 16:58:52 -0400

>the end of time, even if the issues overlap 80%?

Having separate documents is a really good idea.... unlesss  you are 
willing to fight people that feel that introducing changes to v4 
protocols damages their status quo.

As a matter of fact, I have often been surprised of v6 docs 
referencing v4 docs as normative (eg., RFC 4443 referencing RFC1122). 
IMO, that's  a (politically) very bad idea.

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1