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

[Julien Meuric]

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


Nov. 20, 2015 - ie...@btconnect.com:

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

- Original Message -
From: "Julien Meuric" 
To: "Dhruv Dhody" ; "DIEGO LOPEZ GARCIA"

Cc: 
Sent: Thursday, November 19, 2015 10:19 AM


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

Nov. 19, 2015 - dhruv.dh...@huawei.com:

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:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: 19 November 2015 14:56

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 - diego.r.lo...@telefonica.com:


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?




___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[t . petch]

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

- Original Message -
From: "Julien Meuric" 
To: "Dhruv Dhody" ; "DIEGO LOPEZ GARCIA"

Cc: 
Sent: Thursday, November 19, 2015 10:19 AM

> 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
>
> Nov. 19, 2015 - dhruv.dh...@huawei.com:
> > 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:pce-boun...@ietf.org] On Behalf Of Julien Meuric
> >> Sent: 19 November 2015 14:56
> >>
> >> 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 - diego.r.lo...@telefonica.com:
> >>>
> >>> 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?

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[t . petch]

 Original Message -
From: "Julien Meuric" 
To: "Dhruv Dhody" ; "DIEGO LOPEZ GARCIA"

Cc: 
Sent: Thursday, November 19, 2015 10:19 AM
> 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,

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













>
> Julien
>
>
> Nov. 19, 2015 - dhruv.dh...@huawei.com:
> > 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:pce-boun...@ietf.org] On Behalf Of Julien Meuric
> >> Sent: 19 November 2015 14:56
> >>
> >> 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 - diego.r.lo...@telefonica.com:
> >>>
> >>> 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?
> >>
> >> ___
> >> Pce mailing list
> >> Pce@ietf.org
> >> https://www.ietf.org/mailman/listinfo/pce
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Julien Meuric]

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


Nov. 19, 2015 - dhruv.dh...@huawei.com:

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:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: 19 November 2015 14:56

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 - diego.r.lo...@telefonica.com:


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?


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[DIEGO LOPEZ GARCIA]

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 
mailto:julien.meu...@orange.com>> wrote:

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 - 
diego.r.lo...@telefonica.com:

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?


--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lo...@telefonica.com
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
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Dhruv Dhody]

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:pce-boun...@ietf.org] On Behalf Of Julien Meuric
> Sent: 19 November 2015 14:56
> To: DIEGO LOPEZ GARCIA
> Cc: pce@ietf.org
> Subject: Re: [Pce] PCE WG Last Call - draft-ietf-pce-pceps-04
> 
> 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 - diego.r.lo...@telefonica.com:
> >
> > 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?
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Julien Meuric]

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 - diego.r.lo...@telefonica.com:


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?


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[DIEGO LOPEZ GARCIA]

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 
mailto:ie...@btconnect.com>> wrote:

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" 
mailto:diego.r.lo...@telefonica.com>>
To: mailto:pce@ietf.org>>
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.
mailto:daedu...@btconnect.com><mailto:daedu...@btconnect.com>>
 wrote:

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.

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.

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.

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

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.

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.

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

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.

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

[t . petch]

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" 
To: 
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.
mailto:daedu...@btconnect.com>> wrote:
>
> 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.
>
> 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.
>
> 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.
>
> So, do you care who is TLS client and who TLS server?  It will be
> interesting to see a security review of this.
>
> 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.
>
> 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.
>
> DRL> Good catch. It will ve deleted in the coming version.
>
> Be goode,
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
> Telefonica I+D
> http://people.tid.es/diego.lopez/
>
> e-mail: diego.r.lo...@telefonica.com
> 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 i

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

[DIEGO LOPEZ GARCIA]

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. 
mailto:daedu...@btconnect.com>> wrote:

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.

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.

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.

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

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.

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.

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

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lo...@telefonica.com
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
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[t . p .]

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)"
mailto:jvass...@cisco.com>> 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.
>
>

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Dhruv Dhody]

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:pce-boun...@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA
Sent: 03 November 2015 09:52
To: Dhruv Dhody
Cc: pce@ietf.org; Cyril Margaria
Subject: Re: [Pce] PCE WG Last Call - draft-ietf-pce-pceps-04

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 
mailto:dhruv.i...@gmail.com>> wrote:

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 
mailto:cyril.marga...@gmail.com>> wrote:
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)" 
mailto:jvass...@cisco.com>> 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
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce

--
"Esta vez no fallar

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

[DIEGO LOPEZ GARCIA]

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 
mailto:dhruv.i...@gmail.com>> wrote:

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 
mailto:cyril.marga...@gmail.com>> wrote:

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)" 
mailto:jvass...@cisco.com>> 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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce


___
Pce mailing list
Pce@ietf.org
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: diego.r.lo...@telefonica.com
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
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Dhruv Dhody]

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 
wrote:

> 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)"  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
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce
>>
>>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Cyril Margaria]

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)"  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
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[JP Vasseur (jvasseur)]

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.

smime.p7s
Description: S/MIME cryptographic signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce