Draft: draft-ietf-mpls-rfc3036bis-03.txt Reviewer: Black_David@emc.com Review Date: Tuesday 2/21/2006 7:49 PM CST IETF LC Date: 16 Feb 2006 Summary: On the right track but has open issues, described in the review. All of the significant new issues are IETF process issues. There are also a number of nits in the draft that need to be corrected, and I found the security issue described in Sam Hartman's Discuss. While Brian Carpenter has already voted No Objection on this draft, I think a Discuss is in order to resolve the process issues. Review: ------- (1) This draft has a major process problem - Section 2.9 has a normative dependency on the TCP MD5 signature option. The maturity variance for the TCP MD5 signature option in RFC 4278 is primarily for BGP - RFC 4278 has only this to say about LDP (Section 5): The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385]. Deployment practices for LDP are very similar to those of BGP: LDP connections are usually confined within a single autonomous system and most frequently span a single link between two routers. This makes the LDP threat environment very similar to BGP's. Given this, and a considerable installed base of LDP in service provider networks, we are not deprecating [RFC2385] for use with LDP. While that text indicates the IESG's inclination to grant a maturity variance for TCP MD5's usage in LDP, it does not actually grant the variance. The LDP draft attempts to sidestep this by making RFC 2385 a non-normative reference (Section 9.2). That approach is clearly wrong, as Section 2.9 says: This section specifies a mechanism to protect against the introduc- tion of spoofed TCP segments into LDP session connection streams. The use of this mechanism MUST be supported as a configurable option. The mechanism is based on use of the TCP MD5 Signature Option speci- fied in [RFC2385] for use by BGP. The "MUST" in the quoted text requires that RFC 2385 be a normative reference. Hence, the IESG appears to need to grant an explicit standards maturity variance for TCP MD5's use in LDP if Section 2.9 is to remain in the LDP draft. Granting that variance is probably the proverbial "right thing" to do, but it does appear to be necessary to do so. (2) Section 3.6.1.1 allows the U bit to be clear for a vendor-private TLV, so that if the TLV is not understood, the entire message is rejected. This appears to allow mandatory vendor-private extensions, which has been an IESG concern in the past. If mandatory vendor- private TLV elements are not to be allowed, this section would need to require that the U bit always be set for a vendor-private TLV. An analogous issue occurs for the U bit in vendor-private messages in Section 3.6.1.2, but could be addressed by requiring a sender to continue if a vendor-private message is rejected. (3) Sam Hartman's Discuss on Section 5.1 should be supported - an explanation of why something is bad should generally be provided when specifying mitigation measures for it. Nits: Section 2.5.3 uses the acronyms VPI, VCI and DLCI without prior definition. While I'm sure these acronyms are obvious to MPLS experts, expansions should be provided. Expansions are provided later (Sections 3.4.2.2 and 3.4.2.3) and need to be reproduced here. Section 2.8.3 "should" in first line ought to be "SHOULD", but I could be convinced otherwise as this is a requirement on network administrators as opposed to protocol implementers. A number of the TLVs are not aligned lengths (e.g., Hop Count is an odd number of bytes - 5). Section 3.3 implies that there is no padding between TLVs, but it would be useful for Section 3.5 to say that there is no padding at the end of a message (e.g., despite the diagram in Section 3.5, parameters can end on odd-byte boundaries). Section 5.3, subsection 2 contains a number of "should" statements that probably ought to be changed to "SHOULD"s. Section 6 uses the CoS acronym without prior definition or expansion.