Networking Working Group Rich Bradford (Ed) IETF Internet Draft JP Vasseur (Ed) Cisco Systems, Inc. Adrian Farrel Old Dog Consulting Proposed Status: Standard Expires: August 2006 February 2006 draft-rbradfor-ccamp-confidential-segment-00.txt Protocol Extensions for Signaling Confidential Path Segments in Multiprotocol Label Switching Traffic Engineering. Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Bradford, Vasseur et al. 1 draft-rbradfor-ccamp-confidential-segment-00.txt February 2006 Abstract Routes for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the LSP crosses multiple domains such as Autonomous Systems (ASs) the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases such as when ASs are administered by separate Service Providers, it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary LSR during LSP setup as the LSP enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document allows a PCE to provide a full path, but to hide the contents of a segment of that path called the Confidential Path Segment (CPS). The CPS may be conveyed in the PCE Communication Protocol (PCEP) and signaled in a Resource Reservation Protocol (RSVP) explicit route either by replacing it with a path key or by encrypting it. Table of contents To be Added Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 1. Note It must be noted that this document proposes RSVP-TE and PCEP protocol extensions and will eventually result in two separate documents to be discussed in the CCAMP and PCE Working Groups respectively. 2. Terminology ASBR Routers: border routers used to connect to another AS of a different or the same Service Provider via one or more links inter- connecting between ASs. Bradford, Vasseur, and Farrel 2 draft-rbradfor-ccamp-confidential-segment-00.txt February 2006 CPS: Confidential Path Segment. A segment of a calculated path which contains nodes and links internal to an AS and which the AS policy requires not to be disclosed outside the AS. Inter-AS TE LSP: A TE LSP that crosses an AS boundary. LSR: Label Switching Router. LSP: Label Switched Path. PCC: Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element. PCE: Path Computation Element: an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. TE LSP: Traffic Engineering Label Switched Path 3. Introduction Path computation techniques using the Path Computation Element (PCE) have been described in [PCE-ARCH] and allow for optimal path computation of inter-domain Multiprotocol (MPLS) traffic engineering (TE) Label Switched Paths (LSPs). An important element of inter-domain TE is that TE information is not shared between domains for scalability and confidentiality reasons. Therefore, a single PCE is unlikely to be able to compute a full inter-domain path. Two routing scenarios can be used for inter-domain TE LSPs: one using per-domain path computation (defined in [PD-PATH-COMP]), and the other using a PCE-based path computation technique with cooperation between PCEs (as described in [PCE-ARCH]). In this second case, paths for inter-domain LSPs are computed by cooperation between PCEs each of which computes a segment of the path across one domain. If confidentiality is required between domains (such as would very likely be the case between ASs) then cooperating PCEs cannot exchange path segments or else the PCE and the Path Computation Client (PCC) will be able to see the individual hops through another domain. We define the part of the path which we wish to keep confidential as the Confidential Path Segment (CPS). One mechanism for preserving the confidentiality of the CPS is for the PCE to return a path consisting of loose hops for the segment internal to a domain. The concept of loose hops for the route of an LSP is described in [RFC3209]. The Path Computation Element Bradford, Vasseur, and Farrel 3 draft-rbradfor-ccamp-confidential-segment-00.txt February 2006 Communication Protocol (PCEP) supports the use of paths with loose hops and it is a local policy decision at a PCE whether it returns a full explicit path or uses loose hops. If loose hops are used, the TE LSPs are signaled as normal [RFC3209] and when a loose hop is encountered in the explicit route it is resolved by performing a secondary path computation. Given the nature of the cooperation between PCEs in computing the original path, this secondary computation occurs at a Label Switching Router (LSR) at a domain boundary and the route is expanded as described in [PD-PATH- COMP]. The PCE-based computation model is particularly useful for determining mutually disjoint inter-domain paths such as might be required for service protection. A single path computation request is used. However, if loose hops are returned, the path of each LSP must be recomputed at the domain boundaries as the LSPs are signaled, and since the LSP signaling proceeds independently for each LSP, disjoint paths cannot be guaranteed. Therefore, using existing techniques, confidentiality and path diversity are mutually incompatible requirements. This document defines two solutions, each extending the Explicit Route Object defined in [RFC3209] with a new sub-object. The first solution preserves confidentiality by encrypting the path for the CPS into a Private Route sub-object (PRS). The second solution preserves confidentiality by replacing the CPS segment with a Path Key sub- object (PKS), which is used to retrieve the computed path segment. The next sections provide the details for the PKS and PRS solutions. 4. Path-Key Solution The Path-Key solution applies exclusively to the PCE-based path computation context. A PCE computes a path segment and replaces it in the path reported to the PCC (or another PCE) by a single sub-object referred to as the PKS. The entry and exit boundary LSRs of each CPS MUST be specified as strict nodes in the returned path - only the path segments strictly between these boundary routers are replaced by the PKS. 4.1. Mode of Operation Bradford, Vasseur, and Farrel 4 draft-rbradfor-ccamp-confidential-segment-00.txt February 2006 During path computation, when local policy dictates that confidentiality must be preserved, the PCE associates a path-key with the computed path for the CPS, inserts its PCE-ID along with the path-key in a PKS, and inserts the PKS in between the sub-objects that identify the start and end points of the CPS in the path returned to the PCC. The PCE MUST store the computed path segment and the path-key for later retrieval. A local policy SHOULD be used to determine for how long to retain such stored information and whether to discard the information after it has been queried using the procedures described below. A head-end LSR that is a PCC converts the path returned by a PCE into an explicit route object (ERO) that it includes in the Resource Reservation Protocol (RSVP) Path message. If the path returned by the PCE contains PKSs these are included in the ERO. Like any other sub- objects, the PKS is passed transparently from hop to hop, until it becomes the first sub-object in the ERO. This will occur at the domain boundary. The PKS MUST be preceded by an ERO sub-object that identifies the start of the CPS and so the PKS will not be encountered in ERO processing until the LSR at the start of the CPS attempts to evaluate the next hop along the path of the LSP. An LSR that encounters a PKS when trying to identify the next-hop retrieves the PCE-ID from the PKS and sends the path-key to the PCE in a PCEP query. Upon receiving the path computation request, the PCE identifies the computed path segment using the supplied path-key, and returns the previously computed path segment in the form of explicit hops to the requesting node. The requesting node inserts the explicit hops into the ERO and continues to process the LSP setup as per [RFC3209]. Note that if a PCE fails to expand a PKS, the requesting LSR MUST fail the LSP setup and SHOULD use the procedures associated with loose hop expansion failure [RFC3209]. 5. Encrypted Path Segment Solution This section describes the mechanism where the LSR or PCE encrypts path of a CPS(s) in order to preserve confidentiality. Following the complete route calculation for a given domain, the PCE encrypts the path for the CPS using a locally configured encryption technique and places the resulting information into a PRS. The path returned to the PCC contains sub-objects identifying the start and end of the CPS, but the path between these points is replaced by the PRS. Bradford, Vasseur, and Farrel 5 draft-rbradfor-ccamp-confidential-segment-00.txt February 2006 The head-end LSR (PCC) includes the path supplied by the PCE in its signaling message encoded as an ERO just as normal. When an LSR encounters a PRS in the ERO during next hop resolution, the LSR attempts to extract the CPS from the PRS by decrypting the information. If an ingress node fails to expand a PRS, the LSP setup MUST be rejected using a PathErr message carrying the Error Code PRS object supported but unknown key. Each domain could be configured to use its own encryption method, so that if a route spans several domains, each encrypted CPS could be encrypted using a different algorithm as well as a different key. Decryption could be available on domain boundary LSRs or could require the consultation of a PCE according to domain policy. Since the PCE is aware of the LSR that will attempt decryption, it MAY select a key that is known by that LSR. Indeed, the PCE's choice of encryption method and key is a matter of configurable policy on each PCE and could allow: - Using a single encryption method and key for an entire domain. - Using an encryption method and key for a specific group of LSR interfaces. For example, all the LSR interfaces that connect to Customer A could use one key, and all those that connect to Customer B could use a different key. This method would allow the encryption to be disabled or for the keys to be made available to a third-party for purposes of monitoring, debugging, or route validation, without the information being made available about paths computed to other customers. - Use an encryption method and key specific to an LSR or group of LSRs. This would allow, for example, every LSR that might be the start of a CPS within the domain (nominally, every domain border LSR) to share a unique public key with the PCE, providing every LSR with independent encryption. The PRS is defined to allow multiple encryption options, but as a minimum MUST support AES with a 128-bit key as defined in the NIST CBC definition from [CBC], along with the padding method defined in Appendix A of that document. In addition, to provide adequate message authentication, the encryption MUST also adhere to the AES CMAC as described in [CMAC]: 6. PCEP/RSVP-TE Object extensions Two extensions to the ERO are defined. Each requires the addition of a new sub-object. Each sub-object is used to represent an entire CPS. 6.1. Path Key Sub-object Bradford, Vasseur, and Farrel 6 draft-rbradfor-ccamp-confidential-segment-00.txt February 2006 The Path Key sub-object (PKS) is carried within the ERO of the PCEP PCRep message [PCEP] and the ERO of the RSVP-TE Path message [RFC3209]. The PKS is a fixed-length sub-object containing a Path-Key and a PCE-ID. The Path Key is an identifier, or token used to represent the CPS within the context of the PCE identified by the PCE-ID. The PCE-ID identifies the PCE that encoded and can decode the Path Key using an IPv4 or IPv6 address of the PCE. Because of the IPv4 and IPv6 variants, two subobjects are defined as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Path Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L The L bit MUST NOT be set, so that the sub-object represents a strict hop in the explicit route. Type TBD Path Key with IPv4 address Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 8. IPv4 address An IPv4 address of the PCE that can decode this key. The address used SHOULD be an address of the PCE that is always reachable, but MAY be an address that is restricted to the domain in which the CPS lies. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Path Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (16 bytes) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bradford, Vasseur, and Farrel 7 draft-rbradfor-ccamp-confidential-segment-00.txt February 2006 L The L bit MUST NOT be set, so that the sub-object represents a strict hop in the explicit route. Type TBD Path Key with IPv6 address Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 20. IPv6 address An IPv6 address of the PCE that can decode this key. The address used SHOULD be an address of the PCE that is always reachable, but MAY be an address that is restricted to the domain in which the CPS lies. 6.2. Private Route Sub-object The Private Route Subobject (PRS) is carried within the ERO of the PCEP PCRep message [PCEP] and the ERO of the RSVP-TE Path message [RFC3209]. The PRS is a variable length sub-object containing an encryption type field to specify the encryption algorithm configured that was used and the encrypted path. The sub-object is padded with trailing zeros as necessary to align it with a four-byte boundary. The sub-object is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Encryption | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Encrypted Path ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L The L bit MUST NOT be set, so that the sub-object represents a strict hop in the explicit route. Type Bradford, Vasseur, and Farrel 8 draft-rbradfor-ccamp-confidential-segment-00.txt February 2006 TBD Encrypted Path Length The Length contains the total length of the subobject in bytes, including the Type and Length fields, and including any trailing zero pads. Encrypted Path The encrypted path segment. This field is padded with trailing zeros to make the sub-object a multiple of four bytes long. 7. Security Considerations This document proposes tunneling secure topology information across an untrusted AS, so the considerations are many. Issues include: - Security of the CPS. - Authenticity of the CPS (resilience to alteration by intermediaries). - Resilience from DNS attacks. 8. IANA considerations The IANA section will be detailed in further revision of this document. For RSVP, it will include code point requests for the three new ERO sub-objects, and a new ErrorSpec Error Code. For PCEP, it will include code point requests for the three new computed path sub-objects. Bradford, Vasseur, and Farrel 9 draft-rbradfor-ccamp-confidential-segment-00.txt February 2006 9. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element (PCE) communication Protocol (PCEP)", draft-vasseur-pce-pcep, work in progress. 10.2. Informational References [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation Element (PCE) Architecture", draft-ietf-pce-architecture, work in progress. [PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation method for establishing Inter-domain Traffic Engineering (TE) Label Bradford, Vasseur, and Farrel 10 draft-rbradfor-ccamp-confidential-segment-00.txt February 2006 Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path-comp, work in progress. [RBPC] Vasseur, J., et al "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Path", draft-vasseur-ccamp-brpc, work in progress. [CBC] Morris Dworkin, "Recommendation for Block Cipher Modes of Operation Methods and Techniques", http://csrc.nist.gov/CryptoToolkit/modes/800- 38_Series_Publications/SP800-38A.pdf [CMAC] Morris Dworkin, "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", http://csrc.nist.gov/CryptoToolkit/modes/800- 38_Series_Publications/SP800-38B.pdf 11. Authors' Addresses: Rich Bradford (Editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough , MA - 01719 USA Email: rbradfor@cisco.com J.-P Vasseur (Editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough , MA - 01719 USA Email: jpv@cisco.com Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Bradford, Vasseur, and Farrel 11 draft-rbradfor-ccamp-confidential-segment-00.txt February 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Bradford, Vasseur, and Farrel 12