IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED)
updates
- rfc-5088 — OSPF Protocol Extensions for Path Computation Element (PCE) Discovery
- rfc-5089 — IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery
- rfc-8231 — Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
- rfc-8306 — Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
Extracted elements (20)
TCP security-related key parameters must be known before the PCEP session is established and PCEP Open messages are exchanged, which is why IGP advertisement and flooding mechanisms must be used for PCE security capability discovery rather than the PCEP Open message exchange.
The PCE Capability Flags registry was moved from the OSPFv2 Parameters grouping to the IGP Parameters grouping because the flags apply equally to IS-IS and OSPF, and a shared registry better reflects this dual-protocol scope.
An LSR that does not support the IGP PCE capability bits or the KEY-ID and KEY-CHAIN-NAME sub-TLVs defined in this document silently ignores them. The IGP extensions introduce no new interoperability issues.
This document updates RFCs 5088 and 5089, which previously stated no new sub-TLVs would be added to the PCED TLV. The addition of KEY-ID and KEY-CHAIN-NAME sub-TLVs is an explicit exception justified by the requirement to discover PCEP security support prior to establishing a PCEP session.
Before advertising PCEP security parameters via IGP, the IGP MUST be known to provide authentication and integrity for the PCED TLV using mechanisms defined in RFC 5304, RFC 5310, or RFC 5709, because the new capability bits are susceptible to downgrade attacks.
If a client is configured to require TCP-AO support, it MUST verify the TCP-AO flag bit in the PCE-CAP-FLAGS sub-TLV is set before opening a connection. Similarly, if TLS is required, the client MUST verify the PCEP over TLS support flag bit is set.
If a PCE supports TCP-AO, its IGP advertisement SHOULD include a TCP-AO support flag bit; if it supports TLS, the IGP advertisement SHOULD include a PCEP over TLS support flag bit. If multiple security mechanisms are supported, all corresponding flag bits SHOULD be included.
It is RECOMMENDED that PCEP be secured using TLS per RFC 8253, as TCP MD5 has been obsoleted by TCP-AO due to security concerns and TCP-AO is not widely implemented. An implementation SHOULD offer at least one of the two security capabilities defined in this document.
The KEY-CHAIN-NAME field MUST be encoded using UTF-8, and a receiving entity MUST NOT interpret invalid UTF-8 sequences. UTF-8 'Shortest Form' encoding is REQUIRED to guard against technical issues outlined in UTR36.
The OSPF KEY-CHAIN-NAME sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet aligned.
The Reserved field in the OSPF KEY-ID sub-TLV MUST be set to zero while sending and ignored on receipt.
The KEY-CHAIN-NAME sub-TLV (Type=7) carries a variable-length UTF-8 key chain name (1 to 255 octets) to identify the key chain for TCP-AO. It MAY be present in the PCED sub-TLV when the TCP-AO capability flag bit is set.
The KEY-ID sub-TLV (Type=6) carries a one-octet KeyID as per RFC 5925 to uniquely identify the Master Key Tuple (MKT) for TCP-AO. It MAY be present in PCED sub-TLV when the TCP-AO capability flag bit is set.
Two new PCE Capability Flag bits are defined: Bit 17 for TCP-AO Support and Bit 18 for PCEP over TLS support, carried in the PCE-CAP-FLAGS sub-TLV advertised via IGP flooding for both OSPF and IS-IS.
IANA created a new 'PCE Discovery (PCED) Sub-TLV Type Indicators' registry under IGP Parameters with Standards Action policy (range 0-65535), initially populated with values 0-7 covering Reserved, PCE-ADDRESS, PATH-SCOPE, PCE-DOMAIN, NEIG-PCE-DOMAIN, PCE-CAP-FLAGS, KEY-ID, and KEY-CHAIN-NAME.
IANA moved the 'Path Computation Element (PCE) Capability Flags' registry from the OSPFv2 Parameters grouping to the 'Interior Gateway Protocol (IGP) Parameters' grouping, and assigned Bit 17 for TCP-AO Support and Bit 18 for PCEP over TLS support.
The new capability flag bits defined in this document are susceptible to a downgrade attack by setting them to zero, and Key-ID or KEY-CHAIN-NAME content can be altered to enable an on-path attack. IGP authentication and integrity (RFC 5304, 5310, or 5709) MUST be in place before advertising these parameters.
There are no mechanisms in OSPF or IS-IS to protect the confidentiality of the PCED TLV. Operators must ensure no private data is carried, for example ensuring KeyIDs or key chain names do not reveal sensitive information about the network.
The OSPF KEY-CHAIN-NAME sub-TLV has Type=7, variable Length (padding not included), followed by the Key Chain Name string zero-padded to 4-octet alignment. The IS-IS variant uses the same Type=7 with variable length encoding the value field length.
The OSPF KEY-ID sub-TLV has Type=6, Length=4, with a one-octet KeyID field followed by 3 Reserved octets that MUST be set to zero. The IS-IS variant has Type=6, Length=1, with only the KeyID octet.