Re: [xml2rfc] New xml2rfc release: v2.8.0

[Henrik Levkowetz <[e-mail]>]

Hi Dhruv,

On 2017-09-04 21:01, Dhruv Dhody wrote:
> Hi,
> 
> Because of this change idnits is failing and submission for draft is
> getting blocked.
> I am going to make manual change now, idnits output below for your
> reference -

Oops.  Right.  Preparing to release a new idnits now.

Thanks, and best regards,

	Henrik

> Thanks!
> 
> Dhruv
> 
> idnits 2.14.01  /var/www/.idnits
> 
> 
> tmp/draft-ietf-pce-pceps-17.txt:
> 
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>   http://trustee.ietf.org/license-info):
>   ----------------------------------------------------------------------------
> 
>   ** The document seems to lack a License Notice according IETF Trust
>      Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
>      Section 6.b -- however, there's a paragraph with a matching beginning.
>      Boilerplate error?
> 
>      IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
>         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.
> 
>      ... text found in draft:
>         This document is subject to BCP 78 and the IETF Trust's Legal Provisions
>         Relating to IETF Documents
> ..................................^
>         (https://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.
> 
> 
> 
>   Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
>   ----------------------------------------------------------------------------
> 
>   ** The document seems to lack a 1id_guidelines paragraph about
>      Internet-Drafts being working documents -- however, there's a paragraph
>      with a matching beginning. Boilerplate error?
> 
>      1id_guidelines, paragraph 1:
>         Internet-Drafts are working documents of the Internet Engineering Task
>         Force (IETF), its areas, and its working groups.  Note that other
>         groups may also distribute working documents as Internet-Drafts.
> 
>      ... text found in draft:
>         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
>         https://datatracker.ietf.org/drafts/current/.
> 
> 
>   ** The document seems to lack a 1id_guidelines paragraph about the list of
>      current Internet-Drafts.
> 
>      1id_guidelines, paragraph 3:
>         The list of current Internet-Drafts can be accessed at
>         http://www.ietf.org/1id-abstracts.html
> 
>   ** The document seems to lack a 1id_guidelines paragraph about the list of
>      Shadow Directories.
> 
>      1id_guidelines, paragraph 4:
>         The list of Internet-Draft Shadow Directories can be accessed at
>         http://www.ietf.org/shadow.html
> 
> 
>   Checking nits according to http://www.ietf.org/id-info/checklist :
>   ----------------------------------------------------------------------------
> 
>      No issues found here.
> 
>   Miscellaneous warnings:
>   ----------------------------------------------------------------------------
> 
>   == The document seems to lack the recommended RFC 2119 boilerplate, even if
>      it appears to use RFC 2119 keywords -- however, there's a paragraph with
>      a matching beginning. Boilerplate error?
> 
>      RFC 2119, paragraph 2:
>         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 RFC 2119.
> 
>      ... text found in draft:
>         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>         "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
> ................................................^
>         and "OPTIONAL" in this document are to be interpreted as
>         described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>         appear in all capitals, as shown here.
> 
> 
>      (The document does seem to have the reference to RFC 2119 which the
>      ID-Checklist requires).
>      (Using the creation date from RFC5440, updated by this document, for
>      RFC5378 checks: 2007-11-16)
> 
>   -- The document seems to contain a disclaimer for pre-RFC5378 work, and may
>      have content which was first submitted before 10 November 2008.  The
>      disclaimer is necessary when there are original authors that you have
>      been unable to contact, or if some do not wish to grant the BCP78 rights
>      to the IETF Trust.  If you are able to get all authors (current and
>      original) to grant those rights, you can and should remove the
>      disclaimer; otherwise, the disclaimer is needed and you can ignore this
>      comment. (See the Legal Provisions document at
>      http://trustee.ietf.org/license-info for more information.)
> 
> 
>   Checking references for intended status: Proposed Standard
>   ----------------------------------------------------------------------------
> 
>      (See RFCs 3967 and 4897 for information about using normative references
>      to lower-maturity documents in RFCs)
> 
>   -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS'
> 
> 
>      Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).
> 
> --------------------------------------------------------------------------------
> 
> 
> 2	PCE Working Group                                               D. Lopez
> 3	Internet-Draft                                       O. Gonzalez de Dios
> 4	Updates: 5440 (if approved)                               Telefonica I+D
> 5	Intended status: Standards Track                                   Q. Wu
> 6	Expires: March 8, 2018                                          D. Dhody
> 7	                                                                  Huawei
> 8	                                                       September 4, 2017
> 
> 10	                       Secure Transport for PCEP
> 11	                        draft-ietf-pce-pceps-17
> 
> 13	Abstract
> 
> 15	   The Path Computation Element Communication Protocol (PCEP) defines
> 16	   the mechanisms for the communication between a Path Computation
> 17	   Client (PCC) and a Path Computation Element (PCE), or among PCEs.
> 18	   This document describes the usage of Transport Layer Security (TLS)
> 19	   to enhance PCEP security, hence the PCEPS acronym proposed for it.
> 20	   The additional security mechanisms are provided by the transport
> 21	   protocol supporting PCEP, and therefore they do not affect the
> 22	   flexibility and extensibility of PCEP.
> 
> 24	   This document updates RFC 5440 in regards to the PCEP initialization
> 25	   phase procedures.
> 
> 27	Status of This Memo
> 
> 29	   This Internet-Draft is submitted in full conformance with the
> 30	   provisions of BCP 78 and BCP 79.
> 
> 32	   Internet-Drafts are working documents of the Internet Engineering
> 33	   Task Force (IETF).  Note that other groups may also distribute
> 34	   working documents as Internet-Drafts.  The list of current Internet-
> 35	   Drafts is at https://datatracker.ietf.org/drafts/current/.
> 
> 37	   Internet-Drafts are draft documents valid for a maximum of six months
> 38	   and may be updated, replaced, or obsoleted by other documents at any
> 39	   time.  It is inappropriate to use Internet-Drafts as reference
> 40	   material or to cite them other than as "work in progress."
> 
> 42	   This Internet-Draft will expire on March 8, 2018.
> 
> 44	Copyright Notice
> 
> 46	   Copyright (c) 2017 IETF Trust and the persons identified as the
> 47	   document authors.  All rights reserved.
> 
> 49	   This document is subject to BCP 78 and the IETF Trust's Legal
> 50	   Provisions Relating to IETF Documents
> 51	   (https://trustee.ietf.org/license-info) in effect on the date of
> 52	   publication of this document.  Please review these documents
> 53	   carefully, as they describe your rights and restrictions with respect
> 54	   to this document.  Code Components extracted from this document must
> 55	   include Simplified BSD License text as described in Section 4.e of
> 56	   the Trust Legal Provisions and are provided without warranty as
> 57	   described in the Simplified BSD License.
> 
> 59	   This document may contain material from IETF Documents or IETF
> 60	   Contributions published or made publicly available before November
> 61	   10, 2008.  The person(s) controlling the copyright in some of this
> 62	   material may not have granted the IETF Trust the right to allow
> 63	   modifications of such material outside the IETF Standards Process.
> 64	   Without obtaining an adequate license from the person(s) controlling
> 65	   the copyright in such materials, this document may not be modified
> 66	   outside the IETF Standards Process, and derivative works of it may
> 67	   not be created outside the IETF Standards Process, except to format
> 68	   it for publication as an RFC or to translate it into languages other
> 69	   than English.
> 
> 71	Table of Contents
> 
> 73	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
> 74	   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
> 75	   3.  Applying PCEPS  . . . . . . . . . . . . . . . . . . . . . . .   4
> 76	     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
> 77	     3.2.  Initiating the TLS Procedures . . . . . . . . . . . . . .   4
> 78	     3.3.  The StartTLS Message  . . . . . . . . . . . . . . . . . .   7
> 79	     3.4.  TLS Connection Establishment  . . . . . . . . . . . . . .  12
> 80	     3.5.  Peer Identity . . . . . . . . . . . . . . . . . . . . . .  14
> 81	     3.6.  Connection Establishment Failure  . . . . . . . . . . . .  15
> 82	   4.  Discovery Mechanisms  . . . . . . . . . . . . . . . . . . . .  15
> 83	     4.1.  DANE Applicability  . . . . . . . . . . . . . . . . . . .  16
> 84	   5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .  16
> 85	   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
> 86	     6.1.  New PCEP Message  . . . . . . . . . . . . . . . . . . . .  17
> 87	     6.2.  New Error-Values  . . . . . . . . . . . . . . . . . . . .  17
> 88	   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
> 89	   8.  Manageability Considerations  . . . . . . . . . . . . . . . .  19
> 90	     8.1.  Control of Function and Policy  . . . . . . . . . . . . .  19
> 91	     8.2.  Information and Data Models . . . . . . . . . . . . . . .  20
> 92	     8.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  20
> 93	     8.4.  Verifying Correct Operations  . . . . . . . . . . . . . .  20
> 94	     8.5.  Requirements on Other Protocols . . . . . . . . . . . . .  20
> 95	     8.6.  Impact on Network Operation . . . . . . . . . . . . . . .  21
> 96	   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
> 97	   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
> 98	     10.1.  Normative References . . . . . . . . . . . . . . . . . .  21
> 99	     10.2.  Informative References . . . . . . . . . . . . . . . . .  23
> 100	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24
> 
> 102	1.  Introduction
> 
> 104	   The Path Computation Element Communication Protocol (PCEP) [RFC5440]
> 105	   defines the mechanisms for the communication between a Path
> 106	   Computation Client (PCC) and a Path Computation Element (PCE), or
> 107	   between two PCEs.  These interactions include requests and replies
> 108	   that can be critical for a sustainable network operation and adequate
> 109	   resource allocation, and therefore appropriate security becomes a key
> 110	   element in the PCE infrastructure.  As the applications of the PCE
> 111	   framework evolves, and more complex service patterns emerge, the
> 112	   definition of a secure mode of operation becomes more relevant.
> 
> 114	   [RFC5440] analyzes in its section on security considerations the
> 115	   potential threats to PCEP and their consequences, and discusses
> 116	   several mechanisms for protecting PCEP against security attacks,
> 117	   without making a specific recommendation on a particular one or
> 118	   defining their application in depth.  Moreover, [RFC6952] remarks the
> 119	   importance of ensuring PCEP communication confidentiality, especially
> 120	   when PCEP communication endpoints do not reside in the same
> 121	   Autonomous System (AS), as the interception of PCEP messages could
> 122	   leak sensitive information related to computed paths and resources.
> 
> 124	   Among the possible solutions mentioned in these documents, Transport
> 125	   Layer Security (TLS) [RFC5246] provides support for peer
> 126	   authentication, message encryption and integrity.  TLS provides well-
> 127	   known mechanisms to support key configuration and exchange, as well
> 128	   as means to perform security checks on the results of PCE discovery
> 129	   procedures via Interior Gateway Protocol (IGP) ([RFC5088] and
> 130	   [RFC5089]).
> 
> 132	   This document describes a security container for the transport of
> 133	   PCEP messages, and therefore it does not affect the flexibility and
> 134	   extensibility of PCEP.
> 
> 136	   This document describes how to apply TLS to secure interactions with
> 137	   PCE, including initiation of the TLS procedures, the TLS handshake
> 138	   mechanism, the TLS methods for peer authentication, the applicable
> 139	   TLS ciphersuites for data exchange, and the handling of errors in the
> 140	   security checks.  In the rest of the document we will refer to this
> 141	   usage of TLS to provide a secure transport for PCEP as "PCEPS".
> 
> 143	   Within this document, PCEP communications are described through PCC-
> 144	   PCE relationship.  The PCE architecture also supports the PCE-PCE
> 145	   communication, this is achieved by requesting PCE fill the role of a
> 146	   PCC, as usual.  Thus, in this document, the PCC refers to a PCC or a
> 147	   PCE initiating the PCEP session and acting as a client.
> 
> 149	2.  Requirements Language
> 
> 151	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> 152	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
> 153	   "OPTIONAL" in this document are to be interpreted as described in BCP
> 154	   14 [RFC2119] [RFC8174] when, and only when, they appear in all
> 155	   capitals, as shown here.
> 
> 157	3.  Applying PCEPS
> 
> 159	3.1.  Overview
> 
> 161	   The steps involved in establishing a PCEPS session are as follows:
> 
> 163	   1.  Establishment of a TCP connection.
> 
> 165	   2.  Initiating the TLS procedures by the StartTLS message from PCE to
> 166	       PCC and from PCC to PCE.
> 
> 168	   3.  Negotiation and establishment of TLS connection.
> 
> 170	   4.  Start exchanging PCEP messages as per [RFC5440].
> 
> 172	   This document uses the standard StartTLS procedure in PCEP, instead
> 173	   of using a different port for the secured session.  This is done to
> 174	   avoid requesting allocation of another port number for the PCEPS.
> 175	   The StartTLS procedure makes more efficient use of scarce port
> 176	   numbers and allow simpler configuration of PCEP.
> 
> 178	   Implementations SHOULD follow the best practices and recommendations
> 179	   for using TLS, as per [RFC7525].
> 
> 181	   It should be noted that this procedure updates what is defined in
> 182	   section 4.2.1 and section 6.7 of [RFC5440] regarding the
> 183	   initialization phase and the processing of messages prior to the Open
> 184	   message.  The details of processing, including backward
> 185	   compatibility, are discussed in the following sections.
> 
> 187	3.2.  Initiating the TLS Procedures
> 
> 189	   Since PCEP can operate either with or without TLS, it is necessary
> 190	   for a PCEP speaker to indicate whether it wants to set up a TLS
> 191	   connection or not.  For this purpose, this document specifies a new
> 192	   PCEP message called StartTLS.  Thus, the PCEP session is secured via
> 193	   TLS from the start before exchange of any other PCEP message (that
> 194	   includes the Open message).  This document thus updates [RFC5440],
> 195	   which required the Open message to be the first PCEP message that is
> 196	   exchanged.  In the case of a PCEP session using TLS, the StartTLS
> 197	   message will be sent first.  Also a PCEP speaker that supports PCEPS
> 198	   MUST NOT start the OpenWait timer after the TCP establishment,
> 199	   instead it starts a StartTLSWait timer as described in Section 3.3.
> 
> 201	   The PCEP speaker MAY discover that the PCEP peer supports PCEPS or
> 202	   can be preconfigured to use PCEPS for a given peer (see Section 4 for
> 203	   more details).  An existing PCEP session cannot be secured via TLS,
> 204	   the session MUST be closed and re-established with TLS as per the
> 205	   procedure described in this document.
> 
> 207	   The StartTLS message is a PCEP message sent by a PCC to a PCE and by
> 208	   a PCE to a PCC in order to initiate the TLS procedure for PCEP.  The
> 209	   PCC initiates the use of TLS by sending a StartTLS message.  The PCE
> 210	   agrees to the use of TLS by responding with its own StartTLS message.
> 211	   If the PCE is configured to only support TLS, it may send the
> 212	   StartTLS message immediately upon TCP connection establishment;
> 213	   otherwise it MUST wait for the PCC's first message to see whether it
> 214	   is an Open or a StartTLS message.  The TLS negotiation and
> 215	   establishment procedures are triggered once the PCEP speaker has sent
> 216	   and received the StartTLS message.  The Message-Type field of the
> 217	   PCEP common header for the StartTLS message is set to [TBA1 by IANA].
> 
> 219	   Once the TCP connection has been successfully established, the first
> 220	   message sent by the PCC to the PCE and by the PCE to the PCC MUST be
> 221	   a StartTLS message for the PCEPS.  Note that, this is a significant
> 222	   change from [RFC5440], where the first PCEP message is the Open
> 223	   message.
> 
> 225	   A PCEP speaker receiving a StartTLS message, after any other PCEP
> 226	   exchange has taken place (by receiving or sending any other messages
> 227	   from either side) MUST treat it as an unexpected message and reply
> 228	   with a PCErr message with Error-Type set to [TBA2 by IANA] (PCEP
> 229	   StartTLS failure) and Error-value set to 1 (reception of StartTLS
> 230	   after any PCEP exchange), and MUST close the TCP connection.
> 
> 232	   Any message received prior to StartTLS or Open message MUST trigger a
> 233	   protocol error condition causing a PCErr message to be sent with
> 234	   Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure) and Error-
> 235	   value set to 2 (reception of a message apart from StartTLS or Open)
> 236	   and MUST close the TCP connection.
> 
> 238	   If the PCEP speaker that does not support PCEPS, receives a StartTLS
> 239	   message, it will behave according to the existing error mechanism
> 240	   described in section 6.2 of [RFC5440] (in case message is received
> 241	   prior to an Open message) or section 6.9 of [RFC5440] (for the case
> 242	   of reception of unknown message).  See Section 5 for more details.
> 
> 244	   If the PCEP speaker that only supports PCEPS connection (as a local
> 245	   policy), receives an Open message, it MUST treat it as an unexpected
> 246	   message and reply with a PCErr message with Error-Type set to 1 (PCEP
> 247	   session establishment failure) and Error-value set to 1 (reception of
> 248	   an invalid Open message or a non Open message), and MUST close the
> 249	   TCP connection.
> 
> 251	   If a PCC supports PCEPS connections as well as allow non-PCEPS
> 252	   connection (as a local policy), it MUST first try to establish PCEPS,
> 253	   by sending StartTLS message and in case it receives an PCErr message
> 254	   from the PCE, it MAY retry to establish connection without PCEPS by
> 255	   sending an Open message.  If a PCE supports PCEPS connections as well
> 256	   as allow non-PCEPS connection (as a local policy), it MUST wait to
> 257	   respond after TCP establishment, based on the message received from
> 258	   the PCC.  In case of StartTLS message, PCE MUST respond with sending
> 259	   a StartTLS message and moving to TLS establishment procedures as
> 260	   described in this document.  In case of Open message, PCE MUST
> 261	   respond with Open message and move to PCEP session establishment
> 262	   procedure as per [RFC5440].  If a PCE supports PCEPS connections only
> 263	   (as a local policy), it MAY send StartTLS message to PCC without
> 264	   waiting to receive a StartTLS message from PCC.
> 
> 266	   If a PCEP speaker that is unwilling or unable to negotiate TLS
> 267	   receives a StartTLS messages, it MUST return a PCErr message (in
> 268	   clear) with Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure)
> 269	   and Error-value set to:
> 
> 271	   o  3 (Failure, connection without TLS is not possible) if it is not
> 272	      willing to exchange PCEP messages without the solicited TLS
> 273	      connection, and it MUST close the TCP session.
> 
> 275	   o  4 (Failure, connection without TLS is possible) if it is willing
> 276	      to exchange PCEP messages without the solicited TLS connection,
> 277	      and it MUST close the TCP session.  The receiver MAY choose to
> 278	      attempt to re-establish the PCEP session without TLS next.  The
> 279	      attempt to re-establish the PCEP session without TLS SHOULD be
> 280	      limited to only once.
> 
> 282	   If the PCEP speaker supports PCEPS and can establish a TLS connection
> 283	   it MUST start the TLS connection negotiation and establishment steps
> 284	   described in Section 3.4 before the PCEP initialization procedure
> 285	   (section 4.2.1 of [RFC5440]).
> 
> 287	   After the exchange of StartTLS messages, if the TLS negotiation fails
> 288	   for some reason (e.g. the required mechanisms for certificate
> 289	   revocation checking are not available), both peers SHOULD immediately
> 290	   close the connection.
> 
> 292	   A PCEP speaker that does not support PCEPS sends the Open message
> 293	   directly, as per [RFC5440].  A PCEP speaker that supports PCEPS, but
> 294	   has learned in the last exchange the peer's willingness to
> 295	   reestablish session without TLS, MAY send the Open message directly,
> 296	   as per [RFC5440].  The attempt to re-establish the PCEP session
> 297	   without TLS SHOULD be limited to only once.
> 
> 299	   Given the asymmetric nature of TLS for connection establishment, it
> 300	   is relevant to identify the roles of each of the PCEP peers in it.
> 301	   The PCC SHALL act as TLS client, and the PCE SHALL act as TLS server
> 302	   as per [RFC5246].
> 
> 304	   As per the recommendation from [RFC7525] to avoid downgrade attacks,
> 305	   PCEP peers that support PCEPS, SHOULD default to strict TLS
> 306	   configuration i.e. do not allow non-TLS PCEP sessions to be
> 307	   established.  PCEPS implementations MAY provide an option to allow
> 308	   the operator to manually override strict TLS configuration and allow
> 309	   unsecured connections.  Execution of this override SHOULD trigger a
> 310	   warning about the security implications of permitting unsecured
> 311	   connections.
> 
> 313	3.3.  The StartTLS Message
> 
> 315	   The StartTLS message is used to initiate the TLS procedure for a
> 316	   PCEPS session between the PCEP peers.  A PCEP speaker sends the
> 317	   StartTLS message to request negotiation and establishment of TLS
> 318	   connection for PCEP.  On receiving a StartTLS message from the PCEP
> 319	   peer (i.e.  when the PCEP speaker has sent and received StartTLS
> 320	   message) it is ready to start the negotiation and establishment of
> 321	   TLS and move to steps described in Section 3.4.
> 
> 323	   The collision resolution procedures described in [RFC5440] for the
> 324	   exchange of Open messages MUST be applied by the PCEP peers during
> 325	   the exchange of StartTLS messages.
> 
> 327	   The format of a StartTLS message is as follows:
> 
> 329	      <StartTLS Message>::= <Common Header>
> 
> 331	   The StartTLS message MUST contain only the PCEP common header with
> 332	   Message-Type field set to [TBA1 by IANA].
> 
> 334	   Once the TCP connection has been successfully established, the PCEP
> 335	   speaker MUST start a timer called StartTLSWait timer, after the
> 336	   expiration of which, if neither StartTLS message has been received,
> 337	   nor a PCErr/Open message (in case of failure and PCEPS not supported
> 338	   by the peer, respectively), it MUST send a PCErr message with Error-
> 339	   Type set to [TBA2 by IANA] and Error-value set to 5 (no StartTLS (nor
> 340	   PCErr/Open) message received before the expiration of the
> 341	   StartTLSWait timer) and it MUST release the TCP connection . A
> 342	   RECOMMENDED value for StartTLSWait timer is 60 seconds.  The value of
> 343	   StartTLSWait timer MUST NOT be less than OpenWait timer.
> 
> 345	                  +-+-+                 +-+-+
> 346	                  |PCC|                 |PCE|
> 347	                  +-+-+                 +-+-+
> 348	                    |                     |
> 349	                    | StartTLS            |
> 350	                    | msg                 |
> 351	                    |-------              |
> 352	                    |       \   StartTLS  |
> 353	                    |        \  msg       |
> 354	                    |         \  ---------|
> 355	                    |          \/         |
> 356	                    |          /\         |
> 357	                    |         /  -------->|
> 358	                    |        /            |
> 359	                    |<------              |
> 360	                    |:::::::::TLS:::::::::|
> 361	                    |:::::Establishment:::|
> 362	                    |                     |
> 363	                    |                     |
> 364	                    |:::::::PCEP::::::::::|
> 365	                    |                     |
> 
> 367	            Figure 1: Both PCEP Speaker supports PCEPS (strict)
> 368	                  +-+-+                 +-+-+
> 369	                  |PCC|                 |PCE|
> 370	                  +-+-+                 +-+-+
> 371	                    |                     |
> 372	                    | StartTLS            |
> 373	                    | msg                 |
> 374	                    |-------              |
> 375	                    |       \   StartTLS  |
> 376	                    |        \  msg       |
> 377	                    |         \  ---------|
> 378	                    |          \/         |
> 379	                    |          /\         |
> 380	                    |         /  -------->|
> 381	                    |        /            |
> 382	                    |<------              |
> 383	                    |:::::::::TLS:::::::::| TLS Establishment
> 384	                    |:::::Establishment:::| Failure, Both
> 385	                    |                     | peers close
> 386	                                            session
> 
> 388	      Figure 2: Both PCEP Speaker supports PCEPS (strict), but cannot
> 389	                               establish TLS
> 
> 391	                  +-+-+                 +-+-+
> 392	                  |PCC|                 |PCE|
> 393	                  +-+-+                 +-+-+
> 394	                    |                     |  Does not support
> 395	                    | StartTLS            |  PCEPS and thus
> 396	                    | msg                 |  sends Open
> 397	                    |-------              |
> 398	                    |       \   Open      |
> 399	                    |        \  msg       |
> 400	                    |         \  ---------|
> 401	                    |          \/         |
> 402	                    |          /\         |
> 403	                    |         /  -------->|
> 404	                    |        /            |
> 405	                    |<------              |
> 406	                    |                     |
> 407	                    |<--------------------| Send Error
> 408	                    |       PCErr         | Type=1,Value=1
> 409	                    |                     | (non-Open message
> 410	                    |<--------------------|  received)
> 411	                    |       Close         |
> 412	                    ///////// TCP /////////
> 413	                    //////re-establish/////
> 414	          Send Open | Open                |
> 415	          this time | msg                 |
> 416	                    |-------              |
> 417	                    |       \   Open      |
> 418	                    |        \  msg       |
> 419	                    |         \  ---------|
> 420	                    |          \/         |
> 421	                    |          /\         |
> 422	                    |         /  -------->|
> 423	                    |        /            |
> 424	                    |<------              |
> 
> 426	    Figure 3: One PCEP Speaker (PCE) does not support PCEPS, while PCC
> 427	                    supports both with or without PCEPS
> 
> 429	                  +-+-+                 +-+-+
> 430	                  |PCC|                 |PCE|
> 431	                  +-+-+                 +-+-+
> 432	                    |                     |
> 433	                    | StartTLS            |
> 434	                    | msg                 | PCE waits
> 435	                    |-------------------->| for PCC and
> 436	                    |            StartTLS | respond with
> 437	                    |<--------------------| Start TLS
> 438	                    |                     |
> 439	                    |:::::::::TLS:::::::::|
> 440	                    |:::::Establishment:::|
> 441	                    |                     |
> 442	                    |                     |
> 443	                    |:::::::PCEP::::::::::|
> 444	                    |                     |
> 
> 446	    Figure 4: Both PCEP Speaker supports PCEPS as well as without PCEPS
> 
> 448	                  +-+-+                 +-+-+
> 449	                  |PCC|                 |PCE|
> 450	                  +-+-+                 +-+-+
> 451	                    |                     |
> 452	                    | StartTLS            |
> 453	                    | msg                 | PCE waits
> 454	                    |-------------------->| for PCC
> 455	                    |               PCErr |
> 456	                    |<--------------------| Send Error
> 457	                    |                     | Type=TBA2,Value=3
> 458	                    |                     | (Failure, connection
> 459	                    |<--------------------|  without TLS is not
> 460	                    |       Close         |  possible)
> 
> 462	   Figure 5: Both PCEP Speaker supports PCEPS as well as without PCEPS,
> 463	                   but PCE cannot start TLS negotiation
> 
> 465	                  +-+-+                 +-+-+
> 466	                  |PCC|                 |PCE|
> 467	                  +-+-+                 +-+-+
> 468	                    |                     |
> 469	                    | Open                |
> 470	                    | msg                 | PCE waits
> 471	                    |-------------------->| for PCC and
> 472	                    |                Open | respond with
> 473	                    |<--------------------| Open
> 474	                    |                     |
> 475	                    |:::::::PCEP::::::::::|
> 476	                    |                     |
> 
> 478	   Figure 6: PCE supports PCEPS as well as without PCEPS, while PCC does
> 479	                             not support PCEPS
> 
> 481	3.4.  TLS Connection Establishment
> 
> 483	   Once the establishment of TLS has been agreed by the PCEP peers, the
> 484	   connection establishment SHALL follow the following steps:
> 
> 486	   1.  Immediately negotiate a TLS session according to [RFC5246].  The
> 487	       following restrictions apply:
> 
> 489	       *  Support for TLS v1.2 [RFC5246] or later is REQUIRED.
> 
> 491	       *  Support for certificate-based mutual authentication is
> 492	          REQUIRED.
> 
> 494	       *  Negotiation of a ciphersuite providing for integrity
> 495	          protection is REQUIRED.
> 
> 497	       *  Negotiation of a ciphersuite providing for confidentiality is
> 498	          RECOMMENDED.
> 
> 500	       *  Support for and negotiation of compression is OPTIONAL.
> 
> 502	       *  PCEPS implementations MUST, at a minimum, support negotiation
> 503	          of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460], and
> 504	          SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as
> 505	          well.  Implementations SHOULD support the NIST P-256
> 506	          (secp256r1) curve [RFC4492].  In addition, PCEPS
> 507	          implementations MUST support negotiation of the mandatory-to-
> 508	          implement ciphersuites required by the versions of TLS that
> 509	          they support from TLS 1.3 onwards.
> 
> 511	   2.  Peer authentication can be performed in any of the following two
> 512	       REQUIRED operation models:
> 
> 514	       *  TLS with X.509 certificates using Public-Key Infrastructure
> 515	          Exchange (PKIX) trust models:
> 
> 517	          +  Implementations MUST allow the configuration of a list of
> 518	             trusted Certification Authorities (CAs) for incoming
> 519	             connections.
> 
> 521	          +  Certificate validation MUST include the verification rules
> 522	             as per [RFC5280].
> 
> 524	          +  PCEPS implementations SHOULD incorporate revocation methods
> 525	             (CRL downloading, OCSP...) according to the trusted CA
> 526	             policies.
> 
> 528	          +  Implementations SHOULD indicate their trusted CAs.  For TLS
> 529	             1.2, this is done using [RFC5246], Section 7.4.4,
> 530	             "certificate_authorities" (server side) and [RFC6066],
> 531	             Section 6 "Trusted CA Indication" (client side).
> 
> 533	          +  Implementations MUST follow the rules and guidelines for
> 534	             peer validation as defined in [RFC6125].  If an expected
> 535	             DNS name or IP address for the peer is configured, then the
> 536	             implementations MUST check them against the values in the
> 537	             presented certificate.  The DNS names and the IP addresses
> 538	             can be contained in the CN-ID [RFC6125] (Common Name
> 539	             Identifier) or the subjectAltName entries.  For
> 540	             verification, only one of these entries is considered.  The
> 541	             following precedence applies: for DNS name validation, DNS-
> 542	             ID [RFC6125] has precedence over CN-ID; for IP address
> 543	             validation, subjectAltName:iPAddr has precedence over CN-
> 544	             ID.
> 
> 546	          +  Implementations MAY allow the configuration of a set of
> 547	             additional properties of the certificate to check for a
> 548	             peer's authorization to communicate (e.g., a set of allowed
> 549	             values in URI-ID [RFC6125] or a set of allowed X509v3
> 550	             Certificate Policies).  The definition of these properties
> 551	             are out of scope of this document.
> 
> 553	       *  TLS with X.509 certificates using certificate fingerprints:
> 554	          Implementations MUST allow the configuration of a list of
> 555	          certificates that are trusted to identify peers, identified
> 556	          via fingerprint of the Distinguished Encoding Rules (DER)
> 557	          encoded certificate octets.  Implementations MUST support
> 558	          SHA-256 as defined by [SHS] as the hash algorithm for the
> 559	          fingerprint, but a later revision may demand support for a
> 560	          stronger hash function.
> 
> 562	   3.  Start exchanging PCEP messages.
> 
> 564	       *  Once the TLS connection has been successfully established, the
> 565	          PCEP speaker MUST start the OpenWait timer [RFC5440], after
> 566	          the expiration of which, if no Open message has been received,
> 567	          it sends a PCErr message and releases the TCP/TLS connection.
> 
> 569	3.5.  Peer Identity
> 
> 571	   Depending on the peer authentication method in use, PCEPS supports
> 572	   different operation modes to establish peer's identity and whether it
> 573	   is entitled to perform requests or can be considered authoritative in
> 574	   its replies.  PCEPS implementations SHOULD provide mechanisms for
> 575	   associating peer identities with different levels of access and/or
> 576	   authoritativeness, and they MUST provide a mechanism for establishing
> 577	   a default level for properly identified peers.  Any connection
> 578	   established with a peer that cannot be properly identified SHALL be
> 579	   terminated before any PCEP exchange takes place.
> 
> 581	   In TLS-X.509 mode using fingerprints, a peer is uniquely identified
> 582	   by the fingerprint of the presented certificate.
> 
> 584	   There are numerous trust models in PKIX environments, and it is
> 585	   beyond the scope of this document to define how a particular
> 586	   deployment determines whether a peer is trustworthy.  Implementations
> 587	   that want to support a wide variety of trust models should expose as
> 588	   many details of the presented certificate to the administrator as
> 589	   possible so that the trust model can be implemented by the
> 590	   administrator.  At least the following parameters of the X.509
> 591	   certificate SHOULD be exposed:
> 
> 593	   o  Peer's IP address
> 
> 595	   o  Peer's fully qualified domain name (FQDN)
> 
> 597	   o  Certificate Fingerprint
> 
> 599	   o  Issuer
> 
> 601	   o  Subject
> 
> 603	   o  All X509v3 Extended Key Usage
> 
> 605	   o  All X509v3 Subject Alternative Name
> 
> 607	   o  All X509v3 Certificate Policies
> 608	   Note that the remote IP address used for the TCP session
> 609	   establishment is also exposed.
> 
> 611	   [I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Entity
> 612	   Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that is
> 613	   included in the OPEN Object.  It contains a unique identifier for the
> 614	   node that does not change during the lifetime of the PCEP speaker.
> 615	   An implementation would thus expose the speaker entity identifier as
> 616	   part of the X509v3 certificate's subjectAltName:otherName, so that an
> 617	   implementation could use this identifier for the peer identification
> 618	   trust model.
> 
> 620	   In addition, a PCC MAY apply the procedures described in [RFC6698]
> 621	   DNS-Based Authentication of Named Entities (DANE) to verify its peer
> 622	   identity when using DNS discovery.  See section Section 4.1 for
> 623	   further details.
> 
> 625	3.6.  Connection Establishment Failure
> 
> 627	   In case the initial TLS negotiation or the peer identity check fails,
> 628	   according to the procedures listed in this document, both peers
> 629	   SHOULD immediately close the connection.
> 
> 631	   The initiator SHOULD follow the procedure listed in [RFC5440] to
> 632	   retry session setup as per the exponential back-off session
> 633	   establishment retry procedure.
> 
> 635	4.  Discovery Mechanisms
> 
> 637	   This document does not specify any discovery mechanism for support of
> 638	   PCEPS.  Other documents, [I-D.wu-pce-discovery-pceps-support] and
> 639	   [I-D.wu-pce-dns-pce-discovery] have made proposals:
> 
> 641	   o  A PCE can advertise its capability to support PCEPS using the
> 642	      IGP's advertisement mechanism of the PCE discovery information.
> 643	      The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to advertise
> 644	      PCE capabilities.  It is present within the PCE Discovery (PCED)
> 645	      sub-TLV carried by OSPF or IS-IS.  [RFC5088] and [RFC5089] provide
> 646	      the description and processing rules for this sub-TLV when carried
> 647	      within OSPF and IS-IS, respectively.  PCE capability bits are
> 648	      defined in [RFC5088].  A new capability flag bit for the PCE-CAP-
> 649	      FLAGS sub-TLV that can be announced as an attribute to distribute
> 650	      PCEP security support information is proposed in
> 651	      [I-D.wu-pce-discovery-pceps-support].
> 
> 653	   o  A PCE can advertise its capability to support PCEPS using the DNS
> 654	      [I-D.wu-pce-dns-pce-discovery] by identifying the support of TLS.
> 
> 656	4.1.  DANE Applicability
> 
> 658	   DANE [RFC6698] defines a secure method to associate the certificate
> 659	   that is obtained from a TLS server with a domain name using DNS,
> 660	   i.e., using the TLSA DNS resource record (RR) to associate a TLS
> 661	   server certificate or public key with the domain name where the
> 662	   record is found, thus forming a "TLSA certificate association".  The
> 663	   DNS information needs to be protected by DNS Security (DNSSEC).  A
> 664	   PCC willing to apply DANE to verify server identity MUST conform to
> 665	   the rules defined in section 4 of [RFC6698].  The implementation MUST
> 666	   support Service certificate constraint (TLSA Certificate Usages type
> 667	   1) with Matching type 2 (SHA2-256) as described in
> 668	   [RFC6698][RFC7671].  The server's domain name must be authorized
> 669	   separately, as TLSA does not provide any useful authorization
> 670	   guarantees.
> 
> 672	5.  Backward Compatibility
> 
> 674	   The procedures described in this document define a security container
> 675	   for the transport of PCEP requests and replies carried by a TLS
> 676	   connection initiated by means of a specific extended message
> 677	   (StartTLS) that does not interfere with PCEP speaker implementations
> 678	   not supporting it.
> 
> 680	   A PCC that does not support PCEPS will send Open message as the first
> 681	   message on TCP establishment.  A PCE that supports PCEPS only, will
> 682	   send StartTLS message on TCP establishment.  On receiving StartTLS
> 683	   message, PCC would consider it as an error and behave according to
> 684	   the existing error mechanism of [RFC5440] and send PCErr message with
> 685	   Error-Type 1 (PCEP session establishment failure) and Error-Value 1
> 686	   (reception of an invalid Open message or a non Open message) and
> 687	   close the session.
> 
> 689	   A PCC that support PCEPS will send StartTLS message as the first
> 690	   message on TCP establishment.  A PCE that does not supports PCEPS,
> 691	   would consider receiving StartTLS message as an error and respond
> 692	   with PCErr message (with Error-Type 1 and Error-Value 1) and close
> 693	   the session.
> 
> 695	   If a StartTLS message is received at any other time by a PCEP speaker
> 696	   that does not implement PCEPS, it would consider it as an unknown
> 697	   message and would behave according to the existing error mechanism of
> 698	   [RFC5440] and send PCErr message with Error-Type 2 (Capability not
> 699	   supported) and close the session.
> 
> 701	   An existing PCEP session cannot be upgraded to PCEPS, the session
> 702	   needs to be terminated and reestablished as per the procedure
> 703	   described in this document.  During the incremental upgrade, the PCEP
> 704	   speaker SHOULD allow session establishment with and without TLS.
> 705	   Once both PCEP speakers are upgraded to support PCEPS, the PCEP
> 706	   session is re-established with TLS, otherwise PCEP session without
> 707	   TLS is setup.  A redundant PCE MAY also be used during the
> 708	   incremental deployment to take over the PCE undergoing upgrade.  Once
> 709	   the upgrade is completed, support for unsecured version SHOULD be
> 710	   removed.
> 
> 712	   A PCE that accepts connections with or without PCEPS, it would
> 713	   respond based on the message received from PCC.  A PCC that supports
> 714	   connection with or without PCEPS, it would first attempt to connect
> 715	   with PCEPS and in case of error, it MAY retry to establish connection
> 716	   without PCEPS.  For successful TLS operations with PCEP, both PCEP
> 717	   peers in the network would need to be upgraded to support this
> 718	   document.
> 
> 720	   Note that, a PCEP implementation that support PCEPS would respond
> 721	   with PCErr message with Error-Type set to [TBA2 by IANA] (PCEP
> 722	   StartTLS failure) and Error-value set to 2 if any other message is
> 723	   sent before StartTLS or Open.  If the sender of the invalid message
> 724	   is a PCEP implementation that does not support PCEPS, it will not be
> 725	   able to understand this error.  A PCEPS implementation could also
> 726	   send the PCErr message as per [RFC5440] with Error-Type "PCEP session
> 727	   establishment failure" and Error-value "reception of an invalid Open
> 728	   message or a non Open message" before closing the session.
> 
> 730	6.  IANA Considerations
> 
> 732	6.1.  New PCEP Message
> 
> 734	   IANA is requested to allocate new message types within the "PCEP
> 735	   Messages" sub-registry of the PCEP Numbers registry, as follows:
> 
> 737	      Value  Description                             Reference
> 738	       TBA1  The Start TLS Message (StartTLS)        This document
> 
> 740	6.2.  New Error-Values
> 
> 742	   IANA is requested to allocate new Error Types and Error Values within
> 743	   the " PCEP-ERROR Object Error Types and Values" sub-registry of the
> 744	   PCEP Numbers registry, as follows:
> 
> 746	   Error-
> 747	   Type    Meaning               Error-value             Reference
> 
> 749	   TBA2    PCEP StartTLS         0:Unassigned            This document
> 750	           failure               1:Reception of          This document
> 751	                                 StartTLS after
> 752	                                 any PCEP exchange
> 753	                                 2:Reception of          This document
> 754	                                 any other message
> 755	                                 apart from StartTLS,
> 756	                                 Open or PCErr
> 757	                                 3:Failure, connection   This document
> 758	                                 without TLS is not
> 759	                                 possible
> 760	                                 4:Failure, connection   This document
> 761	                                 without TLS is
> 762	                                 possible
> 763	                                 5:No StartTLS message   This document
> 764	                                 (nor PCErr/Open)
> 765	                                 before StartTLSWait
> 766	                                 timer expiry
> 
> 768	7.  Security Considerations
> 
> 770	   While the application of TLS satisfies the requirement on
> 771	   confidentiality as well as fine-grained, policy-based peer
> 772	   authentication, there are security threats that it cannot address.
> 773	   It may be advisable to apply additional protection measures, in
> 774	   particular in what relates to attacks specifically addressed to
> 775	   forging the TCP connection underpinning TLS, especially in the case
> 776	   of long-lived connections.  One of these measures is the application
> 777	   of TCP-AO (TCP Authentication Option [RFC5925]), which is fully
> 778	   compatible with and deemed as complementary to TLS.  The mechanisms
> 779	   to configure the requirements to use TCP-AO and other lower-layer
> 780	   protection measures with a particular peer are outside the scope of
> 781	   this document.
> 
> 783	   Since computational resources required by TLS handshake and
> 784	   ciphersuite are higher than unencrypted TCP, clients connecting to a
> 785	   PCEPS server can more easily create high load conditions and a
> 786	   malicious client might create a Denial-of-Service attack more easily.
> 
> 788	   Some TLS ciphersuites only provide integrity validation of their
> 789	   payload, and provide no encryption, such ciphersuites SHOULD NOT be
> 790	   used by default.  Administrators MAY allow the usage of these
> 791	   ciphersuites after careful weighting of the risk of relevant internal
> 792	   data leakage, that can occur in such a case, as explicitly stated by
> 793	   [RFC6952].
> 
> 795	   When using certificate fingerprints to identify PCEPS peers, any two
> 796	   certificates that produce the same hash value will be considered the
> 797	   same peer.  Therefore, it is important to make sure that the hash
> 798	   function used is cryptographically uncompromised, so that attackers
> 799	   are very unlikely to be able to produce a hash collision with a
> 800	   certificate of their choice.  This document mandates support for
> 801	   SHA-256 as defined by [SHS], but a later revision may demand support
> 802	   for stronger functions if suitable attacks on it are known.
> 
> 804	   PCEPS implementations that continue to accept connections without TLS
> 805	   are susceptible to downgrade attacks as described in [RFC7457].  An
> 806	   attacker could attempt to remove the use of StartTLS message that
> 807	   request the use of TLS as it pass on the wire in clear, and further
> 808	   inject a PCErr message that suggest to attempt PCEP connection
> 809	   without TLS.
> 
> 811	   The guidance given in [RFC7525] SHOULD be followed to avoid attacks
> 812	   on TLS.
> 
> 814	8.  Manageability Considerations
> 
> 816	   All manageability requirements and considerations listed in [RFC5440]
> 817	   apply to PCEP protocol extensions defined in this document.  In
> 818	   addition, requirements and considerations listed in this section
> 819	   apply.
> 
> 821	8.1.  Control of Function and Policy
> 
> 823	   A PCE or PCC implementation SHOULD allow configuring the PCEP
> 824	   security via TLS capabilities as described in this document.
> 
> 826	   A PCE or PCC implementation supporting PCEP security via TLS MUST
> 827	   support general TLS configuration as per [RFC5246].  At least the
> 828	   configuration of one of the trust models and its corresponding
> 829	   parameters, as described in Section 3.4 and Section 3.5, MUST be
> 830	   supported by the implementation.
> 
> 832	   A PCEP implementation SHOULD allow configuring the StartTLSWait timer
> 833	   value.
> 
> 835	   PCEPS implementations MAY provide an option to allow the operator to
> 836	   manually override strict TLS configuration and allow unsecure
> 837	   connections.  Execution of this override SHOULD trigger a warning
> 838	   about the security implications of permitting unsecure connections.
> 
> 840	   Further, the operator needs to develop suitable security policies
> 841	   around PCEP within his network.  The PCEP peers SHOULD provide ways
> 842	   for the operator to complete the following tasks in regards to a PCEP
> 843	   session:
> 
> 845	   o  Determine if a session is protected via PCEPS.
> 
> 847	   o  Determine the version of TLS, the mechanism used for
> 848	      authentication, and the ciphersuite in use.
> 
> 850	   o  Determine if the certificate could not be verified, and the reason
> 851	      for this circumstance.
> 
> 853	   o  Inspect the certificate offered by the PCEP peer.
> 
> 855	   o  Be warned if StartTLS procedure fails for the PCEP peers, that are
> 856	      known to support PCEPS via configurations or capability
> 857	      advertisements.
> 
> 859	8.2.  Information and Data Models
> 
> 861	   The PCEP MIB module is defined in [RFC7420].  The MIB module could be
> 862	   extended to include the ability to view the PCEPS capability, TLS
> 863	   related information as well as TLS status for each PCEP peer.
> 
> 865	   Further, to allow the operator to configure the PCEPS capability and
> 866	   various TLS related parameters as well as to view the current TLS
> 867	   status for a PCEP session, the PCEP YANG module
> 868	   [I-D.ietf-pce-pcep-yang] is extended to include TLS related
> 869	   information.
> 
> 871	8.3.  Liveness Detection and Monitoring
> 
> 873	   Mechanisms defined in this document do not imply any new liveness
> 874	   detection and monitoring requirements in addition to those already
> 875	   listed in [RFC5440] and [RFC5246].
> 
> 877	8.4.  Verifying Correct Operations
> 
> 879	   A PCEPS implementation SHOULD log error events and provide PCEPS
> 880	   failure statistics with reasons.
> 
> 882	8.5.  Requirements on Other Protocols
> 
> 884	   Mechanisms defined in this document do not imply any new requirements
> 885	   on other protocols.  Note that, Section 4 list possible discovery
> 886	   mechanism for support of PCEPS.
> 
> 888	8.6.  Impact on Network Operation
> 
> 890	   Mechanisms defined in this document do not have any significant
> 891	   impact on network operations in addition to those already listed in
> 892	   [RFC5440], and the policy and management implications discussed
> 893	   above.
> 
> 895	9.  Acknowledgements
> 
> 897	   This specification relies on the analysis and profiling of TLS
> 898	   included in [RFC6614] and the procedures described for the STARTTLS
> 899	   command in [RFC4513].
> 
> 901	   We would like to thank Joe Touch for his suggestions and support
> 902	   regarding the StartTLS mechanisms.
> 
> 904	   Thanks to Daniel King for reminding the authors about manageability
> 905	   considerations.
> 
> 907	   Thanks to Cyril Margaria for shepherding this document.
> 
> 909	   Thanks to David Mandelberg for early SECDIR review comments as well
> 910	   as re-reviewing during IETF last call.
> 
> 912	   Thanks to Dan Frost for the RTGDIR review and comments.
> 
> 914	   Thanks to Dale Worley for the Gen-ART review and comments.
> 
> 916	   Also thanks to Tianran Zhou for OPSDIR review.
> 
> 918	   Thanks to Deborah Brungard for being the responsible AD and guiding
> 919	   the authors as needed.
> 
> 921	   Thanks to Mirja Kuhlewind, Eric Rescorla, Warren Kumari, Kathleen
> 922	   Moriarty, Suresh Krishnan, Ben Campbell and Alexey Melnikov for the
> 923	   IESG review and comments.
> 
> 925	10.  References
> 
> 927	10.1.  Normative References
> 
> 929	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
> 930	              Requirement Levels", BCP 14, RFC 2119,
> 931	              DOI 10.17487/RFC2119, March 1997,
> 932	              <https://www.rfc-editor.org/info/rfc2119>.
> 
> 934	   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
> 935	              (TLS) Protocol Version 1.2", RFC 5246,
> 936	              DOI 10.17487/RFC5246, August 2008,
> 937	              <https://www.rfc-editor.org/info/rfc5246>.
> 
> 939	   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
> 940	              Housley, R., and W. Polk, "Internet X.509 Public Key
> 941	              Infrastructure Certificate and Certificate Revocation List
> 942	              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
> 943	              <https://www.rfc-editor.org/info/rfc5280>.
> 
> 945	   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
> 946	              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
> 947	              DOI 10.17487/RFC5440, March 2009,
> 948	              <https://www.rfc-editor.org/info/rfc5440>.
> 
> 950	   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
> 951	              Extensions: Extension Definitions", RFC 6066,
> 952	              DOI 10.17487/RFC6066, January 2011,
> 953	              <https://www.rfc-editor.org/info/rfc6066>.
> 
> 955	   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
> 956	              Verification of Domain-Based Application Service Identity
> 957	              within Internet Public Key Infrastructure Using X.509
> 958	              (PKIX) Certificates in the Context of Transport Layer
> 959	              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
> 960	              2011, <https://www.rfc-editor.org/info/rfc6125>.
> 
> 962	   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
> 963	              of Named Entities (DANE) Transport Layer Security (TLS)
> 964	              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
> 965	              2012, <https://www.rfc-editor.org/info/rfc6698>.
> 
> 967	   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
> 968	              "Recommendations for Secure Use of Transport Layer
> 969	              Security (TLS) and Datagram Transport Layer Security
> 970	              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
> 971	              2015, <https://www.rfc-editor.org/info/rfc7525>.
> 
> 973	   [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based
> 974	              Authentication of Named Entities (DANE) Protocol: Updates
> 975	              and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
> 976	              October 2015, <https://www.rfc-editor.org/info/rfc7671>.
> 
> 978	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
> 979	              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
> 980	              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
> 
> 982	   [SHS]      National Institute of Standards and Technology, "Secure
> 983	              Hash Standard (SHS), FIPS PUB 180-4",
> 984	              DOI 10.6028/NIST.FIPS.180-4, August 2015,
> 985	              <http://nvlpubs.nist.gov/nistpubs/FIPS/
> 986	              NIST.FIPS.180-4.pdf>.
> 
> 988	10.2.  Informative References
> 
> 990	   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
> 991	              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
> 992	              for Transport Layer Security (TLS)", RFC 4492,
> 993	              DOI 10.17487/RFC4492, May 2006,
> 994	              <https://www.rfc-editor.org/info/rfc4492>.
> 
> 996	   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
> 997	              (LDAP): Authentication Methods and Security Mechanisms",
> 998	              RFC 4513, DOI 10.17487/RFC4513, June 2006,
> 999	              <https://www.rfc-editor.org/info/rfc4513>.
> 
> 1001	   [RFC5088]  Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
> 1002	              Zhang, "OSPF Protocol Extensions for Path Computation
> 1003	              Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,
> 1004	              January 2008, <https://www.rfc-editor.org/info/rfc5088>.
> 
> 1006	   [RFC5089]  Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
> 1007	              Zhang, "IS-IS Protocol Extensions for Path Computation
> 1008	              Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
> 1009	              January 2008, <https://www.rfc-editor.org/info/rfc5089>.
> 
> 1011	   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
> 1012	              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
> 1013	              June 2010, <https://www.rfc-editor.org/info/rfc5925>.
> 
> 1015	   [RFC6460]  Salter, M. and R. Housley, "Suite B Profile for Transport
> 1016	              Layer Security (TLS)", RFC 6460, DOI 10.17487/RFC6460,
> 1017	              January 2012, <https://www.rfc-editor.org/info/rfc6460>.
> 
> 1019	   [RFC6614]  Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
> 1020	              "Transport Layer Security (TLS) Encryption for RADIUS",
> 1021	              RFC 6614, DOI 10.17487/RFC6614, May 2012,
> 1022	              <https://www.rfc-editor.org/info/rfc6614>.
> 
> 1024	   [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
> 1025	              BGP, LDP, PCEP, and MSDP Issues According to the Keying
> 1026	              and Authentication for Routing Protocols (KARP) Design
> 1027	              Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
> 1028	              <https://www.rfc-editor.org/info/rfc6952>.
> 
> 1030	   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
> 1031	              Hardwick, "Path Computation Element Communication Protocol
> 1032	              (PCEP) Management Information Base (MIB) Module",
> 1033	              RFC 7420, DOI 10.17487/RFC7420, December 2014,
> 1034	              <https://www.rfc-editor.org/info/rfc7420>.
> 
> 1036	   [RFC7457]  Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
> 1037	              Known Attacks on Transport Layer Security (TLS) and
> 1038	              Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
> 1039	              February 2015, <https://www.rfc-editor.org/info/rfc7457>.
> 
> 1041	   [I-D.ietf-pce-stateful-sync-optimizations]
> 1042	              Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
> 1043	              and D. Dhody, "Optimizations of Label Switched Path State
> 1044	              Synchronization Procedures for a Stateful PCE", draft-
> 1045	              ietf-pce-stateful-sync-optimizations-10 (work in
> 1046	              progress), March 2017.
> 
> 1048	   [I-D.ietf-pce-pcep-yang]
> 1049	              Dhody, D., Hardwick, J., Beeram, V., and j.
> 1050	              [e-mail], "A YANG Data Model for Path
> 1051	              Computation Element Communications Protocol (PCEP)",
> 1052	              draft-ietf-pce-pcep-yang-05 (work in progress), June 2017.
> 
> 1054	   [I-D.wu-pce-dns-pce-discovery]
> 1055	              Wu, Q., Dhody, D., King, D., Lopez, D., and J. Tantsura,
> 1056	              "Path Computation Element (PCE) Discovery using Domain
> 1057	              Name System(DNS)", draft-wu-pce-dns-pce-discovery-10 (work
> 1058	              in progress), March 2017.
> 
> 1060	   [I-D.wu-pce-discovery-pceps-support]
> 1061	              Lopez, D., Wu, Q., Dhody, D., and D. King, "IGP extension
> 1062	              for PCEP security capability support in the PCE
> 1063	              discovery", draft-wu-pce-discovery-pceps-support-07 (work
> 1064	              in progress), March 2017.
> 
> 1066	Authors' Addresses
> 
> 1068	   Diego R. Lopez
> 1069	   Telefonica I+D
> 1070	   Don Ramon de la Cruz, 82
> 1071	   Madrid  28006
> 1072	   Spain
> 
> 1074	   Phone: [phone]
> 1075	   EMail: [e-mail]
> 1076	   Oscar Gonzalez de Dios
> 1077	   Telefonica I+D
> 1078	   Don Ramon de la Cruz, 82
> 1079	   Madrid  28006
> 1080	   Spain
> 
> 1082	   Phone: [phone]
> 1083	   EMail: [e-mail]
> 
> 1085	   Qin Wu
> 1086	   Huawei
> 1087	   101 Software Avenue, Yuhua District
> 1088	   Nanjing, Jiangsu  210012
> 1089	   China
> 
> 1091	   EMail: [e-mail]
> 
> 1093	   Dhruv Dhody
> 1094	   Huawei
> 1095	   Divyashree Techno Park, Whitefield
> 1096	   Bangalore, KA  560066
> 1097	   India
> 
> 1099	   EMail: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Sep 4, 2017 at 8:31 PM, Henrik Levkowetz <[e-mail]>
> wrote:
> 
>>
>> Hi,
>>
>> This is an automatic notification about a new xml2rfc release,
>> v2.8.0, generated when running the mkrelease script.
>>
>> Release notes:
>>
>> xml2rfc (2.8.0) ietf; urgency=low
>>   This is a small feature release which changes URLs in boilerplate to
>>   use https: instead of http:.  There are also some bugfixes.
>>   * Include notes when doing index processing.  Fixes issue #335.
>>   * Include erefs with text equal to the URL in the URIs section.  See
>>     issue #334.
>>   * Changed the use of http: to https: in many places.  In the generation
>>     of RFCs, the code uses a switchover date of August 21, 2017 when
>> deciding
>>     whether to insert http: or https: URLs.  In practice, this means that
>> RFCs
>>     with a date of September 2017 or later will get https:.  Also fixed URL
>>     line-breaking prevention to apply to https: URLS.  Fixes issue #333.
>>   * In urlkeep(), prevent breaking also for https:, not only http: URLs
>>
>> The new version is available through SVN checkout, with
>>   'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.8.0
>> '
>>
>> Regards,
>>
>>         Henrik
>>         (via the mkrelease script)
>>
>> _______________________________________________
>> xml2rfc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/xml2rfc
>>
>