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

Charlie Kaufman <charliekaufman@outlook.com> Mon, 09 January 2017 00:10 UTC

Return-Path: <charliekaufman@outlook.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 E7ABF129A09; Sun, 8 Jan 2017 16:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.019
X-Spam-Level:
X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com
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 sveIXeXSDXtB; Sun, 8 Jan 2017 16:10:47 -0800 (PST)
Received: from BLU004-OMC4S30.hotmail.com (blu004-omc4s30.hotmail.com [65.55.111.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90317129A08; Sun, 8 Jan 2017 16:10:47 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com ([65.55.111.136]) by BLU004-OMC4S30.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 8 Jan 2017 16:10:46 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TH66C+B5lEFsSjbgAgfKYDmhZd4iyK6N0Q2gNQNx8sM=; b=ewp/KBTunph1N6o+O0ZUy6mIuzXYxKfCrRQrlMT+6Drw40bWKv2ezOifGHW4tQP0lb3YoKECOVZE/xbzP5eXd0zhwgYTfotnLBHD4nF4HgOiYGhkgf8J8kr7gAgn/Zyi0BCsYVTRlQyTirgl9uQQ3TCXILD8mfdxLNevcRIEE/7iB5mznXiuPdmqMAHd+frQZW6HBO3bwHOdpQiZCCzxpb0FI6hb+W9REmp7QN7dKQwb7VZ0o8Xw+rO+v9Q0oVYLbCbpXKKA4iFMgFqqzM4qKqvUYXbGjlG3Tp2VsZweEWuGi+aYEhdikQyQqf94aH96LxIXYFl7qWi3lxUTiglKyQ==
Received: from SN1NAM01FT045.eop-nam01.prod.protection.outlook.com (10.152.64.51) by SN1NAM01HT234.eop-nam01.prod.protection.outlook.com (10.152.65.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.8; Mon, 9 Jan 2017 00:10:45 +0000
Received: from CY4PR17MB0997.namprd17.prod.outlook.com (10.152.64.58) by SN1NAM01FT045.mail.protection.outlook.com (10.152.65.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.8 via Frontend Transport; Mon, 9 Jan 2017 00:10:45 +0000
Received: from CY4PR17MB0997.namprd17.prod.outlook.com ([10.173.181.7]) by CY4PR17MB0997.namprd17.prod.outlook.com ([10.173.181.7]) with mapi id 15.01.0829.013; Mon, 9 Jan 2017 00:10:45 +0000
From: Charlie Kaufman <charliekaufman@outlook.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-lisp-type-iana.all@tools.ietf.org" <draft-ietf-lisp-type-iana.all@tools.ietf.org>, 'The IESG' <iesg@ietf.org>
Thread-Topic: Secdir review of draft-ietf-lisp-type-iana-04
Thread-Index: AQHSagjbiUfYI4y900KEQY8wFG97hg==
Date: Mon, 9 Jan 2017 00:10:45 +0000
Message-ID: <CY4PR17MB09976540F211EFAC84EF3831DF650@CY4PR17MB0997.namprd17.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=outlook.com;
x-incomingtopheadermarker: OriginalChecksum:30BCD05BB94B4850FF157E5980D1E22A3B1238E73855538BC5C18251DF07F007; UpperCasedChecksum:86215B9A83908D609046D393227D559653D6644E8B636B6EDEF2F154DD678169; SizeAsReceived:7652; Count:37
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [bb91tSqbqvCQK81iQ5jp45Dw0bk+DWPH]
x-incomingheadercount: 37
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1; SN1NAM01HT234; 7:Qdk2v4IuyERR8UfYHNtprGFffMOE91CWA4TD4obi8wRLO1jZmUnZuFwgVW1KQnOhwK3eSOK9QjwzTrvU3F6VTkzy921BRXg4ipOa6NjhQbVrmyxOYV+4rpcUUydvNikuQSSICSyi0RSWC02eVxmCXcgLRNv2zBLKVYSc882fOFghnLbdfIEzN2e/OSOxcaSd+O88AIfN/eGlB2shYjkPEDMJcmIpgtC9vL1VUNDV0h5GhgypGMubzUgLyq17sxF4wGvIfnbLavkUMs8V9AnLUPivzqdBiRCND2dBe8Zag4h8Sqx4+Ai11sD7+BRx10VjOxnpMBelLfVY8LmEfTsh0GFCY2/JcXVHOCtAzYkec/3XTDWGWAONLCtOpwIacw3UhVU4B1z+blYpNphVy1O0uTAAmPPxHe8/v0en/KPHsjoHo7grN0gRMtH6BzNoUDB05+T//qp53CFVoeWyQdPdBg==
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM01HT234; H:CY4PR17MB0997.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-ms-office365-filtering-correlation-id: bef016b4-fac1-4bdd-3d6a-08d43823f554
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(1603103113)(1603101340)(1601125047)(1701031023); SRVR:SN1NAM01HT234;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444111334)(444112120)(432015012)(82015046); SRVR:SN1NAM01HT234; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT234;
x-forefront-prvs: 0182DBBB05
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR17MB09976540F211EFAC84EF3831DF650CY4PR17MB0997namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2017 00:10:45.6121 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT234
X-OriginalArrivalTime: 09 Jan 2017 00:10:46.0549 (UTC) FILETIME=[D35E4C50:01D26A0C]
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/m3jnevfOjB5BsT9U0omHQLjSNEQ>
Subject: [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: Mon, 09 Jan 2017 00:10:49 -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.

This document is: Ready

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.


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


--Charlie