Re: [secdir] Secdir review of draft-ietf-lisp-type-iana-04

<mohamed.boucadair@orange.com> Fri, 13 January 2017 09:39 UTC

Return-Path: <mohamed.boucadair@orange.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 C894F129461 for <secdir@ietfa.amsl.com>; Fri, 13 Jan 2017 01:39:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.117
X-Spam-Level:
X-Spam-Status: No, score=-5.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9byLZ0inE2Gh for <secdir@ietfa.amsl.com>; Fri, 13 Jan 2017 01:39:31 -0800 (PST)
Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201D312944F for <secdir@ietf.org>; Fri, 13 Jan 2017 01:39:31 -0800 (PST)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 508EC120ACA; Fri, 13 Jan 2017 10:39:29 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 321C580071; Fri, 13 Jan 2017 10:39:29 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0319.002; Fri, 13 Jan 2017 10:39:26 +0100
From: <mohamed.boucadair@orange.com>
To: "Charlie Kaufman (charliekaufman@outlook.com)" <charliekaufman@outlook.com>
Thread-Topic: [secdir] Secdir review of draft-ietf-lisp-type-iana-04
Thread-Index: AdJtfiZacKQ2D09nS9CA4jvIThlj+QAAFaoQ
Date: Fri, 13 Jan 2017 09:39:25 +0000
Message-ID: <b5528dc9-93d3-4863-b7f1-12205687997f@OPEXCLILM33.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B933009DE3CA7@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009DE3CA7@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_b5528dc993d34863b7f112205687997fOPEXCLILM33corporateadr_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/2hUD3sXUi5JqITBMZWcmOHNuSJE>
Cc: JACQUENET Christian IMT/OLN <christian.jacquenet@orange.com>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-lisp-type-iana-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 13 Jan 2017 09:39:34 -0000

Dear Charlie,

Thank you for the review.

Please see inline.

Cheers,
Med

Objet : [secdir] Secdir review of draft-ietf-lisp-type-iana-04

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.

This document is: Ready

[Med] OK, thank you.

No security concerns.


This document proposes creation of two new IANA registries and defines a new message type within the Locator/ID Separation Protocol (RFC6830). The first registry should have been created by RFC6830, which assigned codes to 5 values for a four bit field. This document proposes creating a registry for holding those 5 values and a sixth value for the purpose of holding experimental extensions.


Because the 4 bit field can only ever support 16 values and several independent extensions are already being proposed, the proposal is to reserve the value 15 for experimental extensions where it has a 12 bit sub-type field to distinguish those extensions. This document proposes to create a second IANA registry for holding up to 4096 assigned values for that field, to be handed out on a first come first served basis.


While future extensions might have security implications, defining these new registries does not.


I don't know what IANA's experience has been with first come first served registries. With no review procedure, they are subject to abuse and I don't know who gets to exercise judgment as to whether a particular request is abusive.

[Med] FCFS is defined in https://tools.ietf.org/html/rfc5226#section-4.1. This type of allocation is not specific to this document, but it is in use by many protocols, e.g.,

*         http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

*         http://www.iana.org/assignments/epp-repository-ids/epp-repository-ids.xhtml

*         https://www.iana.org/assignments/service-codes/service-codes.xhtml

*         https://www.iana.org/assignments/imap-list-extended/imap-list-extended.xml

*         http://www.iana.org/assignments/ldp-namespaces/ldp-namespaces.xhtml

*         ...

The document states that the subtypes of value 15 are reserved for Experimental Use. My sense is that the intention of the authors is that should an experimental protocol be promoted to standards track that it will at that time be assigned on of the 16 values from the 4 bit field. This might be an unfortunate restriction for two reasons: 1) Given that there are only 16 types available and 6 have already been assigned, it seems possible that this space would eventually be exhausted; and 2) Requiring that protocols change syntax when they are promoted from experimental to standards track places a burden on implementers who often end up supporting both syntaxes indefinitely (and having interoperability problems if they don't). There's no reason obvious to me why subtypes could not be kept for standardized usage later. That is one of the advantages of having an IANA registry over reserving them for private use.


The intended status of this document is listed as Experimental. This seems wrong to me. While any future documents defining uses of newly assigned values might well be experimental, I would expect that this document would seek the same status as RFC6830 (and this document should be incorporated into any future revisions of that one).

[Med] As noted in the write-up, the initial intended status was standard track. But as an outcome of the rtgdir review, it was agreed to use the same status as RFC6830 (i.e., Experimental).


--Charlie