[secdir] Secdir last call review of draft-ietf-mpls-app-aware-tldp-08

Yoav Nir <ynir.ietf@gmail.com> Thu, 08 June 2017 21:47 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BD612952D; Thu, 8 Jun 2017 14:47:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yoav Nir <ynir.ietf@gmail.com>
To: secdir@ietf.org
Cc: mpls@ietf.org, ietf@ietf.org, draft-ietf-mpls-app-aware-tldp.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.54.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149695844237.15142.17304755568511932911@ietfa.amsl.com>
Date: Thu, 08 Jun 2017 14:47:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/lQKGwIaItFSQzu5KsTDFEOAXAxQ>
Subject: [secdir] Secdir last call review of draft-ietf-mpls-app-aware-tldp-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 08 Jun 2017 21:47:22 -0000

Reviewer: Yoav Nir
Review result: Has Nits

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.

My biggest issue with this document is that it is hard to read.  For example,
the Introduction expands tLDP to "targeted LDP", and the Introduction begins
with "LDP uses extended discovery...", but LDP itself is only expanded to
"label distribution protocol" in the IANA considerations section.  Similarly,
the much-overloaded term "application" is never explained except that some
applications are "targeted" and that "FEC 128 pseudowire" is an example of an
application.  I am sure this makes sense to participants of the MPLS working
group, but to others this is much harder. There needs to be at least a
reference to RFC 5036 where these terms are better explained (RFC 5036 is
referenced but only as the document where tLDP adjacency is described).

Nits:
The Security Considerations section begins with "The Capability procedure
described in this document will apply and does not introduce any change to LDP
Security Considerations".  The procedure will apply what?  Or will apply to
what?  I think the words "will apply and" are superfluous.

The second paragraph seems to be repeating part of the (rather extensive)
security considerations of RFC 5036, but it does not say why (or even whether)
that particular anti-DoS measure applies in particular to the mechanism
described in this document. IOW why is this measure singled out from among the
three pages of security considerations from RFC 5036?

The third paragraph is not clear to me. It talks about two nodes not
establishing a tLDP session if they don't support the same application. I don't
know why that belongs in the security considerations section. The SHOULD NOT
(establish a session) mandate definitely does not belong there.