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

[Dhruv Dhody <[e-mail]>]

Hi Alexey, 

> -----Original Message-----
> From: Alexey Melnikov [mailto:[e-mail]]
> Sent: 03 August 2017 19:24
> To: Dhruv Dhody <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> 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:[e-mail]] On Behalf Of Alexey Melnikov
> > > Sent: 03 August 2017 15:35
> > > To: The IESG <[e-mail]>
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]
> > > 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.
END

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.