Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Tue, 08 August 2017 12:49 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD3413201D for <pce@ietfa.amsl.com>; Tue, 8 Aug 2017 05:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApEQ9M5_4jOE for <pce@ietfa.amsl.com>; Tue, 8 Aug 2017 05:49:00 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F871321A2 for <pce@ietf.org>; Tue, 8 Aug 2017 05:49:00 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id l82so20332305ywc.2 for <pce@ietf.org>; Tue, 08 Aug 2017 05:49:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ihP1lD37oBpUYBUDqxJyk1rhQsQRadfMwHFACWIQc5c=; b=mgHGMNFeUufIWKLOFwSPv018+t7mvc0xuJzL5EOgCn61c9huvsblIBNqE0U1nW4zQs Z++hMbg1i0rNBwStaz3yK6RhRDA1dLqIQ6hjHd2/USiyXGY3FcdwlFKbs2NMc6R4tFZ7 LPvNv+XF+irlGGHRAe1C43gsFAVglM/pUSVwa5x1Y5kUOTz9ylhyx3D5OIUr/ZR0tJEe +7+mZexJuXwXoOCp3rW4+irtfJKyrrONHXbmK1eVHzwGC/7IF1X0QfS7kCjtWz8gxfwl zZf7aG+TEsM9ju/dfE+2GodamXj2ubWmngFgDvNMerijgEXd86WYs8VQJQ8ZjJDbXQsk kwnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ihP1lD37oBpUYBUDqxJyk1rhQsQRadfMwHFACWIQc5c=; b=f2dEekWNVgWUTcCr4ShtFkcUEamsxmU6Xdz8TivU5NmsMO+yyNFNHgqsXVUf15NTxF dUSKSlPwXjC4IfhI8AMEafTTrnefajLBKszjQJ5xziUJVM0GclX79/SlpCALHOMYc0Lt 2i0XL5ynAxPcSr+xwpdaJcpmZ6ScMYgJsNFPNDj2MOBjsgwQ7KnjHoKbo7x5dK2G4Rr0 BWemJiE3iOl6Vw5r7UzWXMDPhk5SiT4uCWu+SLTw+ptFmNm7UwDTRZedLpeYyaClF+k2 vF1v8Vw0y9eJUPUbZH4CKusDsQf8ScRwa1R4AyGF6lSvB/yiYtyQzUeaJbAv71NL6ETI t8uQ==
X-Gm-Message-State: AHYfb5hk5+jarEvC4KF65oUXlm+0as+SGbpKX3u1SguSA+w5ib4218+b 33mJO+/JRaTSpEck43Nw0DNQAH9SBHhC
X-Received: by 10.37.248.12 with SMTP id u12mr3233749ybd.248.1502196539745; Tue, 08 Aug 2017 05:48:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.218.130 with HTTP; Tue, 8 Aug 2017 05:48:19 -0700 (PDT)
In-Reply-To: <23CE718903A838468A8B325B80962F9B8CB99B99@blreml501-mbb>
References: <150175472723.9824.8664411936101979517.idtracker@ietfa.amsl.com> <23CE718903A838468A8B325B80962F9B8CB9867E@blreml501-mbb> <1501768430.1127539.1062021760.5848DD02@webmail.messagingengine.com> <23CE718903A838468A8B325B80962F9B8CB98DC9@blreml501-mbb> <CABcZeBOE_3QggT0PiojJOCR=mYnPN1_B=1efBLvMuU5ukG9wDg@mail.gmail.com> <23CE718903A838468A8B325B80962F9B8CB99517@blreml501-mbb> <CABcZeBOCnEi4JS+NQ9NSjxf_1DEJEyOwaOSHPaMG-+=FmBn0=A@mail.gmail.com> <23CE718903A838468A8B325B80962F9B8CB99B99@blreml501-mbb>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 08 Aug 2017 05:48:19 -0700
Message-ID: <CABcZeBO4bpFv7rHd-OsaxJ59gc=ke_qmJXOrp0aCo-tZqMZxZw@mail.gmail.com>
To: Dhruv Dhody <dhruv.dhody@huawei.com>
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, "draft-ietf-pce-pceps@ietf.org" <draft-ietf-pce-pceps@ietf.org>, "pce@ietf.org" <pce@ietf.org>, The IESG <iesg@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>, "cmargaria@juniper.net" <cmargaria@juniper.net>
Content-Type: multipart/alternative; boundary="f403045db86622ff9505563d6304"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/uxYjYuaRwzgXceAvgLhHjN_bJ8o>
Subject: Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Aug 2017 12:49:05 -0000
On Tue, Aug 8, 2017 at 4:01 AM, Dhruv Dhody <dhruv.dhody@huawei.com> wrote: > Hi Eric, > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* 07 August 2017 20:54 > *To:* Dhruv Dhody <dhruv.dhody@huawei.com> > *Cc:* Alexey Melnikov <aamelnikov@fastmail.fm>; > draft-ietf-pce-pceps@ietf.org; pce@ietf.org; The IESG <iesg@ietf.org>; > pce-chairs@ietf.org; cmargaria@juniper.net > > *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 <dhruv.dhody@huawei.com> > wrote: > > Hi Eric, > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* 05 August 2017 22:58 > *To:* Dhruv Dhody <dhruv.dhody@huawei.com> > *Cc:* Alexey Melnikov <aamelnikov@fastmail.fm>; The IESG <iesg@ietf.org>; > cmargaria@juniper.net; draft-ietf-pce-pceps@ietf.org; pce@ietf.org; > pce-chairs@ietf.org > > > *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 <dhruv.dhody@huawei.com> > wrote: > > Hi Alexey, > > > -----Original Message----- > > From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm] > > Sent: 03 August 2017 19:24 > > To: Dhruv Dhody <dhruv.dhody@huawei.com>; The IESG <iesg@ietf.org> > > Cc: cmargaria@juniper.net; draft-ietf-pce-pceps@ietf.org; pce@ietf.org; > > pce-chairs@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-bounces@ietf.org] On Behalf Of Alexey Melnikov > > > > Sent: 03 August 2017 15:35 > > > > To: The IESG <iesg@ietf.org> > > > > Cc: cmargaria@juniper.net; draft-ietf-pce-pceps@ietf.org; > > > > pce@ietf.org; pce-chairs@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 > > *[[[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. > > > > >
- [Pce] Alexey Melnikov's Discuss on draft-ietf-pce… Alexey Melnikov
- Re: [Pce] Alexey Melnikov's Discuss on draft-ietf… Dhruv Dhody
- Re: [Pce] Alexey Melnikov's Discuss on draft-ietf… Alexey Melnikov
- Re: [Pce] Alexey Melnikov's Discuss on draft-ietf… Dhruv Dhody
- Re: [Pce] Alexey Melnikov's Discuss on draft-ietf… Eric Rescorla
- Re: [Pce] Alexey Melnikov's Discuss on draft-ietf… Dhruv Dhody
- Re: [Pce] Alexey Melnikov's Discuss on draft-ietf… Eric Rescorla
- Re: [Pce] Alexey Melnikov's Discuss on draft-ietf… Dhruv Dhody
- Re: [Pce] Alexey Melnikov's Discuss on draft-ietf… Eric Rescorla
- Re: [Pce] Alexey Melnikov's Discuss on draft-ietf… Dhruv Dhody