[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-lopez-pce-pceps) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 8253

PCE Working Group                                               D. Lopez
Internet-Draft                                       O. Gonzalez de Dios
Updates: 5440 (if approved)                               Telefonica I+D
Intended status: Standards Track                                   Q. Wu
Expires: January 9, 2017                                        D. Dhody
                                                                  Huawei
                                                           July 08, 2016


                       Secure Transport for PCEP
                        draft-ietf-pce-pceps-10

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.

   This document updates RFC 5440 regarding the PCEP initialization
   phase specification.

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 January 9, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Lopez, et al.            Expires January 9, 2017                [Page 1]


Internet-Draft          Secure Transport for PCEP              July 2016


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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   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  . . . . . . . . . . . . . . . . . . . .  12
   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 . . . . . . . . . . . . . . . .  14
     8.5.  Requirements on Other Protocols . . . . . . . . . . . . .  15
     8.6.  Impact on Network Operations  . . . . . . . . . . . . . .  15
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15



Lopez, et al.            Expires January 9, 2017                [Page 2]


Internet-Draft          Secure Transport for PCEP              July 2016


   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   The Path Computation Element Communication Protocol (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 messages, 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".





Lopez, et al.            Expires January 9, 2017                [Page 3]


Internet-Draft          Secure Transport for PCEP              July 2016


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].

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 4.2.1 and section 6.7 of [RFC5440] regarding the
   initialization phase and 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 specifies a new
   PCEP message called StartTLS.  This message MUST be issued by the
   party willing to use TLS, prior to any other PCEP message including
   open message.  This document thus updates [RFC5440] which required
   the Open message to be the first PCEP message, since in the case of a
   PCEP session using TLS the StartTLS message will be sent first.

   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.





Lopez, et al.            Expires January 9, 2017                [Page 4]


Internet-Draft          Secure Transport for PCEP              July 2016


   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
   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, open, 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 any other message apart from
   StartTLS, Open, or 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]).




Lopez, et al.            Expires January 9, 2017                [Page 5]


Internet-Draft          Secure Transport for PCEP              July 2016


   A PCEP speaker that does not support PCEPS or has learned the peer
   willingness to reestablish session without TLS, can send the Open
   message directly, as per [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.

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 the 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 January 9, 2017                [Page 6]


Internet-Draft          Secure Transport for PCEP              July 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 January 9, 2017                [Page 7]


Internet-Draft          Secure Transport for PCEP              July 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 January 9, 2017                [Page 8]


Internet-Draft          Secure Transport for PCEP              July 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)

       *  TLS with X.509 certificates using certificate fingerprints:
          Implementations MUST allow the configuration of a list of



Lopez, et al.            Expires January 9, 2017                [Page 9]


Internet-Draft          Secure Transport for PCEP              July 2016


          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

   o  All X509v3 Extended Key Usage




Lopez, et al.            Expires January 9, 2017               [Page 10]


Internet-Draft          Secure Transport for PCEP              July 2016


   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
   connection for the next FQDN returned by the SRV lookup based on the
   priority and weight.



Lopez, et al.            Expires January 9, 2017               [Page 11]


Internet-Draft          Secure Transport for PCEP              July 2016


   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

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:





Lopez, et al.            Expires January 9, 2017               [Page 12]


Internet-Draft          Secure Transport for PCEP              July 2016


     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
                                     any other message
                                     apart from StartTLS,
                                     Open or PCErr
                                   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.

   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].



Lopez, et al.            Expires January 9, 2017               [Page 13]


Internet-Draft          Secure Transport for PCEP              July 2016


   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].

8.4.  Verify Correct Operations

   A PCEPS implementation SHOULD log error events and provide PCEPS
   failure statistics with reasons.




Lopez, et al.            Expires January 9, 2017               [Page 14]


Internet-Draft          Secure Transport for PCEP              July 2016


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 [RFC4513].

   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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc5246>.

   [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>.

   [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>.





Lopez, et al.            Expires January 9, 2017               [Page 15]


Internet-Draft          Secure Transport for PCEP              July 2016


   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <http://www.rfc-editor.org/info/rfc5440>.

   [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>.

   [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 (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <http://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

   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
              (LDAP): Authentication Methods and Security Mechanisms",
              RFC 4513, DOI 10.17487/RFC4513, June 2006,
              <http://www.rfc-editor.org/info/rfc4513>.

   [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>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <http://www.rfc-editor.org/info/rfc5925>.





Lopez, et al.            Expires January 9, 2017               [Page 16]


Internet-Draft          Secure Transport for PCEP              July 2016


   [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) 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", draft-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


   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



Lopez, et al.            Expires January 9, 2017               [Page 17]


Internet-Draft          Secure Transport for PCEP              July 2016


   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  560066
   India

   EMail: dhruv.ietf@gmail.com



































Lopez, et al.            Expires January 9, 2017               [Page 18]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/