< draft-ietf-pce-pceps-14.txt | draft-ietf-pce-pceps-15.txt > | |||
---|---|---|---|---|
PCE Working Group D. Lopez | PCE Working Group D. Lopez | |||
Internet-Draft O. Gonzalez de Dios | Internet-Draft O. Gonzalez de Dios | |||
Updates: 5440 (if approved) Telefonica I+D | Updates: 5440 (if approved) Telefonica I+D | |||
Intended status: Standards Track Q. Wu | Intended status: Standards Track Q. Wu | |||
Expires: November 23, 2017 D. Dhody | Expires: January 29, 2018 D. Dhody | |||
Huawei | Huawei | |||
May 22, 2017 | July 28, 2017 | |||
Secure Transport for PCEP | Secure Transport for PCEP | |||
draft-ietf-pce-pceps-14 | draft-ietf-pce-pceps-15 | |||
Abstract | Abstract | |||
The Path Computation Element Communication Protocol (PCEP) defines | The Path Computation Element Communication Protocol (PCEP) defines | |||
the mechanisms for the communication between a Path Computation | the mechanisms for the communication between a Path Computation | |||
Client (PCC) and a Path Computation Element (PCE), or among PCEs. | Client (PCC) and a Path Computation Element (PCE), or among PCEs. | |||
This document describe the usage of Transport Layer Security (TLS) to | This document describe the usage of Transport Layer Security (TLS) to | |||
enhance PCEP security, hence the PCEPS acronym proposed for it. The | enhance PCEP security, hence the PCEPS acronym proposed for it. The | |||
additional security mechanisms are provided by the transport protocol | additional security mechanisms are provided by the transport protocol | |||
supporting PCEP, and therefore they do not affect the flexibility and | supporting PCEP, and therefore they do not affect the flexibility and | |||
skipping to change at page 1, line 43 ¶ | skipping to change at page 1, line 43 ¶ | |||
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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://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 November 23, 2017. | This Internet-Draft will expire on January 29, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://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 2, line 38 ¶ | skipping to change at page 2, line 38 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 | 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Applying PCEPS . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Applying PCEPS . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3.2. Initiating the TLS Procedures . . . . . . . . . . . . . . 4 | 3.2. Initiating the TLS Procedures . . . . . . . . . . . . . . 4 | |||
3.3. The StartTLS Message . . . . . . . . . . . . . . . . . . 6 | 3.3. The StartTLS Message . . . . . . . . . . . . . . . . . . 6 | |||
3.4. TLS Connection Establishment . . . . . . . . . . . . . . 8 | 3.4. TLS Connection Establishment . . . . . . . . . . . . . . 8 | |||
3.5. Peer Identity . . . . . . . . . . . . . . . . . . . . . . 10 | 3.5. Peer Identity . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.6. Connection Establishment Failure . . . . . . . . . . . . 11 | 3.6. Connection Establishment Failure . . . . . . . . . . . . 11 | |||
4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . 11 | 4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . 12 | |||
4.1. DANE Applicability . . . . . . . . . . . . . . . . . . . 12 | 4.1. DANE Applicability . . . . . . . . . . . . . . . . . . . 12 | |||
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 | 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
6.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . 12 | 6.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . 13 | |||
6.2. New Error-Values . . . . . . . . . . . . . . . . . . . . 13 | 6.2. New Error-Values . . . . . . . . . . . . . . . . . . . . 13 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
8. Manageability Considerations . . . . . . . . . . . . . . . . 14 | 8. Manageability Considerations . . . . . . . . . . . . . . . . 15 | |||
8.1. Control of Function and Policy . . . . . . . . . . . . . 14 | 8.1. Control of Function and Policy . . . . . . . . . . . . . 15 | |||
8.2. Information and Data Models . . . . . . . . . . . . . . . 15 | 8.2. Information and Data Models . . . . . . . . . . . . . . . 16 | |||
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 | 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 16 | |||
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 | 8.4. Verifying Correct Operations . . . . . . . . . . . . . . 16 | |||
8.5. Requirements on Other Protocols . . . . . . . . . . . . . 15 | 8.5. Requirements on Other Protocols . . . . . . . . . . . . . 16 | |||
8.6. Impact on Network Operation . . . . . . . . . . . . . . . 16 | 8.6. Impact on Network Operation . . . . . . . . . . . . . . . 16 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 17 | 10.2. Informative References . . . . . . . . . . . . . . . . . 18 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
1. Introduction | 1. Introduction | |||
The Path Computation Element Communication Protocol (PCEP) [RFC5440] | The Path Computation Element Communication Protocol (PCEP) [RFC5440] | |||
defines the mechanisms for the communication between a Path | defines the mechanisms for the communication between a Path | |||
Computation Client (PCC) and a Path Computation Element (PCE), or | Computation Client (PCC) and a Path Computation Element (PCE), or | |||
between two PCEs. These interactions include requests and replies | between two PCEs. These interactions include requests and replies | |||
that can be critical for a sustainable network operation and adequate | that can be critical for a sustainable network operation and adequate | |||
resource allocation, and therefore appropriate security becomes a key | resource allocation, and therefore appropriate security becomes a key | |||
element in the PCE infrastructure. As the applications of the PCE | element in the PCE infrastructure. As the applications of the PCE | |||
skipping to change at page 3, line 40 ¶ | skipping to change at page 3, line 40 ¶ | |||
Among the possible solutions mentioned in these documents, Transport | Among the possible solutions mentioned in these documents, Transport | |||
Layer Security (TLS) [RFC5246] provides support for peer | Layer Security (TLS) [RFC5246] provides support for peer | |||
authentication, and message encryption and integrity. TLS supports | authentication, and message encryption and integrity. TLS supports | |||
the usage of well-known mechanisms to support key configuration and | the usage of well-known mechanisms to support key configuration and | |||
exchange, and means to perform security checks on the results of PCE | exchange, and means to perform security checks on the results of PCE | |||
discovery procedures via Interior Gateway Protocol (IGP) ([RFC5088] | discovery procedures via Interior Gateway Protocol (IGP) ([RFC5088] | |||
and [RFC5089]). | and [RFC5089]). | |||
This document describes a security container for the transport of | This document describes a security container for the transport of | |||
PCEP messages, and therefore they do not affect the flexibility and | PCEP messages, and therefore it does not affect the flexibility and | |||
extensibility of PCEP. | extensibility of PCEP. | |||
This document describes how to apply TLS in securing PCE | This document describes how to apply TLS in securing PCE | |||
interactions, including initiation of the TLS procedures, the TLS | interactions, including initiation of the TLS procedures, the TLS | |||
handshake mechanisms, the TLS methods for peer authentication, the | handshake mechanisms, the TLS methods for peer authentication, the | |||
applicable TLS ciphersuites for data exchange, and the handling of | applicable TLS ciphersuites for data exchange, and the handling of | |||
errors in the security checks. In the rest of the document we will | errors in the security checks. In the rest of the document we will | |||
refer to this usage of TLS to provide a secure transport for PCEP as | refer to this usage of TLS to provide a secure transport for PCEP as | |||
"PCEPS". | "PCEPS". | |||
Within this document, PCEP communications are described through PCC- | ||||
PCE relationship. The PCE architecture also supports the PCE-PCE | ||||
communication, by having the requesting PCE fill the role of a PCC, | ||||
as usual. Thus, the PCC refers to a PCC or a PCE initiating the PCEP | ||||
session and acting as a client. | ||||
2. Requirements Language | 2. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
3. Applying PCEPS | 3. Applying PCEPS | |||
3.1. Overview | 3.1. Overview | |||
skipping to change at page 5, line 29 ¶ | skipping to change at page 5, line 35 ¶ | |||
StartTLS failure) and Error-value set to 1 (reception of StartTLS | StartTLS failure) and Error-value set to 1 (reception of StartTLS | |||
after any PCEP exchange), and MUST close the TCP connection. A PCEP | after any PCEP exchange), and MUST close the TCP connection. A PCEP | |||
speaker receiving any other message apart from StartTLS, Open, or | speaker receiving any other message apart from StartTLS, Open, or | |||
PCErr as the first message, MUST treat it as an unexpected message | PCErr as the first message, MUST treat it as an unexpected message | |||
and reply with a PCErr message with Error-Type set to [TBA2 by IANA] | and reply with a PCErr message with Error-Type set to [TBA2 by IANA] | |||
(PCEP StartTLS failure) and Error-value set to 2 (reception of any | (PCEP StartTLS failure) and Error-value set to 2 (reception of any | |||
other message apart from StartTLS, Open, or PCErr message), and MUST | other message apart from StartTLS, Open, or PCErr message), and MUST | |||
close the TCP connection. | close the TCP connection. | |||
If the PCEP speaker that does not support PCEPS, receives a StartTLS | If the PCEP speaker that does not support PCEPS, receives a StartTLS | |||
message, it MUST behave according to the existing error mechanism | message, it will behave according to the existing error mechanism | |||
described in section 6.2 of [RFC5440] (in case message is received | described in section 6.2 of [RFC5440] (in case message is received | |||
prior to an Open message) or section 6.9 of [RFC5440] (for the case | prior to an Open message) or section 6.9 of [RFC5440] (for the case | |||
of reception of unknown message). | of reception of unknown message). See Section 5 for more details. | |||
After the exchange of startTLS messages, if a PCEP speaker cannot | After the exchange of StartTLS messages, if a PCEP speaker cannot | |||
establish a TLS connection for some reason (e.g. the required | establish a TLS connection for some reason (e.g. the required | |||
mechanisms for certificate revocation checking are not available), it | mechanisms for certificate revocation checking are not available), it | |||
MUST return a PCErr message (in clear) with Error-Type set to [TBA2 | MUST return a PCErr message (in clear) with Error-Type set to [TBA2 | |||
by IANA] (PCEP StartTLS failure) and Error-value set to: | by IANA] (PCEP StartTLS failure) and Error-value set to: | |||
o 3 (not without TLS) if it is not willing to exchange PCEP messages | o 3 (not without TLS) if it is not willing to exchange PCEP messages | |||
without the solicited TLS connection, and it MUST close the TCP | without the solicited TLS connection, and it MUST close the TCP | |||
session. | session. | |||
o 4 (ok without TLS) if it is willing to exchange PCEP messages | o 4 (ok without TLS) if it is willing to exchange PCEP messages | |||
without the solicited TLS connection, and it MUST close the TCP | without the solicited TLS connection, and it MUST close the TCP | |||
session. The peer MAY choose to re-establish the PCEP session | session. The receiver MAY choose to re-establish the PCEP session | |||
without TLS next. | without TLS next. | |||
If the PCEP speaker supports PCEPS and can establish a TLS connection | If the PCEP speaker supports PCEPS and can establish a TLS connection | |||
it MUST start the TLS connection establishment steps described in | it MUST start the TLS connection establishment steps described in | |||
Section 3.4 before the PCEP initialization procedure (section 4.2.1 | Section 3.4 before the PCEP initialization procedure (section 4.2.1 | |||
of [RFC5440]). | of [RFC5440]). | |||
A PCEP speaker that does not support PCEPS or has learned the peer | A PCEP speaker that does not support PCEPS or has learned the peer | |||
willingness to reestablish session without TLS, can send the Open | willingness to reestablish session without TLS, can send the Open | |||
message directly, as per [RFC5440]. | message directly, as per [RFC5440]. | |||
skipping to change at page 7, line 4 ¶ | skipping to change at page 7, line 13 ¶ | |||
The format of a StartTLS message is as follows: | The format of a StartTLS message is as follows: | |||
<StartTLS Message>::= <Common Header> | <StartTLS Message>::= <Common Header> | |||
The StartTLS message MUST contain only the PCEP common header with | The StartTLS message MUST contain only the PCEP common header with | |||
Message-Type field set to [TBA1 by IANA]. | Message-Type field set to [TBA1 by IANA]. | |||
Once the TCP connection has been successfully established and the | Once the TCP connection has been successfully established and the | |||
StartTLS message sent, the sender MUST start a timer called | StartTLS message sent, the sender MUST start a timer called | |||
StartTLSWait timer, after the expiration of which, if no StartTLS | StartTLSWait timer, after the expiration of which, if no StartTLS | |||
message has been received, it MUST send a PCErr message and releases | message has been received (and in case of failure, a PCErr or Open | |||
the TCP connection with Error-Type set to [TBA2 by IANA] and Error- | message is not received), it MUST send a PCErr message with Error- | |||
value set to 5 (no StartTLS message received before the expiration of | Type set to [TBA2 by IANA] and Error-value set to 5 (no StartTLS (nor | |||
the StartTLSWait timer). A RECOMMENDED value for StartTLSWait timer | PCErr/Open) message received before the expiration of the | |||
is 60 seconds. | StartTLSWait timer) and it MUST release the TCP connection . A | |||
RECOMMENDED value for StartTLSWait timer is 60 seconds. | ||||
+-+-+ +-+-+ | +-+-+ +-+-+ | |||
|PCC| |PCE| | |PCC| |PCE| | |||
+-+-+ +-+-+ | +-+-+ +-+-+ | |||
| | | | | | |||
| StartTLS | | | StartTLS | | |||
| msg | | | msg | | |||
|------- | | |------- | | |||
| \ StartTLS | | | \ StartTLS | | |||
| \ msg | | | \ msg | | |||
skipping to change at page 8, line 31 ¶ | skipping to change at page 8, line 45 ¶ | |||
| PCErr | (non-Open message | | PCErr | (non-Open message | |||
| | received) | | | received) | |||
Figure 3: One PCEP Speaker does not support PCEPS | Figure 3: One PCEP Speaker does not support PCEPS | |||
3.4. TLS Connection Establishment | 3.4. TLS Connection Establishment | |||
Once the establishment of TLS has been agreed by the PCEP peers, the | Once the establishment of TLS has been agreed by the PCEP peers, the | |||
connection establishment SHALL follow the following steps: | connection establishment SHALL follow the following steps: | |||
1. Immediately negotiate TLS sessions according to [RFC5246]. The | 1. Immediately negotiate a TLS session according to [RFC5246]. The | |||
following restrictions apply: | following restrictions apply: | |||
* Support for TLS v1.2 [RFC5246] or later is REQUIRED. | * Support for TLS v1.2 [RFC5246] or later is REQUIRED. | |||
* Support for certificate-based mutual authentication is | * Support for certificate-based mutual authentication is | |||
REQUIRED. | REQUIRED. | |||
* Negotiation of mutual authentication is REQUIRED. | * Negotiation of mutual authentication is REQUIRED. | |||
* Negotiation of a ciphersuite providing for integrity | * Negotiation of a ciphersuite providing for integrity | |||
skipping to change at page 11, line 4 ¶ | skipping to change at page 11, line 18 ¶ | |||
o Peer's fully qualified domain name (FQDN) | o Peer's fully qualified domain name (FQDN) | |||
o Certificate Fingerprint | o Certificate Fingerprint | |||
o Issuer | o Issuer | |||
o Subject | o Subject | |||
o All X509v3 Extended Key Usage | o All X509v3 Extended Key Usage | |||
o All X509v3 Subject Alternative Name | o All X509v3 Subject Alternative Name | |||
o All X509v3 Certificate Policies | o All X509v3 Certificate Policies | |||
Note that the remote IP address used for the TCP session | ||||
establishment is also exposed. | ||||
[I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Entity | [I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Entity | |||
Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that MAY be | Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that MAY be | |||
included in the OPEN Object. It contains a unique identifier for the | included in the OPEN Object. It contains a unique identifier for the | |||
node that does not change during the lifetime of the PCEP speaker. | node that does not change during the lifetime of the PCEP speaker. | |||
An implementation would thus expose the speaker entity identifier as | An implementation would thus expose the speaker entity identifier as | |||
part of the X509v3 certificate, so that an implementation could use | part of the X509v3 certificate, so that an implementation could use | |||
this identifier for the peer identification trust model. | this identifier for the peer identification trust model. | |||
In addition, a PCC MAY apply the procedures described in [RFC6698] | In addition, a PCC MAY apply the procedures described in [RFC6698] | |||
DNS-Based Authentication of Named Entities (DANE) to verify its peer | DNS-Based Authentication of Named Entities (DANE) to verify its peer | |||
skipping to change at page 11, line 32 ¶ | skipping to change at page 12, line 7 ¶ | |||
In case the initial TLS negotiation or the peer identity check fails, | In case the initial TLS negotiation or the peer identity check fails, | |||
according to the procedures listed in this document, the peer MUST | according to the procedures listed in this document, the peer MUST | |||
first send a PCErr message as per Section 3.2 and then terminate the | first send a PCErr message as per Section 3.2 and then terminate the | |||
session. It SHOULD follow the procedure listed in [RFC5440] to retry | session. It SHOULD follow the procedure listed in [RFC5440] to retry | |||
session setup along with an exponential back-off session | session setup along with an exponential back-off session | |||
establishment retry procedure. | establishment retry procedure. | |||
4. Discovery Mechanisms | 4. Discovery Mechanisms | |||
A PCE can advertise its capability to support PCEPS using the IGP | This document does not specify any discovery mechanism for support of | |||
advertisement and discovery mechanism. The PCE-CAP-FLAGS sub-TLV is | PCEPS. Other documents, [I-D.wu-pce-discovery-pceps-support] and | |||
an optional sub-TLV used to advertise PCE capabilities. It MAY be | [I-D.wu-pce-dns-pce-discovery] have made proposals: | |||
present within the PCE Discovery (PCED) sub-TLV carried by OSPF or | ||||
IS-IS. [RFC5088] and [RFC5089] provide the description and | ||||
processing rules for this sub-TLV when carried within OSPF and IS-IS, | ||||
respectively. PCE capability bits are defined in [RFC5088]. A new | ||||
capability flag bit for the PCE-CAP-FLAGS sub-TLV that can be | ||||
announced as attribute to distribute PCEP security support | ||||
information is proposed in [I-D.wu-pce-discovery-pceps-support] | ||||
When DNS is used by a PCC (or a PCE acting as a client, for the rest | ||||
of the section, PCC refers to both) willing to use PCEPS to locate an | ||||
appropriate PCE [I-D.wu-pce-dns-pce-discovery], the PCC as an | ||||
initiating entity, chooses at least one of the returned FQDNs to | ||||
resolve, which it does by performing DNS "A" or "AAAA" lookups on the | ||||
FDQN. This will eventually result in an IPv4 or IPv6 address. The | ||||
PCC SHALL use the IP address(es) from the successfully resolved FDQN | ||||
(with the corresponding port number returned by the DNS Service | ||||
Record (SRV) lookup) as the connection address(es) for the receiving | ||||
entity. | ||||
If the PCC fails to connect using an IP address but the "A" or "AAAA" | o A PCE can advertise its capability to support PCEPS using the | |||
lookups returned more than one IP address, then the PCC SHOULD use | IGP's advertisement mechanism of the PCE discovery information. | |||
the next resolved IP address for that FDQN as the connection address. | The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to advertise | |||
If the PCC fails to connect using all resolved IP addresses for a | PCE capabilities. It is present within the PCE Discovery (PCED) | |||
given FDQN, then it SHOULD repeat the process of resolution and | sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] provide | |||
connection for the next FQDN returned by the SRV lookup based on the | the description and processing rules for this sub-TLV when carried | |||
priority and weight. | within OSPF and IS-IS, respectively. PCE capability bits are | |||
defined in [RFC5088]. A new capability flag bit for the PCE-CAP- | ||||
FLAGS sub-TLV that can be announced as an attribute to distribute | ||||
PCEP security support information is proposed in | ||||
[I-D.wu-pce-discovery-pceps-support]. | ||||
If the PCC receives a response to its SRV query but it is not able to | o A PCE can advertise its capability to support PCEPS using the DNS | |||
establish a PCEPS connection using the data received in the response, | [I-D.wu-pce-dns-pce-discovery] by identifying the support of TLS. | |||
as initiating entity it MAY fall back to lookup a PCE that uses TCP | ||||
as transport. | ||||
4.1. DANE Applicability | 4.1. DANE Applicability | |||
DANE [RFC6698] defines a secure method to associate the certificate | DANE [RFC6698] defines a secure method to associate the certificate | |||
that is obtained from a TLS server with a domain name using DNS, | that is obtained from a TLS server with a domain name using DNS, | |||
i.e., using the TLSA DNS resource record (RR) to associate a TLS | i.e., using the TLSA DNS resource record (RR) to associate a TLS | |||
server certificate or public key with the domain name where the | server certificate or public key with the domain name where the | |||
record is found, thus forming a "TLSA certificate association". The | record is found, thus forming a "TLSA certificate association". The | |||
DNS information needs to be protected by DNS Security (DNSSEC). A | DNS information needs to be protected by DNS Security (DNSSEC). A | |||
PCC willing to apply DANE to verify server identity MUST conform to | PCC willing to apply DANE to verify server identity MUST conform to | |||
skipping to change at page 12, line 43 ¶ | skipping to change at page 12, line 49 ¶ | |||
5. Backward Compatibility | 5. Backward Compatibility | |||
The procedures described in this document define a security container | The procedures described in this document define a security container | |||
for the transport of PCEP requests and replies carried by a TLS | for the transport of PCEP requests and replies carried by a TLS | |||
connection initiated by means of a specific extended message | connection initiated by means of a specific extended message | |||
(StartTLS) that does not interfere with PCEP speaker implementations | (StartTLS) that does not interfere with PCEP speaker implementations | |||
not supporting it. | not supporting it. | |||
If a PCEP implementation that does not support PCEPS receives a | If a PCEP implementation that does not support PCEPS receives a | |||
StartTLS message, it would behave according to the existing error | StartTLS message, it would behave according to the existing error | |||
mechanism of [RFC5440]. | mechanism of [RFC5440]. On receiving the error, based on the local | |||
policy, a peer could try to establishing PCEP session without TLS as | ||||
per the procedures defined in [RFC5440]. For successful TLS | ||||
operations with PCEP, both PCEP peers in the network would need to be | ||||
upgraded to support this document. | ||||
An existing PCEP session cannot be upgraded to PCEPS, the session | ||||
needs to be terminated and reestablished as per the procedure | ||||
described in this document. During the incremental upgrade, the PCEP | ||||
speaker SHOULD allow session establishment with and without TLS. | ||||
Once both PCEP speakers are upgraded to support PCEPS, the PCEP | ||||
session is re-established with TLS, otherwise PCEP session without | ||||
TLS is setup. A redundant PCE MAY also be used during the | ||||
incremental deployment to take over the PCE undergoing upgrade. Once | ||||
the upgrade is completed, support for unsecured version SHOULD be | ||||
removed. | ||||
6. IANA Considerations | 6. IANA Considerations | |||
6.1. New PCEP Message | 6.1. New PCEP Message | |||
IANA is requested to allocate new message types within the "PCEP | IANA is requested to allocate new message types within the "PCEP | |||
Messages" sub-registry of the PCEP Numbers registry, as follows: | Messages" sub-registry of the PCEP Numbers registry, as follows: | |||
Value Description Reference | Value Description Reference | |||
TBA1 The Start TLS Message (StartTLS) This document | TBA1 The Start TLS Message (StartTLS) This document | |||
6.2. New Error-Values | 6.2. New Error-Values | |||
IANA is requested to allocate new Error Types and Error Values within | IANA is requested to allocate new Error Types and Error Values within | |||
the " PCEP-ERROR Object Error Types and Values" sub-registry of the | the " PCEP-ERROR Object Error Types and Values" sub-registry of the | |||
PCEP Numbers registry, as follows: | PCEP Numbers registry, as follows: | |||
Error- | Error- | |||
Type Meaning Error-value Reference | Type Meaning Error-value Reference | |||
TBA2 StartTLS Failure 0:Unassigned This document | TBA2 PCEP StartTLS 0:Unassigned This document | |||
1:Reception of This document | failure 1:Reception of This document | |||
StartTLS after | StartTLS after | |||
any PCEP exchange | any PCEP exchange | |||
2:Reception of This document | 2:Reception of This document | |||
any other message | any other message | |||
apart from StartTLS, | apart from StartTLS, | |||
Open or PCErr | Open or PCErr | |||
3:Failure, connection This document | 3:Failure, connection This document | |||
without TLS not | without TLS not | |||
possible | possible | |||
4:Failure, connection This document | 4:Failure, connection This document | |||
without TLS possible | without TLS possible | |||
5:No StartTLS message This document | 5:No StartTLS message This document | |||
(nor PCErr/Open) | ||||
before StartTLSWait | before StartTLSWait | |||
timer expiry | timer expiry | |||
7. Security Considerations | 7. Security Considerations | |||
While the application of TLS satisfies the requirement on privacy as | While the application of TLS satisfies the requirement on privacy as | |||
well as fine-grained, policy-based peer authentication, there are | well as fine-grained, policy-based peer authentication, there are | |||
security threats that it cannot address. It may be advisable to | security threats that it cannot address. It may be advisable to | |||
apply additional protection measures, in particular in what relates | apply additional protection measures, in particular in what relates | |||
to attacks specifically addressed to forging the TCP connection | to attacks specifically addressed to forging the TCP connection | |||
skipping to change at page 14, line 41 ¶ | skipping to change at page 15, line 32 ¶ | |||
A PCE or PCC implementation MUST allow configuring the PCEP security | A PCE or PCC implementation MUST allow configuring the PCEP security | |||
via TLS capabilities as described in this document. | via TLS capabilities as described in this document. | |||
A PCE or PCC implementation supporting PCEP security via TLS MUST | A PCE or PCC implementation supporting PCEP security via TLS MUST | |||
support general TLS configuration as per [RFC5246]. At least the | support general TLS configuration as per [RFC5246]. At least the | |||
configuration of one of the trust models and its corresponding | configuration of one of the trust models and its corresponding | |||
parameters, as described in Section 3.4 and Section 3.5, MUST be | parameters, as described in Section 3.4 and Section 3.5, MUST be | |||
supported by the implementation. | supported by the implementation. | |||
A PCEP implementation SHOULD allow configuring the following PCEP | A PCEP implementation SHOULD allow configuring the StartTLSWait timer | |||
security parameters: | value. | |||
o StartTLSWait timer value | ||||
PCEPS implementations MAY provide an option to allow the operator to | PCEPS implementations MAY provide an option to allow the operator to | |||
manually override strict TLS configuration and allow unsecure | manually override strict TLS configuration and allow unsecure | |||
connections. Execution of this override SHOULD trigger a warning | connections. Execution of this override SHOULD trigger a warning | |||
about the security implications of permitting unsecure connections. | about the security implications of permitting unsecure connections. | |||
Further, the operator needs to develop suitable security policies | Further, the operator needs to develop suitable security policies | |||
around PCEP within his network. Further the PCEP peers SHOULD | around PCEP within his network. Further the PCEP peers SHOULD | |||
provide ways for the operator to complete the following tasks: | provide ways for the operator to complete the following tasks in | |||
regards to a PCEP session: | ||||
o Determine if a PCEP session is protected via PCEPS. | o Determine if a session is protected via PCEPS. | |||
o Determine the version of TLS, the mechanism used for | o Determine the version of TLS, the mechanism used for | |||
authentication, and the ciphersuite in use. | authentication, and the ciphersuite in use. | |||
o Determine if the certificate could not be verified, and the reason | o Determine if the certificate could not be verified, and the reason | |||
for this circumstance. | for this circumstance. | |||
o Inspect the certificate offered by the PCEP peer. | o Inspect the certificate offered by the PCEP peer. | |||
o Be warned if StartTLS procedure fails for the PCEP peers, that are | o Be warned if StartTLS procedure fails for the PCEP peers, that are | |||
known to support PCEPS, via configurations or capability | known to support PCEPS, via configurations or capability | |||
advertisements. | advertisements. | |||
8.2. Information and Data Models | 8.2. Information and Data Models | |||
The PCEP MIB module SHOULD be extended to include PCEPS capabilities, | The PCEP MIB module is defined in [RFC7420]. The MIB module could be | |||
information, and status. | extended to include the ability to view the PCEPS capability, TLS | |||
related information as well as TLS status for each PCEP peer. | ||||
An implementation SHOULD allow the operator to configure the PCEPS | An implementation SHOULD also allow the operator to configure the | |||
capability and various TLS related parameters, as well as allow to | PCEPS capability and various TLS related parameters in addition to | |||
view the current TLS status for a PCEP session. To serve this | ability to view the current TLS status for a PCEP session. To serve | |||
purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] can be | this purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] is | |||
extended to include TLS related configuration and state. | extended to include TLS related configuration and state information. | |||
8.3. Liveness Detection and Monitoring | 8.3. Liveness Detection and Monitoring | |||
Mechanisms defined in this document do not imply any new liveness | Mechanisms defined in this document do not imply any new liveness | |||
detection and monitoring requirements in addition to those already | detection and monitoring requirements in addition to those already | |||
listed in [RFC5440] and [RFC5246]. | listed in [RFC5440] and [RFC5246]. | |||
8.4. Verify Correct Operations | 8.4. Verifying Correct Operations | |||
A PCEPS implementation SHOULD log error events and provide PCEPS | A PCEPS implementation SHOULD log error events and provide PCEPS | |||
failure statistics with reasons. | failure statistics with reasons. | |||
8.5. Requirements on Other Protocols | 8.5. Requirements on Other Protocols | |||
Mechanisms defined in this document do not imply any new requirements | Mechanisms defined in this document do not imply any new requirements | |||
on other protocols. | on other protocols. Note that, Section 4 list possible discovery | |||
mechanism for support of PCEPS. | ||||
8.6. Impact on Network Operation | 8.6. Impact on Network Operation | |||
Mechanisms defined in this document do not have any significant | Mechanisms defined in this document do not have any significant | |||
impact on network operations in addition to those already listed in | impact on network operations in addition to those already listed in | |||
[RFC5440], and the policy and management implications discussed | [RFC5440], and the policy and management implications discussed | |||
above. | above. | |||
9. Acknowledgements | 9. Acknowledgements | |||
This specification relies on the analysis and profiling of TLS | This specification relies on the analysis and profiling of TLS | |||
included in [RFC6614] and the procedures described for the STARTTLS | included in [RFC6614] and the procedures described for the STARTTLS | |||
command in [RFC4513]. | command in [RFC4513]. | |||
We would like to thank Joe Touch for his suggestions and support | We would like to thank Joe Touch for his suggestions and support | |||
regarding the TLS start mechanisms. | regarding the TLS start mechanisms. | |||
Thanks to Dan King for reminding the authors about manageability | Thanks to Daniel King for reminding the authors about manageability | |||
considerations. | considerations. | |||
Thanks to Cyril Margaria for shepherding this document. | Thanks to Cyril Margaria for shepherding this document. | |||
Thanks to Dan Frost for the RTGDIR review. | Thanks to David Mandelberg for early SECDIR review comments as well | |||
as re-reviewing during IETF last call. | ||||
Thanks to Dan Frost for the RTGDIR review and comments. | ||||
Thanks to Dale Worley for the Gen-ART review and comments. | ||||
Also thanks to Tianran Zhou for OPSDIR review. | ||||
Thanks to Deborah Brungard for being the responsible AD and guiding | ||||
the authors as needed. | ||||
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, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
skipping to change at page 18, line 20 ¶ | skipping to change at page 19, line 20 ¶ | |||
"Transport Layer Security (TLS) Encryption for RADIUS", | "Transport Layer Security (TLS) Encryption for RADIUS", | |||
RFC 6614, DOI 10.17487/RFC6614, May 2012, | RFC 6614, DOI 10.17487/RFC6614, May 2012, | |||
<http://www.rfc-editor.org/info/rfc6614>. | <http://www.rfc-editor.org/info/rfc6614>. | |||
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of | [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of | |||
BGP, LDP, PCEP, and MSDP Issues According to the Keying | BGP, LDP, PCEP, and MSDP Issues According to the Keying | |||
and Authentication for Routing Protocols (KARP) Design | and Authentication for Routing Protocols (KARP) Design | |||
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, | Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, | |||
<http://www.rfc-editor.org/info/rfc6952>. | <http://www.rfc-editor.org/info/rfc6952>. | |||
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. | ||||
Hardwick, "Path Computation Element Communication Protocol | ||||
(PCEP) Management Information Base (MIB) Module", | ||||
RFC 7420, DOI 10.17487/RFC7420, December 2014, | ||||
<http://www.rfc-editor.org/info/rfc7420>. | ||||
[I-D.ietf-pce-stateful-sync-optimizations] | [I-D.ietf-pce-stateful-sync-optimizations] | |||
Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., | Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., | |||
and D. Dhody, "Optimizations of Label Switched Path State | and D. Dhody, "Optimizations of Label Switched Path State | |||
Synchronization Procedures for a Stateful PCE", draft- | Synchronization Procedures for a Stateful PCE", draft- | |||
ietf-pce-stateful-sync-optimizations-10 (work in | ietf-pce-stateful-sync-optimizations-10 (work in | |||
progress), March 2017. | progress), March 2017. | |||
[I-D.ietf-pce-pcep-yang] | [I-D.ietf-pce-pcep-yang] | |||
Dhody, D., Hardwick, J., Beeram, V., and j. | Dhody, D., Hardwick, J., Beeram, V., and j. | |||
jefftant@gmail.com, "A YANG Data Model for Path | jefftant@gmail.com, "A YANG Data Model for Path | |||
Computation Element Communications Protocol (PCEP)", | Computation Element Communications Protocol (PCEP)", | |||
draft-ietf-pce-pcep-yang-02 (work in progress), March | draft-ietf-pce-pcep-yang-05 (work in progress), June 2017. | |||
2017. | ||||
[I-D.wu-pce-dns-pce-discovery] | [I-D.wu-pce-dns-pce-discovery] | |||
Wu, Q., Dhody, D., King, D., Lopez, D., and J. Tantsura, | Wu, Q., Dhody, D., King, D., Lopez, D., and J. Tantsura, | |||
"Path Computation Element (PCE) Discovery using Domain | "Path Computation Element (PCE) Discovery using Domain | |||
Name System(DNS)", draft-wu-pce-dns-pce-discovery-10 (work | Name System(DNS)", draft-wu-pce-dns-pce-discovery-10 (work | |||
in progress), March 2017. | in progress), March 2017. | |||
[I-D.wu-pce-discovery-pceps-support] | [I-D.wu-pce-discovery-pceps-support] | |||
Lopez, D., Wu, Q., Dhody, D., and D. King, "IGP extension | Lopez, D., Wu, Q., Dhody, D., and D. King, "IGP extension | |||
for PCEP security capability support in the PCE | for PCEP security capability support in the PCE | |||
End of changes. 35 change blocks. | ||||
83 lines changed or deleted | 110 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |