Subject: draft-ietf-ipv6-deprecate-rh0-01-candidate-01

From: Joe Abley <[email-masked]>
Date: Tue, 12 Jun 2007 23:57:28 -0700

Here's a revised candidate -01. As before, I have not submitted this  
to the i-d repository, but offer it here first instead in order to  
make sure my changes seem reasonable.

Substantive changes include:

  + removed section 3.1 ("Origination"), since hosts will originate  
any junk they want, and it's pointless to presume to dictate  
otherwise (paraphrasing Jinmei). I left in the comment about hosts  
not being required to support RH0 in the introduction, after the line  
"This document updates [RFC2460] and [RFC4294]".

  + section 3.2 becomes section 3, and has been re-worked to spell  
out the undefined RH type behaviour from 2460, and to be more  
specific about which addresses nodes need to check when deciding  
whether or not to look for RH0. I have not incorporated the more  
conservative OpenBSD/Mac OS X behaviour as a requirement, since it's  
not clear to me that such a requirement is reasonable for all nodes  
(e.g. for routers).

  + section 5 has been substantially reduced (and its subsections  
removed) along the lines suggested by Jinmei. I added a note about  
the side-effects of deprecation on benign uses of RH0, and included  
mention of the possibility of new, future, safe routing header types  
which might fill some of the resulting gap.

I have not corrected the alleged typos such as "recognized" vs.  
"recognised", since the latter is a valid example of how we spell  
things in my world :-)

Revised text attached. Comments welcome. Apologies for the delay in  
getting these edits done; I expect subsequent text wrangling to be  
turned around more rapidly.

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

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 13 Jun 2007 16:52:29 +0900 (JST)

> make sure my changes seem reasonable.
(snip)

	I'm very happy with the 01-candidate-01.  concise, straight to the
	point.

itojun

---

From: Thomas Narten <[email-masked]>
Date: Wed, 13 Jun 2007 04:53:50 -0700

On the whole, looks pretty good.

> Abstract

>    The functionality provided by IPv6's Type 0 Routing Header can be
>    exploited in order to achieve packet amplification for the purposes
>    of generating denial-of-service traffic.  This document updates the
>    IPv6 specification to deprecate the use of IPv6 Type 0 Routing
>    Headers, in the light of the severity of this security concern.

The "amplification" terminology seems imprecise/wrong. When I think of
amplification attacks, I think of one packet causing more packets to
be generated or one packet resulting in a bigger response. I.e., there
is amplification of the amount of data sent. In case at hand, packets
are not amplified, they are just routed in a sort of loop. Is there
more precise terminology that could be used? (Then again, maybe this
particular terminology is already widely used here.)

>    The functionality provided by IPv6's Type 0 Routing Header can be
>    exploited in order to achieve packet amplification for the purposes
>    of generating denial-of-service traffic.  This document updates the

Seems like a sentence or two describing the exploitation itself would
be good. Not a lot of detail, but more than just "it can be
exploited". (Later, I see that you include such text in the security
considerations section. I think it should be moved to (or included in)
the beginning of the document.

> 4.2.  Packet Filtering

>    Firewall policy intended to protect against packets containing RH0
>    should be constructed such that routing headers of other types (which
>    may well have legitimate and benign applications) are handled on
>    their own merits.  For example, discarding all packets with any type
>    of routing header simply as a reaction to the problems with RH0 is
>    inappropriate, and may hamper future functionality designed using
>    non-type 0 routing headers.  For example, Mobile IPv6 uses the type 2
>    Routing Header [RFC3775].

The next to last sentence is a bit weak. Dropping all packets with
routing headers will flat-out break MIPv6. If routers/firewalls start
doing that, that would be very bad. From a standards perspecive, we
should clearly flag that as bad/non compliant.

>    Where filtering capabilities do not facilitate matching specific
>    types of Routing Headers, filtering based on the presence of any
>    Routing Headers on IPv6 routers, without explicitly checking the
>    Routing Header type, is strongly discouraged.

Again, this is too weak, IMO. "strongly discouraged" is not the same
as "don't do that". It should be clear that from a standards
perspective that that sort of filtering is non-compliant.

> 8.1.  Normative References

>    [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,
>               April 2006.

Shouldn't this  reference be informative?

Thomas

---

From: "George V. Neville-Neil" <[email-masked]>
Date: Wed, 13 Jun 2007 21:50:08 +0800

I am happy with the revisions.

Best,
George

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Jun 2007 06:54:48 -0700

> particular terminology is already widely used here.)

How about if I say "traffic amplification over a remote path" instead  
of "packet amplification"?

> the beginning of the document.

Would a forward reference to the Security Considerations section be a  
reasonable compromise?

> should clearly flag that as bad/non compliant.

If I understand your point, you are happy with the meaning of this  
section but wish that it made its point more forcefully.

 From other comments on previous revisions of this document, people  
expressed concern over whether normative language had any place in  
descriptions of operational practice (as opposed to protocol  
implementation). As such it's not clear to me whether MUST NOTs in  
this section would have any teeth.

How about replacing "hamper" with something stronger ("defeat"?  
"break"?) If you have other suggestions for text, I would be happy to  
see them.

> perspective that that sort of filtering is non-compliant.

I wonder again about normative language being applied to operational  
practices, and would appreciate enlightenment.

How about adding a sentence which is a little more blunt, along the  
lines of "filtering routing headers indiscriminately, without regard  
to type, will seriously impair future extensions of the IPv6 protocol  
which make use of Routing Headers"? Other suggestions?

> Shouldn't this  reference be informative?

The document states that it update RFC4294 in section 1, so I  
presumed that reference needed to be normative.

Joe

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 Jun 2007 10:00:29 -0700

Joe,

> this section would have any teeth.

I agree with Thomas that it is important to state this very  
clearly.   How about something like this:

    Firewall policy intended to protect against packets containing RH0
    must be constructed such that routing headers of other types
    are not filtered by default.  Doing so will break other uses of
    the routing headers such as the Routing Header Type 2 used by  
Mobile IPv6 [RFC3775] and future
    functionality designed using other routing header types.

and something similar for the later text.

Comments?

Bob

> "break"?) If you have other suggestions for text, I would be happy  
> to see them.
>
> I wonder again about normative language being applied to  
> operational practices, and would appreciate enlightenment.
>
> lines of "filtering routing headers indiscriminately, without  
> regard to type, will seriously impair future extensions of the IPv6  
> protocol which make use of Routing Headers"? Other suggestions?
>

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 13 Jun 2007 18:09:26 +0100

Bob Hinden wrote:
[..]
> I agree with Thomas that it is important to state this very clearly.  
> How about something like this:
> 
>    the routing headers such as the Routing Header Type 2 used by Mobile
>    IPv6 [RFC3775] and future

When the above, or similar text, is included in the document I will
fully support it for advancement.

I have one teeny thing that I think would be worthwhile repeating in
that document: "Please enable uRPF where possible" as that actually
already takes care of the most of the problem as packets can't go where
they are not able to come from.

Additionally, one nit in section 7 if you didn't catch it yet:
"   This document also benefits from the contributions of IPv6 and V6OPS
   orking group participants,"

a "W" is missing there.

Thanks Joe, Pekka, George and the rest of the WG for drafting this up.

Greets,
 Jeroen

---

From: Thomas Narten <[email-masked]>
Date: Wed, 13 Jun 2007 10:42:21 -0700

Bob Hinden <[email-masked]> writes:

> clearly.

To be clear, if even a small fraction of firewalls get deployed that
just block all traffic with a RH, MIPv6 breaks and becomes
undeployable in practice. For EVERYONE!

MIPv6 can't work if (in practice), moving around results in stuff not
working with even only a low degree of frequency. Hence, this is a
hugely serious issue.

>     functionality designed using other routing header types.

Could be even stronger. How about:

     It must be understood that blocking all traffic with any RH
     (rather than restricting blockage only to type 0) has very
     serious implications for the deployment of future
     technology. Quite simply, if even a small percentage of deployed
     firewalls block other types of routing headers by default, it
     will become impossible to deploy technologies using a routing
     header. MIPv6 [RFCxxx] relies on a type 2 RH. If even a small
     fraction of firewalls block MIPv6 traffic, MIPv6 will become
     undeployable in practice.

     Consequently, firewall policy intended to protect against packets
     containing RH0 MUST NOT simply filter all traffic with a routing
     header; it must be possible to disable forwarding of type 0
     traffic without blocking other types of routing headers. In
     addition, the default configuration MUST be to permit forwarding
     of traffic using a RH other than 0.

Thomas

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 13 Jun 2007 20:53:59 +0300

> undeployable in practice. For EVERYONE!

The answer to the upcoming question must be obvious to many people here, 
but anyway not to me: Does blocking RH2 breaks Mobile Nodes in your 
network, or does it break both Mobile Nodes *AND* Correspondant Nodes?

In the later case, it might be worth mentioning that "blocking RH breaks 
connectivity toward external peers completely (or almost)". This looks 
more terrifying to me that "blocking RH prevents deployment of future 
technology". In fact, whether you and I like it or not (I hate it), 
firewalls are quite often blocking "future technology" on purpose.

In the poor real world of IT, there are some network administrator that 
are responsible for the security of their perimeter. There are seldom 
responsible for new technology not working out of the box. It's a 
truth, we'd rather adapt to, if we can.

My 2 eurocents,

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Bob Hinden <[email-masked]>
Date: Wed, 13 Jun 2007 11:17:50 -0700

Thomas,

>      of traffic using a RH other than 0.

Works for me.

Bob

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Jun 2007 14:24:10 -0700

> they are not able to come from.

Is this not implicit in the various references to RFC2827 and RFC3704?

Joe

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 13 Jun 2007 22:33:11 +0100

> Is this not implicit in the various references to RFC2827 and RFC3704?

Yes, but how many people actually implement it? :)
It is also why I noted that it might be worthwhile repeating it.

Clearly a lot of networks don't do uRPF. It is still possible to spoof
from a lot of networks (both IPv4 and IPv6). The most heard reason is
that they "can't" because the hardware/software of their routers/AP's
don't support it. In a lot of cases it can be enabled, but people simply
don't.

If a network does do uRPF most RH0 attacks are already resolved as then
the router can't send the packet back over the link as the source
address is incorrect. As such it is IMHO relevant to mention.

I am not requiring or anything near that, that it goes in btw, but I do
think it might be a good idea to put in the document just as a reminder
for people who don't read the whole chain of documents.

Greets,
 Jeroen

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Jun 2007 14:37:29 -0700

>      of traffic using a RH other than 0.

I'm slightly concerned that such advice flies in the face of  
conventional advice given to those constructing firewall policy. It  
is normal practice, I believe, for end-site firewall policy to be  
deployed based on denying everything by default, and only permitting  
those packets which are known to correspond to traffic which ought to  
be permitted. I believe it is generally considered to be good advice  
to block all "future technology" by default, and to permit it only  
once the implications of doing so are well-known.

Outside end-sites, in the core, dropping packets based on the  
presence of any type of routing header is clearly a bad idea.

If we want the advice in this section to be taken seriously, do we  
need to distinguish between firewall policy in end-sites and packet  
filters that might be added to core/ISP networks as a mitigation of  
the specific problems associated with RH0?

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 13 Jun 2007 14:39:20 -0700

> It is also why I noted that it might be worthwhile repeating it.

So, should we make the language wrapping the references to 2827 and  
3704 stronger, perhaps saying that operators SHOULD deploy ingress  
filtering as an appropriate reaction to the threats described in RH0?

Joe

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 13 Jun 2007 22:55:57 +0100

Joe Abley wrote:
> So, should we make the language wrapping the references to 2827 and 3704
> stronger, perhaps saying that operators SHOULD deploy ingress filtering
> as an appropriate reaction to the threats described in RH0?

IMHO yes. Unfortunately a MUST is too strong, thus a SHOULD would be
perfect. It might just help some operators configure their networks with
uRPF, as they will be looking at the RFC's that describe harmful things
which can happen to their networks, also RH0 has had quite some press
thus people are aware of it.

I don't know what the rest of the WG thinks about this though and this
is what in my opinion would be a good thing to have.

Greets,
 Jeroen

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 14 Jun 2007 11:40:19 +0900

At Wed, 13 Jun 2007 04:53:50 -0700,

> the beginning of the document.

To clarify the point: are you suggesting to add this to Abstract or to
Introduction?  I think it's too much for Abstract, but I agree it
would be worth adding to Introduction (in fact, having a mere copy of
Abstract in Introduction isn't really useful).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jun 2007 10:58:51 +0200

On 2007-06-13 23:37, Joe Abley wrote:
> conventional advice given to those constructing firewall policy. It is 
> normal practice, I believe, for end-site firewall policy to be deployed 
> based on denying everything by default, and only permitting those 
> packets which are known to correspond to traffic which ought to be 
> permitted. 

Mobile IPv6 ought to be permitted, surely.

> I believe it is generally considered to be good advice to 
> block all "future technology" by default, and to permit it only once the 
> implications of doing so are well-known.

Mobile IPv6 isn't future technology.

    Brian
> 
> Outside end-sites, in the core, dropping packets based on the presence 
> of any type of routing header is clearly a bad idea.
> 
> If we want the advice in this section to be taken seriously, do we need 
> to distinguish between firewall policy in end-sites and packet filters 
> that might be added to core/ISP networks as a mitigation of the specific 
> problems associated with RH0?
> 
> 
> Joe
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 14 Jun 2007 17:09:09 -0700

> once the implications of doing so are well-known.

Understood. So maybe we should just go ahead and deprecate all routing
headers now? Why bother complicating implementations, if in practice,
no one will be able to enable/use such features because there is no
way to get firewall configs updated?

> the specific problems associated with RH0?

We need to assume that other types of routing headers are "safe" to
use, and make sure than any usage actually is safe. If we can't do
that, we might as well just deprecate them all now.

Thomas

---

From: Joe Abley <[email-masked]>
Date: Thu, 14 Jun 2007 17:11:58 -0700

> way to get firewall configs updated?

I think you are missing my point.

Joe

---

From: Thomas Narten <[email-masked]>
Date: Thu, 14 Jun 2007 21:27:26 -0400

> I think you are missing my point.

I don't think so (though I may have been overly sarcastic in my
response). I understand that the default security policy/config is
"just say no".

But if we accept that, in this case, then I think the implication
really is we might as well toss out the routing header entirely.

If someone came up with some cool new technology/application, but
deploying it required people to change firewall filters (especially
those they do not have direct control over -- or do not understand how
to update), do you think the new application would ever get deployed?
Its just too hard in practice to make this happen.

It's analogous to the problem of "not deployable" if it doesn't work
through a NAT today.

Thomas

---

From: james woodyatt <[email-masked]>
Date: Thu, 14 Jun 2007 18:53:11 -0700

On Jun 14, 2007, at 18:27, Thomas Narten wrote:
>
> I understand that the default security policy/config is "just say no".
>
> [...]

We already did accept that as the Best Current Practice for  
residential IPv6 gateways, c.f. the discussion in the V6OPS working  
group over what eventually went on to become RFC 4864, and which led  
to the formation of the V6CPE Design Team mailing list where I am  
editing a draft that will elaborate on the recommendation for the  
default security policy/config in residential IPv6 gateways that it  
essentially should be "just say no."

I'm not sure I see a good argument for tossing out the routing header  
entirely.  At the moment, our draft recommends only blocking RH0.  It  
does not recommend blocking all routing headers.  Those participants  
with reasonable arguments for recommending that all routing headers  
be blocked should present them.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Joe Abley <[email-masked]>
Date: Thu, 14 Jun 2007 20:57:00 -0700

> response). I understand that the default security policy/config is

OK, good then. Sorry for mischaracterising your reply.

I think there is a difference between firewalls which:

(a) are applied between private networks and the Internet, which  
might reasonably be expected to have a default policy which says  
"deny everything" and to have exceptions to that rule carefully  
formulated according to known requirements;

(b) are applied in front of somewhat but not entirely public networks  
like wifi hotspots, hotels in order to block known troublesome  
traffic (common windows worm proliferation ports, tcp/25, ICMP, DNS,  
and all kinds of other bad ideas);

(c) are applied in networks which provide internet access as their  
primary business (some of which might be similar to (b) above);

(d) backbone routers, which in times of severe need might be  
configured to drop known-bad traffic (e.g. DDoS mitigation, prolific  
virus outbreaks, etc)

This is not an exhaustive taxonomy. It seems to me that what people  
think of most commonly when they read the word "firewall" is the  
meaning in (a) above, whereas we might reasonably concur that (a)'s  
policy is fine as it is (if they want their users to be able to take  
advantage of MIPv6, presumably they will modify their policy to  
accommodate it). It seems to me that the main places we're anxious  
that people don't get the wrong idea about RHn>0 is (b), (c), (d), etc.

My concern is fundamentally that if we give the appearance of being  
dictatorial greybeards living in ivory towers ("the Internet should  
be open! future technology must be accommodated! NAT is wrong!") then  
we run the risk that the entire document will be ignored by those we  
most hope to educate, who will instead consume soundbites and make  
bad decisions ("IPv6 IS INSECURE!" "HAVE YOU BLOCKED ROUTING HEADERS?  
IF NOT YOU MAY BE AT RISK!").

Perhaps this is a non-issue and I'm out of touch with reality.  
Certainly, I don't hear anybody else sharing my concern, regardless  
of how many times I try to explain it :-)

Joe

---

From: Pekka Savola <[email-masked]>
Date: Fri, 15 Jun 2007 08:16:11 +0300 (EEST)

> I think there is a difference between firewalls which:
...

I'm not sure if the document needs to say much at all about firewalls. 
draft-ietf-v6ops-security-overview-06.txt has already said a lot about 
this (now in RFC-ed queue) and there was significant IESG debate. 
RFC 4890 may also be an interesting precedent here.  Both are 
Informational documents.

But if this document said something, perhaps the best would be to 
recommend operators don't try to filter RH0 in any ACLs or firewalls.

(a) class of networks already de-facto filter it (all RH) so nothing 
is changed.  The rest shouldn't bother because 1) hosts will get 
updated, and 2) ingress filtering will block most of the abuse.

IMHO, it's pointless to try to block RH0 in any firewalls except in 
very well-managed networks.  The more configuration we recommend 
venders to build in or operators to deploy, the more likely it is that 
it breaks something especially given that most firewall/ACL 
implementations have restrictions on which RHs it can see.

-- 
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: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Jun 2007 08:45:28 +0200

On 2007-06-15 03:53, james woodyatt wrote:
> We already did accept that as the Best Current Practice for residential 
> IPv6 gateways, c.f. the discussion in the V6OPS working group over what 
> eventually went on to become RFC 4864, and which led to the formation of 
> the V6CPE Design Team mailing list where I am editing a draft that will 
> elaborate on the recommendation for the default security policy/config 
> in residential IPv6 gateways that it essentially should be "just say no."
> 
> with reasonable arguments for recommending that all routing headers be 
> blocked should present them.

As I already noted, it makes no sense to block Mobile IPv6 by default,
so it makes no sense to block RH>0 by default. But of course, product
managers don't always apply common sense. There is little the IETF
can do about that except publish guidance, as in the forthcoming CPE
draft.

    Brian

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 15 Jun 2007 08:51:18 +0200

> way to get firewall configs updated?

I think the point is, we should stngly emphasis that blocking all RH
kills existing technology (e.g. Mobile IPv6 Correspondant Nodes) than
future technologies. Or better yet, that it kills both.

Two reasons why blocking RH are bound to convince more people than one.
And it is widely known that "future technology" frightens some firewall
operators (whether that's justified or not is not relevant in this case).

> use, and make sure than any usage actually is safe.

Yes.

-- 
Rémi

---

From: "TJ" <[email-masked]>
Date: Fri, 15 Jun 2007 08:20:24 -0400

>-----Original Message-----
>From: james woodyatt [mailto:[email-masked]]
>Sent: Thursday, June 14, 2007 21:53
>To: IETF IPv6 Mailing List
>Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01
>

For clarification - let's say we have a device that can filter based on the
presence of a routing header, but cannot be more granular and filter based
on what type of routing header it is.
	Is the recommendation be to "fail closed" - block all RHs, including
Type2, thus breaking Route Optimization?
	Or should we "fail open" - permit them, including potentially
malicious Type0s?

I know that to date my recommendation has been to fail closed, block them
all if you can't be more specific ... 

/TJ
(Yes - I agree, the "right" answer is to upgrade to something that can be
more granular ... but work with me for a moment :) )

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 15 Jun 2007 13:26:58 +0100

TJ wrote:
[..]
> on what type of routing header it is.

Then that device's IPv6 implementation is inherently broken. This, as
with the current standard (before the upcoming deprecation) it should
always process Type 0 headers.

If it is able to process them, then it should not be a difficult feat to
also have it filter it or disable that processing.

Greets,
 Jeroen

---

From: Guillaume Valadon / ギョーム バラドン<[email-masked]>
Date: Fri, 15 Jun 2007 14:28:40 +0200

> Type2, thus breaking Route Optimization?

If you block all RHs, you break Mobile IPv6 and not only the Route  
Optimization.
The RH2 is used to *carry* the Binding Acknowledgment from the home  
agent to the mobile node.

Regarding MIPv6, it is really big issue to block all RH. It seems  
that some operators are already applying the block all RH policy.

Guillaume

--
Guillaume Valadon / ギョーム バラドン
[email-masked]

---

From: "TJ" <[email-masked]>
Date: Fri, 15 Jun 2007 08:35:52 -0400

Excellent point, thank you.

It still begs the question however - 
If you need to choose either accepting or blocking all routing headers, which do you recommend to your (potentially very paranoid, and that isn't necessarily bad) clients?

(Yes, still with an emphasis on "the right approach" of doing more granular filtering ... but this isn't just a hypothetical situation :))

/TJ

>From: Guillaume Valadon / ギョーム バラドン
>[mailto:[email-masked]]
>Sent: Friday, June 15, 2007 08:29
>To: [email-masked]
>Cc: 'IETF IPv6 Mailing List'
>> 	Is the recommendation be to "fail closed" - block all RHs,
>
>Regarding MIPv6, it is really big issue to block all RH. It seems that
>some operators are already applying the block all RH policy.
>
>Guillaume
>
>--

---

From: Guillaume Valadon / ギョーム バラドン<[email-masked]>
Date: Fri, 15 Jun 2007 14:54:09 +0200

> If you need to choose either accepting or blocking all routing  
> headers, which do you recommend to your (potentially very paranoid,  
> and that isn't necessarily bad) clients?

RH2 are harmless and are only supported by Mobile IPv6 aware nodes  
(Mobile Nodes, and Correspondent Nodes supporting the return  
routability procedure).
I think that it is not necessary to filter them.

Guillaume

---

From: Thomas Narten <[email-masked]>
Date: Fri, 15 Jun 2007 10:15:51 -0400

> of "packet amplification"?

wfm.

> Would a forward reference to the Security Considerations section be a  

IMO, no. The document should flow smoothly to the reader. This belongs
up front, not at the end. IMO.

> presumed that reference needed to be normative.

Ah, right. OK.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 15 Jun 2007 10:16:56 -0400

> network, or does it break both Mobile Nodes *AND* Correspondant

It breaks mobile nodes. The HA sends traffic to the MN using a type 2
RH header. That is, instead of "tunneling", e.g., via IP in IP, the HA
forwards packets to the MN at its temporary Care-of-Address via a
type 2 RH header. The HA can't communicate with the MN if such traffic
is filtered.

Hence, if such filtering becomes even occasionaly common on the open
Internet, MIPv6 will become unusable/undeployable in practice.

Thomas

---

From: "Nour, Nina N." <[email-masked]>
Date: Fri, 15 Jun 2007 10:18:52 -0400

I have been trying to unsubscribe from this mailing list
unsuccessfully. Could someone help!

Nina Nour
[email-masked]

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Friday, June 15, 2007 10:17 AM
To: Rémi Denis-Courmont
Cc: [email-masked]
Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01 

=?windows-1252?q?R=E9mi_Denis-Courmont?= <[email-masked]>
writes:

> Le mercredi 13 juin 2007, Thomas Narten a Ã©crit :

Thomas

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 15 Jun 2007 17:42:06 +0100

[excuses for the intermission, but clearly it is time to state it again]

> unsuccessfully. Could someone help!

For clarity, mainly for people who don't ask and do want to get out:

As an aside: [email-masked] can be reached for these and similarily
for other IETF mailinglists: <wg>[email-masked].

I'll unsub you in a few moments.

(first have to nullroute the ipv6 address of www1 as something is again
dropping large packets towards me :( )

Greets,
 Jeroen

---

From: james woodyatt <[email-masked]>
Date: Fri, 15 Jun 2007 11:01:12 -0700

> 	Or should we "fail open" - permit them, including potentially

For my part, I'd rather not try to answer this question.  If pressed,  
I would say that such a device ought not try to be a filter at all.   
If that's not possible, then the device should permit all routing  
headers.  More damage will be done by blocking all routing headers  
than by passing routing headers with type zero through obsolescent  
middleboxes.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 15 Jun 2007 15:36:34 -0400

> Internet, MIPv6 will become unusable/undeployable in practice.

If you mean ISPs, I agree. If you mean home nets, it doesn't matter so much. The home user can simply be informed that mobile IPv6 won't work with the default configuration (assuming default blocks all RH > 0 too). And he can be told to "check this box if you want to support mobile IP in your home network."

Bert

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 15 Jun 2007 22:40:51 +0300

Le vendredi 15 juin 2007, Manfredi, Albert E a écrit :
> > Hence, if such filtering becomes even occasionaly common on the
> > open Internet, MIPv6 will become unusable/undeployable in practice.
>
> If you mean ISPs, I agree. If you mean home nets, it doesn't matter
> so much. The home user can simply be informed that mobile IPv6 won't
> work with the default configuration (assuming default blocks all RH >
> 0 too). And he can be told to "check this box if you want to support
> mobile IP in your home network."

Well no. The whole point is that if someone else does Mobile IPv6 
*OUTSIDE* your network, but happens to be willing to contact you, it 
breaks. Besides, it is well known that most users (and probably even 
admins) are not capable of making any wise choice on such a technical 
question.

So MIP6 *will* become undeployable if RH is blocked in even a small 
portion of the Internet.

---

From: "Christopher Morrow" <[email-masked]>
Date: Sat, 16 Jun 2007 02:23:34 -0400

> that, we might as well just deprecate them all now.

I'd actually be a fan of not deprecating the headers in question, but
permitting implementations to either ignore+forward, drop, use them.
So, in the case at hand an operator could decide that 'source routing
is ok' on their network and follow the wishes of the packet creator.
Another may well decide that honoring source-route options (RH0) is
not something they feel comfortable doing, but don't want to discard
the packet out of hand. A third may decide that all source-routing
(RH0) is 'evil' and must be dropped immediately.

This lets the technology be used where appropriate and doesn't do undo
harm because folks can choose to, as adults, handle the traffic
properly for their network/systems.

Is this too heretical to be considered?

-Chris

---

From: "Christopher Morrow" <[email-masked]>
Date: Sat, 16 Jun 2007 02:38:07 -0400

> than by passing routing headers with type zero through obsolescent

please keep in mind that often there is a cost associated with
handling the RH headers, they must be processed by something 'smart'
in the 'middlebox' (today atleast). Having an option to simply ignore
RH headers (all extension headers maybe?) instead of processing them
seems very nice indeed. Simply throwing away traffic willy-nilly seems
to be a problem, to me atleast.

-Chris

---

From: Joe Abley <[email-masked]>
Date: Sat, 16 Jun 2007 07:21:38 -0400

> is ok' on their network and follow the wishes of the packet creator.

The approach that we seem to have consensus to follow is that RH0 has  
practical risks which are too great and hence should be deprecated,  
but that this does not preclude some form of "off-by-default" source  
routing functionality to be defined in future. This new source- 
routing feature presumably would lack some of the features that make  
RH0 particularly potent/dangerous, and be implemented as some other- 
numbered routing header so it can be distinguished from RH0 by  
firewalls.

Some concern has been voiced that if we don't deprecate RH0, and just  
require processing by hosts and routers to be disabled by default,  
some malware or other will just turn it back on.

The following text at the end of section 5 of -01-c-01 refers to this  
approach:

    The severity of the threat is considered to be sufficient to warrant
    deprecation of RH0 entirely.  This has the unfortunate side-effect
    that benign use cases for RH0 are eliminated along with the  
potential
    security hazards; such applications may be facilitated in the future
    by new routing header specifications which do not suffer from RH0's
    problems.

> properly for their network/systems.

The approach above does not preclude that entirely; it's just more  
conservative.

Joe

---

From: Ole Troan <[email-masked]>
Date: Sat, 16 Jun 2007 16:45:45 +0100

> Internet, MIPv6 will become unusable/undeployable in practice.

we could fix MIPv6. i.e use IP in IP instead of RH2.

/ot

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Sat, 16 Jun 2007 18:57:16 +0300

Le samedi 16 juin 2007, Ole Troan a écrit :
> >> > To be clear, if even a small fraction of firewalls get deployed
> >> > that just block all traffic with a RH, MIPv6 breaks and becomes
> >> The answer to the upcoming question must be obvious to many people
> >> here, but anyway not to me: Does blocking RH2 breaks Mobile Nodes
> >> in your network, or does it break both Mobile Nodes *AND*
> >> Correspondant Nodes?
> >
> > It breaks mobile nodes. The HA sends traffic to the MN using a type
> > 2 RH header. That is, instead of "tunneling", e.g., via IP in IP,
> > the HA forwards packets to the MN at its temporary Care-of-Address
> > via a type 2 RH header. The HA can't communicate with the MN if
> > such traffic is filtered.
> >

At the end of the day, it would only add more overhead while decreasing 
the "expresiveness" of the mobility header (which is a "vulgar" IP 
header instead of specifically a mobility header).

And it would annoy firewall vendors as much as RH does, since they would 
still have to parse skip through inner IP header in order to reach the 
transport header.

Therefore, I think it is totally pointless, and it definitely is NOT 
a "fix".

---

From: Geoff Huston <[email-masked]>
Date: Mon, 18 Jun 2007 09:51:17 +1000

> Is this too heretical to be considered?

No! For a _standards_ body it's an entirely appropriate way to consider 
this technology, imho. Source-based routing technology has been around 
for about the same period of time as circuits (indeed circuits could be 
considered a form of source-based routing). IN certain contects 
source-based routing is useful, and in networks where there there is no 
routing function it may even be essential.

Yes, in the context of the Internet, we've seen that enabling source 
routing can cause some unpleasant side effects, and the responsible 
advice is that this technology knob should be turned off in these forms 
of deployment, and even go so far as to say such capability should be 
turned off by default.

But trying to erase the capability itself from the protocol standard 
smacks to me of overreaction, and in terms of the security and safety of 
the internet is another classic example of security pantomime!

[But, like Chris, in thinking these evil thoughts I'm now a heretic. 
Quick, fetch the stake, the rope and some fire! :-)]

   Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Jun 2007 08:52:38 +0200

Geoff and Chris,

> Quick, fetch the stake, the rope and some fire! :-)]

My first thought some weeks ago was to add rules to RH0 to eliminate
at least most of the problem, but I've become convinced that the
cleanest way to do that is to abolish RH0 and design a new RHn
which is intrinsically safer. As far as implementers and operators
are concerned that should be better, since there won't be ambiguity
about whether code has been updated to support RH0bis or not, since
we have no provision for versioning routing headers.

That way, we could avoid the auto da fé.

    Brian