I reviewed draft-ietf-mpls-tp-on-demand-cv 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 draft extends LSP-PING to provide ping/traceroute for MPLS-TP LSPs and PWs, using G-ACh when the intermediate nodes would not be able to provide the IP service LSP-PING requires. Background: LSP-PING (RFC4379) was defined to provide connectivity checks (like ping) and route tracing checks (like traceroute) for MPLS LSPs. LSP-PING uses an IP packet format to be carried as payload under the MPLS labels (RFC4379). Each node is presumed to have an IP host stack to process the IP packet format. Pseudowires (PW - RFC 3985) are constructed over varying packet switched nodes types, including MPLS as well as IP, so could not count on the IP capability being present in any PW node. PWE3 defined their own connection verification (VCCV - RFC5085) function, which uses a PW control channel feature, identified in MPLS networks by a ACH - Associated Channel Header (RFC4385). A generic version (G-ACh) of the PW control channel ACH was defined for use with LSPs (and "Sections", haven't quite grasped that yet) - RFC5586. MPLS-TP (RFC5921) is a "profile" of MPLS for providing a transport service and this draft was needed to provide MPLS-TP its own ping/traceroute capability using the G-ACh. Security comments This draft defines a new Channel Type for the G-ACh control channel defined in RFC5586. The Channel Type indicates the particular protocol using the generic G-ACh. The security considerations section of RFC5586 says that: The security considerations for the associated control channel are described in RFC 4385 [RFC4385]. Further security considerations MUST be described in the relevant associated channel type specification. And RFC4385 makes a stronger warning: An application using a PW Associated Channel must be aware that the channel can potentially be misused. Any application using the Associated Channel MUST therefore fully consider the resultant security issues, and provide mechanisms to prevent an attacker from using this as a mechanism to disrupt the operation of the PW or the PE, and to stop this channel from being used as a conduit to deliver packets elsewhere. The selection of a suitable security mechanism for an application using a PW Associated Channel is outside the scope of this document. Finally, RFC5921 (MPLS-TP) reiterates that: A third and last area of concern relates to the processing of the actual contents of G-ACh messages. It is necessary that the definition of the protocols using these messages carried over a G-ACh include appropriate security measures. This draft's security considerations section is brief and only points to the security considerations of LSP-PING: The draft does not introduce any new security considerations. Those discussed in [RFC4379] are also applicable to this document. Perhaps the authors considered this adequate to satisfy the requirements from 5586 and 4385 and 5921 for consideration of the security issues. But I am not sure that all the security discussion of RFC4379 apply to this new CV protocol. RFC4379 (LSP-PING) and RFC5085 (VCCV) both discuss the concerns about misuse of the control channel - intercepting or injecting packets, flooding, etc. LSP-PING discusses potential mitigation techniques based on rate limiting to the UDP port, and filtering and access lists based on the source and destination addresses of the LSP-PING payload. This draft defines source and destination ID TLVs for the non-IP use of this on-demand-cv, which contain identifiers (see draft-ietf-mpls-tp-identifiers) that sound like they could also be used for filters and access lists (the "global ID" is typically the ASN and the "node ID" is typically the IP address -- but specifically not required to be - for example, probably not when they are "compatible with ITU-T transport-based operations".). Unfortunately, the source and destination ID TLVs are a MAY, so they don't have to appear. So I don't believe that the mitigations suggested in RFC4379 apply to this draft in a straightforward way. VCCV has a different suggestion for protection: However the implementation of the connectivity verification protocol expands the range of possible data-plane attacks. For this reason implementations MUST provide a method to secure the data plane. This can be in the form of encryption of the data by running IPsec on MPLS packets encapsulated according to [RFC4023], or by providing the ability to architect the MPLS network in such a way that no external MPLS packets can be injected (private MPLS network). (Note that when VCCV and MPLS-TP talk about data plane attacks they mean the payloads in the control channel, not the user data traffic.) RFC4023 is encapsulating MPLS in IP or GRE, so again these techniques would not apply to the non-IP case that is the motivation for this draft. Of course, the "private MPLS network" mitigation will continue to work. (Probably not in inter-domain applications - perhaps inter-domain pings would be rare.) So I doubt that this draft can rely completely on the security considerations section of LSP-PING and don't know if it needs to take the security considerations advice of VCCV and MPLS-TP. I do believe that the needs to decide how to handle the MUST requirements in the security considerations of 4385/5586/5921. Editorial comments: This draft says it updates RFC4379. But I was unclear about some sections, for example, sections 3.1 and 3.2 that talk about IP encapsulation. Section 3.1 in particular does not seem to extend RFC4379 at all, and it says: This form of On-demand CV OAM MUST be supported for MPLS-TP LSPs when IP addressing is in use. Will LSP-PING packets be considered one "form" of On-demand CV? The draft defines new TLVs and sub-TLVs. But it also refers often to "On-demand CV payload". It appears this means the entire LSP-PING packet as defined in RFC4379 section 3 but it is not clear whether this means those packets that include both old TLVs and/or new TLV/sub-TLVs, or those packets with only the new TLVs/sub-TLVs. It wouldn't take much to make this clear. As there are requirements for what happens with "On-demand CV payload", (e.g. in section 3.3, if the reply mode is 4 then the "On-demand CV payload MUST directly follow the ACH header"), it would be good to be very clear what is meant by "On-demand CV payload". In section 3.3, in the following: If the Reply mode indicated in an On-demand CV Request is 4 (Reply via application level control channel), the On-demand CV reply message MUST be sent on the reverse path of the LSP using ACH. The On-demand CV payload MUST directly follow the ACH header and IP and/or UDP headers MUST NOT be attached. Does this same restriction on the placement of the On-demand CV payload apply to the echo request as well? In the "MUST be sent on the reverse path of the LSP using ACH" -- is that "MUST (be sent on the reverse path of the LSP) (using ACH)" or "MUST be sent on the reverse path of (the LSP that is using ACH)". I'm thinking the first is right, but I am not sure. In the following: If a node receives an MPLS echo request with a reply mode other than 4 (reply via application level control channel), and if the node supports that reply mode, then it MAY respond using that reply mode. If the node does not support the reply mode requested, or is unable to reply using the requested reply mode in any specific instance, the node MUST drop the echo request packet and not attempt to send a response. The section does not say what happens if the reply mode *is* 4, but the node does not support reply mode 4. I don't know if that ever could happen. I believe the same response holds - drop the request. I believe the "that reply mode" means the requested reply mode, not the 4 reply mode. RFC5586 discusses examples of "ACH TLVs" as source and destination information. It places restrictions on the definition of ACH TLVs in any new Channel Type, such as this draft: If the G-ACh message MAY be preceded by one or more ACH TLVs, then this MUST be explicitly specified in the definition of an ACH Channel Type. If the ACH Channel Type definition does state that one or more ACH TLVs MAY precede the G-ACh message, an ACH TLV Header MUST follow the ACH. If no ACH TLVs are required in a specific associated channel packet, but the Channel Type nevertheless defines that ACH TLVs MAY be used, an ACH TLV Header MUST be present but with a length field set to zero to indicate that no ACH TLV follow this header. If an ACH Channel Type specification does not explicitly specify that ACH TLVs MAY be used, then the ACH TLV Header MUST NOT be used. I do not know if the Source and Destination Identifier TLVs are ACH TLVs or if they can precede the G-ACh. It looks to me like different interpretations of whether these two paragraphs apply to the source/destination TLVs could change the packet ordering and content. Section 3.4.2 and 3.4.3 (part of the Reverse Path CV discussion) say: The requesting node (on receipt of the response) can use the Reverse-path Target FEC Stack TLV to perform reverse path connectivity verification. and On receipt of the echo response, the requesting node MUST perform the following checks: 1. Perform interface and label-stack validation to ensure that the packet is received on the reverse path of the bi-directional LSP 2. If the Reverse-Path Target FEC Stack TLV is present in the echo response, then perform FEC validation. Does only the requesting node perform the FEC validation check on the Reverse-Path Target FEC Stack? Don't intermediate nodes do the check? Section 4.2.2 The On-demand CV route tracing responses will be received on the LSP itself and the presence of an ACH header with channel type of On- demand CV is an indicator that the packet contains On-demand CV ^an payload. The "On-demand CV" Channel Type is not defined until the IANA considerations section. A forward reference would be good. Section 4.2.3 unable to identify the LSP on which the echo response would to be would be All responses MUST always be sent on a LSP path using the ACH header and ACH channel type of On-demand CV. Section 3.3 says that requests in a non-IP ACH case SHOULD be sent with reply mode of 4 [i.e., could be other than 4] and responses when the reply mode is not 4 can be sent using the requested reply mode. Reply modes 2&3 are IP encapsulation - does this mean that they must also use the ACH header? Section 5: 5. Applicability The procedures specified in this document for non-IP encapsulation apply only to MPLS-TP Transport paths. This includes LSPs and PWs when IP encapsulation is not desired. However, when IP addressing is used, as in non MPLS-TP LSPs, procedures specified in [RFC4379] MUST be used. If this document applies only to MPLS-TP, why place requirements on cases that fall outside the scope of this document? Is there an implication that the procedures in RFC4379 differ from the procedures in this draft in those non MPLS-TP LSPs? What does this imply about section 3.1 "LSP-Ping with IP encapsulation"? I obviously am somewhat confused about the area of overlap, if any, between RFC4379 and this draft. --Sandy