Subject: Re: I-D Action: draft-gont-6man-ipv6-universal-extension-header-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 May 2014 15:57:34 +1200

Hi,

I've finally understood what's been bothering me about this draft.
Actually, two things:

1. If a node (regardless of whether it's the destination host,
or an intermediate node such as a firewall) has a policy
of discarding packets with an unknown extension header
or an unknown transport protocol, it *doesn't matter* that
it can't distinguish them. The packet is discarded anyway.

Comment on that: In either case, this discard by a host is
consistent with RFC2460 (even as updated by RFC7045). In either
case, it's what we would expect a firewall to do if it has the
usual sort of paranoid policy, and that again is consistent
with RFC7045.

2. Given that argument, I think this draft should consider a
4th possible solution: Do Nothing. I think it's a valid option.

Nits: I don't see why this draft is tagged as Standards Track
and Updates 2460. It's an informational discussion.

Please change the title of the draft. At the moment it has
the same title as draft-gont-6man-rfc6564bis.

Regards
   Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 3 May 2014 12:12:12 -0700 (PDT)

> usual sort of paranoid policy, and that again is consistent

What motivated the draft was work on L2 middlebox functions that are 
not required to have the usual paranoid "default deny" policy in 
order to accomplish the intended purpose.  One was RA-Guard (see 
http://tools.ietf.org/html/rfc7113); the other was DHCPv6-Shield 
(http://tools.ietf.org/html/draft-ietf-opsec-dhcpv6-shield).  For 
those functions extension headers do not matter so long as the 
transport header can be found and inspected; the implementation 
advice for the RA-Guard and DHCPv6-Shield filters is to pass 
everything that can be positively identified as NOT being a 
forbidden RA message or DHCPv6 message.

That being said, if Brian is correct in his assertion that we should 
expect typical filtering middleboxes to agressively apply a "default 
deny" policy to unknown extension headers, then I'd have to agree 
with his conclusion that UEH (or a reserved range of next header 
values) would fail to achieve its intended purpose, which is to get 
them to skip over unknown extention headers.  On the other hand, I 
have gotten the impression from much of the discussion here and on 
v6ops that the usual aim of filtering middeboxes is to inspect 
transport headers, not specifically extension headers, and apply a 
"default deny" policy to transport protocols.  If the reason packets 
with extension headers get dropped is because the middleboxes lack 
the ability to find the transport header, then UEH (or a reserved 
range of next header values) could help.

> 2. Given that argument, I think this draft should consider a 4th 
> possible solution: Do Nothing. I think it's a valid option.

If "do nothing" means make no changes to the normative 
specifications in 7045 and 6564, then yes, that is a valid option.

That being said, there has in the past been an impression that RFC 
6564 guaranteed that it would be possible to skip over unknown 
extension headers -- see, e.g., the changes in the above-referenced 
DHCPv6-Shield draft in going from -01 to -02.

In order to clear up thus confusion, it would probably be useful to 
at least publish advice to implementors of middleboxes that any 
unrecognized Next Header value SHOULD be treated as if it indicates 
the presence of an unknown upper-layer header, because it is unsafe 
to treat it as if it were a new extension header with the TLV format 
defined by RFC 6564.  It would also be good to remind them that they 
MUST provide a configuration option to allow packets containing such 
values, as specified in RFC 7045, noting that a side-effect of 
allowing all unrecognized extension headers is that unrecognized 
transport protocols will be allowed also.

Mike Heard

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 May 2014 14:11:24 +1200

> range of next header values) could help.

The scenario would be, for example, a load balancer or QoS classifier
that needs to find the transport header in order to extract port numbers.
And yes, I think you're right, if we have to cope with the risk of both
unknown extension headers (presumed to conform to RFC 6564) *and*
unknown transport protcols (about which we can presume nothing).

> defined by RFC 6564.  

Right, because even if they use the complete IANA list of extension
headers, as specified in RFC 7045, it might be out of date.

> It would also be good to remind them that they 

Yes. Whatever we decide about this draft and UEH, I think an
implementation guide is sorely needed.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 07 May 2014 05:39:55 -0500

Hi, Brian,

On 05/01/2014 10:57 PM, Brian E Carpenter wrote:
> consistent with RFC2460 (even as updated by RFC7045). 

While I agree that it is consistent with RFC2460, that also implicitly
means that new EHs are not incrementally deployable. Not only because of
firewalls, but also because of the hosts themselves. (i.e., if I send
you my packets with my sihny new EH then, if you don't understand it,
you'd drop the packet).

(another way to see it would be to assume that the reason for which
RFC2460 says so is because it didn't define a uniform format for EHs in
the first place?)

> In either

I'm not sure I'd agree. in v4, some firewalls do not just filter packets
for the options they contain, but they do filter based on the {src ip,
dst ip, protocol, src port, dst port}

> 4th possible solution: Do Nothing. I think it's a valid option.

At the very least 6564 should probably be updated, or at least a
clarification issued. -- quite a few of us had assumed that as a result
of RFC6564, one could parse past unknown EH -- which is certainly not
possible.

> and Updates 2460. It's an informational discussion.

It's std track. And the "update" tag is because the UEH would be part of
the v6 specification (not to mention that otherwise it would be
virtually impossible for an IPv6 implementer to spot this document in
the first place).

> the same title as draft-gont-6man-rfc6564bis.

Will do.

Thanks!
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Wed, 07 May 2014 05:56:12 -0500

On 05/05/2014 09:11 PM, Brian E Carpenter wrote:
>> deny" policy to unknown extension headers, 

Well, policy is policy. Why I'd expect such policy to be widespread,
we're essentially ruling out the other possibility.

>> then I'd have to agree 
>> "default deny" policy to transport protocols.

Exactly. That's the comment that I made in my previous response ot Brian.

>> to treat it as if it were a new extension header with the TLV format 

Agreed.

> implementation guide is sorely needed.

Yes. That's kind f the stuff we had in mind as part of elaborating on
Section 5.3 -- should that option be the "winner".

We will expand and resubmit.

Thanks!

Best regards,

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 7 May 2014 09:27:14 -0700 (PDT)

On Wed, 7 May 2014, Fernando Gont wrote:
> you my packets with my [shiny] new EH then, if you don't understand it,
> you'd drop the packet).

I don't agree with that at all.  If intermediate systems were 
transparent to EHs, as envisioned by RC 2460, then it would be 
possible for consenting hosts to use them without updates to the 
intervening network.  That counts as incremental deployment to me.

> RFC2460 says so is because it didn't define a uniform format for EHs in

I'd be inclined to say RFC 2460 did not bother to define a uniform 
format for EHs because it there was no need: the Destination Options 
header already provided a way to provide optional information that a 
host could skip over (i.e., ignore).  Here is what it said:

   Note that there are two possible ways to encode optional destination
   information in an IPv6 packet: either as an option in the Destination
   Options header, or as a separate extension header.  The Fragment
   header and the Authentication header are examples of the latter
   approach.  Which approach can be used depends on what action is
   desired of a destination node that does not understand the optional
   information:

      o  If the desired action is for the destination node to discard
         the packet and, only if the packet's Destination Address is not
         a multicast address, send an ICMP Unrecognized Type message to
         the packet's Source Address, then the information may be
         encoded either as a separate header or as an option in the
         Destination Options header whose Option Type has the value 11
         in its highest-order two bits.  The choice may depend on such
         factors as which takes fewer octets, or which yields better
         alignment or more efficient parsing.

      o  If any other action is desired, the information must be encoded
         as an option in the Destination Options header whose Option
         Type has the value 00, 01, or 10 in its highest-order two bits,
         specifying the desired action (see section 4.2).

To me, it is obvious that anything UEH can do, a destination option 
can also do, provided that a destination option header is allowed to 
appear as many times as needed.  To see this, consider the proposed 
UEH format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |    Subtype    |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                                                               |
    .                                                               .
    .                   Subtype Specific Data                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If this were encoded as a destination option, it would look like this:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |    Subtype    | SubtypDataLen |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                   Subtype Specific Data                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

True, the subtype would need to have the two upper bits encoded to 
signal to the destination what to do if it does not understand the 
subtype.  But that is a feature, not a bug.  It also requires one 
extra byte for a possibly redundant subtype/option data length.  
One could imagine circumstances in which this would expand the 
header by up to eight bytes.  There is a possible cost in 
efficiency, but not in functionality.

> > In either case, it's what we would expect a firewall to do if it 
> > has the usual sort of paranoid policy, and that again is 
> > consistent with RFC7045.
> 

If firewalls treat IPv6 destination options as the do IPv4 options, 
then the desired effect is achieved by using the destination options 
header instead of the proposed UEH.

//cmh

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 May 2014 08:48:05 +1200

Fernando,

On 07/05/2014 22:39, Fernando Gont wrote:
...
>> and Updates 2460. It's an informational discussion.

(My error: it claims to update 6564 in fact, but my comment stands.)

> virtually impossible for an IPv6 implementer to spot this document in

Sorry, that seems completely wrong to me. draft-gont-6man-rfc6564bis
is clearly standards track and this one clearly isn't. To quote
the Abstract, it "analyzes a problem... and discusses a number of
possible solutions." That's Informational.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 07 May 2014 16:06:21 -0500

> possible solutions." That's Informational.

You're right about that. Explanation:

The original I-D was clearly std track, proposing a specific solution.
Since some folks suggested that there might be different possible paths
forward, we took a step back, and made this version comment on the
possible options, in the hopes that the next rev or some next rev would
stick to one of them.

I guess that we could just kept version -00, and publish a separate I-D
for the analysis of the possible options...

Thanks!

Cheers,