WDIFF

draft-ietf-pce-path-key-06.txt --> rfc5520.txt

Network Working Group Rich Bradford (Ed)
Internet-Draft JP R. Bradford, Ed.
Request for Comments: 5520 JP. Vasseur
Intended Status:
Category: Standards Track Cisco Systems, Inc.
Created: March 7, 2009 Adrian
A. Farrel
Expires: September 7, 2009
Old Dog Consulting
April 2009

Preserving Topology Confidentiality in
Inter-Domain Path Computation Using a Key-Based Path-Key-Based Mechanism

draft-ietf-pce-path-key-06.txt

Status of this This Memo

This Internet-Draft is submitted to IETF in full conformance with document specifies an Internet standards track protocol for the provisions of BCP 78
Internet community, and BCP 79.

Internet-Drafts are working documents requests discussion and suggestions for
improvements. Please refer to the current edition 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 "Internet
Official Protocol Standards" (STD 1) for a maximum the standardization state
and status of this protocol. Distribution of six months this memo is unlimited.

Copyright (c) 2009 IETF Trust and may be updated, replaced, or obsoleted by other documents at any
time. It the persons identified as the
document authors. All rights reserved.

This document is inappropriate subject to use Internet-Drafts as reference
material or BCP 78 and the IETF Trust's Legal
Provisions Relating to cite them other than as "work IETF Documents in progress."

The list effect on the date of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list
publication of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Abstract

Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
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 (ASes), the path may be
computed by multiple PCEs that cooperate, with each responsible for
computing a segment of the path. However, in some cases (e.g., when
ASes 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 AS-internal topology information.
This issue may be circumvented by returning a loose hop and by
invoking a new path computation from the domain boundary Label
Switching Router (LSR) during TE LSP setup as the signaling message
enters the second domain, but this technique has several issues
including the problem of maintaining path diversity.

Bradford, Vasseur and Farrel et al. Standards Track [Page 1]

draft-ietf-pce-path-key-06.txt March

RFC 5520 Preserving Topology Confidentiality April 2009

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 TE (RSVP-TE) explicit route object.

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

Table of contents

1. Introduction.................................................3 Introduction ....................................................3
1.1. Terminology.................................................4 Terminology ................................................4
2. Path-Key Solution............................................5 Solution ...............................................5
2.1. Mode of Operation...........................................5 Operation ..........................................5
2.2. Example.....................................................6 Example ....................................................6
3. PCEP Protocol Extensions.....................................7 Extensions ........................................7
3.1. Path Keys Path-Keys in PCRep Messages.................................7 Messages ................................7
3.1.1. PKS with 32-bit 32-Bit PCE ID....................................8 ID ..............................8
3.1.2. PKS with 128-bit 128-Bit PCE ID...................................9 ID .............................9
3.2. Unlocking Path Keys.........................................9 Path-Keys .......................................10
3.2.1. Path Key Bit.............................................10 Path-Key Bit .......................................10
3.2.2. PATH-KEY Object..........................................10 Object ....................................10
3.2.3. Path Computation Request (PCReq) message Message
with Path Key...10 Path-Key ......................................11
4. PCEP Mode of Operation for Path Key Expansion...............11 Path-Key Expansion ..................12
5. Security Considerations.....................................12 Considerations ........................................12
6. Manageability Considerations................................13 Considerations ...................................13
6.1. Control of Function Through through Configuration and Policy.......13 Policy ......13
6.2. Information and Data Models................................14 Models ...............................14
6.3. Liveness Detection and Monitoring..........................14 Monitoring .........................15
6.4. Verifying Correct Operation................................14 Operation ...............................15
6.5. Requirements on Other Protocols and Functional Components..15
Components ................................................15
6.6. Impact on Network Operation................................15 Operation ...............................16
7. IANA Considerations.........................................15 Considerations ............................................16
7.1. New Subobjects for the ERO Object..........................15 Object .........................16
7.2. New PCEP Object............................................16 Object ...........................................17
7.3. New RP Object Bit Flag.....................................16 Flag ....................................17
7.4. New NO-PATH-VECTOR TLV Bit Flag............................16 Flag ...........................17
8. References .....................................................17
8.1. Normative References........................................17
9. Informational References....................................17
10. Acknowledgements...........................................18
11. Authors' Addresses.........................................18 References ......................................17
8.2. Informative References ....................................18
Acknowledgements ..................................................19

Bradford, Vasseur, and Farrel et al. Standards Track [Page 2]

draft-ietf-pce-path-key-06.txt March

RFC 5520 Preserving Topology Confidentiality April 2009

1. Introduction

Path computation techniques using the Path Computation Element (PCE)
are described in [RFC4655] and allow for path computation of
inter-domain inter-
domain Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)
and Generalized MPLS (GMPLS) 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
([RFC4105] and [RFC4216]). Therefore, a single PCE is unlikely to be
able to compute a full inter-domain path.

Two path computation scenarios can be used for inter-domain TE LSPs:
one using per-domain path computation (defined in [RFC5152]), and the
other using a PCE-based path computation technique with cooperation
between PCEs (as described in [RFC4655]). In this second case, paths
for inter-domain LSPs can be 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]. [RFC5441].

If confidentiality is required between domains (such as would very
likely be the case between Autonomous Systems (ASes) belonging to
different Service Providers) 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 thus breaking the confidentiality requirement stated in
[RFC4105] and [RFC4216]. We define the part of the path
which that 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 containing a loose hop in place of the
segment that must be kept confidential. The concept of loose and
strict hops for the route of a TE LSP is described in [RFC3209]. The
Path Computation Element Communication Protocol (PCEP) defined in
[RFC5440] 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 with strict hops or uses loose hops. Note that a Path path
computation Request request may request an explicit path with strict hops or
may allow loose hops as detailed in [RFC5440].

The option of returning a loose hop in place of the CPS can be
achieved without further extensions to PCEP or the signaling
protocol. If loose hops are used, the TE LSPs are signaled as normal
([RFC3209]), and when a loose hop is encountered in the explicit route
route, it is resolved by performing a secondary path computation to
reach the resource or set of resources identified by the loose hop.
Given the nature of the cooperation between PCEs in computing the
original path, this secondary computation occurs

Bradford, Vasseur, and Farrel [Page 3]

draft-ietf-pce-path-key-06.txt March 2009 at or on behalf of a

Bradford, et al. Standards Track [Page 3]

RFC 5520 Preserving Topology Confidentiality April 2009

Label Switching Router (LSR) at a domain boundary (i.e., an Area
Border Router (ABR) or an AS Border Router (ASBR)) and the path is
expanded as described in [RFC5152].

The PCE-based computation model is particularly useful for
determining mutually disjoint inter-domain paths such as might be
required for service protection [RFC5298]. A single path computation
request is used. However, if loose hops are returned, the path of
each TE LSP must be recomputed at the domain boundaries as the TE
LSPs are signaled, and since the TE LSP signaling proceeds
independently for each TE LSP, disjoint paths cannot be guaranteed
since the LSRs in charge of expanding the EROs explicit route objects
(EROs) are not synchronized. Therefore, if the loose hop technique
is used without further extensions, path segment confidentiality and
path diversity are mutually incompatible requirements.

This document defines the notion of a Path Key Path-Key that is a token that
replaces a path segment in an explicit route. The Path Key Path-Key is
encoded as a Path Key Path-Key Subobject (PKS) returned in the PCEP Path
Computation Reply message (PCRep) ([RFC5440]). Upon receiving the
computed path, the PKS will be carried in an RSVP-TE Path message
(RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling.

The BNF in this document follows the format described in [RBNF].

Please note that the term "path-key" used in this document refers to
an identifier allocated by a PCE to represent a segment of a computed
path. This term has no relation to the term "cryptographic key" used
in some documents that describe security mechanisms.

1.1. Terminology

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

This document makes use of the following terminology and acronyms.

AS: Autonomous System.

ASBR: Autonomous System Border Routers used to connect to another AS
of a different or the same Service Provider via one or more links
inter-connecting between ASes.

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.

Bradford, et al. Standards Track [Page 4]

RFC 5520 Preserving Topology Confidentiality April 2009

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

Bradford, Vasseur, and Farrel [Page 4]

draft-ietf-pce-path-key-06.txt March 2009 route
based on a network graph and applying computational constraints.

TE LSP: Traffic Engineering Label Switched Path Path.

2. 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
related to a particular domain and replaces any CPS in the path
reported to the requesting PCC (or another PCE) by one or more
subobjects referred to as PKSes. The entry boundary LSR of each CPS
SHOULD be specified using its TE Router Id as a hop in the returned
path immediately preceding the CPS, and other sub-objects subobjects MAY be
included in the path immediately before the hop identifying the
boundary LSR to indicate link and label choices. Where two PKSes are
supplied in sequence with no intervening nodes, the entry node to the
second CPS MAY be part of the first CPS and does not need to be
explicitly present in the returned path. The exit node of a CPS MAY
be present as a strict hop immediately following the PKS.

2.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 or if explicitly requested by the Path
Computation Request, path computation
request, the PCE associates a path-key with the computed path for the
CPS, places its own identifier (its PCE ID as defined in Section 3.1)
along with the path-key in a PKS, and inserts the PKS object in the
path returned to the requesting PCC or PCE immediately after the
subobject that identifies (using the TE Router Id) the LSR that will
expand the PKS into explicit path
hops.This hops. This will usually be the LSR
that is the start starting point of the CPS. The PCE that generates a PKS
SHOULD 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

Bradford, et al. Standards Track [Page 5]

RFC 5520 Preserving Topology Confidentiality April 2009

information, and whether to discard the information after it has been
queried using the procedures described below. It is RECOMMENDED for
a PCE to store the PKS for a period of 10 minutes.

A path-key value is scoped to the PCE that computed it as identified
by the PCE-ID carried in the PKS. A PCE MUST NOT re-use a path-key
value to represent a new CPS for at least 30 minutes after discarding
the previous use of the same path-key. A PCE that is unable to
retain information about previously used path-key values over a
restart SHOULD use some other mechanism to guarantee uniqueness of
path-key values such as embedding a timestamp or version number in
the path-key.

Bradford, Vasseur, and Farrel [Page 5]

draft-ietf-pce-path-key-06.txt March 2009

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 a PKS, this is included in the ERO. Like any other
subobjects, the PKS is passed transparently from hop to hop, until it
becomes the first subobject in the ERO. This will occur at the start
of the CPS CPS, which will usually be the domain boundary. The PKS MUST
be preceded by an ERO subobject that identifies the LSR that must
expand the PKS. This means that (following the rules for ERO
processing set out in [RFC3209]) the PKS will not be encountered in
ERO processing until the ERO is being processed by the LSR that is
capable of correctly handling the PKS.

An LSR that encounters a PKS when trying to identify the next-hop next hop
retrieves the PCE-ID from the PKS and sends a Path Computation
Request (PCReq) message as defined in [RFC5440] to the PCE identified
by the PCE-ID that contains the path-key object .

Upon receiving the PCReq message, 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 using an ERO
object contained in the Path Computation Reply
(PCReqp) (PCRep) to the
requesting node as defined in [RFC5440]. The requesting node inserts
the explicit hops into the ERO and continues to process the TE LSP
setup as per [RFC3209].

2.2. Example

Figure 1 shows a simple two-AS topology with a PCE responsible for
the path computations in each AS. An LSP is requested from the
ingress LSR in one AS to the egress LSR in the other AS. The
ingress, acting as the PCC, sends a path computation request to PCE-
1.
PCE-1. PCE-1 is unable to compute an end-to-end path and invokes PCE-
2
PCE-2 (possibly using the techniques described in [BRPC]). [RFC5441]). PCE-2
computes a path segment from ASBR-2 to the egress as {ASBR-2, C, D,

Bradford, et al. Standards Track [Page 6]

RFC 5520 Preserving Topology Confidentiality April 2009

Egress}. It could pass this path segment back to PCE-1 in full, or
it could send back the path {ASBR-2, Egress} where the second hop is
a loose hop.

However, in order to protect the confidentiality of the topology in
the second AS while still specifying the path in full, PCE-2 may send
PCE-1 a path segment expressed as {ASBR-2, PKS, Egress} where the PKS
is a Path Key Path-Key Subobject as defined in this document. In this case,
PCE-2 has identified the segment {ASBR-2, C, D, Egress} as a
Confidential Path Segment (CPS). PCE-1 will compute the path segment
that it is responsible for, and will supply the full path to the PCC
as {Ingress, A, B, ASBR-1, ASBR-
2, ASBR-2, PKS, Egress}.

Bradford, Vasseur, and Farrel [Page 6]

draft-ietf-pce-path-key-06.txt March 2009

Signaling proceeds in the first AS as normal, but when the Path
message reaches ASBR-2 ASBR-2, the next hop is the PKS, and this must be
expanded before signaling can progress further. ASBR-2 uses the
information in the PKS to request PCE-2 for a path segment, and PCE-2
will return the segment {ASBR-2, C, D, Egress} allowing signaling to
continue to set up the LSP.

----------------------------- ----------------------------
| ------- | | ------- |
| | PCE-1 |<---------------+--+-->| PCE-2 | |
| ------- | | ------- |
| ^ | | ^ |
| | | | | |
| v | | v |
| ------- ---- | | ---- |
| | PCC | - - |ASBR| | | |ASBR| - - ------ |
| |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| |
| ------- - - ----- | | ---- - - ------ |
| | | |
----------------------------- ----------------------------

Figure 1 : A Simple network to demonstrate the use of the PKS

3. PCEP Protocol Extensions

3.1. Path Keys Path-Keys in PCRep Messages

Path Keys

Path-Keys are carried in PCReq and PCRep messages as part of the
various objects that carry path definitions. In particular, a Path Path-
Key is carried in the Explicit Route Object (ERO) on PCRep messages.

In all cases, the Path Key Path-Key is carried in a Path Key Path-Key Subobject (PKS).

Bradford, et al. Standards Track [Page 7]

RFC 5520 Preserving Topology Confidentiality April 2009

The PKS is a fixed-length subobject containing a Path-Key and a
PCE-ID. The Path Key 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 Path-Key using an
identifier that is unique within the domain that the PCE serves. The
PCE-ID has to be mapped to a reachable IPv4 or IPv6 address of the
PCE by the first node of the CPS (usually a domain border router) and
a PCE MAY use one of its reachable IP addresses as its PCE-ID.
Alternatively and to provide greater security (see Section 5) or
increased confidentiality, according to domain-local policy, the PCE
MAY use some other identifier that is scoped only within the domain.

Bradford, Vasseur, and Farrel [Page 7]

draft-ietf-pce-path-key-06.txt March 2009

To allow IPv4 and IPv6 addresses to be carried, two subobjects are
defined in the following subsections.

The Path Key Path-Key Subobject may be present in the PCEP ERO or the PCEP
PATH-KEY object (see Section 3.2).

3.1.1. PKS with 32-bit 32-Bit PCE ID

The Subobject Type for the PKS with 32-bit PCE ID is to be
assigned by IANA (recommended value 64). 64. The format
of this subobject is 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 Path-Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The L bit SHOULD NOT be set, so that the subobject represents a
strict hop in the explicit route.

Type

Subobject Type for a Path Key Path-Key with 32-bit PCE ID as assigned by
IANA. (64).

Length

The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 8.

Bradford, et al. Standards Track [Page 8]

RFC 5520 Preserving Topology Confidentiality April 2009

PCE ID

A 32-bit identifier of the PCE that can decode this key. path-key.
The identifier MUST be unique within the scope of the domain
that the CPS crosses, and MUST be understood by the LSR that
will act as PCC for the expansion of the PKS. The
interpretation of the PCE-ID is subject to domain-local policy.
It MAY be an IPv4 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. Other
values that have no meaning outside the domain (for example,
the Router ID of the PCE) MAY be used to increase security or
confidentiality (see Section 5).

Bradford, Vasseur, and Farrel [Page 8]

draft-ietf-pce-path-key-06.txt March 2009

3.1.2. PKS with 128-bit 128-Bit PCE ID

The Subobject Type for the PKS with 128-bit PCE ID is to be
assigned by IANA (recommended value 65). 65. The format
of the subobject is 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 Path-Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE ID (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As above.

Type

Subobject Type for a Path Key Path-Key with 128-bit PCE ID as assigned
by IANA. (65).

Length

The Length contains the total length of the subobject in bytes,
including the Type and Length fields. The Length is always 20.

PCE ID

A 128-bit identifier of the PCE that can decode this key. path-key.
The identifier MUST be unique within the scope of the domain
that the CPS crosses, and MUST be understood by the LSR that

Bradford, et al. Standards Track [Page 9]

RFC 5520 Preserving Topology Confidentiality April 2009

will act as PCC for the expansion of the PKS. The
interpretation of the PCE-ID is subject to domain-local policy.
It MAY be an IPv6 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. Other
values that have no meaning outside the domain (for example,
the IPv6 TE Router ID) MAY be used to increase security (see
Section 5).

3.2. Unlocking Path Keys Path-Keys

When a network node needs to decode a Path Key Path-Key so that it can
continue signaling for an LSP, it must send a PCReq to the designated
PCE. The PCReq defined in [RFC5440] needs to be modified to support
this usage usage, which differs from the normal path

Bradford, Vasseur, and Farrel [Page 9]

draft-ietf-pce-path-key-06.txt March 2009 computation request.
To that end, a new flag is defined to show that the PCReq relates to
the expansion of a PKS, and a new object is defined to carry the PKS
in the PCReq. These result in an update to the BNF for the message.
The BNF used in this document is as described in [RBNF].

3.2.1. Path Key Path-Key Bit

[RFC5440] defines the Request Parameters (RP) object that is used to
specify various characteristics of the path computation request Path Computation Request
(PCReq).

In this document document, we define a new bit named the Path Key Path-Key bit as
follows. See Section 7.3 for the IANA assignment of the appropriate
bit number.

Path Key

Path-Key bit: When set, the requesting PCC requires the retrieval of
a Confidential Path Segment that corresponds to the PKS carried in a PATH_KEY
PATH-KEY object in the path computation request. The Path Key Path-Key bit
MUST be cleared when the path computation request is not related to a
CPS retrieval.

3.2.2. PATH-KEY Object

When a PCC needs to expand a path-key in order to expand a CPS CPS, it
issues a path computation request Path Computation Request (PCReq) to the PCE identified in
the PKS in the RSVP-TE ERO that it is processing. The PCC supplies
the PKS to be expanded in a PATH-KEY Object in the PCReq message.

Bradford, et al. Standards Track [Page 10]

RFC 5520 Preserving Topology Confidentiality April 2009

The PATH-KEY Object is defined as follows. follows:

PATH-KEY Object-Class is to be assigned by IANA (recommended
value=16)

Path Key 16.

Path-Key Object-Type is to be assigned by IANA (recommended
value=1) 1.

The PATH-KEY Object MUST contain at least one Path Key Path-Key Subobject (see
Section 3.1). The first PKS MUST be processed by the PCE.
Subsequent subobjects SHOULD be ignored.

3.2.3. Path Computation Request (PCReq) message Message with Path Key Path-Key

The format of a PCReq message including a PATH-KEY object is
unchanged as follows:

Bradford, Vasseur, and Farrel [Page 10]

draft-ietf-pce-path-key-06.txt March 2009

where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]

To support the use of the message to expand a PKS, the definition of
<request> is modified as follows :

where:
<segment-computation> ::= <END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
<path-key-expansion> ::= <PATH-KEY>

Thus, the format of the message for use in normal path computation is
unmodified.

Bradford, et al. Standards Track [Page 11]

RFC 5520 Preserving Topology Confidentiality April 2009

4. PCEP Mode of Operation for Path Key Path-Key Expansion

The retrieval of the explicit path (the CPS) associated with a PKS by
a PCC is no different than any other path computation request with
the exception that the PCReq message MUST contain a PATH_KEY PATH-KEY object
and the Path Key Path-Key bit of the RP object MUST the be set. On receipt of a
PCRep containing a CPS, the requesting PCC SHOULD
use insert the CPS into
the ERO that it will signal, in accordance with local policy.

If the receiving PCE does not recognize itself as identified by the
PCE ID carried in the PKS PKS, it MAY forward the PCReq message to
another PCE according to local policy. If the PCE does not forward
such a PCReq, it MUST respond with a PCRep message containing a NO-
PATH
NO-PATH object.

If the receiving PCE recognizes itself, but cannot find the related
CPS, or if the retrieval of the CPS is not allowed by policy, the PCE
MUST send a PCRep message that contains a NO-PATH object. The
NO-PATH-VECTOR TLV SHOULD be used as described in [RFC5440] and a new bit-number
bit number (see Section 7.4) is assigned to indicate "Cannot expand
PKS".

Upon receipt of a negative reply, the requesting LSR MUST fail the
LSP setup and SHOULD use the procedures associated with loose hop
expansion failure [RFC3209].

Bradford, Vasseur, and Farrel [Page 11]

draft-ietf-pce-path-key-06.txt March 2009

5. Security Considerations

This document describes tunneling confidential path information
across an untrusted domain (such as an AS). There are many security
considerations that apply to PCEP and RSVP-TE.

Issues include:

- Confidentiality 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 DoS Denial-of-Service (DoS) attacks (insertion of
spurious path-keys; flooding of bogus path-key expansion requests).

Most of the interactions required by this extension are point to
point, can be authenticated and made secure as described in [RFC5440]
and [RFC3209]. These interactions include the:

Bradford, et al. Standards Track [Page 12]

RFC 5520 Preserving Topology Confidentiality April 2009

- PCC->PCE request

- PCE->PCE request(s)

- PCE->PCE response(s)

- PCE->PCC response

- LSR->LSR request and response (Note response. Note that a rogue LSR could
modify the ERO and insert or modify Path Keys. Path-Keys. This would
result in an LSR (which is downstream in the ERO) sending
decode requests to a PCE. This is actually a larger problem
with RSVP. The rogue LSR is an existing issue with RSVP and
will not be addressed here.

- LSR->PCE request. Note that the PCE can check that the LSR
requesting the decode is the LSR at the head of the Path Key. Path-Key.
This largely contains the previous problem to of DoS rather than a
security issue. A rogue LSR can issue random decode requests,
but these will amount only to DoS.

- PCE->LSR response. response

Thus, the major security issues can be dealt with using standard
techniques for securing and authenticating point-to-point
communications. In addition, it is recommended that the PCE
providing a decode response should check that the LSR that issued the
decode request is the head end of the decoded ERO segment.

Further protection can be provided by using a PCE ID to identify the
decoding PCE that is only meaningful within the domain that contains
the LSR at the head of the CPS. This may be an IP address that is
only reachable from within the domain, or some not-address value.
The former requires configuration of policy on the PCEs, the latter
requires domain-wide policy.

Bradford, Vasseur, and Farrel [Page 12]

draft-ietf-pce-path-key-06.txt March 2009

6. Manageability Considerations

6.1. Control of Function Through through Configuration and Policy

The treatment of a path segment as a CPS, and its substitution in a PCReq
PCRep ERO with a PKS, is a function that MUST be under operator and
policy control where a PCE supports the function. The operator MUST
be given the ability to specify which path segments are to be
replaced and under what circumstances. For example, an operator
might set a policy that states that every path segment for the
operator's domain will be replaced by a PKS when the PCReq has been
issued from outside the domain.

Bradford, et al. Standards Track [Page 13]

RFC 5520 Preserving Topology Confidentiality April 2009

The operation of the PKS extensions require that path-keys are
retained by the issuing PCE to be available for retrieval by an LSR
(acting as a PCC) at a later date. But it is possible that the
retrieval request will never be made, so good housekeeping requires
that a timer is run to discard unwanted path-keys. A default value
for this timer is suggested in Section 2.1. Implementations SHOULD
provide the ability for this value to be over-
ridden overridden through operator
configuration or policy.

After a PKS has been expanded in response to a retrieval request, it
may be valuable to retain the path-key and CPS for debug debugging
purposes. Such retention SHOULD NOT be the default behavior of an
implementation, but MAY be available in response to operator request.

Once a path-key has been discarded, the path-key value SHOULD NOT be
immediately available for re-use for a new CPS since this might lead
to accidental misuse. A default timer value is suggested in Section
2.1. Implementations SHOULD provide the ability for this value to be over-ridden
overridden through operator configuration or policy.

A PCE must set a PCE-ID value in each PKS it creates so that PCCs can
correctly identify it and send PCReq messages to expand the PKS to a
path segment. A PCE implementation SHOULD allow operator or policy
control of the value to use be used as the PCE-ID. If the PCE allows
PCE-ID values that are not routable addresses to be used, the PCCs
MUST be configurable (by the operator or through policy) to allow them the
PCCs to map from the PCE-ID to a routable address of the PCE. Such
mapping may be algorithmic, procedural (for example, mapping a PCE-ID
equal to the IGP Router ID into a routable address), or configured
through a local or remote mapping table.

Bradford, Vasseur, and Farrel [Page 13]

draft-ietf-pce-path-key-06.txt March 2009

6.2. Information and Data Models

A MIB module for PCEP is already defined in [PCEP-MIB]. The
configurable items listed in Section 6.1 MUST be added as readable
objects in the module and SHOULD be added as writable objects.

A new MIB module MUST be created to allow inspection of path-keys.
For a given PCE, this MIB module MUST provide a mapping from path-
key to path segment (that is, a list of hops), and MUST supply other
information including:

- The identity of the PCC that issued the original request that led
to the creation of the path-key.

- The request ID of the original PCReq.

Bradford, et al. Standards Track [Page 14]

RFC 5520 Preserving Topology Confidentiality April 2009

- Whether the path-key has been retrieved yet, and if so, by which
PCC.

- How long until the path segment associated with the path-key will
be discarded.

- How long until the path-key will be available for re-use.

6.3. Liveness Detection and Monitoring

The procedures in this document extend PCEP, but do not introduce new
interactions between network entities. Thus, no new liveness
detection or monitoring is required.

It is possible that a head-end LSR that has be given a path including
PKSs replacing specific CPSs will want to know whether the path-keys
are still valid (or have timed out). However, rather than introduce
a mechanism to poll the PCE that is responsible for the PKS, it is
considered pragmatic to simply signal the associated LSP.

6.4. Verifying Correct Operation

The procedures in this document extend PCEP, but do not introduce new
interactions between network entities. Thus, no new tools for
verifying correct operation are required.

A PCE SHOULD maintain counters and logs of the following events that
might indicate incorrect operation (or might indicate security
issues).

- Attempts to expand an unknown path-key.

- Attempts to expand an expired path-key.

- Duplicate attempts to expand the same path-key.

- Expiry of path-key without attempt to expand it.

Bradford, Vasseur, and Farrel [Page 14]

draft-ietf-pce-path-key-06.txt March 2009

6.5. Requirements on Other Protocols and Functional Components

The procedures described in this document require that the LSRs
signal PKSs as defined in [RSVP-PKS]. Note that the only changes to
LSRs are at the PCCs. Specifically, changes are only needed at the
head-end LSRs that build RSVP-TE Path messages containing Path-Key
Subobjects in their EROs, and the LSRs that discover such subobjects
as next hops and must expand them. Other LSRs in the network, even
if they are on the path of the LSP, will not be called upon to
process the PKS.

Bradford, et al. Standards Track [Page 15]

RFC 5520 Preserving Topology Confidentiality April 2009

6.6. Impact on Network Operation

As well as the security and confidentiality aspects addressed by the
use of the PKS, there may be some scaling benefits associated with
the procedures described in this document. For example, a single PKS
in an explicit route may substitute for many subobjects and can
reduce the overall message size correspondingly. In some
circumstances, such as when the explicit route contains multiple
subobjects for each hop (including node IDs, TE link IDs, component
link IDs for each direction of a bidirectional LSP, and label IDs for
each direction of a bidirectional LSP) or when the LSP is a point-to-multipoint point-
to-multipoint LSP, this scaling improvement may be very significant.

Note that a PCE will not supply a PKS unless it is knows that the LSR
that will receive the PKS through signaling will be able to handle
it. Furthermore, as noted in Section 6.5, only those LSRs
specifically called upon to expand the PKS will be required to
process the subobjects during signaling. Thus, the only backward
compatibility issues associated with the procedures introduced in
this document arise when a head-end LSR receives a PCRep with an ERO
containing a PKS PKS, and it does not know how to encode this into
signaling.

Since the PCE that inserted the PKS requires is required to keep the CPS
confidential, the legacy head-end LSR cannot be protected. It must
either fail the LSP setup, or request a new path computation avoiding
the domain that has supplied it with unknown subobjects.

7. IANA Considerations

IANA assigns values to PCEP parameters in registries defined in
[RFC5440]. IANA is requested to make has made the following additional assignments.

7.1. New Subobjects for the ERO Object

IANA has previously assigned an Object-Class and Object-Type to the
ERO carried in PCEP messages [RFC5440]. IANA also maintains a

Bradford, Vasseur, and Farrel [Page 15]

draft-ietf-pce-path-key-06.txt March 2009 list
of subobject types valid for inclusion in the ERO.

IANA is requested to assign assigned two new subobject types for inclusion in the ERO as
follows:

Subobject Type Reference
64 Path Key Path-Key with 32-bit PCE ID [This.I-D] [RFC5520]
65 Path Key Path-Key with 128-bit PCE ID [This.I-D]

7.2. New PCEP Object

IANA is requested to assign [RFC5520]

Bradford, et al. Standards Track [Page 16]

RFC 5520 Preserving Topology Confidentiality April 2009

7.2. New PCEP Object

IANA assigned a new object class in the registry of PCEP Objects as
follows.

Object Name Object Name Reference
Class Type

16 PATH-KEY 1 Path Key [This.I-D] Path-Key [RFC5520]

Subobjects
This object may carry the following subobjects as defined
for the ERO object.

64 Path Key Path-Key with 32-bit PCE ID [This.I-D] [RFC5520]
65 Path Key Path-Key with 128-bit PCE ID [This.I-D] [RFC5520]

7.3. New RP Object Bit Flag

IANA maintains a registry of bit flags carried in the PCEP RP object
as defined in [RFC5440]. IANA is requested to assign assigned a new bit flag as follows:

Bit Number Hex Name Reference
Number
15 0x000100 Path Key
23 0x000017 Path-Key (P-bit) [This.I-D] [RFC5520]

7.4. New NO-PATH-VECTOR TLV Bit Flag

IANA maintains a registry of bit flags carried in the PCEP NO-
PATH-VECTOR NO-PATH-
VECTOR TLV in the PCEP NO-PATH object as defined in [RFC5440]. IANA is requested to assign
assigned a new bit flag as follows:

Bits

Bit Number Name Flag Reference
1
27 PKS expansion failure [This.I-D]

Bradford, Vasseur, and Farrel [Page 16]

draft-ietf-pce-path-key-06.txt March 2009 [RFC5520]

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.

[RFC5440] Vasseur, J.P., JP., Ed., and JL. Le Roux, J.L., Ayyangar, A., Oki, E.,
Ikejiri, A., Atlas, A., Dolganow, A., Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.

Bradford, et al. Standards Track [Page 17]

RFC 5520 Preserving Topology Confidentiality April 2009

8.2. Informative References

[PCEP-MIB] Koushik, K., and E. Stephan, "PCE Communication Protocol
(PCEP) Management Information Base", Work in Progress,
November 2008.

[RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
in Various Protocol Specifications", Work in Progress,
November 2008.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, Srinivasan T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.

[RFC4105] Le Roux, J., J.-L., Ed., Vasseur, JP., J.-P., Ed., and J. Boyle, J.,
Ed., "Requirements for
Support of Inter-Area and Inter-AS MPLS Traffic
Engineering", RFC 4105, June 2005.

[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, JP., et. al., Ed., "MPLS Inter-AS Inter-
Autonomous System (AS) Traffic Engineering requirements", (TE)
Requirements", RFC 4216, November 2005.

[RFC4655] Farrel, A., Vasseur, & J.-P., and J. Ash, "A Path
Computation Element (PCE)-
Based (PCE)-Based Architecture", RFC 4655,
August 2006.

[RFC5152] Vasseur, JP., et al Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing
Inter-Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", RFC 5152, Fenruary February 2008.

[RFC5298] Takeda, T., et al, Ed., Farrel, A., Ed., Ikejiri, Y., and JP.
Vasseur, "Analysis of Inter-domain Inter-Domain Label Switched Path
(LSP) Recovery", RFC 5298, August 2008.

[RSVP-PKS] Bradford, R., Vasseur, JP., Farrel, A., "RSVP Extensions
for Path Key Support", draft-ietf-ccamp-path-key-ero,
work in progress.

[BRPC]

[RFC5441] Vasseur, JP., et al Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward Recursive PCE-based Backward-Recursive PCE-Based Computation (BRPC) procedure
Procedure to compute shortest inter-
domain Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Path", draft-
ietf-pce-brpc, work in progress.

[PCEP-MIB] Kiran Koushik, A., Paths", RFC 5441, April
2009.

[RSVP-PKS] Bradford, R., Vasseur, JP., and Stephan, E., "PCE communication
protocol (PCEP) Management Information Base", draft-
ietf-pce-pcep-mib, work in progress.

[RBNF] A. Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used
in Various Protocol Specifications", draft-farrel-rtg-
common-bnf, work "RSVP
Extensions for Path Key Support", Work in progress. Progress,
February 2008.

Bradford, Vasseur, and Farrel et al. Standards Track [Page 17]

draft-ietf-pce-path-key-06.txt March 18]

RFC 5520 Preserving Topology Confidentiality April 2009

10.

Acknowledgements

The authors would like to thank Eiji Oki, Ben Campbell, and Ross
Callon for their comments on this document.

11.

Authors' Addresses

Rich Bradford (Editor)
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA - 01719
USA
EMail: rbradfor@cisco.com

Jean-Philippe

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

Intellectual Property

The IETF Trust 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 any IETF 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.

Copies of Intellectual Property 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
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.

The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are

Bradford, Vasseur, and Farrel [Page 18]

draft-ietf-pce-path-key-06.txt March 2009

published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.

For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.

Disclaimer of Validity

All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.

Full Copyright Statement

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF et al. Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.

Bradford, Vasseur, and Farrel Track [Page 19]

----