Re: [secdir] secdir review of draft-ietf-mpls-tp-on-demand-cv
Eric Gray <eric.gray@ericsson.com> Tue, 13 September 2011 20:24 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 95D2B11E8083; Tue, 13 Sep 2011 13:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.385
X-Spam-Level:
X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 BOo2dhP-8QVc; Tue, 13 Sep 2011 13:24:07 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id EA23621F8BEF; Tue, 13 Sep 2011 13:24:06 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8DKQCLp006966; Tue, 13 Sep 2011 15:26:13 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 13 Sep 2011 16:26:07 -0400
From: Eric Gray <eric.gray@ericsson.com>
To: Nitin Bahadur <nitinb@juniper.net>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Sandra Murphy <Sandra.Murphy@sparta.com>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Date: Tue, 13 Sep 2011 16:26:01 -0400
Thread-Topic: secdir review of draft-ietf-mpls-tp-on-demand-cv
Thread-Index: AQHC/Ea6fmSr1RrxfxPRkMI0I+/BkAJv7qxxlUQ6KRCAAGhSE4AGi/5g
Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F11173D85670@EUSAACMS0701.eamcs.ericsson.se>
References: <013701cc6ee0$96fd15c0$c4f74140$@olddog.co.uk> <CA8F8C4D.2355A%nitinb@juniper.net>
In-Reply-To: <CA8F8C4D.2355A%nitinb@juniper.net>
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: Tue, 13 Sep 2011 20:24:08 -0000
Nitin, Or that. Either way a long as it is clear... -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net] Sent: Friday, September 09, 2011 12:27 PM To: adrian@olddog.co.uk; Eric Gray; Sandra Murphy; secdir@ietf.org; iesg@ietf.org Cc: draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org Subject: Re: secdir review of draft-ietf-mpls-tp-on-demand-cv Importance: High Thanks Adrian. Replace with "MUST NOT".... ""ACH TLVs MUST NOT be associated with this channel type." Nitin On 9/9/11 4:06 AM, "Adrian Farrel" <adrian@olddog.co.uk> wrote: "CANNOT" ? Lower case for a statement of fact. 2119 language for a directive. A > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Eric > Gray > Sent: 09 September 2011 04:13 > To: Sandra Murphy; secdir@ietf.org; iesg@ietf.org > Cc: draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: RE: secdir review of draft-ietf-mpls-tp-on-demand-cv > > Sandy, > > I had a conversation with one of my co-authors about the > one item I had not addressed earlier. > > That item (from below) was on the subject of ACH TLVs to > be associated with new Pseudowire associated channel types. > > The Source & Destination identifier TLVs are not ACH TLVs. > They are TLVs within the LSP-Ping message payload. So the ACH > TLV rules do not apply to them. > > We will be adding the following text to section 3 (where > we define the the new Pseudowire associated channel type): > > "ACH TLVs CANNOT be associated with this channel type." > > This should remove any ambiguity on this issue. > > Again, thanks for the thorough review! > > -- > Eric > > -----Original Message----- > From: Eric Gray > Sent: Sunday, September 04, 2011 11:20 PM > To: 'Sandra Murphy'; secdir@ietf.org; iesg@ietf.org > Cc: draft-ietf-mpls-tp-on-demand-cv@tools.ietf.org > Subject: RE: secdir review of draft-ietf-mpls-tp-on-demand-cv > > 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