[secdir] secdir review of draft-ietf-ccamp-wson-signaling-09.txt

Benjamin Kaduk <kaduk@MIT.EDU> Tue, 17 March 2015 20:08 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E4A541A88D5; Tue, 17 Mar 2015 13:08:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Xo11LtR-Kp4r; Tue, 17 Mar 2015 13:08:54 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520E51A88CF; Tue, 17 Mar 2015 13:08:51 -0700 (PDT)
X-AuditID: 12074425-f79846d0000054e1-3c-550889d15c8d
Received: from mailhub-auth-1.mit.edu ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 88.C3.21729.2D988055; Tue, 17 Mar 2015 16:08:50 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2HK8npq011944; Tue, 17 Mar 2015 16:08:49 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2HK8kW4017550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Mar 2015 16:08:48 -0400
Received: (from kaduk@localhost) by multics.mit.edu ( id t2HK8kvG020791; Tue, 17 Mar 2015 16:08:46 -0400 (EDT)
Date: Tue, 17 Mar 2015 16:08:46 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: ietf@ietf.org, secdir@ietf.org, draft-ietf-ccamp-wson-signaling.all@ietf.org
Message-ID: <alpine.GSO.1.10.1503171447350.3953@multics.mit.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUixCmqrHupkyPUYM4EFovtd7wsnm2cz2Lx YeFDFgdmjyVLfjIFMEZx2aSk5mSWpRbp2yVwZfTNOsxUMF2iYtucVawNjEeFuxg5OSQETCTW dLYyQthiEhfurWfrYuTiEBJYzCSxrKuFCcLZyCjx7O41VgjnEJNEw8wORgingVFi1qRuoB4O DhYBbYktrQ4go9gEVCRmvtnIBmKLCERKPPu5CmyFsICDxOPFt8BsXiD74JZJLCC2qICOxOr9 U1gg4oISJ2c+AbOZBbQklk/fxjKBkW8WktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKL dC30cjNL9FJTSjcxggKM3UV1B+OEQ0qHGAU4GJV4eG8UsIcKsSaWFVfmHmKU5GBSEuVlzeUI FeJLyk+pzEgszogvKs1JLT7EKMHBrCTCq9UClONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliS mp2aWpBaBJOV4eBQkuB92AHUKFiUmp5akZaZU4KQZuLgBBnOAzRcthNkeHFBYm5xZjpE/hSj opQ4Lz9IQgAkkVGaB9cLSwCvGMWBXhHm/QWyggeYPOC6XwENZgIa3NLOBjK4JBEhJdXAyPeR J6t4v7rxj7hsczt2ybwPW8pqKo8UXeU+dljN8tr5I7Y7rJtVzC4qPI571p29zas4Z/va5I0S bDrNlWyPHbdbPLu4TtHkv52Uu5P0dh0e/Vea0+7qvX3SceJk1IxbV89dbmlLmjSFrVWocMX3 fuaZPWn7Lpw44pmpsStY+6Fic9wtyStmSizFGYmGWsxFxYkAuCClRdsCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/VxJFkgpPJhGQ3fTuh60m4Z9rmsE>
Subject: [secdir] secdir review of draft-ietf-ccamp-wson-signaling-09.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 17 Mar 2015 20:08:57 -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.

I think this document is ready with nits.

The security considerations notes that this is a simple extension to
existing mechanisms and is not carrying qualitatively different
information compared to the existing specifications.  The security
considerations of RFC 3473, and RFC 5920, seem to provide adequate
treatment of the security issues at play here.

The nits are largely editorial in nature:

The list of WSON Signal Characteristics introduces the acronym FEC and
includes its expansion in the body, but does not explicitly define the
term.  That could be done in the Terminology section.

In section 3.2, the term "3R regeneration" is used, but it is not
mentioned in the Temrinology section.  (As not a routing person, I had to
look it up.)

In section 4.1, I think that an "in the" or "by the" (or similar) is
missing prior to "Generalized Label Request object".

Section 4.2 claims that the requirements for signaling to indicate to a
particular node what type of processing to perform are given in section
3.2, however, I see no such requirements in section 3.2; is a different
section intended?

Also in section 4.2, the term "WSON Processing HOP Attribute TLV" is used.
Is HOP an acronym?  I do not see it in the RFC Editor's list of
(https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt) and I am
not entirely sure that I understand its meaning.

The artwork for the contents of that TLV immediately follows.  The
subsequent descriptive text indicates that there may be padding after the
'Value' field, to align the end of the record to a four-octet boundary.
It might be useful to include some padding in the artwork.

The text description for the "Length" field says that the included length
is four plus the length of the value field in octets, but the artwork has
only one octet for each of the Type and Length fields, which would make
the constant two, not four.  (Perhaps those two fields were changed from
two octets to one octet in some revision of the document?)

Likewise, the description of the WavelengthSelection sub-TLV in the table
with Name/Type/Length indicates that 3 octets of padding would be needed
after the 1 octet of 'Value' contents.  However, if the Type and Length
fields are only one octet each, only one octet of padding would be needed,
not three.

In section 4.2.1, it is said that "No more than two ResourceBlockInfo
sub-TLVs SHOULD be present."  However, the RBNF for the WSON Processing
HOP Attribute allows at most two, so any more than two would be
noncompliant with the RBNF.  It is unclear to me if this incongruity is
actually a cause for concern; it probably depends on why SHOULD is used
instead of MUST.

-Ben Kaduk