Re: I-D Action:draft-ietf-6man-exthdr-01.txt

[Brian E Carpenter <[e-mail]>]

> 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.

Regards
   Brian