On Fri, Aug 4, 2017 at 11:41 AM, Dhruv Dhody <dhruv.dh...@huawei.com> wrote:
> Hi Alexey, > > > -----Original Message----- > > From: Alexey Melnikov [mailto:aamelni...@fastmail.fm] > > Sent: 03 August 2017 19:24 > > To: Dhruv Dhody <dhruv.dh...@huawei.com>; The IESG <i...@ietf.org> > > 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 <i...@ietf.org> > > > > 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 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 > > 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
