< draft-ietf-lsr-pce-discovery-security-support-05.txt.orig | draft-ietf-lsr-pce-discovery-security-support-05.txt > | |||
---|---|---|---|---|
skipping to change at page 1, line 26 ¶ | skipping to change at page 1, line 26 ¶ | |||
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 | |||
method to advertise PCEP security (e.g., Transport Layer | method to advertise PCEP security (e.g., Transport Layer | |||
Security(TLS), TCP Authentication Option (TCP-AO)) support | Security (TLS), TCP Authentication Option (TCP-AO)) support | |||
capability. | capability. | |||
This document proposes new capability flag bits for PCE-CAP-FLAGS | This document defines capability flag bits for PCE-CAP-FLAGS | |||
sub-TLV that can be announced as attribute in the IGP advertisement | sub-TLV that can be announced as an attribute in the IGP advertisement | |||
to distribute PCEP security support information. In addition, this | to distribute PCEP security support information. In addition, this | |||
document updates RFC 5088 and RFC 5089 to allow advertisement of Key | document updates RFC 5088 and RFC 5089 to allow advertisement of Key | |||
ID or Key Chain Name Sub-TLV to support TCP AO security capability. | ID or Key Chain Name Sub-TLV to support TCP-AO security capability. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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/. | |||
skipping to change at page 2, line 34 ¶ | skipping to change at page 2, line 34 ¶ | |||
importance issue, as an attacker that intercepts a Path Computation | importance issue, as an attacker that intercepts a Path Computation | |||
Element (PCE) message could obtain sensitive information related to | Element (PCE) message could obtain sensitive information related to | |||
computed paths and resources. | computed paths and resources. | |||
Among the possible solutions mentioned in these documents, Transport | Among the possible solutions mentioned in these documents, Transport | |||
Layer Security (TLS) [RFC8446] provides support for peer | Layer Security (TLS) [RFC8446] provides support for peer | |||
authentication, and message encryption and integrity while TCP | authentication, and message encryption and integrity while TCP | |||
Authentication Option (TCP-AO) [RFC5925] and Cryptographic Algorithms | Authentication Option (TCP-AO) [RFC5925] and Cryptographic Algorithms | |||
for TCP-AO [RFC5926] offer significantly improved security for | for TCP-AO [RFC5926] offer significantly improved security for | |||
applications using TCP. As specified in section 4 of [RFC8253], in | applications using TCP. As specified in section 4 of [RFC8253], in | |||
order for a Path Computation Client (PCC) to begin a connection with | order for a Path Computation Client (PCC) to establish a connection with | |||
a PCE server using TLS or TCP-AO, PCC needs to know whether PCE | a PCE server using TLS or TCP-AO, PCC needs to know whether the PCE | |||
server supports TLS or TCP-AO as a secure transport. | server supports TLS or TCP-AO as a secure transport. | |||
[RFC5088] and [RFC5089] define a method to advertise path computation | [RFC5088] and [RFC5089] define a method to advertise path computation | |||
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 defines 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 | Note that the PCEP Open message exchange is another way to discover | |||
PCE capabilities information, but in this instance, the TCP security | PCE capabilities information, but in this instance, the TCP security | |||
related key parameters need to be known before the PCEP session is | related key parameters need to be known before the PCEP session is | |||
established and the PCEP Open messages are exchanged, thus the use of | established and the PCEP Open messages are exchanged. Thus, the use of | |||
the PCE discovery and capabilities advertisement in the IGP needs to | the PCE discovery and capabilities advertisement of the IGP needs to | |||
be used. | be leveraged. | |||
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 | |||
[RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF | [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF | |||
Router Information Link State Advertisement (LSA) as defined in | Router Information Link State Advertisement (LSA) as defined in | |||
[RFC7770] to facilitate PCE discovery using OSPF. This document | [RFC7770] to facilitate PCE discovery using OSPF. This document | |||
defines two new capability flag bits in the OSPF PCE Capability Flags | defines two capability flag bits in the OSPF PCE Capability Flags | |||
to indicate TCP Authentication Option (TCP-AO) support | to indicate TCP Authentication Option (TCP-AO) support | |||
[RFC5925][RFC5926], PCEP over TLS support [RFC8253] respectively. | [RFC5925][RFC5926] and PCEP over TLS support [RFC8253] respectively. | |||
Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE | Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE | |||
discovery using IS-IS. This document will use the same flag for the | discovery 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 | OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicate TCP | |||
Authentication Option (TCP-AO) support, PCEP over TLS support | Authentication Option (TCP-AO) support, PCEP over TLS support | |||
respectively. | respectively. | |||
The IANA assignments for shared OSPF and IS-IS Security Capability | The IANA assignments for shared OSPF and IS-IS Security Capability | |||
Flags are documented in Section 8.1 ("OSPF PCE Capability Flag") of | Flags are documented in Section 8.1 ("OSPF PCE Capability Flags") of | |||
this document. | this document. | |||
3.1. Use of PCEP security capability support for PCE discovery | 3.1. Use of PCEP security capability support for PCE discovery | |||
TCP-AO, PCEP over TLS support flag bits are advertised using IGP | TCP-AO, PCEP over TLS support flag bits are advertised using IGP | |||
flooding. | flooding. | |||
o PCE supports TCP-AO: IGP advertisement SHOULD include TCP-AO | o PCE supports TCP-AO: IGP advertisement SHOULD include TCP-AO | |||
support flag bit. | support flag bit. | |||
o PCE supports TLS: IGP advertisement SHOULD include PCEP over TLS | o PCE supports TLS: IGP advertisement SHOULD include PCEP over TLS | |||
support flag bit. | support flag bit. | |||
If PCE supports multiple security mechanisms, it SHOULD include all | If PCE supports multiple security mechanisms, it SHOULD include all | |||
corresponding flag bits in IGP advertisement. | corresponding flag bits in IGP advertisement. | |||
If the client is looking for connecting with PCE server with TCP-AO | If a PC Client is restricted to a PCE server with TCP-AO | |||
support, the client MUST check if TCP-AO support flag bit in the PCE- | support, the client MUST check if TCP-AO support flag bit in the PCE- | |||
CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT consider | CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT consider | |||
this PCE. If the client is looking for connecting with PCE server | this PCE. If the PC Client is restricted to a PCE server | |||
using TLS, the client MUST check if PCEP over TLS support flag bit in | using TLS, the client MUST check if PCEP over TLS support flag bit in | |||
the PCE-CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT | the PCE-CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT | |||
consider this PCE. Note that this can be overridden based on a local | consider this PCE. Note that this can be overridden based on a local | |||
policy at the PCC. | policy at the PCC. | |||
3.2. KEY-ID Sub-TLV | 3.2. KEY-ID Sub-TLV | |||
The KEY-ID sub-TLV specifies a key that can be used by the PCC to | The KEY-ID sub-TLV specifies a key that can be used by the PCC to | |||
identify the TCP-AO key [RFC5925]. | identify the TCP-AO key [RFC5925]. | |||
The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried within | The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried within | |||
the IS-IS Router Information Capability TLV when the capability flag | the IS-IS Router Information Capability TLV when the capability flag | |||
bit of PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP | bit in the PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP | |||
Authentication Option (TCP-AO) support. Similarly, this sub-TLV MAY | Authentication Option (TCP-AO) support. Similarly, this sub-TLV MAY | |||
be present in the PCED TLV carried within OSPF Router Information LSA | be present in the PCED TLV carried within OSPF Router Information LSA | |||
when the capability flag bit of PCE-CAP-FLAGS sub-TLV in OSPF is set | when the capability flag bit in the PCE-CAP-FLAGS sub-TLV in OSPF is set | |||
to indicate TCP-AO support. | to indicate TCP-AO support. | |||
The format of the KEY-ID sub-TLV is as follows: | The format of the KEY-ID sub-TLV is as follows: | |||
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 | 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 = 4 | | | Type = 6 | Length = 4 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| KeyID | Reserved | | | KeyID | Reserved | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
KEY-ID sub-TLV format | KEY-ID sub-TLV format | |||
Type: 6 | Type: 6 | |||
Length: 4 | Length: 4 | |||
KeyID: The one octed Key ID as per [RFC5925] to uniquely identify the | KeyID: The one octet Key ID as per [RFC5925] to uniquely identify the | |||
Master Key Tuple (MKT). | Master Key Tuple (MKT). | |||
Reserved: MUST be set to zero while sending and ignored on receipt. | Reserved: MUST be set to zero while sending and ignored on receipt. | |||
3.3. KEY-CHAIN-NAME Sub-TLV | 3.3. KEY-CHAIN-NAME Sub-TLV | |||
The KEY-CHAIN-NAME sub-TLV specifies a keychain name that can be used | The KEY-CHAIN-NAME sub-TLV specifies a keychain name that can be used | |||
by the PCC to identify the keychain [RFC8177]. | by the PCC to identify the keychain [RFC8177]. | |||
The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV carried | The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV carried | |||
within the IS-IS Router Information Capability TLV when the | within the IS-IS Router Information Capability TLV when the | |||
capability flag bit of PCE-CAP-FLAGS sub-TLV in IS-IS is set to | capability flag bit in the PCE-CAP-FLAGS sub-TLV in IS-IS is set to | |||
indicate TCP Authentication Option (TCP-AO) support. Similarly, this | indicate TCP Authentication Option (TCP-AO) support. Similarly, this | |||
sub-TLV MAY be present in the PCED TLV carried within OSPF Router | sub-TLV MAY be present in the PCED TLV carried within OSPF Router | |||
Information LSA when the capability flag bit of PCE-CAP-FLAGS sub-TLV | Information LSA when the capability flag bit in the PCE-CAP-FLAGS | |||
in OSPF is set to indicate TCP-AO support. | sub-TLV in OSPF is set to indicate TCP-AO support. | |||
The format of the KEY-CHAIN-NAME sub-TLV is as follows: | The format of the KEY-CHAIN-NAME sub-TLV is as follows: | |||
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 | 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 | | | Type = 7 | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
// Key Chain Name // | // Key Chain Name // | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
KEY-CHAIN-NAME sub-TLV format | KEY-CHAIN-NAME sub-TLV format | |||
Type: 7 | Type: 7 | |||
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 sub-TLV MUST be zero-padded so that the | |||
TLV is 4-octet aligned. | sub-TLV is 4-octet aligned. | |||
4. Update to RFC5088 and RFC5089 | 4. Update to RFC5088 and RFC5089 | |||
Section 4 of [RFC5088] states that no new sub-TLVs will be added to | 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 | the PCED TLV, and no new PCE information will be carried in the | |||
Router Information LSA. This document updates [RFC5088] by allowing | Router Information LSA. This document updates [RFC5088] by allowing | |||
the two new sub-TLVs defined in this document to be carried in the | the two sub-TLVs defined in this document to be carried in the | |||
PCED TLV of the for use in the Router Information LSA. | PCED TLV advertised in the Router Information LSA. | |||
Section 4 of [RFC5089] states that no new sub-TLVs will be added to | 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 | the PCED TLV, and no new PCE information will be carried in the | |||
Router CAPABLITY TLV. This document updates [RFC5089] by allowing | Router CAPABLITY TLV. This document updates [RFC5089] by allowing | |||
the two new sub-TLVs defined in this document to be carried in the | the two sub-TLVs defined in this document to be carried in the | |||
PCED TLV of the for use in the Router CAPABILITY TLV. | PCED TLV advertised in the Router CAPABILITY TLV. | |||
The introduction of the additional sub-TLVs should be viewed as an | The introduction of the additional sub-TLVs should be viewed as an | |||
exception to the [RFC5088][RFC5089] policy justified by the need to | exception to the [RFC5088][RFC5089] policy justified by the requirement | |||
know the new information prior to establishing a PCEP session. The | to discover PCE security support prior to establishing a PCEP session. | |||
restrictions defined in [RFC5089][RFC5089] should still be considered | The restrictions defined in [RFC5089][RFC5089] should still be considered | |||
to be in place. | to be in place. | |||
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 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 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 the PCE security capability via OSPF and IS-IS. | |||
7. Security Considerations | 7. Security Considerations | |||
Security considerations as specified by [RFC5088] and [RFC5089] are | Security considerations as specified by [RFC5088] and [RFC5089] are | |||
applicable to this document. | applicable to this document. | |||
The information related to PCEP security is sensitive and due care | The information related to PCEP security is sensitive and due care | |||
needs to be taken by the operator. This document defines new | needs to be taken by the operator. This document defines new | |||
capability bits that are susceptible to downgrade attack by toggling | capability bits that are susceptible to a downgrade attack by toggling | |||
them. The content of Key ID or Key Chain Name Sub-TLV can be tweaked | 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 | to enable a man-in-the-middle attack. Thus before advertisement of | |||
the PCE security parameters, it MUST be insured that the IGP is | the PCE security parameters, it MUST be insured that the IGP is | |||
protected for authentication and integrity of the PCED TLV if the | protected for authentication and integrity of the PCED TLV if the | |||
mechanism described in this document is used. As stated in [RFC5088] | mechanism described in this document is used. As stated in [RFC5088] | |||
and [RFC5089], the IGP do not provide encryption mechanism to protect | and [RFC5089], the IGPs do not provide encryption mechanisms to protect | |||
the privacy of the PCED TLV, if this information can make the PCEP | the privacy of the PCED TLV, if this information can make the PCEP | |||
session less secure then the operator should take that into | session less secure then the operator should take that into | |||
consideration. | deployment consideration. | |||
8. IANA Considerations | 8. IANA Considerations | |||
8.1. OSPF PCE Capability Flag | 8.1. OSPF PCE Capability Flags | |||
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 | |||
xx TCP-AO Support [This.I.D] | xx TCP-AO Support [This.I.D] | |||
xx PCEP over TLS support [This.I.D] | xx PCEP over TLS support [This.I.D] | |||
The registry is located at: https://www.iana.org/assignments/ospfv2- | The registry is located at: https://www.iana.org/assignments/ospfv2- | |||
parameters/ospfv2-parameters.xml#ospfv2-parameters-14.xml | parameters/ospfv2-parameters.xml#ospfv2-parameters-14.xml | |||
8.2. PCED sub-TLV Type Indicators | 8.2. PCED sub-TLV Type Indicators | |||
The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they | The PCED sub-TLVs were defined in [RFC5088] and [RFC5089], but they | |||
did not create a registry for it. This document requests IANA to | did not create a registry for it. This document requests IANA to | |||
create a new top-level OSPF registry, the "PCED sub-TLV type | create a new top-level OSPF registry, the "PCED sub-TLV type | |||
indicators" registry. This registry should be populated with - | indicators" registry. This registry should be populated with: | |||
Value Description Reference | Value Description Reference | |||
0 Reserved [This.I.D][RFC5088] | 0 Reserved [This.I.D][RFC5088] | |||
1 PCE-ADDRESS [This.I.D][RFC5088] | 1 PCE-ADDRESS [This.I.D][RFC5088] | |||
2 PATH-SCOPE [This.I.D][RFC5088] | 2 PATH-SCOPE [This.I.D][RFC5088] | |||
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 the 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, Les Ginsberg, Aijun Wang, Adrian Farrel for the review | Julien Meuric, Les Ginsberg, Aijun Wang, Adrian Farrel for the review | |||
and comments. | and comments. | |||
The authors would also like to speical thank Michale Wang for his | The authors would also like to speical thank Michale Wang for his | |||
major contributions to the initial version. | major contributions to the initial version. | |||
skipping to change at page 9, line 8 ¶ | skipping to change at page 9, line 8 ¶ | |||
DOI 10.17487/RFC5440, March 2009, | DOI 10.17487/RFC5440, March 2009, | |||
<https://www.rfc-editor.org/info/rfc5440>. | <https://www.rfc-editor.org/info/rfc5440>. | |||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
<https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
Appendix A. No MD5 Capability Support | Appendix A. No MD5 Capability Support | |||
To be compliant with Section 10.2 of RFC5440, this document doesn't | To be compliant with Section 10.2 of RFC5440, this document doesn't | |||
consider to add capability for TCP-MD5. Therefore by default, PCEP | consider adding capability for TCP-MD5. Therefore by default, a PCEP | |||
Speaker in communication supports capability for TCP-MD5 (See section | Speaker supports the capability for TCP-MD5 (See section | |||
10.2, [RFC5440]). A method to advertise TCP-MD5 Capability support | 10.2, [RFC5440]). A method to advertise TCP-MD5 Capability support | |||
using IGP flooding is not required. If the client is looking for | using IGP flooding is not required. If the client is looking for | |||
connecting with PCE server with other Security capability support | a PCE server with other Security capability support | |||
(e.g., TLS support) than TCP-MD5, the client MUST check if flag bit | (e.g., TLS support) than TCP-MD5, the client MUST check if the | |||
in the PCE- CAP-FLAGS sub-TLV for specific capability is set (See | corresponding flag bit in the PCE-CAP-FLAGS sub-TLV is set (See | |||
section 3.1). | section 3.1). | |||
Authors' Addresses | Authors' Addresses | |||
Diego R. Lopez | Diego R. Lopez | |||
Telefonica I+D | Telefonica I+D | |||
Spain | Spain | |||
Email: diego.r.lopez@telefonica.com | Email: diego.r.lopez@telefonica.com | |||
End of changes. 32 change blocks. | ||||
45 lines changed or deleted | 45 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |