Hi Eric, From: Eric Rescorla [mailto:e...@rtfm.com] Sent: 08 August 2017 18:18 To: Dhruv Dhody <dhruv.dh...@huawei.com> Cc: Alexey Melnikov <aamelni...@fastmail.fm>; draft-ietf-pce-pc...@ietf.org; pce@ietf.org; The IESG <i...@ietf.org>; 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 <dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>> wrote: Hi Eric, From: Eric Rescorla [mailto:e...@rtfm.com<mailto:e...@rtfm.com>] Sent: 07 August 2017 20:54 To: Dhruv Dhody <dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>> Cc: Alexey Melnikov <aamelni...@fastmail.fm<mailto:aamelni...@fastmail.fm>>; draft-ietf-pce-pc...@ietf.org<mailto:draft-ietf-pce-pc...@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>; The IESG <i...@ietf.org<mailto:i...@ietf.org>>; pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>; cmarga...@juniper.net<mailto: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 <dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>> wrote: Hi Eric, From: Eric Rescorla [mailto:e...@rtfm.com<mailto:e...@rtfm.com>] Sent: 05 August 2017 22:58 To: Dhruv Dhody <dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>> Cc: Alexey Melnikov <aamelni...@fastmail.fm<mailto:aamelni...@fastmail.fm>>; The IESG <i...@ietf.org<mailto:i...@ietf.org>>; cmarga...@juniper.net<mailto:cmarga...@juniper.net>; draft-ietf-pce-pc...@ietf.org<mailto:draft-ietf-pce-pc...@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>; pce-cha...@ietf.org<mailto: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 <dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>> wrote: Hi Alexey, > -----Original Message----- > From: Alexey Melnikov > [mailto:aamelni...@fastmail.fm<mailto:aamelni...@fastmail.fm>] > Sent: 03 August 2017 19:24 > To: Dhruv Dhody <dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>>; The > IESG <i...@ietf.org<mailto:i...@ietf.org>> > Cc: cmarga...@juniper.net<mailto:cmarga...@juniper.net>; > draft-ietf-pce-pc...@ietf.org<mailto:draft-ietf-pce-pc...@ietf.org>; > pce@ietf.org<mailto:pce@ietf.org>; > pce-cha...@ietf.org<mailto: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<mailto:pce-boun...@ietf.org>] On > > > Behalf Of Alexey Melnikov > > > Sent: 03 August 2017 15:35 > > > To: The IESG <i...@ietf.org<mailto:i...@ietf.org>> > > > Cc: cmarga...@juniper.net<mailto:cmarga...@juniper.net>; > > > draft-ietf-pce-pc...@ietf.org<mailto:draft-ietf-pce-pc...@ietf.org>; > > > pce@ietf.org<mailto:pce@ietf.org>; > > > pce-cha...@ietf.org<mailto: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 have a channel to send data on, as the other > > > end will get confused. I think you just have to close connection in > such case. > > > > > [[Dhruv Dhody]] No, the PCErr is sent in clear over the TCP connection > > (underlying transport). > > EKR also made a similar point. I updated the text to include this - > > > > Note that, the PCEP implementation MUST send the PCErr message once > > the TLS connection has been closed i.e. the TLS close_notify > > [RFC5246] has been received from the peer. As per [RFC5246], if the > > data may be carried over the underlying transport after the TLS > > connection is closed, the TLS implementation must receive the > > responding close_notify alert before indicating to the application > > layer that the TLS connection has ended. > > Hmm, I am not sure this will ever work. I know that implementations of TLS > in other protocols I worked on can't read any cleartext TCP data after TLS > has failed. > [[Dhruv Dhody]] One way to resolve this issue would be we move these errors from after TLS negotiation to before it, so that they become the response to StartTLS as suggested by your previous comment. We would not be sending error in clear text in case of TLS negotiation failure. So basically the change would look something like - OLD: After the exchange of StartTLS messages, if a PCEP speaker cannot establish a TLS connection for some reason (e.g. the required mechanisms for certificate revocation checking are not available), 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. 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 receiver MAY choose to attempt to re-establish the PCEP session without TLS next. The attempt to re-establish the PCEP session without TLS SHOULD be limited to only once. NEW: 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. 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 receiver MAY choose to attempt to re-establish the PCEP session without TLS next. The attempt to re-establish the PCEP session without TLS SHOULD be limited to only once. After the exchange of StartTLS messages, if the TLS negotiation fails for some reason (e.g. the required mechanisms for certificate revocation checking are not available), both peers SHOULD immediately close the connection. Since the initiator has no way to know if the peer is willing to accept PCEP connection without TLS, based on the local policy, it MAY attempt to re-establish the PCEP session without TLS. The attempt to re-establish the PCEP session without TLS SHOULD be limited to only once. This will technically work, but is there a reason you don't specify a parameter to STARTTLS which expresses your policy? -Ekr [[[Dhruv Dhody]]] It could be done that way as well, but at this late stage we should avoid making a change that would require adding a new PCEP object. As there is no way to add this in current StartTLS message encoding. This is still an I-D, right? Are there any fielded implementations? -Ekr [[Dhruv Dhody]] There are implementations, not sure if they qualify as “fielded”. Do you feel strongly about making the change? It seems like it would clean up a number of confusing issues in your draft, so I'd like to understand why the WG didn't do it. -Ekr [[[Dhruv Dhody]]] Well to be frank, since it was not proposed, WG did not consider it :) As an author, while referencing StartTLS work in other protocols we did not see such a consideration either, and we ended up with the PCEP error mechanism to convey the information. While the requested change may simplify a few things, but it would also require adding a new section for a new PCEP object - StartTLS object (as unfortunately there is no way to carry the information in the current message/objects). As an editor I am shying away from making a change if the benefit is not big (maybe my biased view) but as an AD if you feel this is required, we would make the change. Thanks for your continued discussion. Regards, Dhruv Regards, Dhruv Regards, Dhruv Working version: https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-pceps-16.txt Diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-pceps-15&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-pceps-16.txt Regards, Dhruv > > > So maybe you need 3 figures describing the above 3 cases.
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
