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

[Dhruv Dhody <[e-mail]>]

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 -

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
>