Subject: Re: [Pce] PCE WG Last Call - draft-ietf-pce-pceps-04

From: Cyril Margaria <[email-masked]>
Date: Sun, 1 Nov 2015 13:07:53 -0500

I have reviewed the id.

I think the document describes well the TLS  procedure.

I have the following comments/questions on the nonTLS support: what should
a PCE peer  do when the error code "pcep startTLS failure" and error value
3 or 4.

For error value 3 i believe closing the connection shoud be done
For error code 4 (ok without TLS) should the peer:

A)Continue without TLS at all

B) close and reconnect without using tls

A) would require more descrption of that case. B) would require the peer to
retry without tls or require a reconfiguration. The reconnect introduces
more states (how long to keep retrying withiut tls,... etc)

I think those points should be specified.

Best regards
Cyril
On Oct 8, 2015 18:57, "JP Vasseur (jvasseur)" <[email-masked]> wrote:

> Dear WG,
>
> This starts a 2-week WG Last Call on draft-ietf-pce-pceps-04, ending on
> Oct 23 at noon ET. Please send your comments to the authors and copy the
> list.
>
> Thanks.
>
> JP, Julien and Jon.
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
>

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 2 Nov 2015 07:46:57 +0530

Hi Cyril,

Thanks for your review and comments. Much Appreciated.

Let me sink up with my co-authors and reply to you with a proposed text.

Regards,
Dhruv

On Mon, Nov 2, 2015 at 2:07 AM, Cyril Margaria <[email-masked]>
wrote:

> A) would require more descrption of that case. B) would require the peer
> to retry without tls or require a reconfiguration. The reconnect introduces

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 3 Nov 2015 00:52:10 +0000

Hi,

Indeed. Thanks for the comments Cyril.

I have just uploaded a new version with a few cosmetic changes to deal with the expiration deadline. We’ll discuss how to address your comments and have a new version anytime soon.

Be goode,

On 2 Nov 2015, at 11:16 , Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:

Hi Cyril,

Regards,
Dhruv

On Mon, Nov 2, 2015 at 2:07 AM, Cyril Margaria <[email-masked]<mailto:[email-masked]>> wrote:

I have reviewed the id.

I have the following comments/questions on the nonTLS support: what should a PCE peer  do when the error code "pcep startTLS failure" and error value 3 or 4.

A) would require more descrption of that case. B) would require the peer to retry without tls or require a reconfiguration. The reconnect introduces more states (how long to keep retrying withiut tls,... etc)

Best regards
Cyril

On Oct 8, 2015 18:57, "JP Vasseur (jvasseur)" <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG,

This starts a 2-week WG Last Call on draft-ietf-pce-pceps-04, ending on Oct 23 at noon ET. Please send your comments to the authors and copy the list.

Thanks.

JP, Julien and Jon.

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

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

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 3 Nov 2015 06:32:15 +0000

Hi Cyril, WG,

Here are the proposed changes  –

OLD:
   If the PCEP speaker supports PCEPS but cannot establish a TLS
   connection for some reason (e.g. the certificate server is not
   responding) it MUST return a PCErr message with Error-Type set to xx
   (TBA by IANA) (PCEP StartTLS failure) and Error-value set to:

   o  3 (not without TLS) if it is not willing to exchange PCEP messages
      without the solicited TLS connection.

   o  4 (ok without TLS) if it is willing to exchange PCEP messages
      without the solicited TLS connection.
NEW:
   If the PCEP speaker supports PCEPS but cannot establish a TLS
   connection for some reason (e.g. the certificate server is not
   responding) it MUST return a PCErr message with Error-Type set to xx
   (TBA by IANA) (PCEP StartTLS failure) and Error-value set to:

   o  3 (not without TLS) if it is not willing to exchange PCEP messages
      without the solicited TLS connection and it MUST close the TCP
      session.

   o  4 (ok without TLS) if it is willing to exchange PCEP messages
      without the solicited TLS connection and it MUST close the TCP
      session. The peer MAY choose to re-establish PCEP session
      without TLS next.

We can also clarify the behavior for error-value 1 and 2 as well –

OLD:
   A PCEP speaker receiving a StartTLS message after any other PCEP
   exchange has taken place (by receiving or sending any other messages
   from either side) MUST treat it as an unexpected message and reply
   with a PCErr message with Error-Type set to xx (TBA by IANA)(PCEP
   StartTLS failure) and Error-value set to 1 (reception of StartTLS
   after any PCEP exchange).  A PCEP speaker receives any other message
   apart from StartTLS or PCErr MUST treat it as an unexpected message
   and reply with a PCErr message with Error-Type set to xx (TBA by
   IANA)(PCEP StartTLS failure) and Error-value set to 2 (reception of
   non-StartTLS or non-PCErr message).
NEW:
   A PCEP speaker receiving a StartTLS message after any other PCEP
   exchange has taken place (by receiving or sending any other messages
   from either side) MUST treat it as an unexpected message and reply
   with a PCErr message with Error-Type set to xx (TBA by IANA)(PCEP
   StartTLS failure) and Error-value set to 1 (reception of StartTLS
   after any PCEP exchange) and MUST close the TCP
   session.  A PCEP speaker receives any other message
   apart from StartTLS or PCErr MUST treat it as an unexpected message
   and reply with a PCErr message with Error-Type set to xx (TBA by
   IANA)(PCEP StartTLS failure) and Error-value set to 2 (reception of
   non-StartTLS or non-PCErr message) and MUST close the TCP session.

Thanks you for your review!

Regards,
Dhruv

From: Pce [mailto:[email-masked]] On Behalf Of DIEGO LOPEZ GARCIA
Sent: 03 November 2015 09:52
To: Dhruv Dhody
Cc: [email-masked]; Cyril Margaria
Subject: Re: [Pce] PCE WG Last Call - draft-ietf-pce-pceps-04

Hi,

Be goode,

Hi Cyril,

Regards,
Dhruv

Thanks.

JP, Julien and Jon.

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

---

From: t.p. <[email-masked]>
Date: Wed, 4 Nov 2015 17:55:14 +0000

s.3 At first, I was unsure whether or not both parties sent a StartTLS.
"The StartTLS message is a PCEP message sent by a PCC to a PCE and by
   a PCE to a PCC " suggests both
"Once the TCP connection has been successfully established, the first
   message sent by the PCC to the PCE or  by the PCE to the PCC MUST be
a
   StartTLS message " suggests only one.
Section 3.3 makes it clearer that both send it.  This is fine but I am
unaware of any other protocol where this happens so I would suggest
/or/and/ in that second sentence and expanding the earlier sentence
OLD
   2.  Initiating the TLS Procedures by the StartTLS message.
NEW
   2.  Initiating the TLS Procedures by the StartTLS message from PCE to
PCC and from PCC to PCE.

I focus on this because I was also looking to see which became TLS
Client.  TLS is asymmetric, designed to authenticate a (HTTP) server to
a client.  Netconf (and SNMP), which I know better, struggled with this
because the key for Netconf is to authenticate the client to the server,
which TLS does not do so well. Posts on the TLS list suggest that there
are very few implementations of TLS client authentication, rather
something else is done once the secure channel has been established.

So, do you care who is TLS client and who TLS server?  It will be
interesting to see a security review of this.

In passing, RFC7465 prohibits RC4 with TLS so I would think it unlikely
that
"SHOULD support  TLS_RSA_WITH_RC4_128_SHA"  will be acceptable.

Tom Petch

----- Original Message -----
> On Oct 8, 2015 18:57, "JP Vasseur (jvasseur)"
<[email-masked]<mailto:[email-masked]>> wrote:
> Dear WG,
>
> This starts a 2-week WG Last Call on draft-ietf-pce-pceps-04, ending
on Oct 23 at noon ET. Please send your comments to the authors and copy
the list.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Mon, 9 Nov 2015 08:23:45 +0000

Hi Tom,

Thanks for the review. We will update the draft text addressing your comments and those we received form Cyril. Some notes inline below

On 4 Nov 2015, at 19:55 , t.p. <[email-masked]<mailto:[email-masked]>> wrote:

DRL> You are right in the ambiguity and we will correct it as you suggest.

DRL> I’d not say there are few implementations, but that client authentication is not commonly employed, especially in the web environment where other mechanisms are preferred, like using a TLS connection based on server authentication to retrieve password credentials from the user… As far as I can tell, TLS is only asymmetric in this requirement for authentication of both peers, as the crypto exchanges become essentially equal if client authentication is required.

DRL> What we had in mind was that the natural approach taking into account the structure of PCEP was to have the PCC peer acting as client and the PCE acting as server. We’ll include a requirement in section 3.2 on this.  I do not see any security issue here, but we could certainly request the UTA WG to make a review. I’d say this completely falls under their area of interest.

DRL> Good catch. It will ve deleted in the coming version.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

---

From: t.petch <[email-masked]>
Date: Sat, 14 Nov 2015 12:47:49 +0000

Picking up on the one point about the asymmetry of TLS, I agree that the
crypto is symmetric once the master key has been created.  The weakness
is the underlying assumption, at least when SSL started, that there is a
human sitting at the client end who can respond to messages about the
certificate being invalid (something my MUA offers me at least once a
day for the past week, for reasons I cannot divine) or any other hiccup
in the process prior to the establishment of the master key  You can
argue that almost all users haven't a clue about certificates and almost
all systems are configured by default to suppress any such messages, but
the technology is there for those who want adequate security, at least
when there is a human at the TLS client.

What I worry about with such as PCE is getting an adequate check of the
authentication, with a focus on how to validate certificates.  As I said
before, I have been involved with this with I-Ds on SNMP and Netconf and
have seen much arise, even at the IESG stage, with some comments that to
me seem misplaced; but as they are DISCUSS, they have to be taken
seriously.

So I value the early intervention of the Security Directorate to try and
fix such issues sooner, and so cheaper, rather than later.

Tom Petch

----- Original Message -----
From: "DIEGO LOPEZ GARCIA" <[email-masked]>
To: <[email-masked]>
Sent: Monday, November 09, 2015 8:23 AM
Subject: Re: [Pce] PCE WG Last Call - draft-ietf-pce-pceps-04

> Hi Tom,
>
> Thanks for the review. We will update the draft text addressing your
comments and those we received form Cyril. Some notes inline below
>
> On 4 Nov 2015, at 19:55 , t.p.
<[email-masked]<mailto:[email-masked]>> wrote:
> DRL> I’d not say there are few implementations, but that client
authentication is not commonly employed, especially in the web
environment where other mechanisms are preferred, like using a TLS
connection based on server authentication to retrieve password
credentials from the user… As far as I can tell, TLS is only asymmetric
in this requirement for authentication of both peers, as the crypto
exchanges become essentially equal if client authentication is required.
> DRL> What we had in mind was that the natural approach taking into
account the structure of PCEP was to have the PCC peer acting as client
and the PCE acting as server. We’ll include a requirement in section 3.2
on this.  I do not see any security issue here, but we could certainly
request the UTA WG to make a review. I’d say this completely falls under
their area of interest.
> 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

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 18 Nov 2015 22:32:53 +0000

Hi Tom,

Precisely the fact that there will be no humans behind is the reason why the checks on the certificates are detailed in Section 3.4. These checks are inspired on the RADSEC mechanisms (RFC 6614) since the type of TLS client-server interactions are similar.

And let me insist that I’d directly ask the UTA WG about this. My only question is about procedure: shall we wait till we finish the last call period? Shall we perform it as part of the last call process? What do our chairs think?

Be goode,

On 14 Nov 2015, at 13:47 , t.petch <[email-masked]<mailto:[email-masked]>> wrote:

Tom Petch

----- Original Message -----
From: "DIEGO LOPEZ GARCIA" <[email-masked]<mailto:[email-masked]>>
To: <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 09, 2015 8:23 AM
Subject: Re: [Pce] PCE WG Last Call - draft-ietf-pce-pceps-04

Hi Tom,

On 4 Nov 2015, at 19:55 , t.p.
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

s.3 At first, I was unsure whether or not both parties sent a
StartTLS.
 2.  Initiating the TLS Procedures by the StartTLS message from PCE
to
PCC and from PCC to PCE.

DRL> You are right in the ambiguity and we will correct it as you
suggest.

I focus on this because I was also looking to see which became TLS
Client.  TLS is asymmetric, designed to authenticate a (HTTP) server
to
a client.  Netconf (and SNMP), which I know better, struggled with
this
because the key for Netconf is to authenticate the client to the
server,
which TLS does not do so well. Posts on the TLS list suggest that
there
are very few implementations of TLS client authentication, rather
something else is done once the secure channel has been established.

In passing, RFC7465 prohibits RC4 with TLS so I would think it
unlikely
that
"SHOULD support  TLS_RSA_WITH_RC4_128_SHA"  will be acceptable.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

Dr Diego R. Lopez
Telefonica I+D

---

From: Julien Meuric <[email-masked]>
Date: Thu, 19 Nov 2015 10:25:39 +0100

Hola Diego,

The WG LC was started for a 2-week period: you can consider it finished.

Finished or not, you are expected to resolve all the received comments 
and publish an update accordingly, so as to have the I-D ready to be 
sent to the IESG. Feel free to proceed as soon as you are able to.

Cheers,

Julien

Nov. 18, 2015 - [email-masked]:
>
> And let me insist that I’d directly ask the UTA WG about this. My only 
> question is about procedure: shall we wait till we finish the last 
> call period? Shall we perform it as part of the last call process? 
> What do our chairs think?

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 19 Nov 2015 09:37:00 +0000

Hi Julien, 

We have the update ready to go. 

Quoting from Tom's mail - 

> So I value the early intervention of the 
> Security Directorate to try and fix such 
> issues sooner, and so cheaper, rather than later.

We were wondering if it would be worthwhile (and allowed by the process) to request for an early Sec-Dir review while the control is still with the WG? 

Regards,
Dhruv

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Julien Meuric
> Sent: 19 November 2015 14:56
> To: DIEGO LOPEZ GARCIA
> Cc: [email-masked]
> Finished or not, you are expected to resolve all the received comments and
> publish an update accordingly, so as to have the I-D ready to be sent to the
> IESG. Feel free to proceed as soon as you are able to.
> 
> Cheers,
> 
> Julien
> 
> 
> > And let me insist that I'd directly ask the UTA WG about this. My only

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 19 Nov 2015 09:41:17 +0000

Hi Julien,

I finished a version addressing the comments and correcting some nits the authors found while addressing the comments. We are making a final review and will upload it this evening (CET)

Be goode,

On 19 Nov 2015, at 10:25 , Julien Meuric <[email-masked]<mailto:[email-masked]>> wrote:

Hola Diego,

Finished or not, you are expected to resolve all the received comments and publish an update accordingly, so as to have the I-D ready to be sent to the IESG. Feel free to proceed as soon as you are able to.

Cheers,

Julien

Nov. 18, 2015 - [email-masked]<mailto:[email-masked]>:

Dr Diego R. Lopez
Telefonica I+D

---

From: Julien Meuric <[email-masked]>
Date: Thu, 19 Nov 2015 11:19:15 +0100

Hi Dhruv,

If you expect some updates after a review from the Security Directorate, 
then the sooner the better. If you feel it useful, we will proceed when 
your next revision is published.

Thanks for being proactive here,

Julien

---

From: t.petch <[email-masked]>
Date: Thu, 19 Nov 2015 15:35:04 +0000

---- Original Message -----
From: "Julien Meuric" <[email-masked]>
To: "Dhruv Dhody" <[email-masked]>; "DIEGO LOPEZ GARCIA"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 19, 2015 10:19 AM
> Thanks for being proactive here,

Two sorts of things that the Security Directorate might comment on

- the use of compression, where the I-D says
"
     *  Support for and negotiation of compression is OPTIONAL.
"
whereas on 26th April 2014 (not 2015) the TLS WG said
"       We have strong confirmation of consensus to remove compression
from TLS 1.3.   The Editor is requested to make the appropriate changes
to the draft on github.

Joe"

This came about because of loopholes that had been found with the use of
compression; my sense is that compression has gone the way of RC4 (but
that there is no I-D to say so).

- fingerprints, where the I-D says
"Implementations MUST support SHA-256 as the hash algorithm for  the
fingerprint."

which seems reasonable but there is an outstanding DISCUSS on another
I-D which says
"(3) Consider zmap. When this is deployed, what'll be the
effect of surveys that fingerprint all of the devices on the
visible Internet who implement this protocol? Did the WG
consider that?"

to which my response is I don't understand; but it is a DISCUSS so
someone will in due course.  Like PCEPS, the reference is to the
fingerprint of a certificate stored in a device for client/server
authentication with TLS.  Will this I-D get the same DISCUSS?  I don't
see why not (but then I don't understand the DISCUSS:-(

Tom Petch

> > We were wondering if it would be worthwhile (and allowed by the
process) to request for an early Sec-Dir review while the control is
still with the WG?

---

From: t.petch <[email-masked]>
Date: Fri, 20 Nov 2015 14:52:37 +0000

Julien

I am happy for the I-D to progress to IETF LC.  I will be interested to
see a review by the Security Directorate and most interested to see what
happens when the Security and Transport ADs review it:-)

Meanwhile, some editorial thoughts to be picked up at some stage.

IANA are being asked to exercise their PCE skills! You are asking for
the allocation of more than one number but use TBA as the placeholder
for every number; this requires someone to understand the protocol to
know which number goes where.  Other editors use TBA1, TBA2,   ... TBA23
etc which I think IANA would find clearer.

IANA will also have to work out which registry is being updated, which
is probably a more straightforward task.

SHA-256 has no reference, and is ambiguous.  TLS uses SHA256 as its term
but another list is currently updating its use of SHA to SHA-2 and is
using SHA-2-256 on the grounds that SHA-3 is around and so SHA-3-256
will be too so how do you tell the two apart when all you have is
SHA256?  I find SHA-2-256 ugly but take their point so think it should
be used here - and given a normative reference.

s.3.1
/this procedure update/this procedure updates/

/The details of processing including backward compatibility is discussed
/The details of processing including backward compatibility are
discussed /

s.3.2
/including the open message/including the Open message/

/session must be closed /the session must be closed /

/A PCEP speaker receives any other message /A PCEP speaker receiving any
other message /

/(e.g. the certificate server is not responding)  /
Is this a refererence to OCSP?  I am not used to there being certificate
servers, unless they are CAs or providing CRLs.

s.3.3
/a PCEP session between the PCEP peers/

Given the context, would /PCEPS session/ be appropriate?

/form the PCEP peer /from the PCEP peer /

Figure 3; based on the preceding text, I would expect there to be a
PCErr message from PCC to PCE since it has received an Open message and
not a StartTLS

Figure 3
/open message/Open message/

s.3.5
"fingerprint of the presented client certificate"
Why only the client?  I would have expected this to apply to the server
as well.

Tom Petch

---

From: Julien Meuric <[email-masked]>
Date: Fri, 20 Nov 2015 16:25:35 +0100

Hi Tom,

Thank you for your valuable feedback. I think your comments could be 
addressed along with those to come from shepherd's review, unless the 
authors prefer to do an update before.

I have just contacted the Security Directorate without specifying a 
fixed version number, which should bring reviewers on the latest at 
review time.

To be continued,

Julien