Network Working Group R. Bradford, Ed.
Request for Comments: 5520 JP. Vasseur
Category: Standards Track Cisco Systems, Inc.
A. Farrel
Old Dog Consulting
April 2009
Preserving Topology Confidentiality in
Inter-Domain Path Computation Using a Path-Key-Based Mechanism
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
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, et al. Standards Track [Page 1]
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.
Table of contents
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Path-Key Solution ...............................................5
2.1. Mode of Operation ..........................................5
2.2. Example ....................................................6
3. PCEP Protocol Extensions ........................................7
3.1. Path-Keys in PCRep Messages ................................7
3.1.1. PKS with 32-Bit PCE ID ..............................8
3.1.2. PKS with 128-Bit PCE ID .............................9
3.2. Unlocking Path-Keys .......................................10
3.2.1. Path-Key Bit .......................................10
3.2.2. PATH-KEY Object ....................................10
3.2.3. Path Computation Request (PCReq) Message
with Path-Key ......................................11
4. PCEP Mode of Operation for Path-Key Expansion ..................12
5. Security Considerations ........................................12
6. Manageability Considerations ...................................13
6.1. Control of Function through Configuration and Policy ......13
6.2. Information and Data Models ...............................14
6.3. Liveness Detection and Monitoring .........................15
6.4. Verifying Correct Operation ...............................15
6.5. Requirements on Other Protocols and Functional
Components ................................................15
6.6. Impact on Network Operation ...............................16
7. IANA Considerations ............................................16
7.1. New Subobjects for the ERO Object .........................16
7.2. New PCEP Object ...........................................17
7.3. New RP Object Bit Flag ....................................17
7.4. New NO-PATH-VECTOR TLV Bit Flag ...........................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
Acknowledgements ..................................................19
Bradford, et al. Standards Track [Page 2]
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 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 [RFC5441].
If confidentiality is required between domains (such as would very
likely be the case between Autonomous Systems (ASes) 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 thus breaking the confidentiality requirement stated in
[RFC4105] and [RFC4216]. We define the part of the path 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
computation 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, 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 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 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 that is a token that
replaces a path segment in an explicit route. The Path-Key is
encoded as a 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 route
based on a network graph and applying computational constraints.
TE LSP: Traffic Engineering Label Switched 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 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, 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 will usually be the LSR
that is the 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.
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, 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
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 (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 is unable to compute an end-to-end path and invokes
PCE-2 (possibly using the techniques described in [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 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, PKS, Egress}.
Signaling proceeds in the first AS as normal, but when the Path
message reaches 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 in PCRep Messages
Path-Keys are carried in PCReq and PCRep messages as part of the
various objects that carry path definitions. In particular, a Path-
Key is carried in the Explicit Route Object (ERO) on PCRep messages.
In all cases, the Path-Key is carried in a 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 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 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.
To allow IPv4 and IPv6 addresses to be carried, two subobjects are
defined in the following subsections.
The 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 PCE ID
The Subobject Type for the PKS with 32-bit PCE ID is 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
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 with 32-bit PCE ID (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 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).
3.1.2. PKS with 128-Bit PCE ID
The Subobject Type for the PKS with 128-bit PCE ID is 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE ID (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
As above.
Type
Subobject Type for a Path-Key with 128-bit PCE ID (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 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
When a network node needs to decode a 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, which differs from the normal path 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 Bit
[RFC5440] defines the Request Parameters (RP) object that is used to
specify various characteristics of the Path Computation Request
(PCReq).
In this document, we define a new bit named the Path-Key bit as
follows. See Section 7.3 for the IANA assignment of the appropriate
bit number.
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 object in the path computation request. The 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, it
issues a 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:
PATH-KEY Object-Class is 16.
Path-Key Object-Type is 1.
The PATH-KEY Object MUST contain at least one 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 with Path-Key
The format of a PCReq message including a PATH-KEY object is
unchanged as follows:
::=
[]
where:
::=[]
::=[]
To support the use of the message to expand a PKS, the definition of
is modified as follows :
::=
RFC, FYI, BCP