RFC 9353

IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED)

📅 published January 2023, from ietf

RFC 9353: IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED) 💖

Bestie, here's the deal with the title block 🎀 This doc came out in January 2023 as a Standards Track document, which is the IETF's official "this is a real spec, go build it" category. It's marked as ISSN 2070-1721, and the authors are D. Lopez (Telefonica I+D), Q. Wu, D. Dhody, Q. Ma (Huawei), and D. King (Old Dog Consulting). It updates RFCs 5088, 5089, 8231, and 8306, so it's basically going back and editing those older specs. Iconic, honestly 💅

Abstract

okay so, when a PCE (Path Computation Element) is an LSR (Label Switching Router) or a server that takes part in the IGP (Interior Gateway Protocol), its existence and path computation skills can be advertised by IGP flooding 🌊. The IGP extensions for PCE Discovery (PCED), RFC 5088 and RFC 5089, explain how to advertise those path computation capabilities through IGP flooding for OSPF and IS-IS, respectively. The problem is that those specs don't have a way to advertise PCEP security support, like TLS (Transport Layer Security) and TCP-AO (TCP Authentication Option) 😭

So this doc defines capability flag bits for the PCE-CAP-FLAGS sub-TLV, which can be announced as an attribute in the IGP advertisement to share PCEP security support info ✨. It also updates RFCs 5088 and 5089 so you can advertise a Key ID or KEY-CHAIN-NAME sub-TLV to support the TCP-AO security capability. And it updates RFCs 8231 and 8306 too. Main character energy 👑

Status of This Memo

This is an Internet Standards Track document 🎀

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🧚

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9353 🌸

Copyright (c) 2023 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 (https://trustee.ietf.org/license-info) as they were in effect on the date this document was published. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License ⭐

Table of Contents

   1.  Introduction
   2.  Conventions Used in This Document
   3.  IGP Extension for PCEP Security Capability Support
     3.1.  Use of PCEP Security Capability Support for PCED
     3.2.  KEY-ID Sub-TLV
       3.2.1.  IS-IS
       3.2.2.  OSPF
     3.3.  KEY-CHAIN-NAME Sub-TLV
       3.3.1.  IS-IS
       3.3.2.  OSPF
   4.  Updates to RFCs
   5.  Backward Compatibility Considerations
   6.  Management Considerations
     6.1.  Control of Policy and Functions
     6.2.  Information and Data Model
     6.3.  Liveness Detection and Monitoring
     6.4.  Verification of Correct Operations
     6.5.  Requirements on Other Protocols and Functional Components
     6.6.  Impact on Network Operations
   7.  Security Considerations
   8.  IANA Considerations
     8.1.  PCE Capability Flags
     8.2.  PCED Sub-TLV Type Indicators
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction 🦋

As [RFC5440] describes, privacy and integrity matter a lot for PCEP (Path Computation Element Communication Protocol) communication 😤 If an attacker intercepts a PCEP message, they could get their hands on sensitive info about computed paths and resources. Authentication and integrity checks let the receiver of a PCEP message confirm two things: that the message really comes from the node that says it sent it, and whether the message got changed along the way 🔒

Among the options mentioned in [RFC5440], Transport Layer Security (TLS) [RFC8446] gives you peer authentication, message encryption, and integrity. TCP-AO) [RFC5925] and Cryptographic Algorithms for TCP-AO [RFC5926] offer a much stronger security upgrade for apps that use TCP 💪 As Section 4 of [RFC8253] specifies, a PCC (Path Computation Client) needs to know whether the PCE server supports TLS or TCP-AO as a secure transport, so that the PCC can connect to the PCE server over TLS or TCP-AO 🫶

[RFC5088] and [RFC5089] define a way to advertise path computation capabilities through IGP flooding for OSPF and IS-IS, respectively. But those specs don't have a method to advertise PCEP security capabilities (like TLS and TCP-AO) 🙃

This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV, which can be announced as attributes in the IGP advertisement to distribute PCEP security support info ✨ It also updates [RFC5088] and [RFC5089] so you can advertise a KeyID or KEY-CHAIN-NAME sub-TLV for the TCP-AO security capability 🎀

IANA created a top-level registry called "Path Computation Element (PCE) Capability Flags" under [RFC5088]. This document updates [RFC5088] and moves that registry so it sits under the heading of the "Interior Gateway Protocol (IGP) Parameters" registry 🍓 [RFC5089] says the IS-IS PCE-CAP-FLAGS sub-TLV uses the same registry as OSPF, and this document updates [RFC5089] to point at the new IGP registry. This doc also updates [RFC8231], which referenced the registry location as the "Open Shortest Path First v2 (OSPFv2) Parameters" registry, so it now refers to the "Interior Gateway Protocol (IGP) Parameters" registry instead 💅 And it updates [RFC8306] by changing the term "OSPF PCE Capability Flag" to "Path Computation Element (PCE) Capability Flags", and noting that the corresponding registry now lives in the "Interior Gateway Protocol (IGP) Parameters" registry 🌈

Note that [RFC5557] uses the term "OSPF registry" instead of the "IGP registry", whereas [RFC8623] and [RFC9168] use the term "OSPF Parameters" instead of "IGP Parameters".
Note that the PCEP Open message exchange is another way to discover PCE capabilities information. However, in this case, the TCP-security-related key parameters need to be known before the PCEP session is established and the PCEP Open messages are exchanged. So the IGP advertisement and flooding mechanisms need to be used for PCE discovery and capabilities advertisement 🧠

2. Conventions Used in This Document ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖 Those are the only time they carry that meaning, so don't go capitalizing them for fun 🙈

3. IGP Extension for PCEP Security Capability Support 🌸

[RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF Router Information Link State Advertisement (LSA), as defined in [RFC7770], to make PCED work with OSPF. This document defines two capability flag bits in the OSPF PCE Capability Flags to show TCP-AO support [RFC5925] [RFC5926] and PCEP over TLS support [RFC8253], respectively 🦋

Similarly, [RFC5089] defines the PCED sub-TLV for PCED with IS-IS. This document will use the same flags for the OSPF PCE Capability Flags sub-TLV so that IS-IS can indicate TCP-AO support and PCEP over TLS support, respectively 🫶

The IANA assignments for the shared OSPF and IS-IS Security Capability Flags are documented in Section 8.1 of this document 📋

3.1. Use of PCEP Security Capability Support for PCED 🔥

The TCP-AO and PCEP over TLS support flag bits are advertised using IGP flooding:

  • PCE supports TCP-AO: IGP advertisement SHOULD include a TCP-AO support flag bit.
  • PCE supports TLS: IGP advertisement SHOULD include PCEP over TLS support flag bit.

If the PCE supports multiple security mechanisms, it SHOULD include all of the corresponding flag bits in its IGP advertisement 💖

A client's configuration MAY indicate that support for a given security capability is required. If a client is configured to require that its PCE server supports TCP-AO, the client MUST verify that the TCP-AO flag bit in the PCE-CAP-FLAGS sub-TLV for a given server is set before it opens a connection to that server 😤 Same deal if the client is configured to require that its PCE server supports TLS: the client MUST verify that the PCEP over TLS support flag bit in the PCE-CAP-FLAGS sub-TLV for a given server is set before it opens a connection to that server 🔐

3.2. KEY-ID Sub-TLV 🗝️

The KEY-ID sub-TLV specifies an identifier that the PCC can use to identify the TCP-AO key (called "KeyID" in [RFC5925]) 💜

3.2.1. IS-IS

The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried within the IS-IS Router CAPABILITY TLV when the capability flag bit of the PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP-AO support ✨

The KEY-ID sub-TLV has the following format 📐

  • Type: 6
  • Length: 1
  • KeyID: The one-octet KeyID as per [RFC5925] to uniquely identify the Master Key Tuple (MKT).

3.2.2. OSPF

Similarly, this sub-TLV MAY be present in the PCED TLV carried within the OSPF Router Information LSA when the capability flag bit of the PCE-CAP-FLAGS sub-TLV in OSPF is set to indicate TCP-AO support 🧚

The format of the KEY-ID sub-TLV goes like this:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type = 6         |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    KeyID      |                 Reserved                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 6
  • Length: 4
  • KeyID: The one-octet KeyID as per [RFC5925] to uniquely identify the MKT.
  • Reserved: MUST be set to zero while sending and ignored on receipt. 🙈

3.3. KEY-CHAIN-NAME Sub-TLV 🌈

The KEY-CHAIN-NAME sub-TLV specifies a key chain name that the PCC can use to identify the key chain. The key chain name could be manually configured via the command-line interface (CLI) or installed in the YANG datastore (see [RFC8177]) at the PCC 🍓

3.3.1. IS-IS 🦋

okay so the KEY-CHAIN-NAME sub-TLV MAY show up in the PCED sub-TLV inside the IS-IS Router CAPABILITY TLV, but ONLY when the capability flag bit in the PCE-CAP-FLAGS sub-TLV is set to say TCP-AO support 💅

here's the vibe of the format:

  • Type: 7
  • Length: Variable, encodes the length of the value field.
  • Key Chain Name: this is the name that identifies the key chain 🔑. It's a string of 1 to 255 octets, and it MUST be encoded in UTF-8. A receiving entity MUST NOT interpret invalid UTF-8 sequences and ignore them 🙈 The field is not NULL terminated. And UTF-8 "Shortest Form" encoding is REQUIRED so we don't run into the technical issues from [UTR36] 🫶

3.3.2. OSPF 🌸

same energy here, ngl 💖 this sub-TLV MAY be in the PCED TLV that lives inside the OSPF Router Information LSA, again only when the PCE-CAP-FLAGS capability bit in OSPF says TCP-AO support. And the sub-TLV MUST be zero-padded so it lands on a 4-octet boundary ✨

this is the layout:

                    1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type = 7         |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
//                     Key Chain Name                          //
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 7
  • Length: Variable, padding is not included in the Length field.
  • Key Chain Name: a string of 1 to 255 octets that identifies the key chain 🔑 It MUST be encoded using UTF-8. A receiving entity MUST NOT interpret invalid UTF-8 sequences and ignore them 🙈 This field is not NULL terminated. UTF-8 "Shortest Form" encoding is REQUIRED to guard against the technical issues outlined in [UTR36]. The sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet aligned 🎀

4. Updates to RFCs 🔄

okay the history tea ☕ Section 4 of [RFC5088] says no new sub-TLVs get added to the PCED TLV and no new PCE info gets carried in the Router Information LSA. This document updates [RFC5088] so the two sub-TLVs defined here CAN ride in the PCED TLV advertised in the Router Information LSA 🦋

same deal with [RFC5089]! Section 4 says no new sub-TLVs in the PCED TLV and no new PCE info in the Router CAPABILITY TLV. This document updates [RFC5089] by letting those two sub-TLVs live in the PCED TLV advertised in the Router CAPABILITY TLV 💜

this is giving exception vibes 👑 It's justified because we need to discover the PCEP security support BEFORE a PCEP session gets set up. The restrictions in [RFC5088] and [RFC5089] should still be considered to be in place 💅 If we ever need new advertisements later, alternative mechanisms like [RFC6823] or [LSR-OSPF-TRANSPORT-INSTANCE] should be considered 🧚

and the registry bit: the PCE Capability Flags registry from Section 8.3 of [RFC5557], Section 8.1 of [RFC8231], Section 6.9 of [RFC8306], Section 11.1 of [RFC8623], and Section 10.5 of [RFC9168] has changed over to the IGP Parameters "Path Computation Element (PCE) Capability Flags" registry created in this document 🌈

5. Backward Compatibility Considerations 🍓

an LSR that doesn't support the IGP PCE capability bits from this document just silently ignores them 🙈

an LSR that doesn't support the KEY-ID and KEY-CHAIN-NAME sub-TLVs from this document also silently ignores those sub-TLVs 🫶

and bestie, the IGP extensions here don't introduce any new interoperability issues ✨

6. Management Considerations 🧚

manageability for PCED is covered in Section 4.10 of [RFC4674], Section 9 of [RFC5088], and Section 9 of [RFC5089] 💅

6.1. Control of Policy and Functions 🎀

a PCE implementation SHOULD let you configure these parameters on the PCE:

  • support for TCP-AO
  • the KeyID used by TCP-AO
  • Key Chain Name
  • support for TLS

6.2. Information and Data Model 📚

the YANG module for PCEP [PCE-PCEP-YANG] supports PCEP security parameters (key, key chain, and TLS) 🔐

6.3. Liveness Detection and Monitoring 💓

normal IGP operations already meet the requirements for liveness detection and monitoring ✨

6.4. Verification of Correct Operations ✅

you can check that the PCEP security info advertised matches what's received 👀 Compare the info in the PCED sub-TLV the PCC receives with what's stored at the PCE, using the PCEP YANG 💖

6.5. Requirements on Other Protocols and Functional Components 🌷

there are no new requirements on other protocols 🦋

6.6. Impact on Network Operations ⚠️

Heads up: frequent changes to the PCEP security info advertised in the PCED sub-TLV can seriously affect the IGP and might destabilize the network by making PCCs reconnect their sessions with PCEs 😭

Section 4.10.4 of [RFC4674], Section 9.6 of [RFC5088], and Section 9.6 of [RFC5089] list techniques that apply to this document too 🫶

7. Security Considerations 🔐💀

the security considerations from [RFC5088] and [RFC5089] apply to this document, periodt 💅

as described in Section 10.2 of [RFC5440], a PCEP speaker MUST support TCP MD5 [RFC2385], so no capability advertisement is needed to show support. BUT as noted in [RFC6952], TCP MD5 got obsoleted by TCP-AO [RFC5925] because of security concerns 😭 TCP-AO isn't widely implemented, so it is RECOMMENDED that PCEP be secured using TLS per [RFC8253] (which updates [RFC5440]) 🔥 An implementation SHOULD offer at least one of the two security capabilities defined in this document 🎀

this info is sensitive, so the operator needs to take due care 🚨 This document defines new capability bits that are susceptible to a downgrade attack by setting them to zero. The content of the Key-ID or KEY-CHAIN-NAME sub-TLV can be altered to enable an on-path attack. So, before advertising the PCEP security parameters using the mechanism in this document, the IGP MUST be known to provide authentication and integrity for the PCED TLV using the mechanisms defined in [RFC5304], [RFC5310], or [RFC5709] 🛡️

and as stated in the security considerations of [RFC5088] and [RFC5089], there are NO mechanisms defined in OSPF or IS-IS to protect the confidentiality of the PCED TLV 🙈 For this reason, the operator must make sure no private data is carried in the TLV. For example, the operator must make sure that KeyIDs or key chain names do not reveal sensitive information about the network 🫣

8. IANA Considerations 📋

8.1. PCE Capability Flags 🏳️

IANA has moved the "Path Computation Element (PCE) Capability Flags" registry from the "Open Shortest Path First v2 (OSPFv2) Parameters" grouping to the "Interior Gateway Protocol (IGP) Parameters" grouping 🧚

IANA also made these additional assignments from the "Path Computation Element (PCE) Capability Flags" registry:

           +=====+========================+===========+
           | Bit | Capability Description | Reference |
           +=====+========================+===========+
           | 17  | TCP-AO Support         | RFC 9353  |
           +-----+------------------------+-----------+
           | 18  | PCEP over TLS support  | RFC 9353  |
           +-----+------------------------+-----------+

             Table 1: Path Computation Element (PCE)
                  Capability Flags Registrations

the grouping lives at: <https://www.iana.org/assignments/igp-parameters/> 🌐

8.2. PCED Sub-TLV Type Indicators 🌟

the PCED sub-TLVs are defined in [RFC5088] and [RFC5089], but there was never a matching IANA registry. IANA has now created a new registry called "PCE Discovery (PCED) Sub-TLV Type Indicators" under the "Interior Gateway Protocol (IGP) Parameters" registry 🎉 The registration policy is "Standards Action" [RFC8126], and values come from the range 0-65535.

this registry is initially populated like so:

         +=======+=================+====================+
         | Value | Description     | Reference          |
         +=======+=================+====================+
         | 0     | Reserved        | RFC 9353, RFC 5088 |
         +-------+-----------------+--------------------+
         | 1     | PCE-ADDRESS     | RFC 9353, RFC 5088 |
         +-------+-----------------+--------------------+
         | 2     | PATH-SCOPE      | RFC 9353, RFC 5088 |
         +-------+-----------------+--------------------+
         | 3     | PCE-DOMAIN      | RFC 9353, RFC 5088 |
         +-------+-----------------+--------------------+
         | 4     | NEIG-PCE-DOMAIN | RFC 9353, RFC 5088 |
         +-------+-----------------+--------------------+
         | 5     | PCE-CAP-FLAGS   | RFC 9353, RFC 5088 |
         +-------+-----------------+--------------------+
         | 6     | KEY-ID          | RFC 9353           |
         +-------+-----------------+--------------------+
         | 7     | KEY-CHAIN-NAME  | RFC 9353           |
         +-------+-----------------+--------------------+

            Table 2: Initial Contents of the PCED Sub-
                   TLV Type Indicators Registry

this registry gets used by both the OSPF PCED TLV and the IS-IS PCED sub-TLV 🦋

the grouping is also at: <https://www.iana.org/assignments/igp-parameters/> 💖

9. References 📖

9.1. Normative References

okay bestie, these are the big ones the spec leans on hard 🫶 every one of these is a document it builds on, so they're kinda the foundation of the whole thing 🧱

9.2. Informative References

these ones are the extra reading 📚 nice to have for context, the spec doesn't need them to make sense 💅

Acknowledgments

big thank-you party time 🎉 these are the people who reviewed and commented, and the spec is better because of them 🫶

The authors of this document would like to thank Acee Lindem, Julien Meuric, Les Ginsberg, Ketan Talaulikar, Tom Petch, Aijun Wang, and Adrian Farrel for the review and comments.

The authors would also like to give special thanks to Michale Wang for his major contributions to the initial draft version. main character energy for the first draft 🌈✨

Thanks to John Scudder for providing an excellent AD review.

Thanks to Carlos Pignataro, Yaron Sheffer, Ron Bonica, and Will (Shucheng) LIU for directorate reviews.

Thanks to Lars Eggert, Robert Wilton, Roman Danyliw, Éric Vyncke, Paul Wouters, Murray Kucherawy, and Warren Kumari for IESG reviews.

Authors' Addresses

the people behind the keyboard, bestie 💖 here's where to find them 🦋

Diego R. Lopez Telefonica I+D Spain Email: diego.r.lopez@telefonica.com

Qin Wu Huawei Technologies Yuhua District 101 Software Avenue Nanjing Jiangsu, 210012 China Email: bill.wu@huawei.com

Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore 560037 Karnataka India Email: dhruv.ietf@gmail.com

Qiufang Ma Huawei Technologies Yuhua District 101 Software Avenue Nanjing Jiangsu, 210012 China Email: maqiufang1@huawei.com

Daniel King Old Dog Consulting United Kingdom Email: daniel@olddog.co.uk

📦 where this page comes from