Re: [secdir] SecDir review of draft-ietf-6man-ext-transmit-03

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

Sandy,

Thanks again for the extensive review. We have a new version out:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-ext-transmit

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-ext-transmit-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ext-transmit-04

Now some direct responses to your review:

On 24/09/2013 10:50, Murphy, Sandra wrote:
...

> The security considerations section discusses mandated behavior for
> firewalls in particular, but without explaining the security
> implications of that mandated behavior.  

A new paragraph has been added.

...

> 
> RFC 4727 security considerations section speaks of the security
> concerns of experimental values that would apply to unrecognized
> extension headers as well.  RFC6564 mentions the potential for a
> covert channel through forwarded unrecognized extension headers.  The
> security considerations section here would be improved by using or
> referring to those sorts of discussions.

OK

> 
> Aside from the security considerations section, I puzzled over many
> parts of this document.  I am not an IPv6 implementers (or of anything
> else), but I believe that some of the language would be ambiguous in
> implementing this draft.
> 
> standardized vs standard vs experimental
> ----------------------------------------
> 
> The draft text says "standardized" in many places where it appears it
> means "published in an IETF specification", and in other places where it
> appears it means "an extension header defined as a standard".  

I think that comes to the same thing. Some extension headers are hidden
in broader specs, others have stand-alone RFCs.

> Sometimes
> "standardized" and "experimental" seem to be mutually exclusive.
> Sometimes "experimental" seems to be one of the set of "standardized'
> extensions.

That, unfortunately, is reality. RFC5201 is an Experimental RFC that defines
an extension header. RFC4727 is a Proposed Standard RFC that defines values
for experimental use. RFC3692 is a BCP that does the same (and, I think, makes
the assignment for RFC5201 illegal, if you're picky).

> That language should be cleared up.
> 
> I read this presuming that "standard/standardized" and "experimental"
> mean "defined in an IETF Standards Track RFC" and "defined in an IETF
> Experimental RFC".  That should be clearer.

We've defined and tried to clarify the terminology, but the confusion is intrinsic
to the existing RFCs. We've attempted to be consistent, at least.

> "by default" and "configuration" and "policy"
> --------------------------------------------
> 
> Section 2.1 says:
> 
> I found the text concerning configuration of policy to discard unrecognize
> extensions and default behavior to be unclear:
> 
> The section starts with:
> 
>                                                        Exceptionally, if
>    this node is designed to examine extension headers for any reason,
>    such as firewalling, it MUST recognise and deal appropriately with
>    all standardised IPv6 extension header types 
> 
> and then
> 
>    RFC 2460 requires destination hosts to discard packets containing
>    unrecognised extension headers.  However, intermediate forwarding
>    nodes SHOULD NOT do this by default,
> 
> and then
> 
>    Experimental IPv6 extension headers, including types 253 and 254
>    defined by [RFC3692] and [RFC4727], SHOULD be treated in the same way
>    as standardised extension headers, but they MAY be dropped by
>    default.
> 
> The text "SHOULD NOT do this by default" and "MAY be dropped by
> default" sound inconsistent to me.

Yes, those ideas are squeezed into too few words.
> 
> 
> The text goes on to say:
> 
>    Forwarding nodes MUST be configurable to allow packets containing
>    unrecognised extension headers, but such packets MAY be dropped by
>    default.
> 
> The text "SHOULD NOT do this by default" and "MAY be dropped by
> default" sound inconsistent to me.
> 
> I'm not clear of the intent.  

What we are trying to do is reconcile the IPv6 architecture that *requires"
all forwarding nodes to allow all extension headers with the firewall role
that requires firewalls to drop suspect packets. We've tuned the language.
There is a logical cascade here:

All nodes MUST recognise all valid extension headers
  Firewalls MUST NOT discard extension headers without good reason
  (expressed as SHOULD NOT discard valid headers by default)
     Except that firewalls MAY discard experimental/unrecognised headers by default.


> The first paragraph above, I believe, is
> arguing against having a hard coded response to unrecognized extension
> headers.  The later text mandating configurability is intended, I
> believe, to force/allow the operator to make a deliberate choice.  But
> then allowing the configuration to have a default that would drop
> unrecognized extension headers seems to me to return to the situation
> the first paragraph warns against.

That's not intended, but we're ttrying to be realistic about what firewall
vendors are likely to set as defaults.  We don't think they would allow
experimental values through by default, whatever we wrote.

> 
> IANA considerations section
> ---------------------------
> 
>    IANA is requested to clearly mark in the Assigned Internet Protocol  
>    Numbers registry those values which are also IPv6 Extension Header
>    types defined by an IETF action, for example by adding an extra
>    column to indicate this.
> 
> I believe "an IETF action" is unclear.  By RFC5237, these fields in the
> current registry are presently assigned by "IESG Approval or Standards
> Action".  

IANA didn't query this, but you are right. We didn't put "Standards Action"
because of experimental values. We need to put "Standards Action or
IESG Approval" to match RFC5226.

> I don't know that you want IESG Approval (which requires no
> RFC) for new extension types.  If I'm right that you expect standard
> extension headers to be defined in Standrads Track RFCs and experimental
> extension headers to be defined in Experimental RFCs, I believe that you
> want "Standards Action or IETF Review".  But I'm not an expert in IANA
> registries, you probably should get another opinion.
> 
>    Additionally, IANA is requested to replace the existing empty IPv6
>    Next Header Types registry by an IPv6 Extension Header Types
>    registry.
> 
> Given that the new registry has a new name, there is no need to replace
> the existing registry with the renamed registry.  True, it is empty
> except for a reference to the protocol numbers registry, but there are
> references in documentation etc. to the Next Header Types registry that
> would become dangling references.  Might as well leave it.

Good catch, but I think leaving it empty is also misleading. We have now
asked IANA to insert a pointer to redirect the dangling reference.

> 
> Section 4.2 of RFC5226 has an explicit template for "What to Put in
> Documents That Create a Registry".  The information in this section
> covers most of what is needed, but not all.  It would be easiest to just
> follow the template.

I'll check, but I think that following IANA's comments we have
covered everthinng now.

> 
> Section 2.1 says
> 
>                                                  Packets containing
>    standardised and undeprecated Routing Headers SHOULD be forwarded by
>    default.  At the time of writing, these include Type 2 [RFC6275],
>    Type 3 [RFC6554],
> 
> I am not certain what the new extension header IANA registry should
> say in this case.  The protocol numbers registry lists only the type
> 43, with routing types in a subregistry of the Internet Protocol
> Version 6 (IPv6) Parameters registry.

Yes, they don't seem to belong here.

> 
> The IPv6 parameters registry also shows that some of the registered
> options for Destination Options and Hop-by-Hop Options are Standards
> Track and some are Experimental, so I'm not sure what the registry
> entries should say for those extension headers.  That's particularly
> important given the encouragement to use these Destination Options in
> lieu of creating new extension headers.  Not that it looks like anyone
> is paying any attention to that advice.

The option headers themselves are standards track, being built into RFC2460.
We really don't want to dive into individual options in this document.
Admittedly, firewall developers may feel they have to do so, but we can't
legislate everything.

> 
> Quibbles
> -------
> 
> Section 1 says:
> 
>              This document focuses on clarifying how the header chain
>    should be traversed in the current IPv6 architecture.
> 
> I don't believe that this document changes how the header chain is
> traversed, but how unrecognzied headers are treated.

Correct.

> 
> 
> In section 3 Security Considerations
> 
>                                      In particular, packets containing
>    standard extension headers are only to be discarded as a result of a
>    configurable policy.
> 
> This disagrees with Section 2.1, which says that 
> 
>                                             The default configuration
>    SHOULD allow all standardised extension headers.
> 
> 
> and
> 
>    Forwarding nodes MUST be configurable to allow packets containing
>    unrecognised extension headers, but such packets MAY be dropped by
>    default.
> 
> which both seem to allow discarding without an explicit configuration
> to discard.

For headers unknown to the firewall, yes. We don't seriously expect anything
else as a factory default.

> 
> In Section 3
> 
>    will need to take account of them. 
> 
> I think you mean "take them into account".

OK

> 
> --Sandy
> 
> Based on checking RFC4727, RFC3692, RFC6564, RFC2460, RFC5237, RFC2780, RFC5226, IANA registry for Assigned Internet Protocol Numbers, RFC6275, RFC6554, and IANA registry for Destination Options and Hop-by-Hop Options.  So I could easily be confused.
>