Re: I-D ACTION:draft-jabley-ipv6-rh0-is-evil-00.txt

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

At Thu, 10 May 2007 17:09:31 -0400,
Joe Abley <[e-mail]> wrote:

> >>> "Compliant IPv6 hosts and routers MUST NOT process RH0 in packets
> >>>   addressed to them. Those packets MUST be dropped without further
> >>>   processing. In particular, the value of the Segments Left field
> >>>   MUST not be considered."
> >>
> >> This is much clearer and easier to implement.
> >
> > Though I am not a router vendor I am the person who has to handle this
> > on FreeBSD.  I like the above sentence as well.
> 
> The above sentences far more closely resemble what I meant to write,  
> compared to the text that actually appeared in the draft :-)

"packets addressed to them" still sounds a little ambiguous to me; it
could be interpreted as including intermediate hops specified in the
routing header or as only meaning the final destination.  The intent
should obviously be the former, so I'd rephrase it further:

 "Compliant IPv6 hosts and routers MUST NOT process RH0 in packets
  whose destination address in the IPv6 header is an address
  assigned to them."

BTW, I agree we shouldn't require routers to inspect every IPv6 packet
and drop it when it contains RH0 (even if whose IPv6 dst is NOT a
routers' address).  It should leave to FWs, not ordinary routers.

> I note that KAME's response to this is similar, but it's not clear to  
> me that it's precisely identical: a patched KAME implementation  
> treats the type 0 routing header as an unknown routing header  
> (according to <http://www.kame.net/newsletter/20070502/>). This  
> suggests to me that a patched KAME implementation will process a  
> datagram containing RH0, but that RH0 header(s) in the datagram will  
> not be acted upon. I would welcome corrections to my feeble  
> assumptions in this area (I have done no tests, nor read any source  
> code to confirm).

I guess you're talking about whether the node returns an ICMPv6 error
when receiving a packet that contains an RH0 whose IPv6 dst is one of
its own addresses.  KAME's implementation treats it as an "unknown
type" of routing header as you guessed and it returns an ICMPv6
parameter problem error as a result.  This is an intentional behavior:

http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/route6.c.diff?r1=1.62;r2=1.63

(Which type of error is appropriate is a different question)

> A packet containing RH0 presumably is intended not to be processed on  
> the system identified by the destination address field; if it was, no  
> RH0 would be present. This suggests to me that "MUST drop" is the  
> right thing, rather than "process as if RH0 was not there"; in  
> addition, if we assume that today any packet with RH0 is likely to be  
> malicious, any processing of a packet containing RH0 which has the  
> potential to result in backscatter seems like it should properly be  
> avoided.

I believe we should rather return an ICMPv6 error.  Even if we decide
to deprecate type0 RH, there will be many non-updated systems for a
certain period of time.  Since there is at least one know popular (but
non-attacking) usage of RH0, i.e., probing 'return path' by
traceroute, we'll still see non-attacking packets containing RH0.  It
would be better to notice such innocent but not just well-informed
users explicitly, rather than simply dropping the packet.  Regarding
'backscatter', if you mean a DoS for the ICMPv6 recipient with a
source-spoofed packets containing RH0, I don't think it's a big
concern in this context; that's not different from other type of
backscatter' attacks with a forged source address, so simply
prohibiting this case wouldn't help much; and I believe returning an
error is actually helpful as I stated above.  Also, ICMPv6 errors are
rate limited, so the backscatter effect is limited accordingly.

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

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