Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism
RFC 5520
|
| Document |
Type |
|
RFC - Proposed Standard
(April 2009; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Replaces |
|
draft-bradford-pce-path-key
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
|
Reviews |
|
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5520 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Ross Callon
|
|
Send notices to |
|
(None)
|
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
Show full document text