--- 1/draft-ietf-lsr-pce-discovery-security-support-01.txt 2019-09-03 04:13:53.530364977 -0700 +++ 2/draft-ietf-lsr-pce-discovery-security-support-02.txt 2019-09-03 04:13:53.554365582 -0700 @@ -1,23 +1,23 @@ PCE working group D. Lopez Internet-Draft Telefonica I+D Updates: 5088,5089 (if approved) Q. Wu Intended status: Standards Track D. Dhody -Expires: December 4, 2019 Z. Wang +Expires: March 5, 2020 Z. Wang Huawei D. King Old Dog Consulting - June 2, 2019 + September 2, 2019 IGP extension for PCEP security capability support in the PCE discovery - draft-ietf-lsr-pce-discovery-security-support-01 + draft-ietf-lsr-pce-discovery-security-support-02 Abstract When a Path Computation Element (PCE) is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating in IGP, its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE discovery (RFC 5088 and RFC 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS respectively. However these specifications lack a @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 4, 2019. + This Internet-Draft will expire on March 5, 2020. Copyright Notice Copyright (c) 2019 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 @@ -83,20 +83,27 @@ capabilities using IGP flooding for OSPF and IS-IS respectively. However these specifications lack a method to advertise PCEP security (e.g., TLS) support capability. This document proposes new capability flag bits for 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 Key ID or Key Chain Name Sub-TLV to support TCP AO security capability. + Note that the PCEP Open message exchange is another way to discover + PCE capabilities information, but 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 use of + the PCE discovery and capabilities advertisement in the IGP needs to + be used. + 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 @@ -201,85 +208,65 @@ Length: Variable Key Name: The Key Chain Name contains a string to be used to identify the key chain. It SHOULD be a string of printable ASCII characters, without a NULL terminator. The TLV MUST be zero-padded so that the TLV is 4-octet aligned. 4. Update to RFC5088 and RFC5089 - Section 4 of [RFC5088] needs to be updated to allow advertisement of - additional PCE information carried in the Router Information LSA. - The following is proposed text for this change. - - Replace the following paragraph from section 4: - - "No additional sub-TLVs will be added to the PCED TLV in the future. - If a future application requires the advertisement of additional PCE - information in OSPF/ISIS, this will not be carried in the Router - Information LSA." - - with - - "If a future application requires the advertisement of additional PCE - information in OSPF, e.g., to facilitate key distribution and - cryptographic authentication and message integrity verification, - additional sub-TLVs could be added to the PCED TLV and carried in the - Router Information LSA." - - Section 4 of [RFC5089] needs to be updated to allow advertisement of - additional PCE information carried in the Router CAPABILITY TLV. The - following is proposed text for this change. - - Replace the following paragraph from section 4: - - "No additional sub-TLVs will be added to the PCED TLV in the future. - If a future application requires the advertisement of additional PCE - information in IS-IS, this will not be carried in the CAPABILITY - TLV." - - with - - "If a future application requires the advertisement of additional PCE - information in IS-IS, e.g., to facilitate key distribution and - cryptographic authentication and message integrity verification, - additional sub-TLVs could be added to the PCED sub-TLV and carried in - the CAPABILITY TLV." + 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 new sub-TLVs defined in this document to be carried in the + PCED TLV of the for use in the Router Information LSA. - At a time of publication of [RFC5088] and [RFC5089] there were - concerns about advertising non-IGP specific information in OSPF(v3) - Router Information LSAs and IS-IS router capability TLV. [RFC7770] - added the functionality of advertising multiple instances of the - OSPF(v3) Router Information LSA and IS-IS support multiple CAPABILITY - TLV [RFC7981]. + 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 CAPABLITY TLV. This document updates [RFC5089] by allowing + the two new sub-TLVs defined in this document to be carried in the + PCED TLV of the for use in the Router CAPABILITY TLV. 5. Backward Compatibility Consideration An LSR that does not support the new IGP PCE capability bits specified in this document silently ignores those bits. An LSR that does not support the new KEYNAME sub-TLV specified in this document silently ignores the sub-TLV. IGP extensions defined in this document do not introduce any new interoperability issues. 6. Management Considerations A configuration option may be provided for advertising and withdrawing PCE security capability via IGP. 7. Security Considerations - This document raises no new security issues beyond those described in - [RFC5088] and [RFC5089]. + Security considerations as specified by [RFC5088] and [RFC5089] are + applicable to 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 downgrade attack by toggling + them. The content of Key ID or Key Chain Name Sub-TLV can be tweaked + to enable a man-in-the-middle attack. Thus before advertisement of + the PCE security parameters, it MUST be insured that the IGP is + protected for authentication and integrity of the PCED TLV if the + mechanism described in this document is used. As stated in [RFC5088] + and [RFC5089], the IGP do not provide encryption mechanism to protect + the privacy of the PCED TLV, if this information can make the PCEP + session less secure then the operator should take that into + consideration. 8. IANA Considerations 8.1. OSPF PCE Capability Flag IANA is requested to allocate new bits assignments for the OSPF Parameters "Path Computation Element (PCE) Capability Flags" registry. Bit Meaning Reference @@ -303,21 +289,22 @@ 3 PCE-DOMAIN [This.I.D][RFC5088] 4 NEIG-PCE-DOMAIN [This.I.D][RFC5088] 6 KEY-ID [This.I.D] 7 KEY-CHAIN-NAME [This.I.D] This registry is also used by IS-IS PCED sub-TLV. 9. Acknowledgments The authors of this document would also like to thank Acee Lindem, - Julien Meuric for the review and comments. + Julien Meuric, Les Ginsberg, Aijun Wang, Adrian Farrel for the review + and comments. 10. References 10.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, .