[secdir] secdir review of draft-ietf-mpls-ldp-typed-wildcard-05

["Richard L. Barnes" <[e-mail]>]

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.