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

[Eric Rescorla <[e-mail]>]

On Fri, Aug 4, 2017 at 11:41 AM, Dhruv Dhody <[e-mail]> wrote:

> 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.


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.
>