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

["George V. Neville-Neil" <[e-mail]>]

At Fri, 11 May 2007 11:16:49 +0900,
jinmei wrote:
> "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.
> 

I agree with what Jinmei is saying here and this is how the HEAD of
FreeBSD works currently, while it is only STABLE (5 and 6) that have
the sysctl.  If the final decision is to go this way then I can
backport a patch to 5 and 6 so that all FreeBSD's work this way.  As
I've said before I am waiting for a decision before I go patching the
code again.

Best,
George

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