< 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/