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:[email protected]] On Behalf Of Alexey Melnikov > > Sent: 03 August 2017 15:35 > > To: The IESG <[email protected]> > > Cc: [email protected]; [email protected]; [email protected]; > > [email protected] > > 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. > > 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. > > So maybe you need 3 figures describing the above 3 cases. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
