[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 draft-ietf-pce-path-key

   Networking Working Group                        Rich Bradford (Ed)
   IETF Internet Draft                                    JP Vasseur
                                                  Cisco Systems, Inc.
                                                        Adrian Farrel
                                                   Old Dog Consulting



   Proposed Status: Standard
   Expires: December 2006
                                                           June 2006



                  draft-bradford-pce-path-key-00.txt


   Preserving Topology Confidentiality in Inter-Domain Path
   Computation and Signaling

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-pce-path-key-00.txt                        June 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.

   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,
   thus disclosing internal topology information. This issue may be
   circumvented by returning a loose hop and by invoking a new path
   computation from the domain boundary LSR during TE LSP setup as
   the LSP enters the second domain, but this technique has several
   issues including the problem of maintaining path diversity.

   This document defines a mechanism to hide the contents of a
   segment of a path, called the Confidential Path Segment (CPS). The
   CPS may be replaced by a path key that can be conveyed in the PCE
   Communication Protocol (PCEP) and signaled within in a Resource
   Reservation Protocol (RSVP) 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.      Note

   It must be noted that this document proposes RSVP-TE and PCEP
   protocol extensions and may 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-bradford-pce-path-key-00.txt                        June 2006

   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.

   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 path
   computation of inter-domain Multiprotocol Label Switching (MPLS)
   traffic engineering (TE) Label Switched Paths (LSPs).

   An important element of inter-domain TE is that TE information is
   not usually shared between domains for scalability and
   confidentiality reasons ([RFC4105] and [RFC4216]). 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. Such a path computation procedure is
   described in [BRPC].

   If confidentiality is required between domains (such as would very
   likely be the case between ASs belonging to different service
   providers) then cooperating PCEs cannot exchange path segments or
   else the receiving 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).

Bradford, Vasseur, and Farrel                                        3

draft-bradford-pce-path-key-00.txt                        June 2006


   One mechanism for preserving the confidentiality of the CPS is for
   the PCE to return a path containing a loose hop for the segment
   internal to a domain that must be kept confidential. The concept
   of loose hops for the route of an LSP is described in [RFC3209].
   The Path Computation Element 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 since the LSRs in
   charge of expanding the EROs are not synchronized.

   Therefore, using the loose hop technique, path segment
   confidentiality and path diversity are mutually incompatible
   requirements.

   This document defines the notion of a Path Key that is a token
   that replaces a path segment in an explicit route. The Path Key
   can be encoded as a Path Key Sub-object (PKS) which can be
   exchanged in PCEP [PCEP] for PCE path computation results and
   subsequent computation requests, and in RSVP-TE [RFC3209] for
   signaling of explicit paths. The PKS may also, optionally, be used
   in recorded routes in RSVP-TE.

   The next section provides the details for this solution.

4.      Path-Key Solution

   The Path-Key solution may be applied in the PCE-based path
   computation context as follows. A PCE computes a path segment and
   replaces it in the path reported to the PCC (or another PCE) by
   one or more sub-objects referred to as the PKS. The entry and
   boundary LSR of each CPS SHOULD be specified as hops in the


Bradford, Vasseur, and Farrel                                        4

draft-bradford-pce-path-key-00.txt                        June 2006

   returned path immediately preceding the PKS, but where two PKSs
   are supplied in sequence the entry node to the second MAY be
   encoded within the first. The exit node of a CPS MAY be present as
   a strict hop immediately following the PKS, but MAY also be hidden
   as part of the PKS and through the use of a subsequent loose hop.

   The PKS, itself, MAY be supplied as a loose hop, but is
   RECOMMENDED to be used as a strict hop immediately following the
   hop that indicates the boundary LSR.

4.1.   Mode of Operation

   During path computation, when local policy dictates that
   confidentiality must be preserved for all or part of the path
   segment being computed, the PCE associates a path-key with the
   computed path for the CPS, places its own identifier (its PCE-ID)
   along with the path-key in a PKS, and inserts the PKS in the path
   returned to the PCC or the collaborating PCE immediately after the
   sub-object that identifies the LSR that will expand the PKS into a
   explicit path hops. This will usually be the LSR that is the start
   point of the CPS. The PCE that generates a PKS 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.
   TBD: Need to define the scope of the PKS and spell out the
   restrictions on Path Key re-use.

   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 start of the CPS which will usually be the
   domain boundary. The PKS MUST be preceded by an ERO sub-object
   that identifies the LSR that must expand the PKS, so the PKS will
   not be encountered in ERO processing until the LSR that can
   process it.

   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 the details of which will be described in a
   further revision of this document.

   Upon receiving the path query, 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

Bradford, Vasseur, and Farrel                                        5

draft-bradford-pce-path-key-00.txt                        June 2006

   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.      PCEP/RSVP-TE Path Key Sub-object


   The Path Key sub-object (PKS) may be carried in the Explicit Route
   Object (ERO) of a PCEP PCRep message [PCEP] or an  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 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


Bradford, Vasseur, and Farrel                                        6

draft-bradford-pce-path-key-00.txt                        June 2006

   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

           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.


6.      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).


Bradford, Vasseur, and Farrel                                        7

draft-bradford-pce-path-key-00.txt                        June 2006

7.      Manageability Considerations

   TBD

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.


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.




Bradford, Vasseur, and Farrel                                        8

draft-bradford-pce-path-key-00.txt                        June 2006

   [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
   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.



11.                              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

Bradford, Vasseur, and Farrel                                        9

draft-bradford-pce-path-key-00.txt                        June 2006

   USA
   Email: jpv@cisco.com

   Adrian Farrel
   Old Dog Consulting
   EMail:  adrian@olddog.co.uk













   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                                       10


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/