From rbonica@juniper.net Tue Aug 30 06:47:23 2011 Return-Path: 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 8C02021F8B5D; Tue, 30 Aug 2011 06:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ywBUfK6qVPdL; Tue, 30 Aug 2011 06:47:22 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2530021F8B56; Tue, 30 Aug 2011 06:47:18 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTlzqOcR/xgO+0Z/6HfewS+e1tX76zgCS@postini.com; Tue, 30 Aug 2011 06:48:50 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 30 Aug 2011 06:43:27 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 30 Aug 2011 09:43:27 -0400 From: Ronald Bonica To: Stephen Farrell , jouni korhonen Date: Tue, 30 Aug 2011 09:43:25 -0400 Thread-Topic: secdir Review of draft-ietf-v6ops-3gpp-eps Thread-Index: AcxnF/ZwpNhsDzCiQsuls6bVRt/+agAAr6Eg Message-ID: <13205C286662DE4387D9AF3AC30EF456D48D92B2CD@EMBX01-WF.jnpr.net> References: <6425C318-F3AB-4321-A238-2828F43580E0@gmail.com> <4E5CCEF5.1020303@cs.tcd.ie> <9CCF3C81-D31A-40F6-80E8-3567E4E7E88E@gmail.com> <4E5CE411.7070708@cs.tcd.ie> In-Reply-To: <4E5CE411.7070708@cs.tcd.ie> 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 X-Mailman-Approved-At: Thu, 01 Sep 2011 09:06:00 -0700 Cc: "secdir@ietf.org" , "draft-ietf-v6ops-3gpp-eps.all@tools.ietf.org" , "iesg@ietf.org" , Russ Mundy Subject: Re: [secdir] secdir Review of draft-ietf-v6ops-3gpp-eps X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 13:47:23 -0000 I think that it would be a good idea to spin a new version before the call = next week. Ron > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Stephen Farrell > Sent: Tuesday, August 30, 2011 9:22 AM > To: jouni korhonen > Cc: Russ Mundy; draft-ietf-v6ops-3gpp-eps.all@tools.ietf.org; > iesg@ietf.org; secdir@ietf.org > Subject: Re: secdir Review of draft-ietf-v6ops-3gpp-eps >=20 >=20 > I think its worth including. Why don't you talk to Ron and > see if he'd prefer you to push out a version now or not and > we can go from there. >=20 > Cheers, > S. >=20 > On 08/30/2011 02:07 PM, jouni korhonen wrote: > > > > Stephen, > > > > Thanks for picking up the nits. And yes, I would push out a new > version with the additional security consideration text below, *if* > folks think it is worth having it there. > > > > And for prohibiting the use of IMSI/MSISDN (or any "3GPP identity") > as the IID, the reference would be Section 5.3.1.2.2 of [TS.23401]. > > > > - Jouni > > > > > > On Aug 30, 2011, at 2:52 PM, Stephen Farrell wrote: > > > >> > >> Hi Jouni, > >> > >> Just checking - do you intend to push out a new version with this > >> included before the telechat next week? > >> > >> A few nits below as well. > >> > >> Ta, > >> Stephen. > >> > >> On 08/25/2011 11:50 AM, jouni korhonen wrote: > >>> Russ, > >>> > >>> Thanks for the review. You are echoing the same thing as the most > in IESG. I crafted a bit of text that could be put into the security > considerations section. I don't know if this would be enough. > >>> > >>> - JOuni > >>> > >>> ---- > >>> > >>> > >>> In 3GPP access the UE and the network always perform a mutual > >>> authentication during the network attachment > [TS.33102][TS.33401]. > >>> Furthermore, each time a PDP Context/PDN Connection gets > created, > >>> a new connection, a modification of an existing connection and > >>> an assignment of an IPv6 prefix or an IP address can be > authorized > >>> against the PCC infrastructure [TS.23203] and/or PDN's AAA > server. > >>> > >>> The wireless part of the 3GPP link between the UE and the > (e)NodeB > >>> as well as the signaling messages between the UE and the > MME/SGSN > >>> can be protected depending on the regional regulation an > operator > >>> deployment policy. User plane traffic can be confidentially > >> > >> s/confidentially/confidentiality/ would be better. > >> > >> If you can add references as to how that can be achieved that > >> would also be good. > >> > >> The same points apply for the control plane I guess. > >> > >>> protected. The control plane is always at least integrity and > >>> replay protected, and may also be confidentially protected. The > >>> protection within the transmission part of the network depends > >>> on the operator deployment policy. > >>> > >>> Due the nature of 3GPP point-to-point link model, the UE and > the > >>> first hop router (PGW/GGSN or SGW) are the only nodes on the > link, > >>> which mitigates most of the known on-link attacks. For off-link > IPv6 > >>> attacks the 3GPP EPS is as vulnerable as any IPv6 system. There > has > >> > >> s/has/have/ > >> > >>> also been concerns that UE IP stack might use permanent > subscriber > >> > >> s/UE IP stack/the UE IP stack/ > >> > >>> identities, such as IMSI and MSISDN, as the source for IPv6 > address > >>> Interface Identifier. This would be a privacy threat and allow > >>> tracking of subscribers, and therefore use of IMSI and MSISDN > as the > >>> Interface Identifier is prohibited. However, there is no > standardized > >>> method to block such misbehaving UEs. > >> > >> Prohibited by whom? Maybe add a reference? > >> > >>> > >>> > >>> > >>> > >>> [TS.33102] > >>> 3GPP, "3G Security; Security architecture", > >>> 3GPP TS 33.102 10.0.0, December 2010. > >>> > >>> > >>> [TS.33401] > >>> 3GPP, "3GPP System Architecture Evolution (SAE); > >>> Security architecture", 3GPP TS 33.401 10.1.1, > >>> June 2011. > >>> > >>> On Aug 25, 2011, at 12:43 AM, Russ Mundy wrote: > >>> > >>>> > >>>> 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. > >>>> > >>>> While I do agree with the factual correctness of the Security > Considerations > >>>> section (the document does not _introduce_ any security related > concerns), > >>>> the support for IPv6 in 3GPP networks described in document > certainly does > >>>> have a number of security concerns. Some obvious examples, use of > DHCP > >>>> based address management and access control/authorization of the > PDN > >>>> Connection (shown in Figure 8). Although these and other security > issues > >>>> are likely addressed in various other documents, it would be > useful to make > >>>> a definitive statement to that effect in the Security > Considerations > >>>> section. It would be even more useful if some more specific > references were > >>>> to be included in parts of the document that clearly deal with > security > >>>> issues such as address management and access control and > authorization. > >>>> > >>>> > >>>> Russ Mundy > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > > > > From new-work-bounces@ietf.org Tue Aug 30 09:29:40 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D66721F8C6B; Tue, 30 Aug 2011 09:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1314721780; bh=y5tuOB1mJzYsM8hub/DeELLqdpRmhR23Lv3y5EQlPIU=; h=From:To:Mime-Version:Message-Id:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=qNgSjO0Z15xWEK1FHph5TMGnz2Rkm/tYiknJcYyOjiLJNInUCI1j4C64h5bf2NYG5 lWjJ1sWO25uEUvSNRx5vbUe4NafzaIM9P6KbGrQ4YubayaHl1NxCzlAsSLypXivlHZ bLAXnzd9pXUmKNUTpGmlxanOWGhrtoMIk9GQ+NtY= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id B515221F8C6B; Tue, 30 Aug 2011 09:29:38 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110830162938.B515221F8C6B@ietfa.amsl.com> Date: Tue, 30 Aug 2011 09:29:38 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Thu, 01 Sep 2011 09:06:00 -0700 Subject: [secdir] [new-work] WG Review: Javascript Object Signing and Encryption (jose) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 16:29:40 -0000 A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, September 6, 2011 Javascript Object Signing and Encryption (jose) ================================================= Status: Proposed Working Group Last updated: 2011-08-18 Chairs TBD Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: jose@ietf.org To Subscribe: Archive: Description of Working Group ---------------------------- Javascript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a desire to offer security services such as encryption, digital signatures, and message authentication codes (MACs) for data that is being carried in JSON format. Different proposals for providing such security services have already been defined and implemented. This Working Group's task is to standardize two security services, integrity protection (signature and MAC) and encryption, in order to increase interoperability of security features between protocols that use JSON. The Working Group will base its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is correct. This group is chartered to work on four documents: 1) A Standards Track document specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures. "Integrity protection" includes public-key digital signatures as well as symmetric-key MACs. 2) A Standards Track document specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures. 3) A Standards Track document specifying how to encode public keys as JSON-structured objects. 4) A Standards Track document specifying mandatory-to-implement algorithms for the other three documents. The working group may decide to address one or more of these goals in a single document, in which case the concrete milestones for signing/encryption below will both be satisfied by the single document. Goals and Milestones -------------------- Jan 2012 Submit JSON object integrity document as a WG item. Jan 2012 Submit JSON object encryption document as a WG item. Jan 2012 Submit JSON key format document as a WG item. Jan 2012 Submit JSON algorithm document as a WG item. Jun 2012 Start Working Group Last Call on JSON object integrity document. Jun 2012 Start Working Group Last Call on JSON object encryption document. Jun 2012 Start Working Group Last Call on JSON key format document. Jun 2012 Start Working Group Last Call on JSON algorithm document. Jul 2012 Submit JSON object integrity document to IESG for consideration as Standards Track document. Jul 2012 Submit JSON object encryption document to IESG for consideration as Standards Track document. Jul 2012 Submit JSON key format document to IESG for consideration as Standards Track document. Jul 2012 Submit JSON algorithm document to IESG for consideration as Standards Track document. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Aug 30 09:37:22 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9A721F8D8D; Tue, 30 Aug 2011 09:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1314722242; bh=Bo0sqo27fxpBBYrOZ1FVWoGZFxc984IIqbpPQ+iUAs8=; h=From:To:Mime-Version:Message-Id:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=BR8uafzgZ8mPgRfj0EtWVw3fLwvMJht2B6vKvy5mYQI8JGZz+tzytA+js/z+VL5f6 kwWhHm0NoMCbToOgSBP+MTtiJSg+o3V6fFEAZZ71IoMQWhLc0n/sr2+Mri3LYttI4q LkSBwqOMRSqDjMk4254ewbgyp2WoKbEzBsBr3Dto= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id CD2FD21F8D83; Tue, 30 Aug 2011 09:37:18 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20110830163718.CD2FD21F8D83@ietfa.amsl.com> Date: Tue, 30 Aug 2011 09:37:18 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Thu, 01 Sep 2011 09:06:00 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Layer 2 Virtual Private Networks (l2vpn) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 16:37:22 -0000 A modified charter has been submitted for the Layer 2 Virtual Private Networks (l2vpn) working group in the Routing Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, September 6, 2011. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- Last updated: 2011-08-30 Current Status: Active Chairs: Nabil Bitar Giles Heron Routing Area Directors: Stewart Bryant Adrian Farrel Routing Area Advisor: Stewart Bryant Mailing Lists: General Discussion: l2vpn@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/l2vpn Archive: http://www.ietf.org/mail-archive/web/l2vpn/current/maillist.html Description of Working Group: The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services. Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as defined by the PWE3 WG or over IP or MPLS PSN tunnels. A L2VPN emulates a "native" service over a PSN that is adequately faithful to, but may not be entirely indistinguishable from the native service itself. Further, following in the "edge-to-edge" nature of the service, the L2VPN WG will not define any mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between the PEs which provide the L2VPN connectivity. Layer-2 VPNs comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates a switched Ethernet (V)LAN across a PSN. 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across a PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that provides point-to-multipoint connectivity for a variety of link layers across a PSN. 4. IP-only L2VPN, an IP-only service over a PSN. The WG will address two specific types of IP-only L2VPN: a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but also supports heterogenous Attachment Circuits at either end of a single point-to-point service. b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS, but learns IP and MAC address bindings from ARPs and broadcast/multicast IP packets. 5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that emulates an Ethernet (V)LAN across a PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. 6. E-Tree, a Layer-2 service defined by the MEF, which provides connectivity between one or more root nodes and one or more leaf nodes, with the restriction that leaf nodes may only communicate with root node(s) (and not with each other). L2VPNs will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PEs participating in a Layer-2 VPN as well as the membership of CE devices for a specific instance of an L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WGs. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms for VPLS. Those extensions will be reviewed by the PWE3 WG to ensure they are aligned with the overall design/architecture of PWE3. The L2VPN WG will not define new encapsulations, control, or resiliency mechanisms specifically related to pseudowires. Furthermore, when the L2VPN solution is based on PWs, the L2VPN WG will not define protocol inter-working between an L2VPN and native service Layer-2 OAM or resiliency mechanisms. The L2VPN WG may define how to operate native service-layer control, OAM or resiliency mechanisms on top of an L2VPN. In addition, it may define native data plane and/or control plane interworking between an L2VPN and an associated native Layer-2 service. The L2VPN WG scope includes the following: 1. Discovery of PEs participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN service. 2. Signaling of information related to the discovery and membership of PEs within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN, when the L2VPN operates over PWs. Once those requirements have been reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIBs for Layer-2 VPN solutions. 4. Specification of requirements, framework and solutions that facilitate Operations Administration and Management (OAM) of any type of L2VPN within the scope of the L2VPN Working Group. 5. Mechanisms to permit optimization of multicast data traffic within an L2VPN. 6. If transport does not involve PWs, mechanisms that support load-balancing/multi-pathing between PEs interconnecting a Layer-2 service using an L2VPN across the PSN. 7. requirements for the multi-homing of CEs to several VPLS or E-VPN PEs, inclusive of active/backup and active/ active (load-sharing) configurations. Based on these requirements define VPLS or E-VPN control plane solutions for achieving fast convergence after failure of an active path in the PSN or on the AC side. 8. Enhancements to increase the scalability of the Control Plane and Data Plane of L2VPN PE nodes, and of core nodes that provide transport services for L2VPN. 9. Requirements and solutions for Auto-Discovery and Signaling of Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized L2VPNs. 10. Requirements and solutions for supporting "E-Tree" services using VPLS. Milestones: Done Submit an I-D describing MIB for VPLS Done Submit an I-D describing MIB for VPWS Done Submit an I-D on OAM requirements for VPLS Done Submit an I-D on OAM requirements for VPWS Done Submit L2 requirements to IESG for publication as Informational RFC Done Submit L2 framework to IESG for publication as Informational RFC Done Identify VPLS and VPWS solutions for the WG Done Submit VPLS solution documents to IESG Done Submit VPWS solution documents to IESG Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPNs Oct 2011 Submit IP-only L2VPN solution documents to IESG Nov 2011 Submit OAM solutions for VPWS to IESG Nov 2011 Submit OAM solutions for VPLS to IESG Nov 2011 Submit signaling solution for multicast-optimized VPLS to IESG Nov 2011 Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Nov 2011 Submit MIB for VPLS to IESG Nov 2011 Submit MIB for VPWS to IESG Mar 2012 Submit scalability solutions for VPLS Data-Plane to IESG Mar 2012 Submit scalability solutions for VPLS Control-Plane to IESG Mar 2012 Submit E-Tree requirements/framework to IESG Jul 2012 Submit MIB for IP-only L2VPN to IESG Jul 2012 Submit OAM solutions for IP-only L2VPN to IESG Jul 2012 Submit Auto-Discovery solution for VPMS to IESG Jul 2012 Submit VPLS service convergence improvement solutions to IESG Jul 2012 Submit VPLS multi-homing solutions to IESG Jul 2012 Submit E-Tree solution to IESG Jul 2012 Submit E-VPN requirements/framework to IESG Nov 2012 Submit E-Tree OAM to IESG Dec 2012 Submit E-Tree MIB to IESG Nov 2012 Submit E-VPN solution to IESG Mar 2013 Submit E-VPN OAM to IESG Apr 2013 Submit E-VPN MIB to IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From mundy@sparta.com Thu Sep 1 11:37:25 2011 Return-Path: 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 22E0C21F97B7; Thu, 1 Sep 2011 11:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 fx2pzGi3o-0H; Thu, 1 Sep 2011 11:37:24 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0791721F97B4; Thu, 1 Sep 2011 11:37:23 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p81Icolp008905; Thu, 1 Sep 2011 13:38:50 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p81IciPk024508; Thu, 1 Sep 2011 13:38:44 -0500 Received: from nermal.tislabs.com ([192.94.214.97]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Sep 2011 14:38:43 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Mundy In-Reply-To: <65E295F7-0904-417C-B483-98413B451DE9@gmail.com> Date: Thu, 1 Sep 2011 14:38:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4E040684-41CC-43E2-BFD7-2B4FE376E946@sparta.com> References: <6425C318-F3AB-4321-A238-2828F43580E0@gmail.com> <4E5CCEF5.1020303@cs.tcd.ie> <9CCF3C81-D31A-40F6-80E8-3567E4E7E88E@gmail.com> <4E5CE411.7070708@cs.tcd.ie> <13205C286662DE4387D9AF3AC30EF456D48D92B2CD@EMBX01-WF.jnpr.net> <65E295F7-0904-417C-B483-98413B451DE9@gmail.com> To: jouni korhonen X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 01 Sep 2011 18:38:43.0296 (UTC) FILETIME=[60302600:01CC68D6] Cc: "secdir@ietf.org" , Ronald Bonica , "draft-ietf-v6ops-3gpp-eps.all@tools.ietf.org" , "iesg@ietf.org" , Russ Mundy Subject: Re: [secdir] secdir Review of draft-ietf-v6ops-3gpp-eps X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 18:37:25 -0000 Jouni, Thanks for the additions to the Security Considerations section, I = believe that they add substantially to the document especially for = readers that do not already have a thorough understanding of 3GPP = architecture and technology. =20 Since the document is planned for Informational status, I believe that = these additions make the Security Considerations section sufficient. Russ On Aug 31, 2011, at 3:40 AM, jouni korhonen wrote: >=20 > I have just uploaded -05 with updated security considerations section. >=20 > - Jouni >=20 >=20 > On Aug 30, 2011, at 4:43 PM, Ronald Bonica wrote: >=20 >> I think that it would be a good idea to spin a new version before the = call next week. >>=20 >> Ron >>=20 >>=20 >>> -----Original Message----- >>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf = Of >>> Stephen Farrell >>> Sent: Tuesday, August 30, 2011 9:22 AM >>> To: jouni korhonen >>> Cc: Russ Mundy; draft-ietf-v6ops-3gpp-eps.all@tools.ietf.org; >>> iesg@ietf.org; secdir@ietf.org >>> Subject: Re: secdir Review of draft-ietf-v6ops-3gpp-eps >>>=20 >>>=20 >>> I think its worth including. Why don't you talk to Ron and >>> see if he'd prefer you to push out a version now or not and >>> we can go from there. >>>=20 >>> Cheers, >>> S. >>>=20 >>> On 08/30/2011 02:07 PM, jouni korhonen wrote: >>>>=20 >>>> Stephen, >>>>=20 >>>> Thanks for picking up the nits. And yes, I would push out a new >>> version with the additional security consideration text below, *if* >>> folks think it is worth having it there. >>>>=20 >>>> And for prohibiting the use of IMSI/MSISDN (or any "3GPP identity") >>> as the IID, the reference would be Section 5.3.1.2.2 of [TS.23401]. >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>> On Aug 30, 2011, at 2:52 PM, Stephen Farrell wrote: >>>>=20 >>>>>=20 >>>>> Hi Jouni, >>>>>=20 >>>>> Just checking - do you intend to push out a new version with this >>>>> included before the telechat next week? >>>>>=20 >>>>> A few nits below as well. >>>>>=20 >>>>> Ta, >>>>> Stephen. >>>>>=20 >>>>> On 08/25/2011 11:50 AM, jouni korhonen wrote: >>>>>> Russ, >>>>>>=20 >>>>>> Thanks for the review. You are echoing the same thing as the most >>> in IESG. I crafted a bit of text that could be put into the security >>> considerations section. I don't know if this would be enough. >>>>>>=20 >>>>>> - JOuni >>>>>>=20 >>>>>> ---- >>>>>>=20 >>>>>>=20 >>>>>> In 3GPP access the UE and the network always perform a mutual >>>>>> authentication during the network attachment >>> [TS.33102][TS.33401]. >>>>>> Furthermore, each time a PDP Context/PDN Connection gets >>> created, >>>>>> a new connection, a modification of an existing connection and >>>>>> an assignment of an IPv6 prefix or an IP address can be >>> authorized >>>>>> against the PCC infrastructure [TS.23203] and/or PDN's AAA >>> server. >>>>>>=20 >>>>>> The wireless part of the 3GPP link between the UE and the >>> (e)NodeB >>>>>> as well as the signaling messages between the UE and the >>> MME/SGSN >>>>>> can be protected depending on the regional regulation an >>> operator >>>>>> deployment policy. User plane traffic can be confidentially >>>>>=20 >>>>> s/confidentially/confidentiality/ would be better. >>>>>=20 >>>>> If you can add references as to how that can be achieved that >>>>> would also be good. >>>>>=20 >>>>> The same points apply for the control plane I guess. >>>>>=20 >>>>>> protected. The control plane is always at least integrity and >>>>>> replay protected, and may also be confidentially protected. The >>>>>> protection within the transmission part of the network depends >>>>>> on the operator deployment policy. >>>>>>=20 >>>>>> Due the nature of 3GPP point-to-point link model, the UE and >>> the >>>>>> first hop router (PGW/GGSN or SGW) are the only nodes on the >>> link, >>>>>> which mitigates most of the known on-link attacks. For off-link >>> IPv6 >>>>>> attacks the 3GPP EPS is as vulnerable as any IPv6 system. There >>> has >>>>>=20 >>>>> s/has/have/ >>>>>=20 >>>>>> also been concerns that UE IP stack might use permanent >>> subscriber >>>>>=20 >>>>> s/UE IP stack/the UE IP stack/ >>>>>=20 >>>>>> identities, such as IMSI and MSISDN, as the source for IPv6 >>> address >>>>>> Interface Identifier. This would be a privacy threat and allow >>>>>> tracking of subscribers, and therefore use of IMSI and MSISDN >>> as the >>>>>> Interface Identifier is prohibited. However, there is no >>> standardized >>>>>> method to block such misbehaving UEs. >>>>>=20 >>>>> Prohibited by whom? Maybe add a reference? >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> [TS.33102] >>>>>> 3GPP, "3G Security; Security architecture", >>>>>> 3GPP TS 33.102 10.0.0, December 2010. >>>>>>=20 >>>>>>=20 >>>>>> [TS.33401] >>>>>> 3GPP, "3GPP System Architecture Evolution (SAE); >>>>>> Security architecture", 3GPP TS 33.401 10.1.1, >>>>>> June 2011. >>>>>>=20 >>>>>> On Aug 25, 2011, at 12:43 AM, Russ Mundy wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> While I do agree with the factual correctness of the Security >>> Considerations >>>>>>> section (the document does not _introduce_ any security related >>> concerns), >>>>>>> the support for IPv6 in 3GPP networks described in document >>> certainly does >>>>>>> have a number of security concerns. Some obvious examples, use = of >>> DHCP >>>>>>> based address management and access control/authorization of the >>> PDN >>>>>>> Connection (shown in Figure 8). Although these and other = security >>> issues >>>>>>> are likely addressed in various other documents, it would be >>> useful to make >>>>>>> a definitive statement to that effect in the Security >>> Considerations >>>>>>> section. It would be even more useful if some more specific >>> references were >>>>>>> to be included in parts of the document that clearly deal with >>> security >>>>>>> issues such as address management and access control and >>> authorization. >>>>>>>=20 >>>>>>>=20 >>>>>>> Russ Mundy >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 From eric.gray@ericsson.com Sun Sep 4 20:33:13 2011 Return-Path: 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 To: Sandra Murphy , "secdir@ietf.org" , "iesg@ietf.org" Date: Sun, 4 Sep 2011 23:34:52 -0400 Thread-Topic: secdir review of draft-ietf-mpls-tp-on-demand-cv Thread-Index: Acxjf1yw+KBgY4VGQjWo007gtWNZnAH8ISZw Message-ID: References: In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From eric.gray@ericsson.com Thu Sep 8 20:11:26 2011 Return-Path: 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 2998B21F84B8; Thu, 8 Sep 2011 20:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 xLVVSxUphGEy; Thu, 8 Sep 2011 20:11:24 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8742621F84B7; Thu, 8 Sep 2011 20:11:24 -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 p893DCTU022315; Thu, 8 Sep 2011 22:13:15 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 8 Sep 2011 23:13:10 -0400 From: Eric Gray To: Sandra Murphy , "secdir@ietf.org" , "iesg@ietf.org" Date: Thu, 8 Sep 2011 23:13:07 -0400 Thread-Topic: secdir review of draft-ietf-mpls-tp-on-demand-cv Thread-Index: Acxjf1yw+KBgY4VGQjWo007gtWNZnAH8ISZwAMtSycA= Message-ID: References: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 03:11:26 -0000 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 From adrian@olddog.co.uk Fri Sep 9 04:05:24 2011 Return-Path: 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 1C72A21F8B1E; Fri, 9 Sep 2011 04:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.555 X-Spam-Level: X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 AjXQEEVCSgy3; Fri, 9 Sep 2011 04:05:09 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 14EDF21F8B1B; Fri, 9 Sep 2011 04:05:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p89B716W011843; Fri, 9 Sep 2011 12:07:01 +0100 Received: from 950129200 (109.82.202.1.static.bjtelecom.net [1.202.82.109] (may be forged)) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p89B6npP011725; Fri, 9 Sep 2011 12:06:53 +0100 From: "Adrian Farrel" To: "'Eric Gray'" , "'Sandra Murphy'" , , References: In-Reply-To: Date: Fri, 9 Sep 2011 12:06:44 +0100 Message-ID: <013701cc6ee0$96fd15c0$c4f74140$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHC/Ea6fmSr1RrxfxPRkMI0I+/BkAJv7qxxlUQ6KRA= Content-Language: en-gb Cc: 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 Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 11:05:24 -0000 "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 From leifj@sunet.se Mon Sep 12 11:29:12 2011 Return-Path: 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 E403521F8C41; Mon, 12 Sep 2011 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] 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 Lq+t7tF2MNYL; Mon, 12 Sep 2011 11:29:11 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id C5A3621F8C2A; Mon, 12 Sep 2011 11:29:10 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p8CIV71R022906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Sep 2011 20:31:12 +0200 (CEST) Message-ID: <4E6E4FEA.7090100@sunet.se> Date: Mon, 12 Sep 2011 20:31:06 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: draft-ietf-oauth-v2@tools.ietf.org, secdir@ietf.org, iesg@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-oauth-v2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 18:29:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 Do not be alarmed. 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 review is rather lengthy. This should not be interpreted as anything beyond a desire to do a thorough review. It may well be that I have stumbled on things already covered on the list. If so I apologize and ask that you silently ignore such bits. Also I have included things that are not directly security related but that I found problematic for other reasons. The notes are presented in the order I wrote them down. ** General observations: POST and/or GET Examples are sometimes POST and sometimes GET. In many cases it is not clear to me from the surrounding text if both POST and GET are allowed or if only one is mandated. Illustrating with both a GET _and_ POST example in the cases where both are supported would help or make the method explicit in the text before the example. The P-word The term 'password' is sprinkled throughout the document, sometimes as in "client password" or "resource owner password credentials" and I suspect that sometimes it is password as in 'an example of a credential type' and in other cases it is password as in 'plain old password'. This needs to be cleared up throughout (I've included some examples below). Normative Language I've often found myself wanting more normative language often to replace existing but less precise text. I've called out some important cases below. Unknown parameters The sentence "The client SHOULD ignore unrecognized response parameters" occurs in several places. First of all I would argue that this has to be a MUST if you want to be able to guarantee extensibility. Secondly there are some error responses that are triggered by unsupported request parameters. This seems like an inconsistency. ** Specifics 1.1 Roles Forward references to the sections where the roles are defined would improve readability. As an illustration of an alternative model for the authorization server maybe an informative reference to UMA would be illustrative here. 1.2 Protocol Flow (A) talks about 'an intermediary such as an authorization server.' it isn't clear it me if this refers to a separate authorization server or if it is the same authorization server that is referenced in (B). 1.3.3 Resource Owner Password Credentials When I first read this I thought - why not talk about Resource Owner Credentials - in fact there is a parenthesis there "(e.g a username and password)" that seems to indicate that other credentials could be supported. This needs to be cleared up. Either its username and password and nothing else or there is a way to support things like Negotiate or X.509-based credentials in which case it should really be Resource Owner Credentials with no reference to passwords other than as as an example of one possible credential type. 1.4 Access Token first paragraph: "The string is usually opaque". This should be reformulated as normative language. In fact I would have liked guidance on generating those tokens (which has been brought up on the list) possibly as part of an implementation-guide. 1.5 Refresh Token Why is the refresh token not simply treated as an access token for the access token resource in the authorization server? This would seem to simplify the model a bit by removing a type of token whose semantic (at least to this reviewer) is a duplication of a normal access token for a particular type of resource. Also in the first paragraph: "(access tokens may have a shorter lifetime and fewer permissions". Why not try to write normative language here - there are security implications of allowing a refresh token to get more permissions (say) than the original access token. 2.1 Client types I find the terminology public/confidential somewhat counter-intuitive. An app you have on your personal device is 'public' while a shared cloud service is 'confidential'...hmm... This section also lacks normative language which isn't good. There should be language defining the behavior of public and confidential client aswell as the three profiles. For instance under native application we have "It is assumed that any client authentication credentials included in the application can be extracted". This should really be normative language. Some of what I am looking for can be found in section 2.3 but it isn't clear to me that it covers the definition of the profiles. 2.3.1 Client Password There is also some confusion here about what the client must implement and what the server must implement wrt the use of client_id. I read the text as trying to say that Servers SHOULD support both and clients SHOULD only do Basic. This section also seems to have been the product of a partial s/password/credential/g operation. Either OAUTH is only meant to use Basic and passwords or we want to cover all/most HTTP authentication methods and credentials and then section 2.3.2 (which feels like an afterthought) needs to get folded into 2.3.1 and the normative language (and examples!) need some work to cover at least X.509s and perhaps even Negotiate. Personally I would try to fold 2.3.1 and 2.3.2 into one section and say that servers MUST support Basic and client_id+client_password. Servers MAY support any HTTP authentication method with a mapping to client_id. If a client supports username+passwords it SHOULD do Basic and if it supports other HTTP authentication methods it MUST NOT use client_password for anything and MUST follow normal HTTP authentication method negotiation. Finally, everywhere there is negotiation there must imho be some mention/discussion/protection of downgrade attacks. 3.1 Authorization Endpoints 6th paragraph: "The authorization server SHOULD ignore unrecognized request parameters". This formulation returns in several places in the document and I don't understand why it isn't a MUST - after all doesn't extensibility depend on this? 3.1.1 Response Type The response_type parameter is REQURED but its absence SHOULD result in an error. Why not MUST? 3.1.2 Redirection Endpoint There should be a clear normative specification for how to match endpoints. There are traces of this in various parts of the document when matching is discussed. I recommend making a concise definition in one place (namely here) and referencing this throughout. Since this comparison has security implications it should be a priority for the specification to be air-tight. 3.1.2.2 Registration Requirements "(the client MAY use the state request parameter to achieve per-request customization)". Doesn't this overload its use for CSRF-protection? 3.1.2.4 Invalid Endpoint "The authorization server SHOULD NOT redirect...". Why isn't this a MUST NOT? 3.1.2.5 Endpoint Content This section basically seems to say "Serve with server-side code not with html or client-side code". If this is the case then I suggest reformulate to say precisely that using normative language. The use of the word "script" could perhaps also be made less ambiguous since in this case it could refer to both server-side code aswell as in-browser code. 3.2.1 Client Authentication The phrase "clients issued client credentials" could be rephrased to make less violence on English - perhaps "clients that have been issued with client credentials", unless that is not the intended meaning in which case I argue for something easier to understand ;-) The second bullet: Using client credentials more often also exposes them more which might be worth mentioning aswell. 4. Obtaining Authorization Perhaps not critical but the term 'password credentials' occurs in the first paragraph and this doesn't seem compatible with resource owner authentication being out of scope. It could just be that it should read 'resource owner credentials' but it could also signal an underlying assumption about username and password being used for resource owner authentication. In either case I thing its best to avoid the use of the word 'password' to avoid any confusion. 4.1 Authorization Code (C) - "using the redirection URI provided earlier" should perhaps read "using the redirection URI provided earlier or associated with the client in client registration" 4.1.1 and 4.1.2 Authorization Request/Authorization Response The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but there is no mention in 4.1.2 how to handle the case when the redirect_uri is not present. I believe the assumption is that the redirect_uri is either resent or part of client registration but that needs to be made explicit in that case. This may apply to other uses of the redirect_uri parameter eg in 4.2.1. Furthermore in 4.2.2 "code" I suggest the following re-formulatation of the last sentence: "The client MUST NOT use an authorization code for more than one request. If an authorization code is re-used, the authorization server should treat that as a replay attack and SHOULD revoke all tokens associated with the client." (i.e loose the "attempt" bit which carries no real meaning) Also note that this is potentially a DOS attack should a single authz code leak. 4.1.2.1 Error Response First paragraph, last sentence "and MUST NOT automatically redirect". In the light of how willing users normally are to click on links presented to them I would strengthen this to "MUST prevent the user from following the redirect URI" In the definition of the invalid_request parameter I don't understand how unsupported parameters can generate an error since endpoints should ignore unsupported parameters (in order to support extensibility). 4.1.3 Access Token Request "require client authentication for confidential clients or for any client issued client credentials (or with other authentication requirements)" This text seems unnecessarily convoluted. Isn't enough to say that if you have issued credentials to a client you MUST require authentication from that client? This applies equally to the other sections where client authentication is an issue (eg 4.3.2). Also cf my comment on 3.1.2 for the discussion of matching redirect_uri in the last bullet: ".. and that their values are identical". Is this really meant to mean identical? 4.2 Implicit Grant The parenthesis "(it does not support the issuance of refresh tokens)" sounds like it should really be normative language, "refresh tokens MUST NOT be issues for implicit grant" because afaiu you could easily extend "fragment-transport" to include a refresh-token, so it isn't a technically motivated constraint, right? In (D) I would like to have a normative reference to a document that specifies browser behavior for URL fragments since this is a critical security dependency for this grant type. 4.4 Client Credentials I think the text should note that this model effectively implies that the client is able to impersonate all users which has the potential for worse security problems than if the client has access to individual user passwords. 6 Refreshing an Access Token scope - The term "lesser than" is intuitive but imprecise. I suggest "MUST NOT include any scope not originally granted by the resource owner". 7.1 and 8.1 Access Token Types The section 7.1 lists two definitions of access token types and provides a couple of examples but doesn't provide any constraints on future development of access tokens except in 8.1 where it is implied that not all access token types would be associated with HTTP authentication mechanisms. Are there really no constraints on access token types that should be captured? 10.6 Authorization Code Redirection URI Manipulation Suggest replace the word 'familiar' with 'trusted' in the first sentence of the second paragraph. The notion of trust opens up several boat loads of worm but it is the correct term here I think. In the third paragraph "the same as" wrt redirection URIs occur and this needs to be defined (cf comments on 3.1.2 above). Finally "The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URI". I am missing a discussion of why the two types of client differ wrt this attack vector. 10.10 Credentials Guessing Attack I found myself wanting implementation advice for how to generate good tokens at this point. This has been raised on the list too. The same goes for how to generate good CSRF cookies where the "(eg a hash of the session cookie..." feels like it is implementation advice yearning to come out of the closet. Thats it. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5uT+YACgkQ8Jx8FtbMZncXQgCfZmTlzuESq0plfpkceQN1ontE a1QAoIEcg06GYK+6Fn4y40cTL1jQ+KmS =ox42 -----END PGP SIGNATURE----- From eric.gray@ericsson.com Tue Sep 13 13:16:14 2011 Return-Path: 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 7DE3A21F8AF7; Tue, 13 Sep 2011 13:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 DdNKfWfVUozb; Tue, 13 Sep 2011 13:16:13 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D1FE221F8AF3; Tue, 13 Sep 2011 13:16:12 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8DKFtPt005060; Tue, 13 Sep 2011 15:18:19 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.158]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 13 Sep 2011 16:18:05 -0400 From: Eric Gray To: "adrian@olddog.co.uk" , "'Sandra Murphy'" , "secdir@ietf.org" , "iesg@ietf.org" Date: Tue, 13 Sep 2011 16:18:00 -0400 Thread-Topic: secdir review of draft-ietf-mpls-tp-on-demand-cv Thread-Index: AQHC/Ea6fmSr1RrxfxPRkMI0I+/BkAJv7qxxlUQ6KRCABvIykA== Message-ID: References: <013701cc6ee0$96fd15c0$c4f74140$@olddog.co.uk> In-Reply-To: <013701cc6ee0$96fd15c0$c4f74140$@olddog.co.uk> 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 20:16:14 -0000 Right. "SHALL NOT" -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Friday, September 09, 2011 7:07 AM To: 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 "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 E= ric > 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 th= e > 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 constructe= d > over varying packet switched nodes types, including MPLS as well as IP, s= o > could not count on the IP capability being present in any PW node. PWE3 > defined their own connection verification (VCCV - RFC5085) function, whic= h > 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. Bu= t > 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 th= e > "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 th= e > 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 thos= e > 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 ver= y > 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 proces= s > 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 gettin= g > 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 repl= y > 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 i= n > 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 From eric.gray@ericsson.com Tue Sep 13 13:24:08 2011 Return-Path: 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 To: Nitin Bahadur , "adrian@olddog.co.uk" , Sandra Murphy , "secdir@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: References: <013701cc6ee0$96fd15c0$c4f74140$@olddog.co.uk> In-Reply-To: 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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@ie= tf.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" 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 E= ric > 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 th= e > 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 constructe= d > over varying packet switched nodes types, including MPLS as well as IP, s= o > could not count on the IP capability being present in any PW node. PWE3 > defined their own connection verification (VCCV - RFC5085) function, whic= h > 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. Bu= t > 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 th= e > "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 th= e > 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 thos= e > 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 ver= y > 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 proces= s > 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 gettin= g > 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 repl= y > 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 i= n > 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 From stbryant@cisco.com Thu Sep 15 07:23:18 2011 Return-Path: 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 119E821F8B34; Thu, 15 Sep 2011 07:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.518 X-Spam-Level: X-Spam-Status: No, score=-110.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 lmEfsiV8g-t7; Thu, 15 Sep 2011 07:23:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C5A4B21F8B39; Thu, 15 Sep 2011 07:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=4970; q=dns/txt; s=iport; t=1316096728; x=1317306328; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=D6r0ACpwpeJczIQxB7AXwZWWJOpUwJR43JwTWXsannA=; b=A9q51T23gdnKVYBgXpswIut2LjLI7e9DRU+BAfv49Of35MiXah9OUv39 QlvO6NUWdpClvurziYmR/U1BUN5MkZaUYK38H8MEoZvoOvw/ZqjP/UQpY 4UeF3cY+UagDyLH2ZmjVEA+rEpZXN9Gz+mGWF7kfCNyYAGEwPEWWi8DO9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB8Kck6Q/khR/2dsb2JhbABDp014gVMBAQEBAgESAQIBIkABBQsLGAkWDwkDAgECAUUGDQEHAQEeh1UEmCMBgyYPAZpghnQEk0eRKw X-IronPort-AV: E=Sophos;i="4.68,387,1312156800"; d="scan'208";a="115606166" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 15 Sep 2011 14:25:27 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8FEPQqj027781; Thu, 15 Sep 2011 14:25:26 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p8FEPNdk008193; Thu, 15 Sep 2011 15:25:23 +0100 (BST) Message-ID: <4E720AD3.5030601@cisco.com> Date: Thu, 15 Sep 2011 15:25:23 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Glen Zorn References: <4E5A36CC.6070506@gmail.com> In-Reply-To: <4E5A36CC.6070506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: daniel@olddog.co.uk, "secdir@ietf.org" , pwe3-chairs@ietf.org, The IESG , adrian@olddog.co.uk, hongyu.lihongyu@huawei.com, robin@huawei.com Subject: Re: [secdir] secdir review of draft-li-pwe3-ms-pw-pon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 14:23:18 -0000 Glen Thank you for the review. On 28/08/2011 13:38, Glen Zorn wrote: > 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. > > I have virtually no knowledge of MPLS and no desire to acquire any. I > do know a little bit about PON, probably enough to be dangerous. For > these reasons I will not comment upon the technical aspects of the > document, instead limiting my comments to editorial issues and the > Security Considerations section. I do have one general question, > though: just out of curiosity, why is this not a pwe3 WG document? > > > EDITORIAL > > Abstract > > The acronym "MPLS" should be expanded on first use > > s/an MPLS Packet Switched Network/a MPLS Packet Switched Network/ "MPLS" is an IETF "well known term" hence expansion is not mandatory. http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > It is sometimes lamented that the people writing the IETF standards are > most often not the people implementing said standards. I think that > this may actually be a blessing in disguise, however: if the people > writing the standards really don't know the difference between a pointer > to an object (e.g, "[RFC3985]") and the object itself (RFC 3985), I > don't want them writing code! Actually I just cross checked this with a random recent RFC and it conforms to the current style. I think we need to leave it to the RFC editor to decide. > > Section 7.1 > > The references to G.987 and G.987.3 are formatted differently from > those for the other ITU-T documents Yes, perhaps the authors can pick this up on the next pass. > The references for RFC 3031, RFC 4447 and RFC 5036 are formatted > incorrectly (leading '"' and trailing '".' characters). Yes, perhaps the authors can pick this up on the next pass. > > SECURITY CONSIDERATIONS > > This section seems woefully inadequate to me. It is a single paragraph, > reproduced in full (with interspersed commentary) below. > > G-PON/XG-PON has its own security mechanism to guarantee each ONU is > isolated on the G-PON/XG-PON link layer. > > Where is the G-PON security mechanism defined? Presumably in one of the > 6 ITU-T standards referenced, but which one? See below I propose a couple of references. > > Other security issues are > unchanged from those applying as standard to PWs and MS-PWs. Please > refer to the referenced architectures and protocol specifications for > further details. > > One of the referenced architectures, specified in RFC 3895, says > > It is outside the scope of this > specification to fully analyze and review the risks of PWE3, > particularly as these risks will depend on the PSN. An example > should make the concern clear. A number of IETF standards employ > relatively weak security mechanisms when communicating nodes are > expected to be connected to the same local area network. The Virtual > Router Redundancy Protocol [RFC3768] is one instance. The relatively > weak security mechanisms represent a greater vulnerability in an > emulated Ethernet connected via a PW. > > This seems to me to specifically assign risk analysis and review of > novel pseudowires (which this would seem to be) to the designers of > such, but this draft does not show any evidence of that analysis. > This draft is not describing a PW type, but a method of using a new PSN type in a MS-PW. The security issues associated with a specific PW type is dealt with in the PW encapsulation spec for that PW type. These are out of scope of this draft. Thus the focus of the security section needs to be on any increased risk associated with using a PON rather than an MPLS segment. Looking at the references provided by the author, PON seems to be at least as good as MPLS when running over a secure datalink. Can propose the following revised security section: This document describes a variation of a multi-segment pseudowire running over an MPLS PSN, in which one or both of the MPLS PSNs that provide connectivity between a T-PE and its associated S-PE is replaced by a G-PON/XG-PON PSN. The security considerations that apply to the PW itself[RFC3985][RFC4385] are unchanged by this change in PSN type. For further considerations of PW security see the security considerations section of the specific PW type being deployed. G-PON/XG-PON [G.987.3][G.984.3]includes security mechanisms that are as good as those provided in a well secured MPLS PSN. The use of a G-PON/XG-PON PSN in place of an MPLS PSN therefore does not increase the security risk of a multi-segmnet pseudowire. - Stewart From turners@ieca.com Wed Sep 21 08:36:12 2011 Return-Path: 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 221215E800A for ; Wed, 21 Sep 2011 08:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.896 X-Spam-Level: X-Spam-Status: No, score=-100.896 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] 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 MCjPRIVf1Rmu for ; Wed, 21 Sep 2011 08:36:11 -0700 (PDT) Received: from nm23-vm0.bullet.mail.sp2.yahoo.com (nm23-vm0.bullet.mail.sp2.yahoo.com [98.139.91.224]) by ietfa.amsl.com (Postfix) with SMTP id 8B98E5E800C for ; Wed, 21 Sep 2011 08:36:11 -0700 (PDT) Received: from [98.139.91.62] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 21 Sep 2011 15:38:38 -0000 Received: from [98.139.91.13] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 21 Sep 2011 15:38:38 -0000 Received: from [127.0.0.1] by omp1013.mail.sp2.yahoo.com with NNFMP; 21 Sep 2011 15:38:38 -0000 X-Yahoo-Newman-Id: 132649.18104.bm@omp1013.mail.sp2.yahoo.com Received: (qmail 7253 invoked from network); 21 Sep 2011 15:38:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1316619518; bh=+jUhzAflAsfqHK93vyD3Z4WD82XGy8n2ng94rL+yaOk=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=5qXD9ZCSVs8jo6pSjE+UVNiJU6GAa5AgArJ843WZeNHDKlfKT4P/sBzg4cTsL50XDug3tSGPRlpDjLt0/6QfmkUbpRzF64NKTANXk4CjSfkj8hXIXGIp8iKR44iLKHisOofhk9VMJqVCXwnGCaJDBfqbjoYu7TCxOd+V2KFaIK4= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: rXN9Pt4VM1lGRgr_q5z1ADqmXWxmxlg5abwuSW2tSKPv93B Vzy2YdGJkzPbUCEIUQsYB.SWq4GglMLj3WHIGXjRMwgvs29wwVmLSTTdPG87 Ru8I_4SZ_q6PSGoioK1hq5.6i7ZhOfiovZm7kmQ0X7Dr.3GB.7vtAQkHWh5k 27H9mfnNBbm0YjYRuZiMkS2uGNp26Oo7drElrxyxCVeHBygmRNnXr8kbemD0 BIWp0.1oGXJK8L7hJ2DTtIhaf3baAmYMeaZZSSOw5wAbMX3CHZ8dda1.88_N LZOp49JYB4ee05d6A9D_6lrgunGl7BiYoBnJ.DJVRyJNhgTyIL_uJ1VTQ0sm 7Oi9qZ9SfQK4IeY0tVUD2RBwxbnYI3IYS4kUJkhGCWzzSyOi_y.gT.9gAT2s jPac8OqxF19eMemm2a1hQYq4Pnxgg0.yr6g16LfcJ2wCdCwD.3J3Q68gX_4q z3tXrEzlXVWAYUa66klnpXMXC.WHcF.6.2NkPmyKOQ_7QJ1YPqlD3D9iy07R jaIgACw-- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.local (turners@96.231.116.178 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 21 Sep 2011 08:38:37 -0700 PDT Message-ID: <4E7A04FC.2070808@ieca.com> Date: Wed, 21 Sep 2011 11:38:36 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] NETCONF Security Advisor X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 15:36:12 -0000 We're looking for a NETCONF WG security advisor. The WG's charter can be found here: http://datatracker.ietf.org/wg/netconf/charter/ If you're interested please contact Stephen or myself. spt From nitinb@juniper.net Fri Sep 9 09:25:36 2011 Return-Path: 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 B852921F8888; Fri, 9 Sep 2011 09:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 1wz-q0F78Igo; Fri, 9 Sep 2011 09:25:35 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE4721F86C1; Fri, 9 Sep 2011 09:25:22 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTmo+WaUQFVzb5cCD4GTleS+ktCowJnc9@postini.com; Fri, 09 Sep 2011 09:27:30 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 9 Sep 2011 09:26:38 -0700 From: Nitin Bahadur To: "adrian@olddog.co.uk" , Eric Gray , Sandra Murphy , "secdir@ietf.org" , "iesg@ietf.org" Date: Fri, 9 Sep 2011 09:26:37 -0700 Thread-Topic: secdir review of draft-ietf-mpls-tp-on-demand-cv Thread-Index: AQHC/Ea6fmSr1RrxfxPRkMI0I+/BkAJv7qxxlUQ6KRCAAGhSEw== Message-ID: In-Reply-To: <013701cc6ee0$96fd15c0$c4f74140$@olddog.co.uk> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 22 Sep 2011 08:04:08 -0700 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 16:25:36 -0000 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" 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 E= ric > 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 th= e > 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 constructe= d > over varying packet switched nodes types, including MPLS as well as IP, s= o > could not count on the IP capability being present in any PW node. PWE3 > defined their own connection verification (VCCV - RFC5085) function, whic= h > 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. Bu= t > 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 th= e > "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 th= e > 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 thos= e > 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 ver= y > 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 proces= s > 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 gettin= g > 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 repl= y > 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 i= n > 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 From eran@hueniverse.com Tue Sep 20 15:08:36 2011 Return-Path: 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 204F11F0C43 for ; Tue, 20 Sep 2011 15:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] 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 c4BQLcjG22Dk for ; Tue, 20 Sep 2011 15:08:36 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 7402821F8C2B for ; Tue, 20 Sep 2011 15:08:33 -0700 (PDT) Received: (qmail 21907 invoked from network); 20 Sep 2011 22:10:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Sep 2011 22:10:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 20 Sep 2011 15:10:49 -0700 From: Eran Hammer-Lahav To: Leif Johansson , "draft-ietf-oauth-v2@tools.ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" Date: Tue, 20 Sep 2011 15:10:39 -0700 Thread-Topic: secdir review of draft-ietf-oauth-v2 Thread-Index: AcxxejcLK5M7cRirTtqV4b97NCZawwGWSTgQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345213D92D58@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E6E4FEA.7090100@sunet.se> In-Reply-To: <4E6E4FEA.7090100@sunet.se> 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 X-Mailman-Approved-At: Thu, 22 Sep 2011 08:04:08 -0700 Subject: Re: [secdir] secdir review of draft-ietf-oauth-v2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 22:08:36 -0000 Thanks Leif. See comments inline. Whatever issues are still open will be addressed along= with the rest of the IETF LC feedback. EHL > -----Original Message----- > From: Leif Johansson [mailto:leifj@sunet.se] > Sent: Monday, September 12, 2011 11:31 AM > ** General observations: > > POST and/or GET > > Examples are sometimes POST and sometimes GET. In many cases it is not > clear to me from the surrounding text if both POST and GET are allowed or= if > only one is mandated. Illustrating with both a GET _and_ POST example in > the cases where both are supported would help or make the method explicit > in the text before the example. > > The P-word > > The term 'password' is sprinkled throughout the document, sometimes as in > "client password" or "resource owner password credentials" and I suspect > that sometimes it is password as in 'an example of a credential type' and= in > other cases it is password as in 'plain old password'. This needs to be c= leared > up throughout (I've included some examples below). > > Normative Language > > I've often found myself wanting more normative language often to replace > existing but less precise text. I've called out some important cases belo= w. > > Unknown parameters > > The sentence "The client SHOULD ignore unrecognized response > parameters" > occurs in several places. First of all I would argue that this has to be = a MUST if > you want to be able to guarantee extensibility. Secondly there are some > error responses that are triggered by unsupported request parameters. Thi= s > seems like an inconsistency. > > ** Specifics > > 1.1 Roles > > Forward references to the sections where the roles are defined would > improve readability. What sections? That's the only place these roles are defined. > As an illustration of an alternative model for the authorization server m= aybe > an informative reference to UMA would be illustrative here. A reference to UMA would be confusing in this document. > 1.2 Protocol Flow > > (A) talks about 'an intermediary such as an authorization server.' it isn= 't clear > it me if this refers to a separate authorization server or if it is the s= ame > authorization server that is referenced in (B). Changed to: (A) The client requests authorization from the resource owner= . The authorization request can be made directly to the resource owner (as shown), or pre= ferably indirectly via the authorization server as an intermediary. > 1.3.3 Resource Owner Password Credentials > > When I first read this I thought - why not talk about Resource Owner > Credentials - in fact there is a parenthesis there "(e.g a username and > password)" that seems to indicate that other credentials could be support= ed. > > This needs to be cleared up. Either its username and password and nothing > else or there is a way to support things like Negotiate or X.509-based > credentials in which case it should really be Resource Owner Credentials = with > no reference to passwords other than as as an example of one possible > credential type. Changed to: (i.e. username and password) This is explicitly just for username and password. Other types require an e= xtension. > 1.4 Access Token > > first paragraph: "The string is usually opaque". This should be reformula= ted as > normative language. In fact I would have liked guidance on generating tho= se > tokens (which has been brought up on the list) possibly as part of an > implementation-guide. There is not requirement for the string to be opaque, but the general archi= tecture assumes it is. Otherwise, please suggest language. > 1.5 Refresh Token > > Why is the refresh token not simply treated as an access token for the ac= cess > token resource in the authorization server? This would seem to simplify t= he > model a bit by removing a type of token whose semantic (at least to this > reviewer) is a duplication of a normal access token for a particular type= of > resource. Simpler architecture but probably more confusing to many developers. > Also in the first paragraph: "(access tokens may have a shorter lifetime = and > fewer permissions". Why not try to write normative language here - there > are security implications of allowing a refresh token to get more permiss= ions > (say) than the original access token. This was discussed before and we could not reach consensus. > 2.1 Client types > > I find the terminology public/confidential somewhat counter-intuitive. > An app you have on your personal device is 'public' while a shared cloud > service is 'confidential'...hmm... These are the best terms we could come up with. Not intuitive but well defi= ned. > This section also lacks normative language which isn't good. There should= be > language defining the behavior of public and confidential client aswell a= s the > three profiles. > > For instance under native application we have "It is assumed that any cli= ent > authentication credentials included in the application can be extracted".= This > should really be normative language. Some of what I am looking for can be > found in section 2.3 but it isn't clear to me that it covers the definiti= on of the > profiles. Please suggest text. > 2.3.1 Client Password > > There is also some confusion here about what the client must implement an= d > what the server must implement wrt the use of client_id. I read the text = as > trying to say that Servers SHOULD support both and clients SHOULD only do > Basic. We could not reach consensus beyond this. This language was carefully craft= ed to work around the disagreements about what is required and what is not. > This section also seems to have been the product of a partial > s/password/credential/g operation. Either OAUTH is only meant to use Basi= c > and passwords or we want to cover all/most HTTP authentication methods > and credentials and then section 2.3.2 (which feels like an > afterthought) needs to get folded into 2.3.1 and the normative language > (and examples!) need some work to cover at least X.509s and perhaps even > Negotiate. When we say password we mean 'plain old password'. Any other types of crede= ntials are not covered by design. > Personally I would try to fold 2.3.1 and 2.3.2 into one section and say t= hat > servers MUST support Basic and client_id+client_password. Servers MAY > support any HTTP authentication method with a mapping to client_id. > If a client supports username+passwords it SHOULD do Basic and if it > supports other HTTP authentication methods it MUST NOT use > client_password for anything and MUST follow normal HTTP authentication > method negotiation. > > Finally, everywhere there is negotiation there must imho be some > mention/discussion/protection of downgrade attacks. Downgrade attacks security section sounds useful. Text? > 3.1 Authorization Endpoints > > 6th paragraph: "The authorization server SHOULD ignore unrecognized > request parameters". This formulation returns in several places in the > document and I don't understand why it isn't a MUST - after all doesn't > extensibility depend on this? I don't have an objection, but extensibility isn't currently required. > 3.1.1 Response Type > > The response_type parameter is REQURED but its absence SHOULD result in > an error. Why not MUST? This is an OAuth 1.0 legacy of not mandating a particular error behavior. M= UST seems like the right language - any objections? > 3.1.2 Redirection Endpoint > > There should be a clear normative specification for how to match endpoin= ts. > There are traces of this in various parts of the document when matching i= s > discussed. I recommend making a concise definition in one place (namely > here) and referencing this throughout. Since this comparison has security > implications it should be a priority for the specification to be air-tigh= t. This has been discussed by the WG and no consensus was reached. We can reco= nsider if someone submits proposed text. > 3.1.2.2 Registration Requirements > > "(the client MAY use the state request parameter to achieve per-request > customization)". Doesn't this overload its use for CSRF-protection? Yep. That's intentional. > 3.1.2.4 Invalid Endpoint > > "The authorization server SHOULD NOT redirect...". Why isn't this a MUST > NOT? I'm ok with MUST NOT - any objections? > 3.1.2.5 Endpoint Content > > This section basically seems to say "Serve with server-side code not with= html > or client-side code". If this is the case then I suggest reformulate to s= ay > precisely that using normative language. > > The use of the word "script" could perhaps also be made less ambiguous > since in this case it could refer to both server-side code aswell as in-b= rowser > code. This is only about the HTML response sent back to the user-agent. This is a= bout including something like 'Share on Twitter/Facebook' widget on a page = with an access token in the URI fragment (which has caused tokens to leak t= o Twitter in some cases). > 3.2.1 Client Authentication > > The phrase "clients issued client credentials" could be rephrased to make= less > violence on English - perhaps "clients that have been issued with client > credentials", unless that is not the intended meaning in which case I arg= ue > for something easier to understand ;-) Ok. > The second bullet: Using client credentials more often also exposes them > more which might be worth mentioning aswell. Proposed text? > 4. Obtaining Authorization > > Perhaps not critical but the term 'password credentials' occurs in the fi= rst > paragraph and this doesn't seem compatible with resource owner > authentication being out of scope. It could just be that it should read > 'resource owner credentials' but it could also signal an underlying assum= ption > about username and password being used for resource owner > authentication. In either case I thing its best to avoid the use of the w= ord > 'password' to avoid any confusion. Password is intentional. This is a special case for passwords. > 4.1 Authorization Code > > (C) - "using the redirection URI provided earlier" should perhaps read "u= sing > the redirection URI provided earlier or associated with the client in cli= ent > registration" Changed to: Assuming the resource owner grants access, the authorization = server redirects the user-agent back to the client using the redirection URI provi= ded earlier (in the request or during client registration). The redirection URI i= ncludes an authorization code and any local state provided by the client earlier. > 4.1.1 and 4.1.2 Authorization Request/Authorization Response > > The redirect_uri is listed as OPTIONAL with a reference to 3.1.2 but ther= e is > no mention in 4.1.2 how to handle the case when the redirect_uri is not > present. I believe the assumption is that the redirect_uri is either rese= nt or > part of client registration but that needs to be made explicit in that ca= se. 3.1.2 describe how to handle this parameter. > This may apply to other uses of the redirect_uri parameter eg in 4.2.1. > > Furthermore in 4.2.2 "code" I suggest the following re-formulatation of t= he > last sentence: "The client MUST NOT use an authorization code for more > than one request. If an authorization code is re-used, the authorization > server should treat that as a replay attack and SHOULD revoke all tokens > associated with the client." (i.e loose the "attempt" > bit which carries no real meaning) Changed to server MUST not allow reuse based on previous feedback. Not sure= treating it as an attack is the right language, but the normative language= is the same either way (about revoking tokens). > Also note that this is potentially a DOS attack should a single authz cod= e leak. Explain? > 4.1.2.1 Error Response > > First paragraph, last sentence "and MUST NOT automatically redirect". In = the > light of how willing users normally are to click on links presented to th= em I > would strengthen this to "MUST prevent the user from following the redire= ct > URI" Not sure what you mean. > In the definition of the invalid_request parameter I don't understand how > unsupported parameters can generate an error since endpoints should > ignore unsupported parameters (in order to support extensibility). Good catch. Dropped 'unsupported parameter' part. > 4.1.3 Access Token Request > > "require client authentication for confidential clients or for any client= issued > client credentials (or with other authentication requirements)" > > This text seems unnecessarily convoluted. Isn't enough to say that if you > have issued credentials to a client you MUST require authentication from > that client? This applies equally to the other sections where client > authentication is an issue (eg 4.3.2). I felt it was important to call out confidential clients explicitly, but I = agree that if we require issuing credentials to such clients, this can be m= ade simpler. What do other think? The same end result, but different emphas= is. > Also cf my comment on 3.1.2 for the discussion of matching redirect_uri i= n > the last bullet: ".. and that their values are identical". Is this really= meant to > mean identical? Here yes. String comparison. > 4.2 Implicit Grant > > The parenthesis "(it does not support the issuance of refresh tokens)" > sounds like it should really be normative language, "refresh tokens MUST > NOT be issues for implicit grant" because afaiu you could easily extend > "fragment-transport" to include a refresh-token, so it isn't a technicall= y > motivated constraint, right? Instead I added this to 4.2.2: The authorization server MUST NOT issue a refresh token. > In (D) I would like to have a normative reference to a document that > specifies browser behavior for URL fragments since this is a critical sec= urity > dependency for this grant type. That's RFC2616. Seems odd to reference it here. > 4.4 Client Credentials > > I think the text should note that this model effectively implies that the= client > is able to impersonate all users which has the potential for worse securi= ty > problems than if the client has access to individual user passwords. Worse how? You can't use this with resource owner password. > 6 Refreshing an Access Token > > scope - The term "lesser than" is intuitive but imprecise. I suggest "MUS= T > NOT include any scope not originally granted by the resource owner". Ok. > 7.1 and 8.1 Access Token Types > > The section 7.1 lists two definitions of access token types and provides = a > couple of examples but doesn't provide any constraints on future > development of access tokens except in 8.1 where it is implied that not a= ll > access token types would be associated with HTTP authentication > mechanisms. Are there really no constraints on access token types that > should be captured? None suggested. > 10.6 Authorization Code Redirection URI Manipulation > > Suggest replace the word 'familiar' with 'trusted' in the first sentence = of the > second paragraph. The notion of trust opens up several boat loads of worm > but it is the correct term here I think. Ok. > In the third paragraph "the same as" wrt redirection URIs occur and this > needs to be defined (cf comments on 3.1.2 above). Changed to identical. > Finally "The authorization server MUST require public clients and SHOULD > require confidential clients to register their redirection URI". I am mis= sing a > discussion of why the two types of client differ wrt this attack vector. Public clients rely on the registration to provide a minimal level of clien= t identification while confidential clients are later authenticated which c= an mitigate redirection URI manipulation. > 10.10 Credentials Guessing Attack > > I found myself wanting implementation advice for how to generate good > tokens at this point. This has been raised on the list too. The same goes= for > how to generate good CSRF cookies where the "(eg a hash of the session > cookie..." feels like it is implementation advice yearning to come out of= the > closet. Need someone to suggest text. EHL