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

From: "Murphy, Sandra" <[email-masked]>
Date: Mon, 23 Sep 2013 22:50:47 +0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

Draft draft-ietf-6man-ext-transmit-03 describes some of the problems of
deployment of new IPv6 extension header types.  It updates RFC 2460 and
RFC 2780 to clarify how extension headers, particularly unrecognized
extension headers, should be treated by intermediate nodes.  It also
creates a new IANA registry for extension headers.

The security considerations section discusses mandated behavior for
firewalls in particular, but without explaining the security
implications of that mandated behavior.  The section also mentions the
possibility of exercising previously unused code paths and slow
deployment.  Section 1 and 2.1 do a better job of describing the
potential safety problem of accepting unknown extenstion header types
and the connectivity problem of dropping them.

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.

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".  Sometimes
"standardized" and "experimental" seem to be mutually exclusive.
Sometimes "experimental" seems to be one of the set of "standardized'
extensions.

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.

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

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

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

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.

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.

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.

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.

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.

In Section 3

   will need to take account of them. 

I think you mean "take them into account".

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Sep 2013 17:21:30 +1200

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

> implications of that mandated behavior.  

A new paragraph has been added.

...

> referring to those sorts of discussions.

OK

> 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

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

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

Yes, those ideas are squeezed into too few words.
> 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

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.

> 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

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.

> covers most of what is needed, but not all.  It would be easiest to just

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

> Version 6 (IPv6) Parameters registry.

Yes, they don't seem to belong here.

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

> traversed, but how unrecognzied headers are treated.

Correct.

> which both seem to allow discarding without an explicit configuration

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

> I think you mean "take them into account".

OK