diff options
Diffstat (limited to 'doc/rfc/rfc9353.txt')
| -rw-r--r-- | doc/rfc/rfc9353.txt | 696 |
1 files changed, 696 insertions, 0 deletions
diff --git a/doc/rfc/rfc9353.txt b/doc/rfc/rfc9353.txt new file mode 100644 index 0000000..30074e3 --- /dev/null +++ b/doc/rfc/rfc9353.txt @@ -0,0 +1,696 @@ + + + + +Internet Engineering Task Force (IETF) D. Lopez +Request for Comments: 9353 Telefonica I+D +Updates: 5088, 5089, 8231, 8306 Q. Wu +Category: Standards Track D. Dhody +ISSN: 2070-1721 Q. Ma + Huawei + D. King + Old Dog Consulting + January 2023 + + +IGP Extension for Path Computation Element Communication Protocol (PCEP) + Security Capability Support in PCE Discovery (PCED) + +Abstract + + When a Path Computation Element (PCE) is a Label Switching Router + (LSR) or a server participating in the Interior Gateway Protocol + (IGP), its presence and path computation capabilities can be + advertised using IGP flooding. The IGP extensions for PCE Discovery + (PCED) (RFCs 5088 and 5089) define a method to advertise path + computation capabilities using IGP flooding for OSPF and IS-IS, + respectively. However, these specifications lack a method to + advertise Path Computation Element Communication Protocol (PCEP) + security (e.g., Transport Layer Security (TLS) and TCP Authentication + Option (TCP-AO)) support capability. + + This document defines capability flag bits for the PCE-CAP-FLAGS sub- + TLV that can be announced as an attribute in the IGP advertisement to + distribute PCEP security support information. In addition, this + document updates RFCs 5088 and 5089 to allow advertisement of a Key + ID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability. + This document also updates RFCs 8231 and 8306. + +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 has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9353. + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided 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 described in [RFC5440], privacy and integrity are important issues + for communication using the Path Computation Element Communication + Protocol (PCEP); an attacker that intercepts a PCEP message could + obtain sensitive information related to computed paths and resources. + Authentication and integrity checks allow the receiver of a PCEP + message to know that the message genuinely comes from the node that + purports to have sent it and whether the message has been modified. + + Among the possible solutions mentioned in [RFC5440], Transport Layer + Security (TLS) [RFC8446] provides support for peer authentication, + message encryption, and integrity while TCP-AO) [RFC5925] and + Cryptographic Algorithms for TCP-AO [RFC5926] offer significantly + improved security for applications using TCP. As specified in + Section 4 of [RFC8253], the PCC needs to know whether the PCE server + supports TLS or TCP-AO as a secure transport in order for a Path + Computation Client (PCC) to establish a connection with a PCE server + using TLS or TCP-AO. + + [RFC5088] and [RFC5089] define a method to advertise path computation + capabilities using IGP flooding for OSPF and IS-IS, respectively. + However, these specifications lack a method to advertise PCEP + security (e.g., TLS and TCP-AO) support capability. + + This document defines capability flag bits for the PCE-CAP-FLAGS sub- + TLV that can be announced as attributes in the IGP advertisement to + distribute PCEP security support information. In addition, this + document updates [RFC5088] and [RFC5089] to allow advertisement of a + KeyID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security + capability. + + IANA created a top-level registry titled "Path Computation Element + (PCE) Capability Flags" per [RFC5088]. This document updates + [RFC5088] and moves it to follow the heading of the "Interior Gateway + Protocol (IGP) Parameters" registry. [RFC5089] states that the IS-IS + PCE-CAP-FLAGS sub-TLV uses the same registry as OSPF. This document + updates [RFC5089] to refer to the new IGP registry. Further, this + document updates [RFC8231] where it references the registry location + as the "Open Shortest Path First v2 (OSPFv2) Parameters" registry to + the "Interior Gateway Protocol (IGP) Parameters" registry. This + document also updates [RFC8306] by changing the term "OSPF PCE + Capability Flag" to read as "Path Computation Element (PCE) + Capability Flags" and to note the corresponding registry now exists + 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 + | instance, the TCP-security-related key parameters need to be + | known before the PCEP session is established and the PCEP Open + | messages are exchanged. Thus, the IGP advertisement and + | flooding mechanisms need to be leveraged 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. + +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 facilitate PCED using OSPF. This document defines two + capability flag bits in the OSPF PCE Capability Flags to indicate + TCP-AO support [RFC5925] [RFC5926] and PCEP over TLS support + [RFC8253], respectively. + + Similarly, [RFC5089] defines the PCED sub-TLV for use in PCED using + IS-IS. This document will use the same flag for the OSPF PCE + Capability Flags sub-TLV to allow IS-IS to indicate TCP-AO support + and PCEP over TLS support, respectively. + + The IANA assignments for 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 + + 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 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. + Similarly, 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 can be used by the + PCC to identify the TCP-AO key (referred to as "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 is as follows: + + 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 can be + used by the PCC to identify the key chain. The key chain name could + be manually configured via command-line interface (CLI) or installed + in the YANG datastore (see [RFC8177]) at the PCC. + +3.3.1. IS-IS + + The KEY-CHAIN-NAME 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-CHAIN-NAME sub-TLV has the following format: + + Type: 7 + + Length: Variable, encodes the length of the value field. + + Key Chain Name: The Key Chain Name contains a string of 1 to 255 + octets to be used to identify 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]. + +3.3.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 + sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet aligned. + + The format of KEY-CHAIN-NAME sub-TLV is as follows: + + 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: The Key Chain Name contains a string of 1 to 255 + octets to be used to identify 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 + + Section 4 of [RFC5088] states that no new sub-TLVs will be added to + the PCED TLV and no new PCE information will be carried in the Router + Information LSA. This document updates [RFC5088] by allowing the two + sub-TLVs defined in this document to be carried in the PCED TLV + advertised in the Router Information LSA. + + Section 4 of [RFC5089] states that no new sub-TLVs will be added to + the PCED TLV and no new PCE information will be carried in the Router + CAPABILITY TLV. This document updates [RFC5089] by allowing the two + sub-TLVs defined in this document to be carried in the PCED TLV + advertised in the Router CAPABILITY TLV. + + This introduction of additional sub-TLVs should be viewed as an + exception to the policies in [RFC5088] and [RFC5089], which is + justified by the requirement to discover the PCEP security support + prior to establishing a PCEP session. The restrictions defined in + [RFC5088] and [RFC5089] should still be considered to be in place. + If new advertisements are required in the future, alternative + mechanisms such as using [RFC6823] or [LSR-OSPF-TRANSPORT-INSTANCE] + should be considered. + + The registry for the PCE Capability Flags assigned in 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 + to the IGP Parameters "Path Computation Element (PCE) Capability + Flags" registry created in this document. + +5. Backward Compatibility Considerations + + An LSR that does not support the IGP PCE capability bits specified in + this document silently ignores those bits. + + An LSR that does not support the KEY-ID and KEY-CHAIN-NAME sub-TLVs + specified in this document silently ignores those sub-TLVs. + + IGP extensions defined in this document do not introduce any new + interoperability issues. + +6. Management Considerations + + Manageability considerations for PCED are addressed 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 allow the following parameters to be + configured 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 operations of the IGP meet the requirements for liveness + detection and monitoring. + +6.4. Verification of Correct Operations + + The correlation of PCEP security information advertised against + information received can be achieved by comparing the information in + the PCED sub-TLV received by the PCC with that 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 + + Frequent changes in PCEP security information advertised in the PCED + sub-TLV may have a significant impact on IGP and might destabilize + the operation of the network by causing the PCCs to reconnect + sessions with PCEs. Section 4.10.4 of [RFC4674], Section 9.6 of + [RFC5088], and Section 9.6 of [RFC5089] list techniques that are + applicable to this document as well. + +7. Security Considerations + + Security considerations as specified by [RFC5088] and [RFC5089] are + applicable to this document. + + As described in Section 10.2 of [RFC5440], a PCEP speaker MUST + support TCP MD5 [RFC2385], so no capability advertisement is needed + to indicate support. However, as noted in [RFC6952], TCP MD5 has + been obsoleted by TCP-AO [RFC5925] because of security concerns. + TCP-AO is not widely implemented; therefore, 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. + + The information related to PCEP security is sensitive and due care + needs to be taken by the operator. 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. Thus, before advertising + the PCEP security parameters by using the mechanism described 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]. + + Moreover, 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 ensure that no private data is carried in the TLV. For + example, the operator must ensure 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 has made the following 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 is located 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 a + corresponding IANA registry was not created. IANA has created a new + registry called "PCE Discovery (PCED) Sub-TLV Type Indicators" under + the "Interior Gateway Protocol (IGP) Parameters" registry. The + registration policy for this registry is "Standards Action" + [RFC8126]. Values in this registry come from the range 0-65535. + + This registry is initially populated as follows: + + +=======+=================+====================+ + | 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 is used by both the OSPF PCED TLV and the IS-IS PCED + sub-TLV. + + This grouping is located at: <https://www.iana.org/assignments/igp- + parameters/>. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. + Zhang, "OSPF Protocol Extensions for Path Computation + Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, + January 2008, <https://www.rfc-editor.org/info/rfc5088>. + + [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. + Zhang, "IS-IS Protocol Extensions for Path Computation + Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, + January 2008, <https://www.rfc-editor.org/info/rfc5089>. + + [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, DOI 10.17487/RFC5304, October + 2008, <https://www.rfc-editor.org/info/rfc5304>. + + [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., + and M. Fanto, "IS-IS Generic Cryptographic + Authentication", RFC 5310, DOI 10.17487/RFC5310, February + 2009, <https://www.rfc-editor.org/info/rfc5310>. + + [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path + Computation Element Communication Protocol (PCEP) + Requirements and Protocol Extensions in Support of Global + Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, + July 2009, <https://www.rfc-editor.org/info/rfc5557>. + + [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., + Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic + Authentication", RFC 5709, DOI 10.17487/RFC5709, October + 2009, <https://www.rfc-editor.org/info/rfc5709>. + + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, DOI 10.17487/RFC5925, + June 2010, <https://www.rfc-editor.org/info/rfc5925>. + + [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and + S. Shaffer, "Extensions to OSPF for Advertising Optional + Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, + February 2016, <https://www.rfc-editor.org/info/rfc7770>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. + Zhang, "YANG Data Model for Key Chains", RFC 8177, + DOI 10.17487/RFC8177, June 2017, + <https://www.rfc-editor.org/info/rfc8177>. + + [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path + Computation Element Communication Protocol (PCEP) + Extensions for Stateful PCE", RFC 8231, + DOI 10.17487/RFC8231, September 2017, + <https://www.rfc-editor.org/info/rfc8231>. + + [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, + "PCEPS: Usage of TLS to Provide a Secure Transport for the + Path Computation Element Communication Protocol (PCEP)", + RFC 8253, DOI 10.17487/RFC8253, October 2017, + <https://www.rfc-editor.org/info/rfc8253>. + + [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, + "Extensions to the Path Computation Element Communication + Protocol (PCEP) for Point-to-Multipoint Traffic + Engineering Label Switched Paths", RFC 8306, + DOI 10.17487/RFC8306, November 2017, + <https://www.rfc-editor.org/info/rfc8306>. + + [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful + Path Computation Element (PCE) Protocol Extensions for + Usage with Point-to-Multipoint TE Label Switched Paths + (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, + <https://www.rfc-editor.org/info/rfc8623>. + + [RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation + Element Communication Protocol (PCEP) Extension for Flow + Specification", RFC 9168, DOI 10.17487/RFC9168, January + 2022, <https://www.rfc-editor.org/info/rfc9168>. + +9.2. Informative References + + [LSR-OSPF-TRANSPORT-INSTANCE] + Lindem, A., Qu, Y., Roy, A., and S. Mirtorabi, "OSPF-GT + (Generalized Transport)", Work in Progress, Internet- + Draft, draft-ietf-lsr-ospf-transport-instance-04, 3 + January 2023, <https://datatracker.ietf.org/doc/html/ + draft-ietf-lsr-ospf-transport-instance-04>. + + [PCE-PCEP-YANG] + Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura, + "A YANG Data Model for Path Computation Element + Communications Protocol (PCEP)", Work in Progress, + Internet-Draft, draft-ietf-pce-pcep-yang-20, 23 October + 2022, <https://datatracker.ietf.org/doc/html/draft-ietf- + pce-pcep-yang-20>. + + [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 + Signature Option", RFC 2385, DOI 10.17487/RFC2385, August + 1998, <https://www.rfc-editor.org/info/rfc2385>. + + [RFC4674] Le Roux, J.L., Ed., "Requirements for Path Computation + Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674, + October 2006, <https://www.rfc-editor.org/info/rfc4674>. + + [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + DOI 10.17487/RFC5440, March 2009, + <https://www.rfc-editor.org/info/rfc5440>. + + [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms + for the TCP Authentication Option (TCP-AO)", RFC 5926, + DOI 10.17487/RFC5926, June 2010, + <https://www.rfc-editor.org/info/rfc5926>. + + [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising + Generic Information in IS-IS", RFC 6823, + DOI 10.17487/RFC6823, December 2012, + <https://www.rfc-editor.org/info/rfc6823>. + + [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of + BGP, LDP, PCEP, and MSDP Issues According to the Keying + and Authentication for Routing Protocols (KARP) Design + Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, + <https://www.rfc-editor.org/info/rfc6952>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + + [UTR36] Davis, M., Ed. and M. Suignard, Ed., "Unicode Security + Considerations", Unicode Technical Report #36, August + 2010, <https://www.unicode.org/unicode/reports/tr36/>. + +Acknowledgments + + 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. + + 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 + + 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 |