Last Call Review of draft-ietf-mpls-ldp-typed-wildcard-
review-ietf-mpls-ldp-typed-wildcard-secdir-lc-barnes-2010-02-02-00

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.

This document extends the matching capabilities of the LDP Wildcard FEC
element, which matches all Forwarding Equivalence Classes bound to a given
label, by adding a second Typed Wildcard FEC element, which matches all FECs of
a given type, with optional additional type-specific constraints.  Because this
change is relatively minor, the security considerations are mostly the same as
the base protocol, as noted by the Security Considerations section; however, I
would prefer if the authors explained a little better why this is the case.

From an editorial perspective, this document is unclear on several important
points, especially with regard to the type-specific constraints and how they
are defined and managed.  I think the document would would benefit from another
revision, focused on making the meaning and management of all parameters clear
to ensure interoperability.

Detailed comments follow.

--Richard

Specific comments:

Section 1, Para "As specified..."

With respect to the phrase "relative to an optional constraint": I don't see
anything in RFC 5036 that allows for such a constraint.  The Wildcard FEC type
"is to be applied to all FECs associated with the label within the following
label TLV."

Section 1, Para "1. The Wildcard FEC Element is untyped"

It's not quite accurate to say that the element is untyped; it has type 0x01.
 Suggest something like "The Wildcard FEC element only allows very coarse
selection of FECs by label."

Section 1, General

Clearly you're really after here isn't to change the Wildcard FEC Element (as
the last sentence of the section says), but to have a new element that is a
typed Wildcard.  It would be clearer and more accurate to say this, e.g., in
bullet (2), "There are situations where it would be useful to have a
wildcard-like FEC Element, with type constraints, in Label Request messages."

Section 2, TLV

s/Lenth/Length/

Section 3, Para "The Typed Wildcard FEC Element..."

The language about constraints here seems vague.  (In what sense is the
constraint "optional"?)  Suggest the following:

"

A Typed Wildcard FEC Element specifies a FEC Type and, optionally, a
constraint.  An element of this type refers to all FECs of the specified FEC
Type that meet the constraint.  The format of the constraint field depends on
the FEC Type specified.

"

Section 3, Para "Additional FEC Type-specific Information ..." et seq

It is unclear whose responsibility it is to define the structure of this field
(i.e., who is the "designer"?).  Do you mean to say this: "Additional
constraints that the FEC must satisfy in order to be selected. The format of
the Additional FEC Type-specific Information depends on the FEC type in
question.  This document defines the format of this field for the Prefix FEC
type."

The text here and in the document suggest that there should perhaps be a
procedure for defining and registering formats for this field.  However, you
may want to specify that any FEC Type may be specified with a zero-length
Additional FEC Type-specific Information field to simply match all FECs of that
FEC Type (in order to make it easy to use without a whole lot of new RFCs).

Section 4, Para "It is the responsibility..." et seq

The authors of this document are the designers of the Typed Wildcard FEC
Element Type; who do you mean?  It is meaningless to have a MUST that is
conditional on "making sense".

Section 4, Para "When a FEC TLV..."

This constraint made sense for the generic Wildcard type, since that would
overwhelm any other FEC Elements, but it's not clear why it's necessary here.
 Couldn't I have a Label Withdraw message that withdraws all CR-LSP FECs and a
single Prefix FEC?

Section 6, General

You need to specify the semantics of this field.  Does it match all FECs that
are of the given address family?  Also, this doesn't allow any constraints on
prefix length or the prefix itself; is that intentional?

Section 7, Para "In other words ..."

s/can not/MUST NOT/

Section 9, General

I would like to see a little more explanation of why this extension to LDP does
not create additional security considerations.  It seems like at the very least
it increases the risk of misconfiguration by adding much more flexible wildcard
matching rules; that is, it seems more likely that an LSR operator will
accidentally match things he doesn't intend to, or vice versa.