Networking Working Group                        Rich Bradford (Ed) 
   IETF Internet Draft                                    JP Vasseur 
                                                  Cisco Systems, Inc. 
                                                        Adrian Farrel 
                                                   Old Dog Consulting 
       
    
    
   Proposed Status: Standard 
   Expires: April 2007                                                
                                                      October 2006 
    
    
                                    
              draft-bradford-ccamp-path-key-ero-00.txt 
    
    
                  RSVP Extensions for Path Key Support 
                                     
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 and Farrel                                        1 
 
 
draft-bradford-ccamp-path-key-ero-00.txt              September 2006 
 
   Abstract 
    
   Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) 
   Label Switched Paths (LSPs) may be computed by Path Computation 
   Elements (PCEs). Where the TE 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. To preserve confidentiality of topology with each AS, 
   the PCE supports a mechanism to hide the contents of a segment of 
   a path, called the Confidential Path Segment (CPS), by encoding 
   the contents as a Path Key Sub-object (PKS). This draft describes 
   the addition of this object to the Explicit Route Object. 
    
    
    
   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.  Introduction 
    
   This document proposes RSVP-TE protocol extensions necessary to 
   support the protocol extensions called out in [PCE-PKS]. 
    
2.  Terminology 
     
   CPS: Confidential Path Segment. A segment of a path that contains 
   nodes and links that the AS policy requires to not be disclosed 
   outside the AS. 
    
   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. 
    
   PKS: Path Key Sub-object. A sub-object of an Explicit Route Object 
   which encodes a CPS, so as to preserve confidentiality. 
    
3.  RSVP-TE Path Key Sub-object 
    
    
   The Path Key sub-object (PKS) may be carried in the Explicit Route 
   Object (ERO) of a RSVP-TE Path message [RFC3209]. The PKS is a 
 
Bradford, Vasseur, and Farrel                                       2 
 
 
draft-bradford-ccamp-path-key-ero-00.txt              September 2006 
 
   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 can decode the Path Key using a reachable 
   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 SHOULD 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, and MAY be an address that is restricted to the domain 
   in which the LSR that is called upon to expand 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)                    | 
    |                                                               | 
    |                                                               | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
       L 
 
Bradford, Vasseur, and Farrel                                       3 
 
 
draft-bradford-ccamp-path-key-ero-00.txt              September 2006 
 
    
           As above. 
    
       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 LSR that is called upon to expand the CPS lies. 
    
   Note: The twins of these sub-objects will be carried in a PCEP 
   PCRep message as defined in [PCE-PKS]. Ideally, IANA assignment of 
   the sub-object types will be identical. 
    
4.  Security Considerations 
    
   This document proposes tunneling secure topology information 
   across an untrusted AS, so the security considerations are many 
   and apply to PCEP and RSVP-TE. 
   Issues include: 
  - Security of the CPS (can other network elements probe for 
     expansion of path-keys, possibly at random?). 
  - Authenticity of the path-key (resilience to alteration by 
     intermediaries, resilience to fake expansion of path-keys). 
  - Resilience from DNS attacks (insertion of spurious path-keys; 
     flooding of bogus path-key expansion requests). 
    
5.  Manageability Considerations 
    
   TBD 
    
6.  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. 
    
 
Bradford, Vasseur, and Farrel                                       4 
 
 
draft-bradford-ccamp-path-key-ero-00.txt              September 2006 
 
   For PCEP, it will include code point requests for the three new 
   computed path sub-objects. 
    
    
7.  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. 
    
8.  References 
    
8.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. 
    
   [PCE-PKS] Bradford, R., Vasseur, J.P., Farrel, A., "Preserving 
   Topology Confidentiality in Inter-Domain Path Computation and 
   Signaling", draft-bradford-pce-path-key, 
   work in progress. 
    
 
Bradford, Vasseur, and Farrel                                       5 
 
 
draft-bradford-ccamp-path-key-ero-00.txt              September 2006 
 
    
      
8.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 Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-
   path-comp, work in progress. 
    
   [BRPC] Vasseur, J., et al "A Backward Recursive PCE-based 
   Computation (BRPC) procedure to compute shortest inter-domain 
   Traffic Engineering Label Switched Path", draft-vasseur-pce-brpc, 
   work in progress. 
    
   [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for 
   Support of Inter-Area and Inter-AS MPLS Traffic Engineering", RFC 
   4105, June 2005. 
    
   [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic 
   Engineering requirements", RFC 4216, November 2005. 
    
    
    
9.  Authors' Addresses: 
    
   Rich Bradford (Editor) 
   Cisco Systems, Inc. 
   1414 Massachusetts Avenue 
   Boxborough , MA - 01719 
   USA 
   Email: rbradfor@cisco.com 
    
   J.-P Vasseur 
   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                                       6 
 
 
draft-bradford-ccamp-path-key-ero-00.txt              September 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                                       7