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

"Murphy, Sandra" <Sandra.Murphy@parsons.com> Mon, 23 September 2013 22:51 UTC

Return-Path: <prvs=297886a515=sandra.murphy@parsons.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D9621F9C4A; Mon, 23 Sep 2013 15:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3khfszIcAOmN; Mon, 23 Sep 2013 15:51:03 -0700 (PDT)
Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id A983F21F9D30; Mon, 23 Sep 2013 15:51:03 -0700 (PDT)
Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r8NMfjfW025908; Mon, 23 Sep 2013 17:51:02 -0500
Received: from uther.sparta.com (uther.sparta.com [157.185.0.2]) by txdal11mx03.parsons.com with ESMTP id 1f2qyvjsca-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 23 Sep 2013 17:51:02 -0500
Received: from durin.laguna.sparta.com ([10.62.216.7]) by Uther.sparta.com (8.13.8/8.13.8) with ESMTP id r8NMor8G002376; Mon, 23 Sep 2013 15:50:53 -0700
Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by durin.laguna.sparta.com (8.13.8/8.13.8) with ESMTP id r8NMonNP030542; Mon, 23 Sep 2013 15:50:53 -0700
Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::20bf:20a8:2ee8:f749%11]) with mapi id 14.02.0342.003; Mon, 23 Sep 2013 18:50:47 -0400
From: "Murphy, Sandra" <Sandra.Murphy@parsons.com>
To: "draft-ietf-6man-ext-transmit.all@tools.ietf.org" <draft-ietf-6man-ext-transmit.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: SecDir review of draft-ietf-6man-ext-transmit-03
Thread-Index: Ac64rbPvblufa5z/SpSQahVH+ho4QQ==
Date: Mon, 23 Sep 2013 22:50:47 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F677CE96C5@CVA-MB002.centreville.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.62.8.138]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-23_04:2013-09-22, 2013-09-23, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=132.136 compositescore=0.0515465056358588 urlsuspect_oldscore=0.515465056358588 suspectscore=0 recipient_domain_to_sender_totalscore=1933 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=8785 rbsscore=0.0515465056358588 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309230140
Subject: [secdir] SecDir review of draft-ietf-6man-ext-transmit-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Sep 2013 22:51:22 -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.