PCE Working Group D. Lopez
Internet-Draft O. Gonzalez de Dios
Intended status: Experimental Telefonica I+D
Expires: September 9, 2016 Q. Wu
D. Dhody
Huawei
March 8, 2016
Secure Transport for PCEP
draft-ietf-pce-pceps-09
Abstract
The Path Computation Element Communication Protocol (PCEP) defines
the mechanisms for the communication between a Path Computation
Client (PCC) and a Path Computation Element (PCE), or among PCEs.
This document describe the usage of Transport Layer Security (TLS) to
enhance PCEP security, hence the PCEPS acronym proposed for it. The
additional security mechanisms are provided by the transport protocol
supporting PCEP, and therefore they do not affect the flexibility and
extensibility of PCEP.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Lopez, et al. Expires September 9, 2016 [Page 1]
Internet-Draft Secure Transport for PCEP March 2016
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Applying PCEPS . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Initiating the TLS Procedures . . . . . . . . . . . . . . 4
3.3. The StartTLS Message . . . . . . . . . . . . . . . . . . . 6
3.4. TLS Connection Establishment . . . . . . . . . . . . . . . 8
3.5. Peer Identity . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Connection Establishment Failure . . . . . . . . . . . . . 11
4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . . 11
4.1. DANE Applicability . . . . . . . . . . . . . . . . . . . . 12
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 12
6.2. New Error-Values . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Manageability Considerations . . . . . . . . . . . . . . . . . 14
8.1. Control of Function and Policy . . . . . . . . . . . . . . 14
8.2. Information and Data Models . . . . . . . . . . . . . . . 14
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 14
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15
8.5. Requirements on Other Protocols . . . . . . . . . . . . . 15
8.6. Impact on Network Operations . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Lopez, et al. Expires September 9, 2016 [Page 2]
Internet-Draft Secure Transport for PCEP March 2016
1. Introduction
PCEP [RFC5440] defines the mechanisms for the communication between a
Path Computation Client (PCC) and a Path Computation Element (PCE),
or between two PCEs. These interactions include requests and replies
that can be critical for a sustainable network operation and adequate
resource allocation, and therefore appropriate security becomes a key
element in the PCE infrastructure. As the applications of the PCE
framework evolves, and more complex service patterns emerge, the
definition of a secure mode of operation becomes more relevant.
[RFC5440] analyzes in its section on security considerations the
potential threats to PCEP and their consequences, and discusses
several mechanisms for protecting PCEP against security attacks,
without making a specific recommendation on a particular one or
defining their application in depth. Moreover, [RFC6952] remarks the
importance of ensuring PCEP communication privacy, especially when
PCEP communication endpoints do not reside in the same Autonomous
System (AS), as the interception of PCEP messages could leak
sensitive information related to computed paths and resources.
Among the possible solutions mentioned in these documents, Transport
Layer Security (TLS) [RFC5246] provides support for peer
authentication, and message encryption and integrity. TLS supports
the usage of well-know mechanisms to support key configuration and
exchange, and means to perform security checks on the results of PCE
discovery procedures via Interior Gateway Protocol (IGP) ([RFC5088]
and [RFC5089]).
This document describes a security container for the transport of
PCEP requests and replies, and therefore they do not affect the
flexibility and extensibility of PCEP.
This document describes how to apply TLS in securing PCE
interactions, including initiation of the TLS procedures, the TLS
handshake mechanisms, the TLS methods for peer authentication, the
applicable TLS ciphersuites for data exchange, and the handling of
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
"PCEPS".
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Lopez, et al. Expires September 9, 2016 [Page 3]
Internet-Draft Secure Transport for PCEP March 2016
3. Applying PCEPS
3.1. Overview
The steps involved in the PCEPS establishment consists of following
successive steps:
1. Establishment of a TCP connection.
2. Initiating the TLS procedures by the StartTLS message from PCE to
PCC and from PCC to PCE.
3. Establishment of TLS connection.
4. Start exchanging PCEP messages as per [RFC5440].
It should be noted that this procedure updates what is defined in
section 6.7 of [RFC5440] regarding the processing of messages prior
to the Open message. The details of processing including backward
compatibility are discussed in the following sections.
3.2. Initiating the TLS Procedures
Since PCEP can operate either with or without TLS, it is necessary
for the PCEP speaker to indicate whether it wants to set up a TLS
connection or not. For this purpose, this document proposes a new
PCEP message called StartTLS. This message MUST be issued by the
party willing to use TLS, prior to any other PCEP message. The PCEP
speaker MAY discover that the PCEP peer supports PCEPS or can be
preconfigured to use PCEPS for a given peer (see Section 4 for more
details). Thus the PCEP session is secured via TLS from the start
before exchange of any other PCEP message including the Open message.
Securing via TLS of an existing PCEP session is not permitted, the
session must be closed and re-established with TLS as per the
procedure described in this document.
The StartTLS message is a PCEP message sent by a PCC to a PCE and by
a PCE to a PCC in order to initiate the TLS procedure for PCEP. The
Message-Type field of the PCEP common header for the StartTLS message
is set to [TBA1 by IANA].
Once the TCP connection has been successfully established, the first
message sent by the PCC to the PCE and by the PCE to the PCC MUST be
a StartTLS message for the PCEPS. Note this is a significant change
from [RFC5440] where the first PCEP message is Open.
A PCEP speaker receiving a StartTLS message after any other PCEP
exchange has taken place (by receiving or sending any other messages
Lopez, et al. Expires September 9, 2016 [Page 4]
Internet-Draft Secure Transport for PCEP March 2016
from either side) MUST treat it as an unexpected message and reply
with a PCErr message with Error-Type set to [TBA2 by IANA] (PCEP
StartTLS failure) and Error-value set to 1 (reception of StartTLS
after any PCEP exchange), and MUST close the TCP connection. A PCEP
speaker receiving any other message apart from StartTLS or PCErr MUST
treat it as an unexpected message 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 non-StartTLS or non-PCErr message), and
MUST close the TCP connection.
If the PCEP speaker that does not support PCEPS, receives a StartTLS
message, it MUST behave according to the existing error mechanism
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
of reception of unknown message).
If the PCEP speaker supports PCEPS but cannot establish a TLS
connection for some reason (e.g. the required mechanisms for
certificate revocation checking are not available) it MUST return a
PCErr message with Error-Type set to [TBA2 by IANA] (PCEP StartTLS
failure) and Error-value set to:
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
session.
o 4 (ok without TLS) if it is willing to exchange PCEP messages
without the solicited TLS connection, and it MUST close the TCP
session. The peer MAY choose to re-establish the PCEP session
without TLS next.
If the PCEP speaker supports PCEPS and can establish a TLS connection
it MUST start the TLS connection establishment steps described in
Section 3.4 before the PCEP initialization procedure (section 4.2.1
of [RFC5440]).
Given the asymmetric nature of TLS for connection establishment it is
relevant to identify the roles of each of the PCEP peers in it. The
PCC SHALL act as TLS client, and the PCE SHALL act as TLS server,
according to [RFC5246].
These procedures minimize the impact of PCEPS support in PCEP
implementations without requiring additional dedicated ports for
running PCEP with TLS.
Lopez, et al. Expires September 9, 2016 [Page 5]
Internet-Draft Secure Transport for PCEP March 2016
3.3. The StartTLS Message
The StartTLS message is used to initiate the TLS procedure for a
PCEPS session between the PCEP peers. A PCEP speaker sends the
StartTLS message to request negotiation and establishment of TLS
connection for PCEP. On receiving a StartTLS message from the PCEP
peer (i.e. when PCEP speaker has sent and received StartTLS message)
it is ready to start TLS negotiation and establishment and move to
steps described in Section 3.4.
The collision resolution procedures described in [RFC5440] for the
exchange of Open messages MUST be applied by the PCEP peers during
the exchange of StartTLS messages.
The format of a StartTLS message is as follows:
<StartTLS Message>::= <Common Header>
The StartTLS message MUST contain only the PCEP common header with
Message-Type field set to [TBA1 by IANA].
Once the TCP connection has been successfully established and the
StartTLS message sent, the sender MUST start a timer called
StartTLSWait timer, after the expiration of which, if no StartTLS
message has been received, it sends a PCErr message and releases the
TCP connection with Error-Type set to [TBA2 by IANA] and Error-value
set to 5 (no StartTLS message received before the expiration of the
StartTLSWait timer). A RECOMMENDED value for StartTLSWait timer is
60 seconds.
Lopez, et al. Expires September 9, 2016 [Page 6]
Internet-Draft Secure Transport for PCEP March 2016
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| StartTLS |
| msg |
|------- |
| \ StartTLS |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
|:::::::::TLS:::::::::|
|:::::Establishment:::|
| |
| |
|:::::::PCEP::::::::::|
| |
Figure 1: Both PCEP Speaker supports PCEPS
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| | Does not send
| StartTLS | StartTLS as
|-------------------->| cannot establish
| | TLS
| |
|<--------------------| Send Error
| PCErr | Error-Value 3/4
| |
Figure 2: Both PCEP Speaker supports PCEPS, But cannot establish TLS
Lopez, et al. Expires September 9, 2016 [Page 7]
Internet-Draft Secure Transport for PCEP March 2016
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| | Does not support
| StartTLS | PCEPS and thus
| msg | sends Open
|------- |
| \ Open |
| \ msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ |
| |
|<--------------------| Send Error
| PCErr | (non-Open message
| | received)
Figure 3: One PCEP Speaker does not support PCEPS
3.4. TLS Connection Establishment
Once the establishment of TLS has been agreed by the PCEP peers, the
connection establishment SHALL follow the following steps:
1. Immediately negotiate TLS sessions according to [RFC5246]. The
following restrictions apply:
* Support for TLS v1.2 [RFC5246] or later is REQUIRED.
* Support for certificate-based mutual authentication is
REQUIRED.
* Negotiation of mutual authentication is REQUIRED.
* Negotiation of a ciphersuite providing for integrity
protection is REQUIRED.
* Negotiation of a ciphersuite providing for confidentiality is
RECOMMENDED.
* Support for and negotiation of compression is OPTIONAL.
Lopez, et al. Expires September 9, 2016 [Page 8]
Internet-Draft Secure Transport for PCEP March 2016
* PCEPS implementations MUST, at a minimum, support negotiation
of the TLS_RSA_WITH_AES_128_GCM_SHA256, and SHOULD support
TLS_RSA_WITH_AES_256_GCM_SHA384 as well [RFC5288]. In
addition, PCEPS implementations MUST support negotiation of
the mandatory-to-implement ciphersuites required by the
versions of TLS that they support.
2. Peer authentication can be performed in any of the following two
REQUIRED operation models:
* TLS with X.509 certificates using Public-Key Infrastructure
Exchange (PKIX) trust models:
+ Implementations MUST allow the configuration of a list of
trusted Certification Authorities (CAs) for incoming
connections.
+ Certificate validation MUST include the verification rules
as per [RFC5280].
+ PCEPS implementations SHOULD incorporate revocation methods
(CRL downloading, OCSP...) according to the trusted CA
policies.
+ Implementations SHOULD indicate their trusted CAs. For TLS
1.2, this is done using [RFC5246], Section 7.4.4,
"certificate_authorities" (server side) and [RFC6066],
Section 6 "Trusted CA Indication" (client side).
+ Peer validation always SHOULD include a check on whether
the locally configured expected DNS name or IP address of
the peer that is contacted matches its presented
certificate. DNS names and IP addresses can be contained
in the Common Name (CN) or subjectAltName entries. For
verification, only one of these entries is to be
considered. The following precedence applies: for DNS name
validation, subjectAltName:DNS has precedence over CN; for
IP address validation, subjectAltName:iPAddr has precedence
over CN.
+ Implementations MAY allow the configuration of a set of
additional properties of the certificate to check for a
peer's authorization to communicate (e.g., a set of allowed
values in subjectAltName:URI or a set of allowed X509v3
Certificate Policies)
Lopez, et al. Expires September 9, 2016 [Page 9]
Internet-Draft Secure Transport for PCEP March 2016
* TLS with X.509 certificates using certificate fingerprints:
Implementations MUST allow the configuration of a list of
trusted certificates, identified via fingerprint of the
Distinguished Encoding Rules (DER) encoded certificate octets.
Implementations MUST support SHA-256 as defined by [SHS] as
the hash algorithm for the fingerprint.
3. Start exchanging PCEP messages.
To support TLS re-negotiation both peers MUST support the mechanism
described in [RFC5746]. Any attempt of initiate a TLS handshake to
establish new cryptographic parameters not aligned with [RFC5746]
SHALL be considered a TLS negotiation failure.
3.5. Peer Identity
Depending on the peer authentication method in use, PCEPS supports
different operation modes to establish peer's identity and whether it
is entitled to perform requests or can be considered authoritative in
its replies. PCEPS implementations SHOULD provide mechanisms for
associating peer identities with different levels of access and/or
authoritativeness, and they MUST provide a mechanism for establish a
default level for properly identified peers. Any connection
established with a peer that cannot be properly identified SHALL be
terminated before any PCEP exchange takes place.
In TLS-X.509 mode using fingerprints, a peer is uniquely identified
by the fingerprint of the presented certificate.
There are numerous trust models in PKIX environments, and it is
beyond the scope of this document to define how a particular
deployment determines whether a peer is trustworthy. Implementations
that want to support a wide variety of trust models should expose as
many details of the presented certificate to the administrator as
possible so that the trust model can be implemented by the
administrator. As a suggestion, at least the following parameters of
the X.509 certificate should be exposed:
o Peer's IP address
o Peer's fully qualified domain name (FQDN)
o Certificate Fingerprint
o Issuer
o Subject
Lopez, et al. Expires September 9, 2016 [Page 10]
Internet-Draft Secure Transport for PCEP March 2016
o All X509v3 Extended Key Usage
o All X509v3 Subject Alternative Name
o All X509v3 Certificate Policies
In addition, a PCC MAY apply the procedures described in [RFC6698]
DNS-Based Authentication of Named Entities (DANE) to verify its peer
identity when using DNS discovery. See section Section 4.1 for
further details.
3.6. Connection Establishment Failure
In case the initial TLS negotiation or the peer identity check fail
according to the procedures listed in this document, the peer MUST
immediately terminate the session. It SHOULD follow the procedure
listed in [RFC5440] to retry session setup along with an exponential
back-off session establishment retry procedure.
4. Discovery Mechanisms
A PCE can advertise its capability to support PCEPS using the IGP
advertisement and discovery mechanism. The PCE-CAP-FLAGS sub-TLV is
an optional sub-TLV used to advertise PCE capabilities. It MAY be
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"
lookups returned more than one IP address, then the PCC SHOULD use
the next resolved IP address for that FDQN as the connection address.
If the PCC fails to connect using all resolved IP addresses for a
given FDQN, then it SHOULD repeat the process of resolution and
Lopez, et al. Expires September 9, 2016 [Page 11]
Internet-Draft Secure Transport for PCEP March 2016
connection for the next FQDN returned by the SRV lookup based on the
priority and weight.
If the PCC receives a response to its SRV query but it is not able to
establish a PCEPS connection using the data received in the response,
as initiating entity it MAY fall back to lookup a PCE that uses TCP
as transport.
4.1. DANE Applicability
DANE [RFC6698] defines a secure method to associate the certificate
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
server certificate or public key with the domain name where the
record is found, thus forming a "TLSA certificate association". The
DNS information needs to be protected by DNS Security (DNSSEC). A
PCC willing to apply DANE to verify server identity MUST conform to
the rules defined in section 4 of [RFC6698]. The server's domain
name must be authorized separately, as TLSA does not provide any
useful authorization guarantees.
5. Backward Compatibility
The procedures described in this document define a security container
for the transport of PCEP requests and replies carried by a TLS
connection initiated by means of a specific extended message
(StartTLS) that does not interfere with PCEP speaker implementations
not supporting it.
If a PCEP implementation that does not support PCEPS receives a
StartTLS message it MUST behave according to the existing error
mechanism of [RFC5440].
6. IANA Considerations
6.1. New PCEP Message
Each PCEP message has a message type value.
One new PCEP messages is defined in this document:
Value Description Reference
TBA1 The Start TLS Message (StartTLS) This document
Lopez, et al. Expires September 9, 2016 [Page 12]
Internet-Draft Secure Transport for PCEP March 2016
6.2. New Error-Values
A registry was created for the Error-type and Error-value of the PCEP
Error Object. Following new Error-Types and Error-Values are
defined:
Error-
Type Meaning Error-value Reference
TBA2 StartTLS Failure 0:Unassigned This document
1:Reception of This document
StartTLS after
any PCEP exchange
2:Reception of This document
non-StartTLS
or non-PCErr message
3:Failure, connection This document
without TLS not
possible
4:Failure, connection This document
without TLS possible
5:No StartTLS message This document
before StartTLSWait
timer expiry
7. Security Considerations
While the application of TLS satisfies the requirement on privacy as
well as fine-grained, policy-based peer authentication, there are
security threats that it cannot address. It is advisable to apply
additional protection measures, in particular in what relates to
attacks specifically addressed to forging the TCP connection
underpinning TLS. TCP-AO (TCP Authentication Option [RFC5925]) is
fully compatible with and deemed as complementary to TLS, so its
usage is to be considered as a security enhancement whenever any of
the PCEPS peers require it, especially in the case of long-lived
connections. The mechanisms to configure the requirements to use
TCP-AO and other lower-layer protection measures, as well as the
association of the required crypto material (MKT in the case of
TCP-AO) with a particular peer are outside the scope of this
document. [I-D.chunduri-karp-using-ikev2-with-tcp-ao] defines a
method to perform such association.
Since computational resources required by TLS handshake and
ciphersuite are higher than unencrypted TCP, clients connecting to a
PCEPS server can more easily create high load conditions and a
malicious client might create a Denial-of-Service attack more easily.
Lopez, et al. Expires September 9, 2016 [Page 13]
Internet-Draft Secure Transport for PCEP March 2016
Some TLS ciphersuites only provide integrity validation of their
payload, and provide no encryption. This specification does not
forbid the use of such ciphersuites, but administrators must weight
carefully the risk of relevant internal data leakage that can occur
in such a case, as explicitly stated by [RFC6952].
When using certificate fingerprints to identify PCEPS peers, any two
certificates that produce the same hash value will be considered the
same peer. Therefore, it is important to make sure that the hash
function used is cryptographically uncompromised so that attackers
are very unlikely to be able to produce a hash collision with a
certificate of their choice. This document mandates support for SHA-
256 as defined by [SHS], but a later revision may demand support for
stronger functions if suitable attacks on it are known.
8. Manageability Considerations
All manageability requirements and considerations listed in [RFC5440]
apply to PCEP protocol extensions defined in this document. In
addition, requirements and considerations listed in this section
apply.
8.1. Control of Function and Policy
A PCE or PCC implementation MUST allow configuring the PCEP security
via TLS capabilities as described in this document.
A PCE or PCC implementation supporting PCEP security via TLS MUST
support general TLS configuration as per [RFC5246]. At least the
configuration of one of the trust models and its corresponding
parameters, as described in Section 3.4 and Section 3.5, MUST be
supported by the implementation.
A PCEP implementation SHOULD allow configuring the following PCEP
security parameters:
o StartTLSWait timer value
8.2. Information and Data Models
The PCEP MIB module SHOULD be extended to include PCEPS capabilities,
information, and status.
8.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [RFC5440] and [RFC5246].
Lopez, et al. Expires September 9, 2016 [Page 14]
Internet-Draft Secure Transport for PCEP March 2016
8.4. Verify Correct Operations
A PCEPS implementation SHOULD log error events and provide PCEPS
failure statistics with reasons.
8.5. Requirements on Other Protocols
Mechanisms defined in this document do not imply any new requirements
on other protocols.
8.6. Impact on Network Operations
Mechanisms defined in this document do not have any impact on network
operations in addition to those already listed in [RFC5440].
9. Acknowledgements
This specification relies on the analysis and profiling of TLS
included in [RFC6614] and the procedures described for the STARTTLS
command in [RFC2830].
We would like to thank Joe Touch for his suggestions and support
regarding the TLS start mechanisms.
Thanks to Dan King for reminding the authors about manageability
considerations.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words
for use in RFCs to
Indicate Requirement
Levels", BCP 14,
RFC 2119, DOI 10.17487/
RFC2119, March 1997, <ht
tp://www.rfc-editor.org/
info/rfc2119>.
[RFC5246] Dierks, T. and E.
Rescorla, "The Transport
Layer Security (TLS)
Protocol Version 1.2",
RFC 5246, DOI 10.17487/
RFC5246, August 2008, <h
ttp://
www.rfc-editor.org/info/
Lopez, et al. Expires September 9, 2016 [Page 15]
Internet-Draft Secure Transport for PCEP March 2016
rfc5246>.
[RFC5288] Salowey, J., Choudhury,
A., and D. McGrew, "AES
Galois Counter Mode
(GCM) Cipher Suites for
TLS", RFC 5288,
DOI 10.17487/RFC5288,
August 2008, <http://
www.rfc-editor.org/info/
rfc5288>.
[RFC5440] Vasseur, JP., Ed. and
JL. Le Roux, Ed., "Path
Computation Element
(PCE) Communication
Protocol (PCEP)",
RFC 5440, DOI 10.17487/
RFC5440, March 2009, <ht
tp://www.rfc-editor.org/
info/rfc5440>.
[RFC5088] Le Roux, JL., Ed.,
Vasseur, JP., Ed.,
Ikejiri, Y., and R.
Zhang, "OSPF Protocol
Extensions for Path
Computation Element
(PCE) Discovery",
RFC 5088, DOI 10.17487/
RFC5088, January 2008, <
http://
www.rfc-editor.org/info/
rfc5088>.
[RFC5089] Le Roux, JL., Ed.,
Vasseur, JP., Ed.,
Ikejiri, Y., and R.
Zhang, "IS-IS Protocol
Extensions for Path
Computation Element
(PCE) Discovery",
RFC 5089, DOI 10.17487/
RFC5089, January 2008, <
http://
www.rfc-editor.org/info/
rfc5089>.
Lopez, et al. Expires September 9, 2016 [Page 16]
Internet-Draft Secure Transport for PCEP March 2016
[RFC5280] Cooper, D., Santesson,
S., Farrell, S., Boeyen,
S., Housley, R., and W.
Polk, "Internet X.509
Public Key
Infrastructure
Certificate and
Certificate Revocation
List (CRL) Profile",
RFC 5280, DOI 10.17487/
RFC5280, May 2008, <http
://www.rfc-editor.org/
info/rfc5280>.
[RFC5746] Rescorla, E., Ray, M.,
Dispensa, S., and N.
Oskov, "Transport Layer
Security (TLS)
Renegotiation Indication
Extension", RFC 5746,
DOI 10.17487/RFC5746,
February 2010, <http://
www.rfc-editor.org/info/
rfc5746>.
[RFC5925] Touch, J., Mankin, A.,
and R. Bonica, "The TCP
Authentication Option",
RFC 5925, DOI 10.17487/
RFC5925, June 2010, <htt
p://www.rfc-editor.org/
info/rfc5925>.
[RFC6066] Eastlake 3rd, D.,
"Transport Layer
Security (TLS)
Extensions: Extension
Definitions", RFC 6066,
DOI 10.17487/RFC6066,
January 2011, <http://
www.rfc-editor.org/info/
rfc6066>.
[RFC6698] Hoffman, P. and J.
Schlyter, "The DNS-Based
Authentication of Named
Entities (DANE)
Transport Layer Security
Lopez, et al. Expires September 9, 2016 [Page 17]
Internet-Draft Secure Transport for PCEP March 2016
(TLS) Protocol: TLSA",
RFC 6698, DOI 10.17487/
RFC6698, August 2012, <h
ttp://
www.rfc-editor.org/info/
rfc6698>.
[SHS] National Institute of
Standards and
Technology, "Secure Hash
Standard (SHS), FIPS PUB
180-4", DOI 10.6028/
NIST.FIPS.180-4,
August 2015, <http://
nvlpubs.nist.gov/
nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
10.2. Informative References
[RFC2830] Hodges, J., Morgan, R.,
and M. Wahl,
"Lightweight Directory
Access Protocol (v3):
Extension for Transport
Layer Security",
RFC 2830, DOI 10.17487/
RFC2830, May 2000, <http
://www.rfc-editor.org/
info/rfc2830>.
[RFC6614] Winter, S., McCauley,
M., Venaas, S., and K.
Wierenga, "Transport
Layer Security (TLS)
Encryption for RADIUS",
RFC 6614, DOI 10.17487/
RFC6614, May 2012, <http
://www.rfc-editor.org/
info/rfc6614>.
[RFC6952] Jethanandani, M., Patel,
K., and L. Zheng,
"Analysis of BGP, LDP,
PCEP, and MSDP Issues
According to the Keying
and Authentication for
Routing Protocols (KARP)
Lopez, et al. Expires September 9, 2016 [Page 18]
Internet-Draft Secure Transport for PCEP March 2016
Design Guide", RFC 6952,
DOI 10.17487/RFC6952,
May 2013, <http://
www.rfc-editor.org/info/
rfc6952>.
[I-D.wu-pce-dns-pce-discovery] Wu, W., Dhody, D., King,
D., Lopez, D., and J.
Tantsura, "Path
Computation Element
(PCE) Discovery using
Domain Name
System(DNS)", draft-wu-
pce-dns-pce-discovery-09
(work in progress),
December 2015.
[I-D.wu-pce-discovery-pceps-support] Lopez, D., Wu, Q.,
Dhody, D., King, D., and
Z. Wang, "IGP extension
for PCEP security
capability support in
the PCE discovery", draf
t-wu-pce-discovery-
pceps-support-05 (work
in progress),
February 2016.
[I-D.chunduri-karp-using-ikev2-with-tcp-ao] Chunduri, U., Tian, A.,
and J. Touch, "A
framework for RPs to use
IKEv2 KMP", draft-
chunduri-karp-using-
ikev2-with-tcp-ao-06
(work in progress),
February 2014.
Authors' Addresses
Diego R. Lopez
Telefonica I+D
Don Ramon de la Cruz, 82
Madrid, 28006
Spain
Phone: +34 913 129 041
EMail: diego.r.lopez@telefonica.com
Lopez, et al. Expires September 9, 2016 [Page 19]
Internet-Draft Secure Transport for PCEP March 2016
Oscar Gonzalez de Dios
Telefonica I+D
Don Ramon de la Cruz, 82
Madrid, 28006
Spain
Phone: +34 913 129 041
EMail: oscar.gonzalezdedios@telefonica.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
EMail: sunseawq@huawei.com
Dhruv Dhody
Huawei
Divyashree Techno Park, Whitefield
Bangalore, KA 560037
India
EMail: dhruv.ietf@gmail.com
Lopez, et al. Expires September 9, 2016 [Page 20]
