Re: [secdir] secdir review of draft-ietf-mpls-tp-on-demand-cv
Eric Gray <eric.gray@ericsson.com> Mon, 05 September 2011 03:33 UTC
Return-Path: <eric.gray@ericsson.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893B321F85B1; Sun, 4 Sep 2011 20:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.326
X-Spam-Level:
X-Spam-Status: No, score=-6.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvJ47YLKNPJ0; Sun, 4 Sep 2011 20:33:12 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 10C4C21F85AB; Sun, 4 Sep 2011 20:33:12 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p853YrkG000980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Sep 2011 22:34:54 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 4 Sep 2011 23:34:53 -0400
From: Eric Gray <eric.gray@ericsson.com>
To: Sandra Murphy <Sandra.Murphy@sparta.com>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Date: Sun, 04 Sep 2011 23:34:52 -0400
Thread-Topic: secdir review of draft-ietf-mpls-tp-on-demand-cv
Thread-Index: Acxjf1yw+KBgY4VGQjWo007gtWNZnAH8ISZw
Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F11173C35427@EUSAACMS0701.eamcs.ericsson.se>
References: <Pine.WNT.4.64.1108251917420.7464@SMURPHY-LT.columbia.ads.sparta.com>
In-Reply-To: <Pine.WNT.4.64.1108251917420.7464@SMURPHY-LT.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org" <draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-mpls-tp-on-demand-cv
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Sep 2011 03:33:13 -0000
Sandra, Thanks for the detailed review! On the security issues, I agree with your points. I am inclined to add text somewhat along the lines of the VCCV RFC (5085) - though VCCV is itself an unrelated protocol (this will limit the similarity of the text). In a nut-shell, I do not think that this specification can (or should) recommend that it is only used in the private MPLS network case. However, I think it is reasonable to suggest that the source identifier would be required for any other case, in order to facilitate filtering. This would be a deployment option, for which this protocol specification can only require that the ability to do this is included in compliant implementations. On the issue of extending RFC 4379, this draft explicitly says exactly how it extends RFC 4379. It is not the intention of this specification to extend RFC 4379 in every possible way. The on-demand payload is everything that follows either the IP header, or the ACH header. This seems every bit as clear to me as "IP payload" or any other protocol usage of the term. I have provided more detailed responses in-line below (look for "Eric Gray >>" at the beginning of lines). Again, thanks! -- Eric -----Original Message----- From: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] Sent: Thursday, August 25, 2011 7:33 PM To: secdir@ietf.org; iesg@ietf.org Cc: draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: secdir review of draft-ietf-mpls-tp-on-demand-cv 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? Eric Gray >> Yes, they are. This specification extends LSP Ping - by Eric Gray >> (among other things) supporting the non-IP case - so that Eric Gray >> LSP Ping is usable for transport networks. There is no Eric Gray >> to limit the usage of existing LSP Ping. 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. Eric Gray >> As stated above, there is no intention to limit the use Eric Gray >> of existing LSP Ping. In particular, except as explicily Eric Gray >> stated, the echo request used in on demand CV may contain Eric Gray >> any existing TLVs defined for LSP Ping. It is up to the Eric Gray >> implementors to work out when and where this might make Eric Gray >> sense. 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". Eric Gray >> This is an artifact of making this specification about on Eric Gray >> "on demand CV." The "payload" is exactly the same as it Eric Gray >> would be for LSP Ping. 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? Eric Gray >> Yes, in this case, it does. We should add text to clarify Eric Gray >> this. 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. Eric Gray >> If we had meant the latter, we would have needed to add the Eric Gray >> "that is" which you have added in the latter case. It takes Eric Gray >> a bit of a stretch to make this any more ambiguous than any Eric Gray >> English expression necessarily will be. 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. Eric Gray >> Any implementation of this specification necessarily MUST Eric Gray >> support reply mode 4. This certainly seems obvious to me, Eric Gray >> given reply mode 4 is part of what this draft specifies. I believe the "that reply mode" means the requested reply mode, not the 4 reply mode. Eric Gray >> Yes. 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. Eric Gray >> We will need to discuss this one amongst ourselves and get Eric Gray >> back to you about it... 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? Eric Gray >> Abolutely not! That would require they intercept and process Eric Gray >> the message rather than simply forward it. This not like a Eric Gray >> route recording, but merely the path the responder thinks is Eric Gray >> the reverse path (to be verified by the requester, on getting Eric Gray >> the response). 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. Eric Gray >> Okay. The "On-demand CV" Channel Type is not defined until the IANA considerations section. A forward reference would be good. Eric Gray >> There is a forward reference currently in the third para Eric Gray >> section 3. 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. Eric Gray >> Okay. 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? Eric Gray >> they would be encapsulated as specified for reply modes 2 or Eric Gray >> 3 in RFC 4379. One reason to use one of these modes would Eric Gray >> be if the LSP is unidirectional. Use of the ACh Header in Eric Gray >> that case will not work. 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. Eric Gray >> Perhaps we should say "primarily" instead of "only", or we Eric Gray >> could simply leave "only" out. Eric Gray >> The general aim is to make the extensions we add to MPLS for Eric Gray >> the transport application usable in general, so we should Eric Gray >> probably not have added such a limitation. Clearly the case Eric Gray >> we want to cover generally is the case where IP addressing Eric Gray >> is not available. The "only" case where this seemed likely Eric Gray >> while we were writing this draft was the transport case. --Sandy
- [secdir] secdir review of draft-ietf-mpls-tp-on-d… Sandra Murphy
- Re: [secdir] secdir review of draft-ietf-mpls-tp-… Eric Gray
- Re: [secdir] secdir review of draft-ietf-mpls-tp-… Eric Gray
- Re: [secdir] secdir review of draft-ietf-mpls-tp-… Adrian Farrel
- Re: [secdir] secdir review of draft-ietf-mpls-tp-… Eric Gray
- Re: [secdir] secdir review of draft-ietf-mpls-tp-… Eric Gray
- Re: [secdir] secdir review of draft-ietf-mpls-tp-… Nitin Bahadur