draft-ietf-lsr-pce-discovery-security-support-01.txt   draft-ietf-lsr-pce-discovery-security-support-02.txt 
PCE working group D. Lopez PCE working group D. Lopez
Internet-Draft Telefonica I+D Internet-Draft Telefonica I+D
Updates: 5088,5089 (if approved) Q. Wu Updates: 5088,5089 (if approved) Q. Wu
Intended status: Standards Track D. Dhody Intended status: Standards Track D. Dhody
Expires: December 4, 2019 Z. Wang Expires: March 5, 2020 Z. Wang
Huawei Huawei
D. King D. King
Old Dog Consulting Old Dog Consulting
June 2, 2019 September 2, 2019
IGP extension for PCEP security capability support in the PCE discovery 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 Abstract
When a Path Computation Element (PCE) is a Label Switching Router When a Path Computation Element (PCE) is a Label Switching Router
(LSR) participating in the Interior Gateway Protocol (IGP), or even a (LSR) participating in the Interior Gateway Protocol (IGP), or even a
server participating in IGP, its presence and path computation server participating in IGP, its presence and path computation
capabilities can be advertised using IGP flooding. The IGP capabilities can be advertised using IGP flooding. The IGP
extensions for PCE discovery (RFC 5088 and RFC 5089) define a method extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
to advertise path computation capabilities using IGP flooding for to advertise path computation capabilities using IGP flooding for
OSPF and IS-IS respectively. However these specifications lack a OSPF and IS-IS respectively. However these specifications lack a
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 5 skipping to change at page 2, line 49
capabilities using IGP flooding for OSPF and IS-IS respectively. capabilities using IGP flooding for OSPF and IS-IS respectively.
However these specifications lack a method to advertise PCEP security However these specifications lack a method to advertise PCEP security
(e.g., TLS) support capability. (e.g., TLS) support capability.
This document proposes new capability flag bits for PCE-CAP-FLAGS This document proposes new capability flag bits for PCE-CAP-FLAGS
sub-TLV that can be announced as attributes in the IGP advertisement sub-TLV that can be announced as attributes in the IGP advertisement
to distribute PCEP security support information. In addition, this to distribute PCEP security support information. In addition, this
document updates RFC5088 and RFC5089 to allow advertisement of Key ID document updates RFC5088 and RFC5089 to allow advertisement of Key ID
or Key Chain Name Sub-TLV to support TCP AO security capability. 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 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. IGP extension for PCEP security capability support 3. IGP extension for PCEP security capability support
skipping to change at page 5, line 28 skipping to change at page 5, line 30
Length: Variable Length: Variable
Key Name: The Key Chain Name contains a string to be used to identify 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, 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 without a NULL terminator. The TLV MUST be zero-padded so that the
TLV is 4-octet aligned. TLV is 4-octet aligned.
4. Update to RFC5088 and RFC5089 4. Update to RFC5088 and RFC5089
Section 4 of [RFC5088] needs to be updated to allow advertisement of Section 4 of [RFC5088] states that no new sub-TLVs will be added to
additional PCE information carried in the Router Information LSA. the PCED TLV, and no new PCE information will be carried in the
The following is proposed text for this change. Router Information LSA. This document updates [RFC5088] by allowing
the two new sub-TLVs defined in this document to be carried in the
Replace the following paragraph from section 4: PCED TLV of the for use in the Router Information LSA.
"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."
At a time of publication of [RFC5088] and [RFC5089] there were Section 4 of [RFC5089] states that no new sub-TLVs will be added to
concerns about advertising non-IGP specific information in OSPF(v3) the PCED TLV, and no new PCE information will be carried in the
Router Information LSAs and IS-IS router capability TLV. [RFC7770] Router CAPABLITY TLV. This document updates [RFC5089] by allowing
added the functionality of advertising multiple instances of the the two new sub-TLVs defined in this document to be carried in the
OSPF(v3) Router Information LSA and IS-IS support multiple CAPABILITY PCED TLV of the for use in the Router CAPABILITY TLV.
TLV [RFC7981].
5. Backward Compatibility Consideration 5. Backward Compatibility Consideration
An LSR that does not support the new IGP PCE capability bits An LSR that does not support the new IGP PCE capability bits
specified in this document silently ignores those bits. specified in this document silently ignores those bits.
An LSR that does not support the new KEYNAME sub-TLV specified in An LSR that does not support the new KEYNAME sub-TLV specified in
this document silently ignores the sub-TLV. this document silently ignores the sub-TLV.
IGP extensions defined in this document do not introduce any new IGP extensions defined in this document do not introduce any new
interoperability issues. interoperability issues.
6. Management Considerations 6. Management Considerations
A configuration option may be provided for advertising and A configuration option may be provided for advertising and
withdrawing PCE security capability via IGP. withdrawing PCE security capability via IGP.
7. Security Considerations 7. Security Considerations
This document raises no new security issues beyond those described in Security considerations as specified by [RFC5088] and [RFC5089] are
[RFC5088] and [RFC5089]. 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. IANA Considerations
8.1. OSPF PCE Capability Flag 8.1. OSPF PCE Capability Flag
IANA is requested to allocate new bits assignments for the OSPF IANA is requested to allocate new bits assignments for the OSPF
Parameters "Path Computation Element (PCE) Capability Flags" Parameters "Path Computation Element (PCE) Capability Flags"
registry. registry.
Bit Meaning Reference Bit Meaning Reference
skipping to change at page 7, line 33 skipping to change at page 7, line 18
3 PCE-DOMAIN [This.I.D][RFC5088] 3 PCE-DOMAIN [This.I.D][RFC5088]
4 NEIG-PCE-DOMAIN [This.I.D][RFC5088] 4 NEIG-PCE-DOMAIN [This.I.D][RFC5088]
6 KEY-ID [This.I.D] 6 KEY-ID [This.I.D]
7 KEY-CHAIN-NAME [This.I.D] 7 KEY-CHAIN-NAME [This.I.D]
This registry is also used by IS-IS PCED sub-TLV. This registry is also used by IS-IS PCED sub-TLV.
9. Acknowledgments 9. Acknowledgments
The authors of this document would also like to thank Acee Lindem, 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. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 9 change blocks. 
50 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/