Hi Brian, Please see response inline. > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: Monday, January 03, 2011 4:25 PM > To: Thomas Narten > Cc: Suresh Krishnan; ipv6@ietf.org > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt > > > 2) The routing header is essentially deprecated, and we > probably won't > > define any more. > > The proposal for RH4, i.e. draft-ietf-6man-rpl-routing-header, > is active. > > However, isn't the real question whether we want to change > the implied intention that adding a new extension header > should be hard? Section 4 of RFC 2460 makes this intention > pretty clear: > unknown extension headers should lead to packet discard and > ICMP Parameter Problem, so this is intended for consenting > adults only. Skipping over unknown extension headers was > definitely not intended to work. > > The basic motivation for the present draft is clear: > > > However, > > some intermediate nodes such as firewalls, may need to > look at the > > transport layer header fields in order to make a > decision to allow or > > deny the packet. > > That is, help middleboxes to violate e2e transparency and, > furthermore, allow unknown headers to cross those > middleboxes. If I was a paranoid security person, I would > definitely not be happy with this. On the contrary - if I saw > an unknown IP header in a packet, I would want to discard it. > A legacy firewall wouldn't recognize the Next Header value > for draft-ietf-6man-exthdr, so would discard the packet. If > my firewall had been updated, and saw a > draft-ietf-6man-exthdr, header, it would need to look at the > embedded "Specific Type" and then decide whether to discard > it. Just a bit more deep packet inspection. > > So the one thing this proposal will *not* do is allow new > extension headers to cross the Internet transparently. All it > might do is cause the firewalls to dig one layer deeper > before discarding the packet.
Correct. But the reason that this part got added to the draft was that firewall vendors wanted to differentiate between unknown extension headers and unknown transport protocols and possibly treat them in a different way. E.g. Section 3.2.2 of http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security-16 Specifies one such need. Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
