Re: [Pce] RtgDir review: draft-ietf-pce-pceps-12

["Diego R. Lopez" <[e-mail]>]

--Apple-Mail=_9FEB5268-98BA-4654-BECA-5C16B7883EF6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8

Hi Dan,

> On 11 May 2017, at 14:31 , Dan Frost <[e-mail]> wrote:
>=20
>=20
> Hello,
>=20
> I have been selected as the Routing Directorate reviewer for this =
draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and
> sometimes on special request. The purpose of the review is to provide
> assistance to the Routing ADs. For more information about the Routing
> Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>=20
> Although these comments are primarily for the use of the Routing ADs, =
it
> would be helpful if you could consider them along with any other IETF
> Last Call comments that you receive, and strive to resolve them =
through
> discussion or by updating the draft.
>=20
> Document: draft-ietf-pce-pceps-12
> Reviewer: Dan Frost
> Review Date: 2017-05-11
> IETF LC End Date:=20
> Intended Status: Standards Track
>=20
> Summary:
>=20
> I have significant concerns about this document and recommend that the
> Routing ADs discuss these issues further with the authors.
>=20
> Comments:
>=20
> This document proposes to add a STARTTLS mechanism to the PCE =
protocol.
> If this basic approach is accepted, then the document is in good =
shape.
> It's clear, complete, and straightforward. The question is whether
> mandating STARTTLS is actually a good idea.
>=20
> Major Issues:
>=20
> My main concern with this document is that it takes as given that
> STARTTLS is the right way to secure PCEP with TLS. Perhaps this =
argument
> was already had at some point and this draft is the result, but if so
> then at a bare minimum it needs rationale explaining why STARTTLS was
> chosen over alternatives, and text that addresses weaknesses and
> mitigations associated with STARTTLS processing, in particular the
> possibility and relative ease of downgrade attacks.
>=20
> The obvious alternative would be to not use STARTTLS and simply =
allocate
> another TCP port for PCEP-over-TLS. This avoids complicating the PCE
> protocol and introducing the potential for downgrade attacks based on
> STARTTLS. PCE is used to convey critical path-determination =
information
> in carrier networks, among other things. That it's not fully
> authenticated and encrypted in all cases already is an unfortunate
> legacy of a bygone era. Ideally operators should move as quickly as
> possible to secure PCEP and aim to entirely remove the unsecure form.
> STARTTLS serves a weaker goal of "opportunistic" security, which, =
while
> it has its uses, makes little sense for PCE compared to simply
> deprecating the unsecured version.

Thanks for the review. Regarding your major concern, let me try to give =
you and the Routing ADs the context for the use of the STARTTLS command. =
In the original versions of the draft we followed the proposal you =
suggest, with a dedicated port for the PCEPS protocol. Here you go the =
part of the -00 version (just after WG adoption, the last one proposing =
a dedicated port) regarding this point:

8<=E2=80=94
3.1.  TCP ports

   Since PCEP can operate either with or without TLS, it is necessary
   for the PCEP speaker to indicate whether it wants to set up a TLS
   connection or not.  There are two main ways of achieving this:

   o  One option is to use a different port number for TLS connections
      (for example, the port 443 used for HTTPS)

   o  The other is to use the regular port number and have the PCEP
      speaker request that the PCE switch the connection to TLS using a
      protocol-specific mechanism (for example, the STARTTLS for mail
      and news protocols)

   To avoid requiring a specific PCEP extension to request TLS, this
   document proposes the usage of the former solution to implement
   PCEPS.

   The default destination port number for PCEPS is TCP/XXXX.

   NOTE: This port has to be agreed and registered as PCEPS with IANA.
8<=E2=80=94

During the discussions for adoption, the community decided to contact =
experts from the TSVWG group to validate this and other proposals, and =
the connection with potentially related techniques like TCP-AO and what =
was being discussed in the TCPINC WG, now included in the "Security =
Considerations". During these discussions, those experts were extremely =
wary of the dedicated port approach, and the final decision was to move =
towards the STARTTLS approach. You have the complete record of the =
debate in the list archives, but I am including a excerpt of it below:

8<=E2=80=94

On 7/1/2014 7:45 AM, Diego R. Lopez wrote:
> On 30 Jun 2014, at 18:28 , Joe Touch <[e-mail] =
<mailto:[e-mail]>> wrote:
>>>=20
>>> We are not proposing to use STARTTLS because, after discussing the
>>> different options for doing so in PCEP, we believe including it =
would
>>> translate into a change of the PCEP protocol:
>>> (1) against the original commitment of not changing it
>>> (2) would translate into a much longer adoption by implementations
>>=20
>> I don't understand or agree with either position. STARTTLS does not =
change the protocol; it precedes it.
>>=20
>> The complex mechanism below is, IMO, much less likely to be =
successfuly adopted than STARTTLS, which is widely used.
>=20
> As far as I know (RFC 2595, RFC 3207, RFC 4217, RFC 6120, RFC 2830,
> RFC 4642)

RFC4217 doesn't appear to use STARTTLS.
RFC6120 just refers completely back to RFC2595.

Section 2.1 of RFC2830 is a good example of performing STARTTLS in a =
non-plaintext command/response protocol (LDAP), and how simple it can =
and should be.

I now see your concern, but RFC2830 provides a great example of a very =
simple way to extend a protocol to address this issue. This further =
ensures that the security state (secure vs. not) is integrated within =
the protocol, so the protocol itself can disable commands if needed when =
security isn't available.

FWIW, Section 7 of RFC2595 gives a good summary of reasons why using a =
separate security port should be discouraged.

Joe


> STARTTLS is directly applicable to communication protocols
> based on plain-text command/response protocols. PCEP does not follow
> this model, so STARTTLS should become a new message or an object in =
the
> Open message. Both options imply changes in the PCEP protocol that =
look
> more complex than the suggested mechanism (or a dedicated port, if you
> pay attention to the discussion shared in the original message by Qin)


>=20
> Be goode,
>=20
>>=20
>> Joe
>>=20
>>>=20
>>> Be goode,
>>>=20
>>> On 28 Jun 2014, at 06:35 , Joe Touch <[e-mail] =
<mailto:[e-mail]>> wrote:
>>>=20
>>>> Hi,
>>>>=20
>>>> On 6/24/2014 4:03 AM, Qin Wu wrote:
>>>>> Hi, Joe:
>>>>> Sorry for late reply.
>>>>>=20
>>>>> Authors have been discussing a mechanism to enable secure PCEP via
>>>>> TLS without making changes to the current PCEP protocol or state
>>>>> machine.
>>>>>=20
>>>>> Since having a separate port has been discouraged, we suggest the
>>>> ? following approach based on discovery mechanisms or configuration =
and
>>>>> initial transport security assessment by the peer.
>>>>>=20
>>>>> 1) A PCE (given a combination of IP address and port) only =
supports
>>>>> one type of connection, either TLS or not.
>>>>=20
>>>> I'm not sure why that needs to be the case, given STARTTLS.
>>>>=20
>>>>> Note that a different IP
>>>>> address SHOULD be used for supporting both and will be considered =
as
>>>>> different PCEs.
>>>>=20
>>>> I don't quite understand this. Different IP addresses should be =
different PCEs anyway. If you want to support both encrypted and =
non-encrypted, why not use the existing TLS mechanism for that - =
STARTTLS?
>>>>=20
>>>>> 2) The PCC MAY discover whether the PCE is willing to connect,
>>>>> requires TLS or not via any of the discovery mechanisms.
>>>>=20
>>>> That seems reasonable, but doesn't answer why a PCE needs to =
support only one type of connection. The discovery could indicate =
"either" and let the client decide, e.g., if both are supported (again, =
via STARTTLS)
>>>>=20
>>>>> 3) When connecting to a PCE that enforces TLS, the PCC MUST start =
a
>>>>> TLS connection prior to any exchange of PCEP messages.
>>>>=20
>>>> Isn't that already what happens if TLS-only is used?
>>>>=20
>>>>> Any PCEP message
>>>>> received out of an appropriate TLS context will be rejected by the =
PCE
>>>>> with a PCErr (Error-Type=3D1, Error-value=3D3, TLV identifying the =
need for
>>>>> TLS) message. [Existing error message, new TLV]
>>>>=20
>>>> If non-TLS connections are rejected, then there shouldn't be any =
such messages seen AFAICT. I.e., that would be a TLS port that is =
configured to not support STARTTLS.
>>>>=20
>>>>> 4) If a PCC attempts to start a TLS connection with a PCE without
>>>>> success, it MAY attempt a further connection attempt without TLS =
on a
>>>>> different IP address if known, though that could imply a security
>>>>> degradation.
>>>>=20
>>>> I don't understand why a different address would be considered =
degraded access to the same PCE. That seems like a different PCE, as =
noted above.
>>>>=20
>>>> If you want to support degraded (non-secure) access, why not just =
support STARTTLS?
>>>>=20
>>>>> Several flows become possible this way, and discovery can be used =
to
>>>> simplify them but it is not essential for them to work. Let's =
consider them
>>>>>=20
>>>>> * With discovery (or config)
>>>>> 1.- PCC learn via discovery that the desired PCE require TLS.
>>>>> 2.- PCC initiates TCP connection and TLS handshake
>>>>> 3.- PCEP exchange within TLS context
>>>>=20
>>>> Makes sense.
>>>>=20
>>>>> ---
>>>>> 1.- PCC learn via discovery that the desired PCE does not use TLS.
>>>>> 2.- PCC initiates TCP connection
>>>>> 3.- PCEP exchange over TCP
>>>>=20
>>>> Makes sense.
>>>>=20
>>>>> * Without discovery - PCE requiring TLS
>>>>> 1.- PCC initiates TCP connection and TLS handshake
>>>>=20
>>>> Wouldn't the TLS handshake here fail? Why would the rest of the =
exchange occur?
>>>>=20
>>>>> 2.- PCEP exchange within TLS context
>>>>> ---
>>>>> 1.- PCC initiates TCP connection and attempts a PCEP OPEN message
>>>>> 2.- PCE rejects the message with a PCErr message (Error-Type=3D1, =
Error-value=3D3, TLV identifying the need for TLS(optionally))
>>>>> 3.- PCC initiates TCP connection and TLS handshake
>>>>> 4.- PCEP exchange within TLS context
>>>>=20
>>>> (see issue above)
>>>>=20
>>>>> * Without discovery - PCE not requiring TLS
>>>>> 1.- PCC initiates TCP connection
>>>>> 2.- PCEP exchange over TCP
>>>>> ---
>>>>> 1.- PCC initiates TCP connection and TLS handshake
>>>>=20
>>>> Why is this even attempted?
>>>>=20
>>>>> 2.- No TLS context established with PCE or error message received
>>>>> (optionally)
>>>>> 3.- PCC initiates TCP connection
>>>>> 4.- PCEP exchange over TCP
>>>>>=20
>>>>> What do you think of this approach?
>>>>>=20
>>>>> Also we like to point a related discussion happened on UTA mailing =
list:
>>>>> http://www.ietf.org/mail-archive/web/uta/current/msg00423.html =
<http://www.ietf.org/mail-archive/web/uta/current/msg00423.html>
>>>>=20
>>>> Those points were raised on the TSVWG list too, but fail to address =
the key issue - insecure ports are insecure. Regardless of how many =
ports we allocate, it's no longer clear we should continue to deploy new =
insecure services on the Internet.
>>>>=20
>>>> Joe
>>>>=20
>>>>>=20
>>>>> Regards,
>>>>> Authors
>>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Joe Touch [mailto:[e-mail] =
<mailto:[e-mail]>]
>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B43=E6=9C=8813=E6=97=
=A5 23:58
>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu; Diego R. Lopez; [e-mail] =
<mailto:[e-mail]>
>>>>> =E6=8A=84=E9=80=81: [e-mail] =
<mailto:[e-mail]>
>>>>> =E4=B8=BB=E9=A2=98: Re: [tcpm] Looking for advice on a draft from =
the PCE working group
>>>>>=20
>>>>> Hi, Qin,
>>>>>=20
>>>>> On 3/13/2014 3:35 AM, Qin Wu wrote:
>>>>>> Hi, Joe:
>>>>>>=20
>>>>>> It is still not clear to me when we choose the same port and when =
we
>>>>>> choose the different port if we apply TLS to different protocols,
>>>>>=20
>>>>> It's simple to determine:
>>>>>=20
>>>>>      - if you designed your service before STARTTLS, then you =
needed
>>>>>      a separate port
>>>>>=20
>>>>>      - if you are designing your port now, you don't
>>>>>=20
>>>>>> Take SMTP, POP3,IMAP as examples:
>>>>> ...
>>>>>> It looks to me when we apply SSL to SMTP,POP3,IMAP, then SMTP, =
POP3
>>>>>> and IMAP with SSL support(i.e.,SMTPS,POP3S,IMAPS)
>>>>>>=20
>>>>>> Will usually choose the different ports.
>>>>>>=20
>>>>>> The same rule above is also applied to HTTP when we apply SSL to
>>>>>> HTTP(i.e., HTTPS).
>>>>>=20
>>>>> All of the above are good examples of the first part of the rule.
>>>>>=20
>>>>> Note that we have other assignments that now would be declined, =
because we've learned to do better. E.g., there would not be a POP2 or =
POP3 because we would expect POP to indicate the protocol version =
in-band. We also no longer assign multiple names for the same service, =
as was done for http/www, nor do we now assign multiple ports for the =
same service (80, 8080), nor do we now assign ports for development =
purposes  (http-dev).
>>>>>=20
>>>>> We've learned to do better.
>>>>>=20
>>>>> Joe
>>>>>=20
>>>=20


8<=E2=80=94

So we decided to go STARTTLS a-la-LDAP, so to say.=20

> Minor Issues:
>=20
> * Section 3.3: "A RECOMMENDED value for StartTLSWait timer is 60
> seconds." This seems like a very long time to wait for an initial =
reply
> on an already-established TCP connection.

This value was proposed to be of the order of magnitude of the KeepAlive =
PCEP timer (recommended to be of 30 seconds in RFC 5440) Since the =
StartTLS message is required to happen before any other message, it is =
not possible to rely on the timer negotiation during the Open message =
exchange. I agree the value looks very long, and we are open to any =
suggestion on this, either as recommending a concrete value or by =
recommending an interval (between 5 and 30 secs?)

> * Section 3.2, fifth paragraph (beginning with "A PCEP speaker
> receiving..."):
>=20
> This paragraph states: "A PCEP speaker receiving any other message =
apart
> from StartTLS, open, or PCErr MUST treat it as an unexpected =
message..."
>=20
> As written this is confusing and seems to imply that no other PCEP
> messages can ever be sent. It looks like this is meant to be scoped to
> the context of the first message sent/received on session initiation?

You are completely right. It should read: =E2=80=9CA PCEP speaker =
receiving as first message any other message apart
from StartTLS, Open, or PCErr MUST treat it as an unexpected message=E2=80=
=A6"

It is corrected in the new version I am editing right now.

> * Section 8.6
>=20
> The subsection titles of Section 8 have been taken from Section 8 of =
RFC
> 5440, but Section 8.6 here is called "Impact on Network Operations"
> while in RFC 5440 it's called "Impact on Network Operation". Funnily
> enough, that final "s" makes a difference. Without it, the section
> refers to an impact on the functioning of the network itself. With it,
> it would usually be taken to refer to impact on human operations and
> management procedures.
>=20
> It looks correct to say that the mechanism of this draft should not
> significantly impact the functioning of the network. On the other =
hand,
> it certainly does impact operations and management procedures, as =
staff
> have to develop policies around security requirements for PCEP within
> the organization, methods for verifying whether device security
> parameters are configured correctly, checking for unexpected =
downgrades
> to insecure sessions, etc. It would be an improvement for the document
> to address the impact of PCEPS on operational processes.

I believe all these operational policy aspects are discussed in the =
other subsections of section 8, and therefore making a explicit mention =
to them under 8.6 would be enough. BTW, in order to be consistent to RFC =
5440 I have deleted the =E2=80=9Cs=E2=80=9D in the title of the =
section...

> Nits:
>=20
> Sec 3.1, first paragraph:
> OLD
>    The steps involved in the PCEPS establishment consists of following
>    successive steps:
> NEW
>    The steps involved in establishing a PCEPS session are as follows:
> END

Corrected.

> Sec 3.4, Step 3:
> s/Any attempt of initiate a TLS/Any attempt to initiate a TLS/

Corrected as well.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [e-mail]
Tel:    [phone]
Mobile: [phone]
----------------------------------


--Apple-Mail=_9FEB5268-98BA-4654-BECA-5C16B7883EF6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Hi Dan,<div class=3D""><br class=3D""></div><div =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 11 =
May 2017, at 14:31 , Dan Frost &lt;<a href=3D"mailto:[e-mail]" =
class=3D"">[e-mail]</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><br =
class=3D"">Hello,<br class=3D""><br class=3D"">I have been selected as =
the Routing Directorate reviewer for this draft.<br class=3D"">The =
Routing Directorate seeks to review all routing or routing-related<br =
class=3D"">drafts as they pass through IETF last call and IESG review, =
and<br class=3D"">sometimes on special request. The purpose of the =
review is to provide<br class=3D"">assistance to the Routing ADs. For =
more information about the Routing<br class=3D"">Directorate, please =
see<br class=3D""><a =
href=3D"http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir" =
class=3D"">http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir</a><br =
class=3D""><br class=3D"">Although these comments are primarily for the =
use of the Routing ADs, it<br class=3D"">would be helpful if you could =
consider them along with any other IETF<br class=3D"">Last Call comments =
that you receive, and strive to resolve them through<br =
class=3D"">discussion or by updating the draft.<br class=3D""><br =
class=3D"">Document: draft-ietf-pce-pceps-12<br class=3D"">Reviewer: Dan =
Frost<br class=3D"">Review Date: 2017-05-11<br class=3D"">IETF LC End =
Date:&nbsp;<br class=3D"">Intended Status: Standards Track<br =
class=3D""><br class=3D"">Summary:<br class=3D""><br class=3D"">I have =
significant concerns about this document and recommend that the<br =
class=3D"">Routing ADs discuss these issues further with the authors.<br =
class=3D""><br class=3D"">Comments:<br class=3D""><br class=3D"">This =
document proposes to add a STARTTLS mechanism to the PCE protocol.<br =
class=3D"">If this basic approach is accepted, then the document is in =
good shape.<br class=3D"">It's clear, complete, and straightforward. The =
question is whether<br class=3D"">mandating STARTTLS is actually a good =
idea.<br class=3D""><br class=3D"">Major Issues:<br class=3D""><br =
class=3D"">My main concern with this document is that it takes as given =
that<br class=3D"">STARTTLS is the right way to secure PCEP with TLS. =
Perhaps this argument<br class=3D"">was already had at some point and =
this draft is the result, but if so<br class=3D"">then at a bare minimum =
it needs rationale explaining why STARTTLS was<br class=3D"">chosen over =
alternatives, and text that addresses weaknesses and<br =
class=3D"">mitigations associated with STARTTLS processing, in =
particular the<br class=3D"">possibility and relative ease of downgrade =
attacks.<br class=3D""><br class=3D"">The obvious alternative would be =
to not use STARTTLS and simply allocate<br class=3D"">another TCP port =
for PCEP-over-TLS. This avoids complicating the PCE<br class=3D"">protocol=
 and introducing the potential for downgrade attacks based on<br =
class=3D"">STARTTLS. PCE is used to convey critical path-determination =
information<br class=3D"">in carrier networks, among other things. That =
it's not fully<br class=3D"">authenticated and encrypted in all cases =
already is an unfortunate<br class=3D"">legacy of a bygone era. Ideally =
operators should move as quickly as<br class=3D"">possible to secure =
PCEP and aim to entirely remove the unsecure form.<br class=3D"">STARTTLS =
serves a weaker goal of "opportunistic" security, which, while<br =
class=3D"">it has its uses, makes little sense for PCE compared to =
simply<br class=3D"">deprecating the unsecured version.<br =
class=3D""></div></blockquote><div class=3D""><br class=3D""></div><div =
class=3D"">Thanks for the review. Regarding your major concern, let me =
try to give you and the Routing ADs the context for the use of the =
STARTTLS command. In the original versions of the draft we followed the =
proposal you suggest, with a dedicated port for the PCEPS protocol. Here =
you go the part of the -00 version (just after WG adoption, the last one =
proposing a dedicated port) regarding this point:</div><div class=3D""><br=
 class=3D""></div><div class=3D"">8&lt;=E2=80=94</div><div class=3D""><div=
 style=3D"margin: 0px; font-family: Monaco;" class=3D"">3.1.&nbsp; TCP =
ports</div><div style=3D"margin: 0px; font-family: Monaco; min-height: =
15px;" class=3D""><br class=3D""></div><div style=3D"margin: 0px; =
font-family: Monaco;" class=3D"">&nbsp;&nbsp; Since PCEP can operate =
either with or without TLS, it is necessary</div><div style=3D"margin: =
0px; font-family: Monaco;" class=3D"">&nbsp;&nbsp; for the PCEP speaker =
to indicate whether it wants to set up a TLS</div><div style=3D"margin: =
0px; font-family: Monaco;" class=3D"">&nbsp;&nbsp; connection or =
not.&nbsp; There are two main ways of achieving this:</div><div =
style=3D"margin: 0px; font-family: Monaco; min-height: 15px;" =
class=3D""><br class=3D""></div><div style=3D"margin: 0px; font-family: =
Monaco;" class=3D"">&nbsp;&nbsp; o&nbsp; One option is to use a =
different port number for TLS connections</div><div style=3D"margin: =
0px; font-family: Monaco;" class=3D"">&nbsp; &nbsp; &nbsp; (for example, =
the port 443 used for HTTPS)</div><div style=3D"margin: 0px; =
font-family: Monaco; min-height: 15px;" class=3D""><br =
class=3D""></div><div style=3D"margin: 0px; font-family: Monaco;" =
class=3D"">&nbsp;&nbsp; o&nbsp; The other is to use the regular port =
number and have the PCEP</div><div style=3D"margin: 0px; font-family: =
Monaco;" class=3D"">&nbsp; &nbsp; &nbsp; speaker request that the PCE =
switch the connection to TLS using a</div><div style=3D"margin: 0px; =
font-family: Monaco;" class=3D"">&nbsp; &nbsp; &nbsp; protocol-specific =
mechanism (for example, the STARTTLS for mail</div><div style=3D"margin: =
0px; font-family: Monaco;" class=3D"">&nbsp; &nbsp; &nbsp; and news =
protocols)</div><div style=3D"margin: 0px; font-family: Monaco; =
min-height: 15px;" class=3D""><br class=3D""></div><div style=3D"margin: =
0px; font-family: Monaco;" class=3D"">&nbsp;&nbsp; To avoid requiring a =
specific PCEP extension to request TLS, this</div><div style=3D"margin: =
0px; font-family: Monaco;" class=3D"">&nbsp;&nbsp; document proposes the =
usage of the former solution to implement</div><div style=3D"margin: =
0px; font-family: Monaco;" class=3D"">&nbsp;&nbsp; PCEPS.</div><div =
style=3D"margin: 0px; font-family: Monaco; min-height: 15px;" =
class=3D""><br class=3D""></div><div style=3D"margin: 0px; font-family: =
Monaco;" class=3D"">&nbsp;&nbsp; The default destination port number for =
PCEPS is TCP/XXXX.</div><div style=3D"margin: 0px; font-family: Monaco; =
min-height: 15px;" class=3D""><br class=3D""></div><div style=3D"margin: =
0px; font-family: Monaco;" class=3D"">&nbsp;&nbsp; NOTE: This port has =
to be agreed and registered as PCEPS with IANA.</div></div><div =
class=3D"">8&lt;=E2=80=94</div><div class=3D""><br class=3D""></div><div =
class=3D"">During the discussions for adoption, the community decided to =
contact experts from the TSVWG group to validate this and other =
proposals, and the connection with potentially related techniques like =
TCP-AO and what was being discussed in the TCPINC WG, now included in =
the "Security Considerations". During these discussions, those experts =
were extremely wary of the dedicated port approach, and the final =
decision was to move towards the STARTTLS approach. You have the =
complete record of the debate in the list archives, but I am including a =
excerpt of it below:</div><div class=3D""><br class=3D""></div><div =
class=3D"">8&lt;=E2=80=94</div><div class=3D""><br class=3D""></div><div =
class=3D""><span style=3D"font-family: Monaco;" class=3D"">On 7/1/2014 =
7:45 AM, Diego R. Lopez wrote:</span><br style=3D"font-family: Monaco;" =
class=3D""><blockquote type=3D"cite" style=3D"font-family: Monaco;" =
class=3D"">On 30 Jun 2014, at 18:28 , Joe Touch &lt;<a =
href=3D"mailto:[e-mail]" class=3D"">[e-mail]</a>&gt; wrote:<br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D""><br class=3D"">We are not proposing to use STARTTLS because, =
after discussing the<br class=3D"">different options for doing so in =
PCEP, we believe including it would<br class=3D"">translate into a =
change of the PCEP protocol:<br class=3D"">(1) against the original =
commitment of not changing it<br class=3D"">(2) would translate into a =
much longer adoption by implementations<br class=3D""></blockquote><br =
class=3D"">I don't understand or agree with either position. STARTTLS =
does not change the protocol; it precedes it.<br class=3D""><br =
class=3D"">The complex mechanism below is, IMO, much less likely to be =
successfuly adopted than STARTTLS, which is widely used.<br =
class=3D""></blockquote><br class=3D"">As far as I know (RFC 2595, RFC =
3207, RFC 4217, RFC 6120, RFC 2830,<br class=3D"">RFC 4642)<br =
class=3D""></blockquote><br style=3D"font-family: Monaco;" =
class=3D""><span style=3D"font-family: Monaco;" class=3D"">RFC4217 =
doesn't appear to use STARTTLS.</span><br style=3D"font-family: Monaco;" =
class=3D""><span style=3D"font-family: Monaco;" class=3D"">RFC6120 just =
refers completely back to RFC2595.</span><br style=3D"font-family: =
Monaco;" class=3D""><br style=3D"font-family: Monaco;" class=3D""><span =
style=3D"font-family: Monaco;" class=3D"">Section 2.1 of RFC2830 is a =
good example of performing STARTTLS in a non-plaintext command/response =
protocol (LDAP), and how simple it can and should be.</span><br =
style=3D"font-family: Monaco;" class=3D""><br style=3D"font-family: =
Monaco;" class=3D""><span style=3D"font-family: Monaco;" class=3D"">I =
now see your concern, but RFC2830 provides a great example of a very =
simple way to extend a protocol to address this issue. This further =
ensures that the security state (secure vs. not) is integrated within =
the protocol, so the protocol itself can disable commands if needed when =
security isn't available.</span><br style=3D"font-family: Monaco;" =
class=3D""><br style=3D"font-family: Monaco;" class=3D""><span =
style=3D"font-family: Monaco;" class=3D"">FWIW, Section 7 of RFC2595 =
gives a good summary of reasons why using a separate security port =
should be discouraged.</span><br style=3D"font-family: Monaco;" =
class=3D""><br style=3D"font-family: Monaco;" class=3D""><span =
style=3D"font-family: Monaco;" class=3D"">Joe</span><br =
style=3D"font-family: Monaco;" class=3D""><br style=3D"font-family: =
Monaco;" class=3D""><br style=3D"font-family: Monaco;" =
class=3D""><blockquote type=3D"cite" style=3D"font-family: Monaco;" =
class=3D"">STARTTLS is directly applicable to communication protocols<br =
class=3D"">based on plain-text command/response protocols. PCEP does not =
follow<br class=3D"">this model, so STARTTLS should become a new message =
or an object in the<br class=3D"">Open message. Both options imply =
changes in the PCEP protocol that look<br class=3D"">more complex than =
the suggested mechanism (or a dedicated port, if you<br class=3D"">pay =
attention to the discussion shared in the original message by Qin)<br =
class=3D""></blockquote><br style=3D"font-family: Monaco;" class=3D""><br =
style=3D"font-family: Monaco;" class=3D""><blockquote type=3D"cite" =
style=3D"font-family: Monaco;" class=3D""><br class=3D"">Be goode,<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D"">Joe<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D""><br class=3D"">Be goode,<br class=3D""><br class=3D"">On 28 =
Jun 2014, at 06:35 , Joe Touch &lt;<a href=3D"mailto:[e-mail]" =
class=3D"">[e-mail]</a>&gt; wrote:<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">Hi,<br class=3D""><br =
class=3D"">On 6/24/2014 4:03 AM, Qin Wu wrote:<br class=3D""><blockquote =
type=3D"cite" class=3D"">Hi, Joe:<br class=3D"">Sorry for late reply.<br =
class=3D""><br class=3D"">Authors have been discussing a mechanism to =
enable secure PCEP via<br class=3D"">TLS without making changes to the =
current PCEP protocol or state<br class=3D"">machine.<br class=3D""><br =
class=3D"">Since having a separate port has been discouraged, we suggest =
the<br class=3D""></blockquote>? following approach based on discovery =
mechanisms or configuration and<br class=3D""><blockquote type=3D"cite" =
class=3D"">initial transport security assessment by the peer.<br =
class=3D""><br class=3D"">1) A PCE (given a combination of IP address =
and port) only supports<br class=3D"">one type of connection, either TLS =
or not.<br class=3D""></blockquote><br class=3D"">I'm not sure why that =
needs to be the case, given STARTTLS.<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">Note that a different =
IP<br class=3D"">address SHOULD be used for supporting both and will be =
considered as<br class=3D"">different PCEs.<br class=3D""></blockquote><br=
 class=3D"">I don't quite understand this. Different IP addresses should =
be different PCEs anyway. If you want to support both encrypted and =
non-encrypted, why not use the existing TLS mechanism for that - =
STARTTLS?<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">2) The PCC MAY discover whether the PCE is willing to =
connect,<br class=3D"">requires TLS or not via any of the discovery =
mechanisms.<br class=3D""></blockquote><br class=3D"">That seems =
reasonable, but doesn't answer why a PCE needs to support only one type =
of connection. The discovery could indicate "either" and let the client =
decide, e.g., if both are supported (again, via STARTTLS)<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">3) When =
connecting to a PCE that enforces TLS, the PCC MUST start a<br =
class=3D"">TLS connection prior to any exchange of PCEP messages.<br =
class=3D""></blockquote><br class=3D"">Isn't that already what happens =
if TLS-only is used?<br class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D"">Any PCEP message<br class=3D"">received out of =
an appropriate TLS context will be rejected by the PCE<br class=3D"">with =
a PCErr (Error-Type=3D1, Error-value=3D3, TLV identifying the need =
for<br class=3D"">TLS) message. [Existing error message, new TLV]<br =
class=3D""></blockquote><br class=3D"">If non-TLS connections are =
rejected, then there shouldn't be any such messages seen AFAICT. I.e., =
that would be a TLS port that is configured to not support STARTTLS.<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">4) If a =
PCC attempts to start a TLS connection with a PCE without<br =
class=3D"">success, it MAY attempt a further connection attempt without =
TLS on a<br class=3D"">different IP address if known, though that could =
imply a security<br class=3D"">degradation.<br class=3D""></blockquote><br=
 class=3D"">I don't understand why a different address would be =
considered degraded access to the same PCE. That seems like a different =
PCE, as noted above.<br class=3D""><br class=3D"">If you want to support =
degraded (non-secure) access, why not just support STARTTLS?<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">Several =
flows become possible this way, and discovery can be used to<br =
class=3D""></blockquote>simplify them but it is not essential for them =
to work. Let's consider them<br class=3D""><blockquote type=3D"cite" =
class=3D""><br class=3D"">* With discovery (or config)<br class=3D"">1.- =
PCC learn via discovery that the desired PCE require TLS.<br =
class=3D"">2.- PCC initiates TCP connection and TLS handshake<br =
class=3D"">3.- PCEP exchange within TLS context<br =
class=3D""></blockquote><br class=3D"">Makes sense.<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">---<br class=3D"">1.- =
PCC learn via discovery that the desired PCE does not use TLS.<br =
class=3D"">2.- PCC initiates TCP connection<br class=3D"">3.- PCEP =
exchange over TCP<br class=3D""></blockquote><br class=3D"">Makes =
sense.<br class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">*=
 Without discovery - PCE requiring TLS<br class=3D"">1.- PCC initiates =
TCP connection and TLS handshake<br class=3D""></blockquote><br =
class=3D"">Wouldn't the TLS handshake here fail? Why would the rest of =
the exchange occur?<br class=3D""><br class=3D""><blockquote type=3D"cite"=
 class=3D"">2.- PCEP exchange within TLS context<br class=3D"">---<br =
class=3D"">1.- PCC initiates TCP connection and attempts a PCEP OPEN =
message<br class=3D"">2.- PCE rejects the message with a PCErr message =
(Error-Type=3D1, Error-value=3D3, TLV identifying the need for =
TLS(optionally))<br class=3D"">3.- PCC initiates TCP connection and TLS =
handshake<br class=3D"">4.- PCEP exchange within TLS context<br =
class=3D""></blockquote><br class=3D"">(see issue above)<br class=3D""><br=
 class=3D""><blockquote type=3D"cite" class=3D"">* Without discovery - =
PCE not requiring TLS<br class=3D"">1.- PCC initiates TCP connection<br =
class=3D"">2.- PCEP exchange over TCP<br class=3D"">---<br class=3D"">1.- =
PCC initiates TCP connection and TLS handshake<br =
class=3D""></blockquote><br class=3D"">Why is this even attempted?<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">2.- No =
TLS context established with PCE or error message received<br =
class=3D"">(optionally)<br class=3D"">3.- PCC initiates TCP =
connection<br class=3D"">4.- PCEP exchange over TCP<br class=3D""><br =
class=3D"">What do you think of this approach?<br class=3D""><br =
class=3D"">Also we like to point a related discussion happened on UTA =
mailing list:<br class=3D""><a =
href=3D"http://www.ietf.org/mail-archive/web/uta/current/msg00423.html" =
class=3D"">http://www.ietf.org/mail-archive/web/uta/current/msg00423.html<=
/a><br class=3D""></blockquote><br class=3D"">Those points were raised =
on the TSVWG list too, but fail to address the key issue - insecure =
ports are insecure. Regardless of how many ports we allocate, it's no =
longer clear we should continue to deploy new insecure services on the =
Internet.<br class=3D""><br class=3D"">Joe<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D""><br class=3D"">Regards,<br=
 class=3D"">Authors<br class=3D"">-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6=
-----<br class=3D"">=E5=8F=91=E4=BB=B6=E4=BA=BA: Joe Touch [<a =
href=3D"mailto:[e-mail]" class=3D"">mailto:[e-mail]</a>]<br =
class=3D"">=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B43=E6=9C=8813=
=E6=97=A5 23:58<br class=3D"">=E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu; Diego =
R. Lopez;&nbsp;<a href=3D"mailto:[e-mail]" =
class=3D"">[e-mail]</a><br class=3D"">=E6=8A=84=E9=80=81:&nbsp;<a =
href=3D"mailto:[e-mail]" =
class=3D"">[e-mail]</a><br class=3D"">=E4=B8=BB=
=E9=A2=98: Re: [tcpm] Looking for advice on a draft from the PCE working =
group<br class=3D""><br class=3D"">Hi, Qin,<br class=3D""><br =
class=3D"">On 3/13/2014 3:35 AM, Qin Wu wrote:<br class=3D""><blockquote =
type=3D"cite" class=3D"">Hi, Joe:<br class=3D""><br class=3D"">It is =
still not clear to me when we choose the same port and when we<br =
class=3D"">choose the different port if we apply TLS to different =
protocols,<br class=3D""></blockquote><br class=3D"">It's simple to =
determine:<br class=3D""><br class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- =
if you designed your service before STARTTLS, then you needed<br =
class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a separate port<br class=3D""><br=
 class=3D"">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- if you are designing your =
port now, you don't<br class=3D""><br class=3D""><blockquote type=3D"cite"=
 class=3D"">Take SMTP, POP3,IMAP as examples:<br =
class=3D""></blockquote>...<br class=3D""><blockquote type=3D"cite" =
class=3D"">It looks to me when we apply SSL to SMTP,POP3,IMAP, then =
SMTP, POP3<br class=3D"">and IMAP with SSL =
support(i.e.,SMTPS,POP3S,IMAPS)<br class=3D""><br class=3D"">Will =
usually choose the different ports.<br class=3D""><br class=3D"">The =
same rule above is also applied to HTTP when we apply SSL to<br =
class=3D"">HTTP(i.e., HTTPS).<br class=3D""></blockquote><br =
class=3D"">All of the above are good examples of the first part of the =
rule.<br class=3D""><br class=3D"">Note that we have other assignments =
that now would be declined, because we've learned to do better. E.g., =
there would not be a POP2 or POP3 because we would expect POP to =
indicate the protocol version in-band. We also no longer assign multiple =
names for the same service, as was done for http/www, nor do we now =
assign multiple ports for the same service (80, 8080), nor do we now =
assign ports for development purposes &nbsp;(http-dev).<br class=3D""><br =
class=3D"">We've learned to do better.<br class=3D""><br class=3D"">Joe<br=
 class=3D""><br class=3D""></blockquote></blockquote><br =
class=3D""></blockquote></blockquote></blockquote></div><div =
class=3D""><br class=3D""></div><div class=3D"">8&lt;=E2=80=94</div><div =
class=3D""><br class=3D""></div><div class=3D"">So we decided to go =
STARTTLS a-la-LDAP, so to say.&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D""><div><blockquote type=3D"cite" =
class=3D""><div class=3D"">Minor Issues:</div><div class=3D""><br =
class=3D"">* Section 3.3: "A RECOMMENDED value for StartTLSWait timer is =
60<br class=3D"">seconds." This seems like a very long time to wait for =
an initial reply<br class=3D"">on an already-established TCP =
connection.<br class=3D""></div></blockquote><div><br =
class=3D""></div><div>This value was proposed to be of the order of =
magnitude of the KeepAlive PCEP timer (recommended to be of 30 seconds =
in RFC 5440) Since the StartTLS message is required to happen before any =
other message, it is not possible to rely on the timer negotiation =
during the Open message exchange. I agree the value looks very long, and =
we are open to any suggestion on this, either as recommending a concrete =
value or by recommending an interval (between 5 and 30 secs?)</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">* =
Section 3.2, fifth paragraph (beginning with "A PCEP speaker<br =
class=3D"">receiving..."):<br class=3D""><br class=3D"">This paragraph =
states: "A PCEP speaker receiving any other message apart<br =
class=3D"">from StartTLS, open, or PCErr MUST treat it as an unexpected =
message..."<br class=3D""><br class=3D"">As written this is confusing =
and seems to imply that no other PCEP<br class=3D"">messages can ever be =
sent. It looks like this is meant to be scoped to<br class=3D"">the =
context of the first message sent/received on session initiation?<br =
class=3D""></div></blockquote><div><br class=3D""></div><div>You are =
completely right. It should read: =E2=80=9CA PCEP speaker receiving as =
first message any other message apart</div><div class=3D"">from =
StartTLS, Open, or PCErr MUST treat it as an unexpected =
message=E2=80=A6"</div><div><br class=3D""></div><div>It is corrected in =
the new version I am editing right now.</div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">* Section 8.6<br class=3D""><br =
class=3D"">The subsection titles of Section 8 have been taken from =
Section 8 of RFC<br class=3D"">5440, but Section 8.6 here is called =
"Impact on Network Operations"<br class=3D"">while in RFC 5440 it's =
called "Impact on Network Operation". Funnily<br class=3D"">enough, that =
final "s" makes a difference. Without it, the section<br class=3D"">refers=
 to an impact on the functioning of the network itself. With it,<br =
class=3D"">it would usually be taken to refer to impact on human =
operations and<br class=3D"">management procedures.<br class=3D""><br =
class=3D"">It looks correct to say that the mechanism of this draft =
should not<br class=3D"">significantly impact the functioning of the =
network. On the other hand,<br class=3D"">it certainly does impact =
operations and management procedures, as staff<br class=3D"">have to =
develop policies around security requirements for PCEP within<br =
class=3D"">the organization, methods for verifying whether device =
security<br class=3D"">parameters are configured correctly, checking for =
unexpected downgrades<br class=3D"">to insecure sessions, etc. It would =
be an improvement for the document<br class=3D"">to address the impact =
of PCEPS on operational processes.<br =
class=3D""></div></blockquote><div><br class=3D""></div><div>I believe =
all these operational policy aspects are discussed in the other =
subsections of section 8, and therefore making a explicit mention to =
them under 8.6 would be enough. BTW, in order to be consistent to RFC =
5440 I have deleted the =E2=80=9Cs=E2=80=9D in the title of the =
section...</div><div><br class=3D""></div><blockquote type=3D"cite" =
class=3D""><div class=3D"">Nits:<br class=3D""><br class=3D"">Sec 3.1, =
first paragraph:<br class=3D"">OLD<br class=3D""> &nbsp;&nbsp;&nbsp;The =
steps involved in the PCEPS establishment consists of following<br =
class=3D""> &nbsp;&nbsp;&nbsp;successive steps:<br class=3D"">NEW<br =
class=3D""> &nbsp;&nbsp;&nbsp;The steps involved in establishing a PCEPS =
session are as follows:<br class=3D"">END<br =
class=3D""></div></blockquote><div><br =
class=3D""></div><div>Corrected.</div><div><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D"">Sec =
3.4, Step 3:<br class=3D"">s/Any attempt of initiate a TLS/Any attempt =
to initiate a TLS/<br class=3D""></div></blockquote><br =
class=3D""></div><div>Corrected as well.</div><div><br =
class=3D""></div><div>Be goode,</div><div><br class=3D""></div><div =
apple-content-edited=3D"true" class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">--<br class=3D"">"Esta vez no fallaremos, Doctor Infierno"<br =
class=3D""><br class=3D"">Dr Diego R. Lopez<br class=3D"">Telefonica =
I+D<br class=3D""><a href=3D"http://people.tid.es/diego.lopez/" =
class=3D"">http://people.tid.es/diego.lopez/</a><br class=3D""><br =
class=3D"">e-mail: [e-mail]<br class=3D"">Tel: =
&nbsp; &nbsp;[phone]<br class=3D"">Mobile: [phone]<br =
class=3D"">----------------------------------</div>

</div>
<br class=3D""></div></div></body></html>=

--Apple-Mail=_9FEB5268-98BA-4654-BECA-5C16B7883EF6--

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição