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

[Eric Rescorla <[e-mail]>]

On Tue, Aug 8, 2017 at 4:01 AM, Dhruv Dhody <[e-mail]> wrote:

> Hi Eric,
>
>
>
> *From:* Eric Rescorla [mailto:[e-mail]]
> *Sent:* 07 August 2017 20:54
> *To:* Dhruv Dhody <[e-mail]>
> *Cc:* Alexey Melnikov <[e-mail]>;
> [e-mail]; [e-mail]; The IESG <[e-mail]>;
> [e-mail]; [e-mail]
>
> *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 <[e-mail]>
> wrote:
>
> Hi Eric,
>
>
>
> *From:* Eric Rescorla [mailto:[e-mail]]
> *Sent:* 05 August 2017 22:58
> *To:* Dhruv Dhody <[e-mail]>
> *Cc:* Alexey Melnikov <[e-mail]>; The IESG <[e-mail]>;
> [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)
>
>
>
>
>
>
>
> 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
>
> *[[[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


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