[secdir] review of draft-ietf-tsvwg-iana-ports-09

"Murphy, Sandra" <Sandra.Murphy@cobham.com> Tue, 01 February 2011 19:04 UTC

Return-Path: <Sandra.Murphy@cobham.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 7D4953A6F35; Tue, 1 Feb 2011 11:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id F5wurdpdwzFF; Tue, 1 Feb 2011 11:04:18 -0800 (PST)
Received: from M4.sparta.com (M4.sparta.com []) by core3.amsl.com (Postfix) with ESMTP id AA1A13A6DF4; Tue, 1 Feb 2011 11:04:17 -0800 (PST)
Received: from Beta5.sparta.com (beta5.sparta.com []) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p11J7Z2b014080; Tue, 1 Feb 2011 13:07:35 -0600
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com []) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p11J7Yfl003306; Tue, 1 Feb 2011 13:07:35 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC243.487C2A50"
Date: Tue, 1 Feb 2011 14:07:33 -0500
Message-ID: <5ABE30CE099A524CBF95C715D37BCACC03A28634@nemo.columbia.ads.sparta.com>
Thread-Topic: review of draft-ietf-tsvwg-iana-ports-09
Thread-Index: AcvCQ0gVV0ZB3J8UQJyiy3Xcw8Z4nQ==
From: "Murphy, Sandra" <Sandra.Murphy@cobham.com>
To: <secdir@ietf.org>, <draft-ietf-tsvwg-iana-ports.all@tools.ietf.org>, <iesg@ietf.org>
X-Mailman-Approved-At: Tue, 01 Feb 2011 13:38:55 -0800
Cc: "Murphy, Sandra" <Sandra.Murphy@cobham.com>
Subject: [secdir] review of draft-ietf-tsvwg-iana-ports-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 01 Feb 2011 19:04:23 -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.


The draft draft-ietf-tsvwg-iana-ports-09 consolidates the procedures
scattered over several RFC for the assignment of service names and ports
for transport protocols.  It establishes definitions and specifications
where they were previously missing (like syntax for service names).  It
provides a single reference for assignment procedures going forward and
establishes procedures for port/name de-assignment, reuse, revocation,
etc., and a description of the required and optional fields that must be
provided in any request.


I did NOT review the referenced documents and did not therefore consider
differences between this procedure and previously employed procedures.


There is a required format for communication of a request to the IANA, I
presume by email.  I did not see any mention of the email address to
which the request should be sent (RFC5226 also doesn't seem to mention


The procedure requires that the same previous Assignee (or Contact) make
any subsequent request about a port/name assignment, where the email
address is provided in the request.  Security question: how does the
IANA know that it is communicating with the same Assignee/Contact?
There's no recommendation for security of that communication.


In the IANA section there is a paragraph:


   IANA is instructed to create a new service name entry in the service
   name and port number registry [PORTREG] for any entry in the
   "Protocol and Service Names" registry [PROTSERVREG] that does not
   already have one assigned.


Are there no guidelines for creating the new service name?  


--Sandy Murphy