Technical Summary
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.
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.
Working Group Summary
WG has good consensus with no disputes or disagreements. An IPR
disclosure has been filed, but the WG has decided to proceed with
this I-D. WG last call issues were limited to editorial and minor
functional nits.
Document Quality
The document has been updated in response to Gen-Art comments. The
responsible AD is not aware of any implementations.
Personnel
Adrian Farrel is the Document Shepherd for this document. Ross
Callon is the responsible Area Director.
RFC Editor Note
Please update the title of this document as follows:
OLD
Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Key-Based Mechanism
NEW
Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Path-Key-Based Mechanism
Section 3.1.1, paragraph under "PCE ID", first sentence. Please
update as follows:
OLD
A 32-bit identifier of the PCE that can decode this key.
NEW
A 32-bit identifier of the PCE that can decode this path-key.
Section 3.1.2, paragraph under "PCE ID", first sentence. Please
update as follows:
OLD
A 128-bit identifier of the PCE that can decode this key.
NEW
A 128-bit identifier of the PCE that can decode this path-key.
Please change every occurance in the document of "path key" to
instead be "path-key".
Please add the following paragraph as the second to last paragraph
of section 1 (before section 1.1, and immediately before the one-
sentence paragraph that begins "The BNF in this document..."):
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.
IANA Note
The document defines small protocol enhancements to PCEP (which
was recently approved by the IESG). This I-D requests further
allocations from the PCEP registry. The IANA section of this
I-D uses the same language as the PCEP specification and, in
particular, uses the same sub-registry names.