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: draft-ietf-mpls-ldp-typed-wildcard@xxxxxxxxxxxxxx > 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:rbarnes@xxxxxxx] > > Sent: Monday, February 01, 2010 10:40 PM > > To: secdir; The IESG; The IETF > > Cc: draft-ietf-mpls-ldp-typed-wildcard@xxxxxxxxxxxxxx > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf