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

["Rajiv Asati (rajiva)" <[e-mail]>]

Hi Richard,

Hope you received the below response on Feb 8th. Should I assume that
you are in agreement to the changes I proposed?

I would proceed with -06 version submission otherwise. Please let us
know. 

Thanks a lot.

Cheers,
Rajiv

> -----Original Message-----
> From: Rajiv Asati (rajiva)
> Sent: Monday, February 08, 2010 3:01 PM
> To: Richard L. Barnes; secdir; The IESG; The IETF; Rajiv Asati
(rajiva)
> Cc: [e-mail]
> Subject: RE: secdir review of draft-ietf-mpls-ldp-typed-wildcard-05
> 
> Hi Richard,
> 
> Thank you so much for your review and critical feedback. This really
> helps to improve this specification. Please see inline,
> 
> > 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.
> 
> Please see my response below (to the last comment).
> 
> > 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.
> 
> I am assuming that the unclarity you refer to is based on the specific
> comments you have provided below.  Right?
> 
> 
> > 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."
> 
> Per RFC5036, the Label TLV is an optional parameter in Label release
> (section 3.5.10) and Label withdraw (section 3.5.10) messages. Hence,
the
> text is section 1 is correct.
> 
> 
> > 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."
> 
> 
> Type-length-value in TLV (encoding) has nothing to do with the 'typed'
> (vs. 'untyped') data, which is what that statement and the whole
document
> refer to.
> 
> Typed data is supplemented with the value, whereas the untyped data is
> not. The latter is what RFC5036 prescribed (note that there is no
value
> in it). The former is what the current document is prescribing.
> 
> Hence, the existing text in the para (and the whole document).
> 
> I don't see any need for changing that para. Do you?
> 
> 
> 
> > 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."
> 
> 
> Agreed. Fixed.
> 
> 
> > Section 2, TLV
> > s/Lenth/Length/
> 
> Agreed. Fixed.
> 
> 
> > 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.
> > "
> 
> 
> Agreed. Pls allow me to suggest a slightly changed replacement instead
-
> 
> ~~~~~~~~~
> The Typed Wildcard FEC Element refers to all FECs of the specified
type
> that meet the constraint. It specifies a 'FEC Element Type' and an
> optional constraint, which is intended to provide additional
information.
> ~~~~~~~~~
> 
> I have also put "Optional" in the figure 1, btw.
> 
> 
> > 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."
> 
> 
> Agreed. Pls allow me to suggest a slightly changed replacement instead
-
> 
> ~~~~~~
> It is important that any document specifying Typed wildcarding for any
> FEC Element Type also specifies the length and format of Additional
FEC
> Type Specific Information, if included.
> ~~~~~~~~~~
> 
> > 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).
> 
> This is already implicit in the description of the 'Leng FEC Type
Info'.
> I have made it explicit in the below update -
> 
> ~~~~~~~~~`
> Additional FEC Type-specific Information:  (Optional) Additional
> information specific to the FEC Element Type required to fully specify
> the Typed Wildcard. If this field is absent, then all FECs of the
> specified FEC Type would be matched.
> ~~~~~~~~~~~~~
> 
> 
> > 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".
> 
> 
> What we mean is that the (future) specifications defining any new FEC
> Element Types should prescribe whether typed wildcarding is needed for
> that FEC Element Type.
> 
> Nonetheless, that para should be in the section 3, not section 4. I
have
> moved it in the section 3. The 2nd para (When Typed Wildcarding....)
has
> been removed, since it is redundant with the existing text.
> 
> 
> > 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?
> 
> 
> Good question. The answer is - No. There must be two different
messages.
> 
> RFC5036 (section 3.4.1) does NOT allow multiple FEC elements in FEC
TLV
> in any message except label mapping message.
> 
> Frankly, it would bring whole set of complexity, if we removed this
> restriction, for minimal benefit.
> 
> 
> 
> 
> > 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?
> 
> Yes. That's intentional (since it is already covered by the Prefix FEC
> Element).
> 
> Wrt semantics, not sure which particular field's semantics you are
> referring to, but the procedures are already specified in section 4,
> hence, there wasn't any benefit in replicating the text.
> 
> 
> > Section 7, Para "In other words ..."
> > s/can not/MUST NOT/
> 
> Agreed. Fixed.
> 
> > 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.
> 
> Strictly speaking, the security exposure is reduced by this
> specification, since the wildcarding is now limited to FECs of a
> particular type (AFI, say), not all the FECs.
> 
> Nonetheless, I agree to your suggestion about having some text to
clarify
> a bit better and suggest adding the following (as 2nd para) to the
> security consideration section:
> 
> ~~~~~~~~~~
> One could deduce that the security exposure is reduced by this
document,
> since an LDP speaker using Typed Wildcard FEC Element could use a
single
> message to request, withdraw or release all the label mappings of a
> particular type (a particular AFI, for example), whereas an LDP
speaker
> using Wildcard FEC Element, as defined in based LDP specification
> [RFC5036], could use a single message to request, withdraw or release
all
> the label mappings of all types (all AFIs, for example).
> ~~~~~~~
> 
> Would this be sufficient?
> 
> Cheers,
> Rajiv
> 
> 
> > -----Original Message-----
> > From: Richard L. Barnes [mailto:[e-mail]]
> > Sent: Monday, February 01, 2010 10:40 PM
> > To: secdir; The IESG; The IETF
> > Cc: [e-mail]
> > Subject: secdir review of draft-ietf-mpls-ldp-typed-wildcard-05
> >
> > 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.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >