Resource Reservation Protocol (RSVP) Extensions for Path Key Support
Extracted elements (25)
A PKS may replace path detail in the RRO as an alternative to recording the full CPS. This preserves topology confidentiality in the route record while still allowing the expansion to be available to diagnostic tools under local policy control.
PKS expansion by an LSR may use the specific PCE identified in the PKS, any PCE as proxy via PCEP, or locally cached CPS data. This flexibility accommodates varying deployment models (e.g., PCE co-located with ASBR) without mandating a single resolution mechanism.
The PCE-ID field MAY carry non-address values (e.g., Router ID) that have no meaning outside the domain, rather than a globally routable address. This design increases security and confidentiality by making the PCE-ID opaque to entities outside the domain that contains the CPS head end.
IANA assigned the same subobject numbers (64 and 65) for the PKS in RSVP-TE as are used for the PKS in PCEP (RFC 5520), ensuring consistent identification across both protocols.
If a CPS is derived from a PKS, the path fragment SHOULD be inserted into the ERO as a direct replacement for the PKS.
If adding the expanded CPS to an ERO causes the Path message to exceed MTU, the LSR MAY replace part of the ERO with loose hops or a further PKS; if unable to reduce size, it MUST send a PathErr with 'Routing Problem' / 'ERO too large for MTU' (value 34).
If an LSR receives a Path message where the first subobject of the ERO is a PKS, it MUST respond with a PathErr message carrying error code/value 'Routing Problem' / 'Bad initial subobject'. A PKS must always be preceded by a subobject identifying the head end of the CPS.
If an LSR strips all local ERO subobjects and finds the next subobject is a PKS, it MUST attempt to resolve the PKS to a CPS. Resolution may use PCEP to contact the identified PCE, any PCE acting as proxy, or locally cached CPS information.
It is RECOMMENDED that the PCE providing a PKS expansion verify that the LSR requesting expansion is the head end of the resulting CPS, to prevent unauthorized probing of confidential path segments.
The L bit in the PKS SHOULD NOT be set, so that the subobject represents a strict hop in the explicit route.
The PCE-ID field 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 expansion in the RRO SHOULD be made available to diagnostic tools under the control of local policy.
When PKS expansion fails because the identified PCE cannot be reached, the LSR MUST send a PathErr with 'Routing Problem' / 'Unreachable PCE for PKS expansion' (value 32); if the PCE cannot decode the key (e.g., expired), 'Unknown Path Key for PKS expansion' (value 33) is used.
When PKS expansion fails because the PCE-ID cannot be matched to a PCE, the LSR MUST send a PathErr with error code 'Routing Problem' and new error value 'Unknown PCE-ID for PKS expansion' (value 31).
When the signaling message crosses a domain boundary, the CPS MAY be replaced in the RRO with a PKS. For a Resv RRO the PKS used SHOULD be the one originally signaled in the ERO; for a Path RRO the PKS SHOULD identify the replacing LSR and provide an expandable Path Key retained for at least the LSP lifetime.
The Path Key Subobject (PKS) is a fixed-length ERO subobject containing a 2-byte Path Key (an opaque identifier/token for the Confidential Path Segment) and a PCE-ID (IPv4 or IPv6 address identifying the PCE that can decode it). It is carried in RSVP-TE EROs and RROs to hide topology within an AS during inter-domain LSP signaling.
IANA allocated four new error values under the 'Routing Problem' error code (24) in the RSVP Parameters registry: 31 = Unknown PCE-ID for PKS expansion, 32 = Unreachable PCE for PKS expansion, 33 = Unknown Path Key for PKS expansion, 34 = ERO too large for MTU.
IANA allocated two new subobject types under EXPLICIT_ROUTE object (Class Number 20, C-Type 1) in the RSVP Parameters registry: subobject type 64 for 'Path Key with 32-bit PCE-ID' and subobject type 65 for 'Path Key with 128-bit PCE-ID', both assigned to RFC 5553.
IANA allocated two new subobject types under ROUTE_RECORD object (Class Number 21, C-Type 1): subobject type 64 for 'Path Key with 32-bit PCE-ID' and subobject type 65 for 'Path Key with 128-bit PCE-ID', matching the ERO subobject numbers.
A PCE is vulnerable to DoS via flood of PKS expansion requests (addressed in RFC 5520) and RSVP-TE is vulnerable to floods of spurious PKS Path messages. The latter is mitigated by RSVP-TE message integrity mechanisms and the chain-of-trust security model.
Alteration or forgery of the Path Key in a PKS can cause erroneous CPS expansion, leading to incorrect EROs, misdirected traffic (potentially enabling interception), or LSP setup failure. Prevention requires protecting PCEP and RSVP-TE protocol exchanges using their respective security mechanisms.
Detailed error codes returned on PKS expansion failure (Section 3.1) can leak topology information via probing. Any LSR MAY substitute all such errors with 'Policy Control Failure' / 'Inter-domain policy failure' to prevent information disclosure.
Unauthorized probing of a PCE for CPS expansion (e.g., by generating random Path Keys) must be mitigated by only allowing PKS expansion when requested by the LSR at the head end of the resulting CPS. Under specific circumstances, configured management stations may also be permitted.
The IPv4 variant of the Path Key Subobject (PKS) is 8 bytes total: 1-byte L+Type field, 1-byte Length (always 8), 2-byte Path Key, and 4-byte PCE-ID (IPv4 address). The subobject type is assigned by IANA as 64.
The IPv6 variant of the Path Key Subobject (PKS) is 20 bytes total: 1-byte L+Type field, 1-byte Length (always 20), 2-byte Path Key, and 16-byte PCE-ID (IPv6 address). The subobject type is assigned by IANA as 65.