Last Call Review of draft-ietf-mpls-forwarding-06
review-ietf-mpls-forwarding-06-secdir-lc-kent-2014-02-06-00
| Request | Review of | draft-ietf-mpls-forwarding |
|---|---|---|
| Requested revision | No specific revision (document currently at 09) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2014-02-12 | |
| Requested | 2014-01-30 | |
| Authors | Curtis Villamizar , Kireeti Kompella , Shane Amante , Andrew G. Malis , Carlos Pignataro | |
| Draft last updated | 2014-02-06 | |
| Completed reviews |
Genart Last Call review of -06
by
Joel M. Halpern
(diff)
Secdir Last Call review of -06 by Stephen Kent (diff) Secdir Telechat review of -08 by Stephen Kent (diff) Opsdir Last Call review of -06 by Al Morton (diff) |
|
| Assignment | Reviewer | Stephen Kent |
| State | Completed | |
| Review |
review-ietf-mpls-forwarding-06-secdir-lc-kent-2014-02-06
|
|
| Reviewed revision | 06 (document currently at 09) | |
| Result | Has Nits | |
| Completed | 2014-02-06 |
review-ietf-mpls-forwarding-06-secdir-lc-kent-2014-02-06-00
SECDIR
review of
draft-ietf-mpls-forwarding-06
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, WG chairs and ADs
should treat
these
comments just like any other last call comments.
This document
is a candidate Informational
RFC. It cites
about 25 MPLS RFCs (normatively) as a basis for guidelines for
MPLS router
implementers and network providers, with respect to forwarding
of MPLS traffic.
The Security
Considerations Section is very brief. It correctly states that
it is a review
of forwarding behavior specified in numerous MPLS RFCs, and thus
introduces no
new security requirements. It makes specific reference to
Section 4.6, which
specifies (at a high level) some tests for DoS susceptibility in
MPLS routers.
The paragraph that includes this reference should be extended to
include
pointers to Section 2.6.1 (which discusses DoS concerns), and to
Section 3.6 (which
includes a list of DoS protection questions to be posed to
suppliers).
It might be
nice to
summarize the security considerations recommendations from the
MPLS RFCs that
are normative references in this document. Since this document
is a summary of
forwarding-relevant requirements from these documents, plus
practical advice,
such a summary would be useful here, and fitting.
Some
suggested edits:
2.1.2.
MPLS Differentiated
Services
[RFC2474] deprecates the
IP Type of Service
(TOS) and IP Precedence
(Prec) fields and replaces
them with the
Differentiated Services
Field more commonly known
as the
Differentiated Services Code Point
(DSCP) field.
[RFC2475] defines the
Differentiated Services
architecture, which in
other
forum
is often called a
Quality of
Service (QoS)
architecture.
Either use
“fora” (correct
Latin) or “forums” (common English)
2.1.8.1.
Pseudowire Sequence Number
Pseudowire (PW) sequence
number support is
most important for PW
payload types with a high
expectation of
lossless and/or in-order
delivery.
Identifying lost PW packets
and
exact amount
of lost
payload is critical for PW
services which
maintain bit timing, such
as Time Division
Multiplexing (TDM) services
since these services
MUST compensate lost
payload on a
bit-for-bit basis.
“the exact
amount”
With PW
services which
maintain bit timing, packets that have been
received out of order also
MUST be
identified and
may
be either re-
ordered or dropped.
Uppercase
MAY?
The term
“microflow” does
not appear to be defined anywhere in this document, but is used
a number of
times. I suggest including the definition from RFC 2474.
2.4.4.
MPLS Entropy Label
The MPLS entropy label
simplifies flow group
identification [RFC6790]
at midpoint
LSR
.
Prior to
the MPLS entropy
label midpoint LSR
needed
to inspect the
entire label stack and often
the IP headers to provide …
Missing an
article, or
make LSR plural.
Many service
providers
consider it a hard requirement
that use of
UDP and TCP
ports can be disabled.
Therefore
there is
a
stong
incentive for
implementations to provide
both options.
“strong”
Cryptographic
authentication can
is
some
circumstances be
subject
to DoS attack
by
overwhelming the capacity of the decryption with
a high volume
of malicious
traffic.
“in”