Re: [Pce] I-D Action: draft-ietf-pce-pceps-16.txt

[Dhruv Dhody]

Hi All, 

I have posted an update with all the changes that have been agreed on. 

There is an open point under discussion with Eric, we could make another update 
if needed. 

Thanks for all the comments! 

Regards,
Dhruv   

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-
> dra...@ietf.org
> Sent: 08 August 2017 23:38
> To: i-d-annou...@ietf.org
> Cc: pce@ietf.org
> Subject: [Pce] I-D Action: draft-ietf-pce-pceps-16.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Path Computation Element WG of the IETF.
> 
> Title   : Secure Transport for PCEP
> Authors : Diego R. Lopez
>   Oscar Gonzalez de Dios
>   Qin Wu
>   Dhruv Dhody
>   Filename: draft-ietf-pce-pceps-16.txt
>   Pages   : 25
>   Date: 2017-08-08
> 
> Abstract:
>The Path Computation Element Communication Protocol (PCEP) defines
>the mechanisms for the communication between a Path Computation
>Client (PCC) and a Path Computation Element (PCE), or among PCEs.
>This document describes the usage of Transport Layer Security (TLS)
>to enhance PCEP security, hence the PCEPS acronym proposed for it.
>The additional security mechanisms are provided by the transport
>protocol supporting PCEP, and therefore they do not affect the
>flexibility and extensibility of PCEP.
> 
>This document updates RFC 5440 in regards to the PCEP initialization
>phase procedures.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-pce-pceps-16
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-pceps-16
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pceps-16
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] PCEP as an SDN controller protocol?

[Dhruv Dhody]

Hi John, Igor,

I tried to answer that question in another thread. Here is my response -

Jon’s original mail asked the question where do we stop? My answer would be -
- at "configuration"
- at use of PCEP for work beyond TE
- kitchen sink (as Jeff put it)
- harm to the network (non-backward compatible etc)
- incompatible with framework in TEAS

I sure we can add more points to the list!

Thanks!
Dhruv

From: Igor Bryskin [mailto:i_brys...@yahoo.com]
Sent: 08 August 2017 23:16
To: jdr...@juniper.net; Dhruv Dhody ; Thomas Nadeau 
; Robert Varga 
Cc: pce@ietf.org; pce-cha...@ietf.org
Subject: Re: [Pce] PCEP as an SDN controller protocol?

Excellent question, John. Wonder myself. Let's ask Gert. He is very good at 
defining thibgs they are not :-)

Yours also irresoectively,
igor
Sent from Yahoo Mail on 
Android

On Tue, Aug 8, 2017 at 1:32 PM, John E Drake
> wrote:
Hi,

So, what exactly is it that PCEP should not do?

Yours Irrespectively,

John


> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On 
> Behalf Of Dhruv Dhody
> Sent: Tuesday, August 8, 2017 11:21 AM
> To: Thomas Nadeau >; 
> Robert Varga >
> Cc: pce@ietf.org; 
> pce-cha...@ietf.org
> Subject: Re: [Pce] PCEP as an SDN controller protocol?
>
> Hi Robert, Thomas,
>
> See inline...
>
> > -Original Message-
> > From: Thomas Nadeau 
> > [mailto:tnad...@lucidvision.com]
> > Sent: 08 August 2017 05:09
> > To: Robert Varga >
> > Cc: Dhruv Dhody >; 
> > olivier.dug...@orange.com;
> > Jonathan Hardwick 
> > >;
> >  pce@ietf.org;
> > pce- cha...@ietf.org
> > Subject: Re: [Pce] PCEP as an SDN controller protocol?
> >
> >
> > > On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga 
> > > > wrote:
> > >
> > > On 07/08/17 13:10, Dhruv Dhody wrote:
> > >> Hi Oliver,
> > >
> > > Hello Dhruv,
> > >
> > >> Sorry for a late response and thanks for engaging on this topic.
> > >> With this response I would try to clear up some misconceptions,
> > >> some context and counter-viewpoint.  Please see inline…
> > >>
> > >>
> > >>
> > >> *From:*Pce [mailto:pce-boun...@ietf.org] 
> > >> *On Behalf Of
> > >> *olivier.dug...@orange.com
> > >> *Sent:* 27 July 2017 23:42
> > >> *To:* Jonathan Hardwick 
> > >> >;
> > >> pce@ietf.org
> > >> *Cc:* pce-cha...@ietf.org
> > >> *Subject:* Re: [Pce] PCEP as an SDN controller protocol?
> > >>
> > >>
> > >>
> > >> Hi Jon,
> > >>
> > >> Thanks to open this thread. As many of you have already said, PCEP
> > >> is already an SDN controller protocol since the work on stateful mode.
> > >> But, IMHO, recent drafts doesn't go into the right direction. Let
> > >> me
> > explain:
> > >>
> > >> 1/ On PCE-LS. Of course there is already plenty of solution to
> > >> learn the topology e.g. listen to IGP protocol, BGP-LS ... But,
> > >> dont forget that the primary goal of PCE is to compute a path on a
> > >> topology. This mean that the PCE need a graph which represent the
> network topology.
> > >> This graph is extract from the TED, later fulfil by the topology
> > >> learning mechanism. Why PCE-LS and other equivalent mechanism that
> > >> collect topology information on a node by node basis ? Simply
> > >> because you are unable to guarantee that the graph you extract from
> > >> what you learn is accurate. Indeed, a node known its interfaces
> > >> through what the administrator configure in this node. But, it
> > >> doesn't know exactly to which neighbour it is connected while there
> > >> is a protocol
> > between node.
> > >> In IP network, it is the role of the IGP. if there is an error in
> > >> the node configuration, the IGP adjacency doesn't fire up and thus,
> > >> IGP or BGP-LS will not report this link betwenn the two nodes. The
> > >> graph is not complete, but not wrong. So when you learn the
> > >> topology from the IGP you could guarantee that the link between two
> > >> nodes corresponds effectively to what is really configured and
> > >> physically connected. If there is no protocol between the nodes,
> > >> you can't guarantee that what the node announce through PCEP-LS is
> accurate.
> > >> E.g. Node A report Link A-B and node B report Link B-A instead of
> > >> Link B-C and Link B-C instead of Link B-A 

[Pce] I-D Action: draft-ietf-pce-pceps-16.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : Secure Transport for PCEP
Authors : Diego R. Lopez
  Oscar Gonzalez de Dios
  Qin Wu
  Dhruv Dhody
Filename: draft-ietf-pce-pceps-16.txt
Pages   : 25
Date: 2017-08-08

Abstract:
   The Path Computation Element Communication Protocol (PCEP) defines
   the mechanisms for the communication between a Path Computation
   Client (PCC) and a Path Computation Element (PCE), or among PCEs.
   This document describes the usage of Transport Layer Security (TLS)
   to enhance PCEP security, hence the PCEPS acronym proposed for it.
   The additional security mechanisms are provided by the transport
   protocol supporting PCEP, and therefore they do not affect the
   flexibility and extensibility of PCEP.

   This document updates RFC 5440 in regards to the PCEP initialization
   phase procedures.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pceps-16
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pceps-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pceps-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [Pce] PCEP as an SDN controller protocol?

[Igor Bryskin]

Excellent question, John. Wonder myself. Let's ask Gert. He is very good at 
defining thibgs they are not :-)
Yours also irresoectively,igor

Sent from Yahoo Mail on Android 
 
  On Tue, Aug 8, 2017 at 1:32 PM, John E Drake wrote:   Hi,

So, what exactly is it that PCEP should not do?

Yours Irrespectively,

John


> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
> Sent: Tuesday, August 8, 2017 11:21 AM
> To: Thomas Nadeau ; Robert Varga 
> Cc: pce@ietf.org; pce-cha...@ietf.org
> Subject: Re: [Pce] PCEP as an SDN controller protocol?
> 
> Hi Robert, Thomas,
> 
> See inline...
> 
> > -Original Message-
> > From: Thomas Nadeau [mailto:tnad...@lucidvision.com]
> > Sent: 08 August 2017 05:09
> > To: Robert Varga 
> > Cc: Dhruv Dhody ; olivier.dug...@orange.com;
> > Jonathan Hardwick ; pce@ietf.org;
> > pce- cha...@ietf.org
> > Subject: Re: [Pce] PCEP as an SDN controller protocol?
> >
> >
> > > On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga  wrote:
> > >
> > > On 07/08/17 13:10, Dhruv Dhody wrote:
> > >> Hi Oliver,
> > >
> > > Hello Dhruv,
> > >
> > >> Sorry for a late response and thanks for engaging on this topic.
> > >> With this response I would try to clear up some misconceptions,
> > >> some context and counter-viewpoint.  Please see inline…
> > >>
> > >>
> > >>
> > >> *From:*Pce [mailto:pce-boun...@ietf.org] *On Behalf Of
> > >> *olivier.dug...@orange.com
> > >> *Sent:* 27 July 2017 23:42
> > >> *To:* Jonathan Hardwick ;
> > >> pce@ietf.org
> > >> *Cc:* pce-cha...@ietf.org
> > >> *Subject:* Re: [Pce] PCEP as an SDN controller protocol?
> > >>
> > >>
> > >>
> > >> Hi Jon,
> > >>
> > >> Thanks to open this thread. As many of you have already said, PCEP
> > >> is already an SDN controller protocol since the work on stateful mode.
> > >> But, IMHO, recent drafts doesn't go into the right direction. Let
> > >> me
> > explain:
> > >>
> > >> 1/ On PCE-LS. Of course there is already plenty of solution to
> > >> learn the topology e.g. listen to IGP protocol, BGP-LS ... But,
> > >> dont forget that the primary goal of PCE is to compute a path on a
> > >> topology. This mean that the PCE need a graph which represent the
> network topology.
> > >> This graph is extract from the TED, later fulfil by the topology
> > >> learning mechanism. Why PCE-LS and other equivalent mechanism that
> > >> collect topology information on a node by node basis ? Simply
> > >> because you are unable to guarantee that the graph you extract from
> > >> what you learn is accurate. Indeed, a node known its interfaces
> > >> through what the administrator configure in this node. But, it
> > >> doesn't know exactly to which neighbour it is connected while there
> > >> is a protocol
> > between node.
> > >> In IP network, it is the role of the IGP. if there is an error in
> > >> the node configuration, the IGP adjacency doesn't fire up and thus,
> > >> IGP or BGP-LS will not report this link betwenn the two nodes. The
> > >> graph is not complete, but not wrong. So when you learn the
> > >> topology from the IGP you could guarantee that the link between two
> > >> nodes corresponds effectively to what is really configured and
> > >> physically connected. If there is no protocol between the nodes,
> > >> you can't guarantee that what the node announce through PCEP-LS is
> accurate.
> > >> E.g. Node A report Link A-B and node B report Link B-A instead of
> > >> Link B-C and Link B-C instead of Link B-A due to a wrong manual
> > >> configuration. You obtain a wrong topology and thus a wrong graph
> > >> as you invert two links between two nodes. An you have no way to
> > >> check it. So, in any case, and it is true for Optical / Transport
> > >> network, you MUST run an IGP in your network to be sure that the
> > >> topology is accurate and so to guarantee that the PCE work on a
> > >> correct graph. A PCE working on a bad topology is painful. So,
> > >> because you must run an IGP in your network, fulfil the PCE TED by
> > >> listen the IGP or BGP-LS is the best solution. IMHO, PCE WG must
> > >> not work on alternative
> > solution to learn topology.
> > >>
> > >> [[Dhruv Dhody]] When PCEP-LS is deployed in SDN mode (node by node
> > >> basis), the node could run any protocol on the link to make
> > >> verification. Adrian also mentioned in his reply, that device could
> > >> be running, some form of discovery/verification protocol such as
> > >> LMP, LLDP or even IGP on the per link basis. Each node is free to
> > >> run any local mechanism to make sure that the link information is 
> > >> correct.
> > >> The PCEP-LS extension is written in such a way that it could be
> > >> used in any mode and independent of what the device choose to do.
> > >> The PCEP-LS also support “remote data” (data a node would have
> > 

Re: [Pce] PCEP as an SDN controller protocol?

[John E Drake]

Hi,

So, what exactly is it that PCEP should not do?

Yours Irrespectively,

John


> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
> Sent: Tuesday, August 8, 2017 11:21 AM
> To: Thomas Nadeau ; Robert Varga 
> Cc: pce@ietf.org; pce-cha...@ietf.org
> Subject: Re: [Pce] PCEP as an SDN controller protocol?
> 
> Hi Robert, Thomas,
> 
> See inline...
> 
> > -Original Message-
> > From: Thomas Nadeau [mailto:tnad...@lucidvision.com]
> > Sent: 08 August 2017 05:09
> > To: Robert Varga 
> > Cc: Dhruv Dhody ; olivier.dug...@orange.com;
> > Jonathan Hardwick ; pce@ietf.org;
> > pce- cha...@ietf.org
> > Subject: Re: [Pce] PCEP as an SDN controller protocol?
> >
> >
> > > On Aug 7, 2017:7:13 PM, at 7:13 PM, Robert Varga  wrote:
> > >
> > > On 07/08/17 13:10, Dhruv Dhody wrote:
> > >> Hi Oliver,
> > >
> > > Hello Dhruv,
> > >
> > >> Sorry for a late response and thanks for engaging on this topic.
> > >> With this response I would try to clear up some misconceptions,
> > >> some context and counter-viewpoint.  Please see inline…
> > >>
> > >>
> > >>
> > >> *From:*Pce [mailto:pce-boun...@ietf.org] *On Behalf Of
> > >> *olivier.dug...@orange.com
> > >> *Sent:* 27 July 2017 23:42
> > >> *To:* Jonathan Hardwick ;
> > >> pce@ietf.org
> > >> *Cc:* pce-cha...@ietf.org
> > >> *Subject:* Re: [Pce] PCEP as an SDN controller protocol?
> > >>
> > >>
> > >>
> > >> Hi Jon,
> > >>
> > >> Thanks to open this thread. As many of you have already said, PCEP
> > >> is already an SDN controller protocol since the work on stateful mode.
> > >> But, IMHO, recent drafts doesn't go into the right direction. Let
> > >> me
> > explain:
> > >>
> > >> 1/ On PCE-LS. Of course there is already plenty of solution to
> > >> learn the topology e.g. listen to IGP protocol, BGP-LS ... But,
> > >> dont forget that the primary goal of PCE is to compute a path on a
> > >> topology. This mean that the PCE need a graph which represent the
> network topology.
> > >> This graph is extract from the TED, later fulfil by the topology
> > >> learning mechanism. Why PCE-LS and other equivalent mechanism that
> > >> collect topology information on a node by node basis ? Simply
> > >> because you are unable to guarantee that the graph you extract from
> > >> what you learn is accurate. Indeed, a node known its interfaces
> > >> through what the administrator configure in this node. But, it
> > >> doesn't know exactly to which neighbour it is connected while there
> > >> is a protocol
> > between node.
> > >> In IP network, it is the role of the IGP. if there is an error in
> > >> the node configuration, the IGP adjacency doesn't fire up and thus,
> > >> IGP or BGP-LS will not report this link betwenn the two nodes. The
> > >> graph is not complete, but not wrong. So when you learn the
> > >> topology from the IGP you could guarantee that the link between two
> > >> nodes corresponds effectively to what is really configured and
> > >> physically connected. If there is no protocol between the nodes,
> > >> you can't guarantee that what the node announce through PCEP-LS is
> accurate.
> > >> E.g. Node A report Link A-B and node B report Link B-A instead of
> > >> Link B-C and Link B-C instead of Link B-A due to a wrong manual
> > >> configuration. You obtain a wrong topology and thus a wrong graph
> > >> as you invert two links between two nodes. An you have no way to
> > >> check it. So, in any case, and it is true for Optical / Transport
> > >> network, you MUST run an IGP in your network to be sure that the
> > >> topology is accurate and so to guarantee that the PCE work on a
> > >> correct graph. A PCE working on a bad topology is painful. So,
> > >> because you must run an IGP in your network, fulfil the PCE TED by
> > >> listen the IGP or BGP-LS is the best solution. IMHO, PCE WG must
> > >> not work on alternative
> > solution to learn topology.
> > >>
> > >> [[Dhruv Dhody]] When PCEP-LS is deployed in SDN mode (node by node
> > >> basis), the node could run any protocol on the link to make
> > >> verification. Adrian also mentioned in his reply, that device could
> > >> be running, some form of discovery/verification protocol such as
> > >> LMP, LLDP or even IGP on the per link basis. Each node is free to
> > >> run any local mechanism to make sure that the link information is 
> > >> correct.
> > >> The PCEP-LS extension is written in such a way that it could be
> > >> used in any mode and independent of what the device choose to do.
> > >> The PCEP-LS also support “remote data” (data a node would have
> > >> learned via other protocols as IGP
> > >> - remote nodes and links).
> > >>
> > >>
> > >>
> > >> There are *already* multiple ways to learn TED at PCE – IGP-TE,
> > >> BGP-LS, NetConf/ RestConf – Yang. The architecture allows that. The
> > >> various 

Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)

[Ben Campbell]

> On Aug 8, 2017, at 6:48 AM, Dhruv Dhody  wrote:
> 
> Hi Ben, 
> 
>> -Original Message-
>> From: Ben Campbell [mailto:b...@nostrum.com]
>> Sent: 08 August 2017 03:08
>> To: Dhruv Dhody 
>> Cc: cmarga...@juniper.net; draft-ietf-pce-pc...@ietf.org; pce@ietf.org;
>> The IESG ; pce-cha...@ietf.org
>> Subject: Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15:
>> (with DISCUSS and COMMENT)
>> 
> (snip)
 
> 
>> - 3.2: "Implementations MUST support SHA-256 as defined by [SHS] as
>>the hash algorithm for the fingerprint."
>> Do you really intend "MUST support" (meaning you have to be able to
>> handle sha-256, but could allow other hashes) vs "MUST use"?
>> 
> [[Dhruv Dhody]] Yes, additional hash algorithm MAY also be
 supported/used.
> 
 
 Is there an expectation people will use multiple hash algorithms
 side-by- side? Or is this for purposes of hash agility?
 
>>> [[Dhruv Dhody]] SHA-256 is the current mandatory hash, others might
>> become usable and useful as the technology evolves. Do you have any
>> suggested change in mind?
>>> I see RFC6614 use similar language "Implementations MUST support SHA-1
>> as the hash algorithm for the fingerprint…."
>> 
>> I guess my question is whether the intent is for implementations to be
>> able to pick any hash they want, as long as SHA-256 is an option, or do
>> you expect everyone to use SHA-256 unless that is replaced at some point
>> due to security concerns. If the former, “MUST support…” makes sense. If
>> the latter, something like “MUST  (or SHOULD) use…” with a caveat that
>> future specs might update this if SHA-256 is proven unsafe at some point
>> in the future.
>> 
> [[Dhruv Dhody]] I was incorrect in my reply before, it is the latter, as we 
> also have this text in the security considerations that explains this - 
> 
>   When using certificate fingerprints to identify PCEPS peers, any two
>   certificates that produce the same hash value will be considered the
>   same peer.  Therefore, it is important to make sure that the hash
>   function used is cryptographically uncompromised, so that attackers
>   are very unlikely to be able to produce a hash collision with a
>   certificate of their choice.  This document mandates support for
>   SHA-256 as defined by [SHS], but a later revision may demand support
>   for stronger functions if suitable attacks on it are known.
> 
> So a future revision would update the Hash function to be used. I will update 
> the text as you suggest. 
> 
>> My real concern here is interoperability—if an implementation chooses a
>> hash other than SHA-256, how does the peer know what hash to use?
>> 
> [[Dhruv Dhody]] This is a local property and does not need to be exchanged. 
> The peer provides the certificate, based on local hash function in use, the 
> hash of DER encoded certificate octets is created and compared to a local 
> fingerprint configured. 

Ah, that makes sense, thanks!  (And in any case, the question is moot based on 
the rest of your response.)

I can’t remember if I mentioned it, but I have cleared my DISCUSS position and 
entered a YES.

Thanks!

Ben.


> 
>>> 
>>> (snip)
>>> 
> 
> Regards,
> Dhruv

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

Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)

[Dhruv Dhody]

Hi Eric,

From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: 08 August 2017 18:18
To: Dhruv Dhody 
Cc: Alexey Melnikov ; draft-ietf-pce-pc...@ietf.org; 
pce@ietf.org; The IESG ; pce-cha...@ietf.org; 
cmarga...@juniper.net
Subject: Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with 
DISCUSS and COMMENT)



On Tue, Aug 8, 2017 at 4:01 AM, Dhruv Dhody 
> wrote:
Hi Eric,

From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: 07 August 2017 20:54
To: Dhruv Dhody >
Cc: Alexey Melnikov >; 
draft-ietf-pce-pc...@ietf.org; 
pce@ietf.org; The IESG 
>; 
pce-cha...@ietf.org; 
cmarga...@juniper.net

Subject: Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with 
DISCUSS and COMMENT)



On Mon, Aug 7, 2017 at 7:41 AM, Dhruv Dhody 
> wrote:
Hi Eric,

From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: 05 August 2017 22:58
To: Dhruv Dhody >
Cc: Alexey Melnikov >; 
The IESG >; 
cmarga...@juniper.net; 
draft-ietf-pce-pc...@ietf.org; 
pce@ietf.org; 
pce-cha...@ietf.org

Subject: Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with 
DISCUSS and COMMENT)



On Fri, Aug 4, 2017 at 11:41 AM, Dhruv Dhody 
> wrote:
Hi Alexey,

> -Original Message-
> From: Alexey Melnikov 
> [mailto:aamelni...@fastmail.fm]
> Sent: 03 August 2017 19:24
> To: Dhruv Dhody >; The 
> IESG >
> Cc: cmarga...@juniper.net; 
> draft-ietf-pce-pc...@ietf.org; 
> pce@ietf.org;
> pce-cha...@ietf.org
> Subject: Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15:
> (with DISCUSS and COMMENT)
>
> Hi,
>
> On Thu, Aug 3, 2017, at 02:36 PM, Dhruv Dhody wrote:
> > Hi Alexey,
> >
> > Thanks for your comments, see inline...
> >
> > > -Original Message-
> > > From: Pce [mailto:pce-boun...@ietf.org] On 
> > > Behalf Of Alexey Melnikov
> > > Sent: 03 August 2017 15:35
> > > To: The IESG >
> > > Cc: cmarga...@juniper.net; 
> > > draft-ietf-pce-pc...@ietf.org;
> > > pce@ietf.org; 
> > > pce-cha...@ietf.org
> > > Subject: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15:
> > > (with DISCUSS and COMMENT)
> > >
> > > Alexey Melnikov has entered the following ballot position for
> > > draft-ietf-pce-pceps-15: Discuss
> > > 
> > > --
> > > DISCUSS:
> > > 
> > > --
> > >
> > > I am very glad to see this document and I will be switching to "Yes"
> > > once we discuss the following issues:
> > >
> > > 1)
> > >   +-+-+ +-+-+
> > >   |PCC| |PCE|
> > >   +-+-+ +-+-+
> > > | |
> > > | StartTLS|
> > > | msg |
> > > |---  |
> > > |   \   StartTLS  |
> > > |\  msg   |
> > > | \  -|
> > > |  \/ |
> > > |  /\ |
> > > | /  >|
> > > |/|
> > > |<--  |
> > > |:TLS:| TLS Establishment
> > > |:Establishment:::| Failure
> > > | |
> > > |<| Send Error-Type TBA2
> > > |  PCErr  | Error-Value 3/4
> > > | |
> > >
> > >   Figure 2: Both PCEP Speaker supports PCEPS (strict), but cannot
> > >establish TLS
> > >
> > > Firstly, I think you also need to 

Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Tue, Aug 8, 2017 at 4:01 AM, Dhruv Dhody  wrote:

> Hi Eric,
>
>
>
> *From:* Eric Rescorla [mailto:e...@rtfm.com]
> *Sent:* 07 August 2017 20:54
> *To:* Dhruv Dhody 
> *Cc:* Alexey Melnikov ;
> draft-ietf-pce-pc...@ietf.org; pce@ietf.org; The IESG ;
> pce-cha...@ietf.org; cmarga...@juniper.net
>
> *Subject:* Re: [Pce] Alexey Melnikov's Discuss on
> draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)
>
>
>
>
>
>
>
> On Mon, Aug 7, 2017 at 7:41 AM, Dhruv Dhody 
> wrote:
>
> Hi Eric,
>
>
>
> *From:* Eric Rescorla [mailto:e...@rtfm.com]
> *Sent:* 05 August 2017 22:58
> *To:* Dhruv Dhody 
> *Cc:* Alexey Melnikov ; The IESG ;
> cmarga...@juniper.net; draft-ietf-pce-pc...@ietf.org; pce@ietf.org;
> pce-cha...@ietf.org
>
>
> *Subject:* Re: [Pce] Alexey Melnikov's Discuss on
> draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)
>
>
>
>
>
>
>
> On Fri, Aug 4, 2017 at 11:41 AM, Dhruv Dhody 
> wrote:
>
> Hi Alexey,
>
> > -Original Message-
> > From: Alexey Melnikov [mailto:aamelni...@fastmail.fm]
> > Sent: 03 August 2017 19:24
> > To: Dhruv Dhody ; The IESG 
> > Cc: cmarga...@juniper.net; draft-ietf-pce-pc...@ietf.org; pce@ietf.org;
> > pce-cha...@ietf.org
>
> > Subject: Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15:
> > (with DISCUSS and COMMENT)
> >
> > Hi,
> >
> > On Thu, Aug 3, 2017, at 02:36 PM, Dhruv Dhody wrote:
> > > Hi Alexey,
> > >
> > > Thanks for your comments, see inline...
> > >
> > > > -Original Message-
> > > > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Alexey Melnikov
> > > > Sent: 03 August 2017 15:35
> > > > To: The IESG 
> > > > Cc: cmarga...@juniper.net; draft-ietf-pce-pc...@ietf.org;
> > > > pce@ietf.org; pce-cha...@ietf.org
> > > > Subject: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15:
> > > > (with DISCUSS and COMMENT)
> > > >
> > > > Alexey Melnikov has entered the following ballot position for
> > > > draft-ietf-pce-pceps-15: Discuss
> > > > 
> > > > --
> > > > DISCUSS:
> > > > 
> > > > --
> > > >
> > > > I am very glad to see this document and I will be switching to "Yes"
> > > > once we discuss the following issues:
> > > >
> > > > 1)
> > > >   +-+-+ +-+-+
> > > >   |PCC| |PCE|
> > > >   +-+-+ +-+-+
> > > > | |
> > > > | StartTLS|
> > > > | msg |
> > > > |---  |
> > > > |   \   StartTLS  |
> > > > |\  msg   |
> > > > | \  -|
> > > > |  \/ |
> > > > |  /\ |
> > > > | /  >|
> > > > |/|
> > > > |<--  |
> > > > |:TLS:| TLS Establishment
> > > > |:Establishment:::| Failure
> > > > | |
> > > > |<| Send Error-Type TBA2
> > > > |  PCErr  | Error-Value 3/4
> > > > | |
> > > >
> > > >   Figure 2: Both PCEP Speaker supports PCEPS (strict), but cannot
> > > >establish TLS
> > > >
> > > > Firstly, I think you also need to demonstrate a case when the server
> > > > end of TLS is refusing to startTLS before trying TLS negotiation
> > > > (e.g. if it doesn't have certificate configured). In this case you
> > > > need to send PCErr in the clear. I think earlier text suggest that
> > this case is possible.
> > > >
> > > [[Dhruv Dhody]] No, the only error to StartTLS is by an implementation
> > > that does not understand the message.
> > > In case certificate is not configured we would start TLS negotiation,
> > > which would fail.
> >
> > I think you should clarify this.
> >
> > I have implemented StartTLS in both IMAP and LDAP and this is not
> > necessarily how it works there: before TLS negotiation starts it is
> > possible for the server end to reject negotiation in cleartext.
> >
>
> [[Dhruv Dhody]] Error can be added here, More on this, see reply below.
>
> > > > Secondly, does the case depicted on this picture mean that TLS was
> > > > negotiated successfully, but TLS identities were not successfully
> > verified?
> > > > (I.e. the PCErr is sent over the TLS layer). If TLS failed to
> > > > negotiate, you don't 

Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with COMMENT)

[Alexey Melnikov]

Hi,
(Top post)
I agree that the new wording is clearer.

On Tue, Aug 8, 2017, at 01:28 PM, Spencer Dawkins at IETF wrote:
> Hi, Dhruv,
> 
> On Tue, Aug 8, 2017 at 6:08 AM, Dhruv Dhody
>  wrote:>> Hi Spencer, 


>> __ __


>> *From:* Spencer Dawkins at IETF
>> [mailto:spencerdawkins.i...@gmail.com] *Sent:* 07 August 2017 21:17
>> *To:* Dhruv Dhody  *Cc:* Alexey Melnikov
>> ; cmarga...@juniper.net; draft-ietf-pce-
>> pc...@ietf.org; pce@ietf.org; The IESG ; pce-
>> cha...@ietf.org *Subject:* Re: [Pce] Alexey Melnikov's Yes on 
>> draft-ietf-pce-pceps-
>> 15: (with COMMENT)>> __ __


>> Hi, Dhruv,


>> __ __


>> On Mon, Aug 7, 2017 at 9:43 AM, Dhruv Dhody 
>> wrote:>>> Hi Spencer, Alexey,


>>>  


>>> The text refers to the Error itself. 


>>>  


>>>If a PCEP speaker that is unwilling or unable to negotiate
>>>TLS>>>receives a StartTLS messages, it MUST return a PCErr 
>>> message
>>>(in>>>clear) with Error-Type set to [TBA2 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.


>>>  


>>> I can see how it could be misleading and I have corrected it to
>>> – >>>  


>>>   +-+-+ +-+-+


>>>   |PCC| |PCE|


>>>   +-+-+ +-+-+


>>> | |


>>> | StartTLS|


>>> | msg | PCE waits


>>> |>| for PCC


>>> |   PCErr |


>>> |<| Send Error


>>> | | Type=TBA2,Value=3>>>
>>>  | | (not without TLS)>>>   
>>>   |<|


>>> |   Close |


>>>  


>>>  


>>>  


>>>Figure 5: Both PCEP Speaker supports PCEPS as well as without
>>>PCEPS,>>>but PCE cannot start TLS negotiation


>> __ __


>> This is still Alexey's ballot, of course, but ...


>> __ __


>> I like the change you're making, but the part that confused me is
>> that in English, multiple negatives don't work well - so, "not
>> without TLS" simplifies to "with TLS" in common usage.>> __ __


>> Are you using "not without TLS" to mean "TLS usage required", or
>> something like that?>> __ __


>> Spencer 


>> **[[Dhruv Dhody]] Yes, it means **"TLS usage required".  **I can
>> reword it to the text we have in the IANA section –**> 
> Thanks! I know what that means.
> 
> Spencer
>  
>> ****


>> **__ __**


>>Error-


>>TypeMeaning   Error-value
>>Reference>> __ __


>>  3:Failure, connection   This
>>document>>
>>   without TLS not


>>  possible


>>  4:Failure, connection   This
>>document>>
>>without TLS possible


>> __ __


>> **Regards,**


>> **Dhruv**


>>>  


>>> Regards,


>>> Dhruv


>>>  


>>> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Spencer
>>> Dawkins at IETF *Sent:* 07 August 2017 19:16 *To:* Alexey Melnikov
>>>  *Cc:* cmarga...@juniper.net; draft-ietf-pce-
>>> pc...@ietf.org; pce@ietf.org; The IESG ; pce-
>>> cha...@ietf.org *Subject:* Re: [Pce] Alexey Melnikov's Yes on 
>>> draft-ietf-pce-pceps-
>>> 15: (with COMMENT)>>>  


>>> This is Alexey's ballot, but ...


>>>  


>>> On Mon, Aug 7, 2017 at 5:48 AM, Alexey Melnikov
>>>  wrote: One more little thing:


  In figure 5, I see: Send Error (not without TLS)

  What does "not without TLS" mean? I think the figure is sending
  PCErr in the clear (without TLS)>>>  


>>> This text wasn't clear to me, either.


>>>  


>>> Thanks for actually mentioning this in your ballot, Alexey.


>>>  


>>> Spencer


>>>  


 On Mon, Aug 7, 2017, at 11:46 AM, Alexey Melnikov wrote:
  > Alexey Melnikov has entered the following ballot position for
  > draft-ietf-pce-pceps-15: Yes
   (snip) > I think the text about use of RFC 6125 should use RFC 
 6125
 > terminology
  > like DNS-ID and CN-ID, because they have a bit more 

Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Dhruv,

On Tue, Aug 8, 2017 at 6:08 AM, Dhruv Dhody  wrote:

> Hi Spencer,
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.i...@gmail.com]
> *Sent:* 07 August 2017 21:17
> *To:* Dhruv Dhody 
> *Cc:* Alexey Melnikov ; cmarga...@juniper.net;
> draft-ietf-pce-pc...@ietf.org; pce@ietf.org; The IESG ;
> pce-cha...@ietf.org
> *Subject:* Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15:
> (with COMMENT)
>
>
>
> Hi, Dhruv,
>
>
>
> On Mon, Aug 7, 2017 at 9:43 AM, Dhruv Dhody 
> wrote:
>
> Hi Spencer, Alexey,
>
>
>
> The text refers to the Error itself.
>
>
>
>If a PCEP speaker that is unwilling or unable to negotiate TLS
>
>receives a StartTLS messages, it MUST return a PCErr message (in
>
>clear) with Error-Type set to [TBA2 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.
>
>
>
> I can see how it could be misleading and I have corrected it to –
>
>
>
>   +-+-+ +-+-+
>
>   |PCC| |PCE|
>
>   +-+-+ +-+-+
>
> | |
>
> | StartTLS|
>
> | msg | PCE waits
>
> |>| for PCC
>
> |   PCErr |
>
> |<| Send Error
>
> | | Type=TBA2,Value=3
>
> | | (not without TLS)
>
> |<|
>
> |   Close |
>
>
>
>
>
>
>
>Figure 5: Both PCEP Speaker supports PCEPS as well as without PCEPS,
>
>but PCE cannot start TLS negotiation
>
>
>
> This is still Alexey's ballot, of course, but ...
>
>
>
> I like the change you're making, but the part that confused me is that in
> English, multiple negatives don't work well - so, "not without TLS"
> simplifies to "with TLS" in common usage.
>
>
>
> Are you using "not without TLS" to mean "TLS usage required", or something
> like that?
>
>
>
> Spencer
>
> *[[Dhruv Dhody]] Yes, it means *"TLS usage required".  *I can reword it
> to the text we have in the IANA section –*
>

Thanks! I know what that means.

Spencer


>
>
>Error-
>
>TypeMeaning   Error-value Reference
>
>
>
>  3:Failure, connection   This document
>
>  without TLS not
>
>  possible
>
>  4:Failure, connection   This document
>
>   without TLS possible
>
>
>
> *Regards,*
>
> *Dhruv*
>
>
>
> Regards,
>
> Dhruv
>
>
>
> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Spencer Dawkins
> at IETF
> *Sent:* 07 August 2017 19:16
> *To:* Alexey Melnikov 
> *Cc:* cmarga...@juniper.net; draft-ietf-pce-pc...@ietf.org; pce@ietf.org;
> The IESG ; pce-cha...@ietf.org
> *Subject:* Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15:
> (with COMMENT)
>
>
>
> This is Alexey's ballot, but ...
>
>
>
> On Mon, Aug 7, 2017 at 5:48 AM, Alexey Melnikov 
> wrote:
>
> One more little thing:
>
>
> In figure 5, I see: Send Error (not without TLS)
>
> What does "not without TLS" mean? I think the figure is sending PCErr in
> the clear (without TLS)
>
>
>
> This text wasn't clear to me, either.
>
>
>
> Thanks for actually mentioning this in your ballot, Alexey.
>
>
>
> Spencer
>
>
>
> On Mon, Aug 7, 2017, at 11:46 AM, Alexey Melnikov wrote:
> > Alexey Melnikov has entered the following ballot position for
> > draft-ietf-pce-pceps-15: Yes
>  (snip)
>
> > I think the text about use of RFC 6125 should use RFC 6125 terminology
> > like
> > DNS-ID and CN-ID, because they have a bit more semantics associated with
> > them
> > other than just subjectAltName:DNS. I think you should also clarify
> > whether you
> > want to allow wildcards in DNS-ID/CN-ID (RFC 6125 talks about that).
> >
> >
>
>
>
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)

[Dhruv Dhody]

Hi Ben, 

> -Original Message-
> From: Ben Campbell [mailto:b...@nostrum.com]
> Sent: 08 August 2017 03:08
> To: Dhruv Dhody 
> Cc: cmarga...@juniper.net; draft-ietf-pce-pc...@ietf.org; pce@ietf.org;
> The IESG ; pce-cha...@ietf.org
> Subject: Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15:
> (with DISCUSS and COMMENT)
> 
(snip)
> >>
> >>>
>  - 3.2: "Implementations MUST support SHA-256 as defined by [SHS] as
>  the hash algorithm for the fingerprint."
>  Do you really intend "MUST support" (meaning you have to be able to
>  handle sha-256, but could allow other hashes) vs "MUST use"?
> 
> >>> [[Dhruv Dhody]] Yes, additional hash algorithm MAY also be
> >> supported/used.
> >>>
> >>
> >> Is there an expectation people will use multiple hash algorithms
> >> side-by- side? Or is this for purposes of hash agility?
> >>
> > [[Dhruv Dhody]] SHA-256 is the current mandatory hash, others might
> become usable and useful as the technology evolves. Do you have any
> suggested change in mind?
> > I see RFC6614 use similar language "Implementations MUST support SHA-1
> as the hash algorithm for the fingerprint…."
> 
> I guess my question is whether the intent is for implementations to be
> able to pick any hash they want, as long as SHA-256 is an option, or do
> you expect everyone to use SHA-256 unless that is replaced at some point
> due to security concerns. If the former, “MUST support…” makes sense. If
> the latter, something like “MUST  (or SHOULD) use…” with a caveat that
> future specs might update this if SHA-256 is proven unsafe at some point
> in the future.
> 
[[Dhruv Dhody]] I was incorrect in my reply before, it is the latter, as we 
also have this text in the security considerations that explains this - 

   When using certificate fingerprints to identify PCEPS peers, any two
   certificates that produce the same hash value will be considered the
   same peer.  Therefore, it is important to make sure that the hash
   function used is cryptographically uncompromised, so that attackers
   are very unlikely to be able to produce a hash collision with a
   certificate of their choice.  This document mandates support for
   SHA-256 as defined by [SHS], but a later revision may demand support
   for stronger functions if suitable attacks on it are known.

So a future revision would update the Hash function to be used. I will update 
the text as you suggest. 

> My real concern here is interoperability—if an implementation chooses a
> hash other than SHA-256, how does the peer know what hash to use?
> 
[[Dhruv Dhody]] This is a local property and does not need to be exchanged. The 
peer provides the certificate, based on local hash function in use, the hash of 
DER encoded certificate octets is created and compared to a local fingerprint 
configured. 

> >
> > (snip)
> >

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

Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with COMMENT)

[Dhruv Dhody]

Hi Spencer,

From: Spencer Dawkins at IETF [mailto:spencerdawkins.i...@gmail.com]
Sent: 07 August 2017 21:17
To: Dhruv Dhody 
Cc: Alexey Melnikov ; cmarga...@juniper.net; 
draft-ietf-pce-pc...@ietf.org; pce@ietf.org; The IESG ; 
pce-cha...@ietf.org
Subject: Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with 
COMMENT)

Hi, Dhruv,

On Mon, Aug 7, 2017 at 9:43 AM, Dhruv Dhody 
> wrote:
Hi Spencer, Alexey,

The text refers to the Error itself.

   If a PCEP speaker that is unwilling or unable to negotiate TLS
   receives a StartTLS messages, it MUST return a PCErr message (in
   clear) with Error-Type set to [TBA2 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.

I can see how it could be misleading and I have corrected it to –

  +-+-+ +-+-+
  |PCC| |PCE|
  +-+-+ +-+-+
| |
| StartTLS|
| msg | PCE waits
|>| for PCC
|   PCErr |
|<| Send Error
| | Type=TBA2,Value=3
| | (not without TLS)
|<|
|   Close |



   Figure 5: Both PCEP Speaker supports PCEPS as well as without PCEPS,
   but PCE cannot start TLS negotiation

This is still Alexey's ballot, of course, but ...

I like the change you're making, but the part that confused me is that in 
English, multiple negatives don't work well - so, "not without TLS" simplifies 
to "with TLS" in common usage.

Are you using "not without TLS" to mean "TLS usage required", or something like 
that?

Spencer
[[Dhruv Dhody]] Yes, it means "TLS usage required".  I can reword it to the 
text we have in the IANA section –

   Error-
   TypeMeaning   Error-value Reference

 3:Failure, connection   This document
 without TLS not
 possible
 4:Failure, connection   This document
  without TLS possible

Regards,
Dhruv

Regards,
Dhruv

From: Pce [mailto:pce-boun...@ietf.org] On Behalf 
Of Spencer Dawkins at IETF
Sent: 07 August 2017 19:16
To: Alexey Melnikov >
Cc: cmarga...@juniper.net; 
draft-ietf-pce-pc...@ietf.org; 
pce@ietf.org; The IESG 
>; 
pce-cha...@ietf.org
Subject: Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with 
COMMENT)

This is Alexey's ballot, but ...

On Mon, Aug 7, 2017 at 5:48 AM, Alexey Melnikov 
> wrote:
One more little thing:


In figure 5, I see: Send Error (not without TLS)

What does "not without TLS" mean? I think the figure is sending PCErr in
the clear (without TLS)

This text wasn't clear to me, either.

Thanks for actually mentioning this in your ballot, Alexey.

Spencer

On Mon, Aug 7, 2017, at 11:46 AM, Alexey Melnikov wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-pce-pceps-15: Yes
 (snip)
> I think the text about use of RFC 6125 should use RFC 6125 terminology
> like
> DNS-ID and CN-ID, because they have a bit more semantics associated with
> them
> other than just subjectAltName:DNS. I think you should also clarify
> whether you
> want to allow wildcards in DNS-ID/CN-ID (RFC 6125 talks about that).
>
>


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