Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism
Extracted elements (29)
A PCE MAY use a PCE-ID that is only meaningful within its domain (e.g., an IGP Router ID or a non-routable value) rather than a globally reachable IP address. This provides greater security and confidentiality by limiting the ability of external entities to target the PCE directly.
A PCE that cannot retain information about previously used path-key values across a restart SHOULD embed a timestamp or version number in the path-key to guarantee uniqueness, since the 30-minute non-reuse window depends on persistent memory of prior key assignments.
A PKS can substitute for many ERO subobjects, potentially providing significant message size reduction. This benefit is especially pronounced for bidirectional LSPs (which carry node IDs, TE link IDs, component link IDs, and label IDs in both directions) and point-to-multipoint LSPs.
The loose-hop approach to CPS confidentiality is insufficient when path diversity is required. Because each TE LSP's ERO is expanded independently at domain boundaries during signaling, disjoint paths cannot be guaranteed since the expanding LSRs are not synchronized. The path-key mechanism was introduced to solve this incompatibility between confidentiality and path diversity.
A legacy head-end LSR that receives a PCRep ERO containing a PKS but does not understand how to encode it into RSVP-TE signaling must either fail the LSP setup or request a new path computation that avoids the domain that supplied the PKS. There is no way to protect such a legacy LSR since the PCE must keep the CPS confidential.
A new MIB module MUST be created for inspection of path-keys, providing a mapping from path-key to path segment plus metadata including the originating PCC identity, request ID, retrieval status, and expiry timers.
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, to prevent accidental misuse or replay.
A PCE SHOULD store the computed CPS and associated path-key for later retrieval; the recommended default retention period is 10 minutes, and implementations SHOULD allow operator configuration of this value.
A PCReq message requesting CPS expansion MUST contain a PATH-KEY object and the Path-Key bit of the RP object MUST be set. On receipt of a PCRep containing a CPS, the requesting PCC SHOULD insert the CPS into the ERO for signaling.
If a PCE receives a PKS expansion request but cannot find the CPS or if retrieval is not allowed by policy, it MUST respond with a PCRep containing a NO-PATH object. The NO-PATH-VECTOR TLV SHOULD indicate 'Cannot expand PKS' using the assigned bit flag.
If a receiving PCE does not recognize itself as identified by the PCE-ID in the PKS, it MAY forward the PCReq to another PCE per local policy; if it does not forward it, it MUST respond with a PCRep containing a NO-PATH object.
The CPS treatment and PKS substitution function MUST be under operator and policy control; operators MUST be able to specify which path segments are replaced and under what circumstances.
The L bit in a PKS SHOULD NOT be set, so that the subobject represents a strict hop in the explicit route.
The PCE-ID in a PKS 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 PKS MUST be preceded by an ERO subobject that identifies the LSR responsible for expanding the PKS, ensuring (per RFC 3209 ERO processing rules) that the PKS is not encountered until processing reaches the capable LSR.
Upon receipt of a negative reply to a PKS expansion request, the requesting LSR MUST fail the LSP setup and SHOULD use the procedures associated with loose hop expansion failure as defined in RFC 3209.
The Confidential Path Segment (CPS) is a segment of a computed path containing nodes and links that AS policy requires not be disclosed outside the AS. A PCE replaces the CPS with one or more Path-Key Subobjects (PKSes) in the path returned to the requesting PCC or peer PCE.
The Path-Key bit (bit 23 of the PCEP RP object) indicates that a PCReq is requesting retrieval of a CPS corresponding to a PKS carried in a PATH-KEY object. It MUST be cleared when the request is not related to CPS retrieval.
The PATH-KEY Object (Object-Class 16, Object-Type 1) is a new PCEP object that carries a PKS in a PCReq message when a PCC is requesting expansion of a CPS. It MUST contain at least one Path-Key Subobject; subsequent subobjects beyond the first SHOULD be ignored.
The Path-Key Subobject (PKS) is a fixed-length subobject containing a Path-Key identifier (token scoped to the issuing PCE) and a PCE-ID. It is carried in PCEP ERO objects and RSVP-TE explicit route objects to represent a hidden CPS without revealing internal topology.
IANA assigned bit 23 (0x000017) as the Path-Key (P-bit) flag in the PCEP RP object, indicating that the PCReq is a CPS retrieval request rather than a normal path computation request.
IANA assigned bit 27 as the 'PKS expansion failure' flag in the PCEP NO-PATH-VECTOR TLV, used to indicate that a PCE cannot expand the requested Path-Key Subobject.
IANA assigned PCEP Object-Class 16, Object-Type 1 for the new PATH-KEY object, which carries PKSes in PCReq messages for CPS expansion requests.
IANA assigned two new ERO subobject types for PCEP: type 64 for Path-Key with 32-bit PCE ID, and type 65 for Path-Key with 128-bit PCE ID. Both are also valid subobjects for the PATH-KEY object.
A PCE providing a CPS decode response SHOULD verify that the LSR issuing the decode request is the LSR at the head of the CPS (i.e., the first node of the decoded ERO segment). This check largely contains the DoS threat from rogue LSRs sending random expansion requests.
A rogue LSR can modify the RSVP-TE ERO to insert or alter Path-Keys, causing downstream LSRs to issue spurious decode requests to the PCE. This is an existing RSVP security problem; it results in DoS rather than confidentiality breach, since the PCE can validate the requester identity.
Three primary security threats apply: (1) probing for CPS contents via random path-key expansion requests, (2) alteration of path-keys by intermediaries or insertion of fake keys, and (3) DoS via flooding with bogus expansion requests. Most threats can be mitigated using existing PCEP and RSVP-TE security mechanisms for point-to-point authenticated communication.
PKS with 128-bit PCE ID (Subobject Type 65): 20-byte fixed-length subobject containing L bit, Type field (65), Length (always 20), a 16-bit Path-Key identifier, and a 128-bit PCE-ID, used to support IPv6 PCE addressing.
PKS with 32-bit PCE ID (Subobject Type 64): 8-byte fixed-length subobject containing L bit, Type field (64), Length (always 8), a 16-bit Path-Key identifier, and a 32-bit PCE-ID that uniquely identifies the PCE within the domain scope.