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