Last Call Review of draft-ietf-mpls-ldp-dod-08
review-ietf-mpls-ldp-dod-08-secdir-lc-kent-2013-05-23-00
| Request | Review of | draft-ietf-mpls-ldp-dod |
|---|---|---|
| Requested revision | No specific revision (document currently at 09) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2013-05-27 | |
| Requested | 2013-05-16 | |
| Authors | Thomas Beckhaus , Bruno Decraene , Kishore Tiruveedhula , Maciek Konstantynowicz , Luca Martini | |
| Draft last updated | 2013-05-23 | |
| Completed reviews |
Genart Last Call review of -08
by
Francis Dupont
(diff)
Genart Telechat review of -09 by Francis Dupont Secdir Last Call review of -08 by Stephen Kent (diff) Secdir Telechat review of -09 by Stephen Kent |
|
| Assignment | Reviewer | Stephen Kent |
| State | Completed | |
| Review |
review-ietf-mpls-ldp-dod-08-secdir-lc-kent-2013-05-23
|
|
| Reviewed revision | 08 (document currently at 09) | |
| Result | Has Issues | |
| Completed | 2013-05-23 |
review-ietf-mpls-ldp-dod-08-secdir-lc-kent-2013-05-23-00
I 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.
An overall comment: There are numerous
(minor) English
errors throughout the document, which I hope will be addressed
through the RFC
Editor process.
The abstract says that the
document describes LDP DoD (downstream on demand) use cases
and lists
required LDP DoD procedures in the context of Seamless MPLS
design. It also
describes a new,
optional TLV type
in the LDP Label Request message. The intent of creating the new
type is to
enable “fast-up” convergence.
Section 2 of the document is devoted to a
description of
reference access topologies that will make use of this new MPLS
feature. These
topologies are divided into two classes: ones that can be
supported via static
routes and ones that require use of a dedicated IGP, e.g., ISIS,
OSPF (v2 or
v3), and
RIP (v2 or ng),
by the access
network.
Section 3 describes use cases for LDP DoD.
It too
distinguishes between topologies that use static routing vs. an
IGP, and
examines various types of failures that may affect the LDP DoD
nodes. This
section includes a lot of normative text, yet almost all
instances of the words
“must” and “should” are lowercase. The authors should revisit
this section to
determine if there need to be more MUSTs and SHOULDs.
Section 4 describes the label request
procedure. It too
contains normative text, yet almost all instances of “must” and
“should” are
lowercase. As with Section 3, the authors should revisit this
section to
determine if there need to be more MUSTs and SHOULDs.
Section 5 describes the LDP extension to
enable “Fast-Up”
convergence. In this very brief section the authors seem to have
done a better
job of using uppercase terms in normative text.
Section 7 addresses Security
Considerations. It cites RFC
5920, the Security Framework for MPLS and GMPLS as the primary
reference
applicable to security concerns that arise in the MPLS DoD
context. RFC 5920
devotes several pages to a discussion of service provider and
inter-provider
security topics, so it seems natural to cite it here. (It too
suffers from a
tendency to use the words “must,” “should,” and “may” only in
lowercase,
despite the apparent normative nature of the comments being
made.) Sections 9.1
and 9.2 are odd parts of 5920; the former enumerates potential
attacks, and the
latter enumerates “deference techniques” without bothering to
establish the
mapping between the two!
This I-D also cites the Security
Consideration section of
the MPLS LDP specification (RFC 5036), noting a need for message
authenticity
and integrity, and for protection against spoofing and DoS
attacks. RFC 5036
contains a more conventional Security Considerations section,
which seems
appropriate to cite here.
In addition to the references to prior
RFCs, this section
analyzes several security contexts:, in terms of tampering with
packet flow
direction, data and control plane security, and network node
security. The
discussion of attacks on packet flow direction seems fairly
good, except for
the ABR LSR network side case, for which the offered advice is
vague. The data
place security discussion seems to be a set of suggestions, but
with a mix of
normative and informative terms; Section 7.2 definitely needs
work.
The discussion of control plane security in
Section 7.3 is
shorter, but not much better. It suggests that the reader be
familiar with a
KARP I-D (
I-D.ietf-karp-routing-tcp-analysis.
This
recommendation is not a precise recommendation and thus ought to
be
reconsidered. The text here also suggests use of TCP/MD5,
recommending TCP/AO
only if the former is not considered good enough. RFC 5925
(TCP-AO) obsoletes
RFC 2385 (use of TCP/MD5 in BGP). This calls into question
whether it is
appropriate to recommend use of TCP/MD5 at all. The subsection
ends with two
suggestions: employ better authentication in access locations
with lower
physical security, and use “stricter network protection
mechanism.” The former
advice seems good, but the latter is too amorphous to be of much
use.
The
final
subsection in Security Considerations (7.4) discusses additional
precautions an operator might employ for nodes that are
considered to be at
risk due to degraded physical security. Addressing this concern
seems
reasonable, but the advice is pretty generic, and the wording
here is
especially poor.