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

[[e-mail] (Jun-ichiro itojun Hagino 2.0)]

	sorry, with flood of emails and phonecalls i really cannot keep up.
	it could be duplicate of comments that were made by various people.

	i'm calm as stillwater now, so it is PG13 rating :-)

> > The above sentences far more closely resemble what I meant to write,  
> > compared to the text that actually appeared in the draft :-)
> > 
> > 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).
> > 
> > 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.

	there were several points joe (jabley) made during our private
	conversation:
	- should we drop a packet silently - without returning ICMPv6 parameter
	  problem (jabley's suggestion), or should we return ICMPv6 so that
	  innocent user of rthdr0 would be notified (kame's latest tree).
	  since there's no amplification and ICMPv6 errors are rate-limited,
	  returning ICMPv6 parameter problem would not harm that much (even
	  under DDoS condition - depending on how your implementation do
	  rate-limit).
	- should we filter more drastically like openbsd does - see May 8 entry
	  at http://opengrok.creo.hu/openbsd/history/src/sys/netinet6/?
	  or it is ok to be conservative like kame tree?
	- packet filters MUST have filtering language/syntax/whatever that
	  supports rthdr0.  openbsd guys are working on it - PF syntax will be
	  annotated with new rule.  see May 8 entry by mcbride@openbsd at
	  http://opengrok.creo.hu/openbsd/history/src/sys/net/.  more to come.
	- # of permitted routing headers has to be less than 2 (no more than 1).
	  there is no need for the source to transmit a packet with multiple
	  routing headers, as they can put a lot of routing header type X.
	- should we mention/suggest filtering at the edge? (ISP customer edge
	  and/or ISP peering edge) 
	  yes, it sounds hairy, but it was done in practice with IPv4 - IPv4
	  packet with IP(v4) option were filtered at US-JP border, so we could
	  not enjoy mobile-ip4-ish "home address" by first 2 revision (or so)
	  of Teraoka-san's VIP, Virtual Internet Protocol.
	  customer edge filtering would be performed with consent of customers.
	  but it comes with no cost: (1) operators MUST run SNMP/whatever on
	  the edge routers (both edges) to watch rthdr0 traffic anyways
	  (2) packets with routing header go into slow path anyway.
	  (we need SNMP mib extension?  yeah, that would be nice)
	- there are two stopgap measure: (1) max hoplimit =  255, (2) packets
	  with routing headergo nito slow path so the attack using rthdr0
	  wouldn't fill up 10G link.
	  about point (2), IIJ guys are making quantitative analysis on our
	  routers, juniper - sorry cisco guys:-) - and i bcc'ed it to them
	  so you might hear from them.
 
> The Kame folks can comment on the current state of their change, they
> made a couple of them.  In FreeBSD 6 an 5 (the stable branches) we
> have a sysctl to turn processing on and off.  In 7 (aka HEAD or
> CURRENT) we treat the RH0 as unknown.  Code diffs can be seen here:

	as i repeatedly mentioned, there's NO NEED AT ALL for such sysctl.
	there are ZERO RFCs that use rthdr0, thanks to efforts in MIP6
	arena (if MIP6 were to use rthdr0 for its source-routing, MIP6 would
	have been dead together with rthdr0).  if it were to be turned on,
	it would be just like giving atomic bomb to script kiddies.
	so please, remove that sysctl knob, at once.  Apple MacOS X guys got it
	right.  no wonder, i gave serious IPv6 tutorial in Apple HQ!
	i won't hack on BSDs that do not randomize PIDs. (i would need to do
	something about Apple MacOS X, yeah)

itojun2.0
Hannibal Lecter in calm mode

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