Re: [multipathtcp] Alissa Cooper's Discuss on draft-ietf-mptcp-rfc6824bis-15: (with DISCUSS and COMMENT)
Alissa Cooper <alissa@cooperw.in> Wed, 15 May 2019 20:07 UTC
Return-Path: <alissa@cooperw.in>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110301200FD; Wed, 15 May 2019 13:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=1s6gPZw+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZVjz4b5h
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 qeeSffu7IJjN; Wed, 15 May 2019 13:07:49 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202C412004C; Wed, 15 May 2019 13:07:49 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id C1A8F1B1; Wed, 15 May 2019 16:07:47 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 15 May 2019 16:07:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=1 +NH4O3vBXaWbimhtoiTC8WJHsXAkdQGnFgxaxgUrzU=; b=1s6gPZw+G42KzaLLV e35Ocer/Y+5TNWfxQmiF90Vg9SCMkUnhhJVOSbwDl6mQkB86rgVgxEYvL1SDJm0E dzdTnz1ktehprxhVCkKEbBqFb+QIBLwbW020SngXCRpzQkU985PMXlYe9Z2VvOtq TOvlrFql3RkJsQxveiE9PvPtFxAbpKLXNt8DhxiYRi8XiGQnE5eJQWnzA0i4ciCv +d0VG46643Kx/13YDGfCToTWVMpCB8shiHKidHqnYrHTkPFwcfpmZwHDDyGeVsKl J+9FjDhddWjLH82HFcxUAqBLfE99aIkysbPKAYmC4YKNvBjiawIWcnhhaJ/h5SGO 3FmLA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=1+NH4O3vBXaWbimhtoiTC8WJHsXAkdQGnFgxaxgUr zU=; b=ZVjz4b5hsl0Pa4bIfIvbHc75pvTegMTqpiIOKczq5mpjuYlSah1h4fE7q Rai++ZNMIMMrDrhVdIpTbE8RbQsKyurONFivv7c+3GcmcjyoFyw23+If1g1LzGcf AO4MvShAQyOMQ3gwE+QbuPCSjfVGat2Kf+HdKfYUtxLQCjaR1R3au7ZqQovF4J6F JEVJ1I7y8oSsYxP51vQw1rwLOgc/44WLb11HRVgbItBZKRPn+utW2i2Hz0sOOYqV RVlvDlPAQKUIWseR6OeipldxDcxMbX3NcqK99Eccp6SSpcznpFTNF/E77HyioOXH h7snoSusDQtaOBu2HNfMpSgQS0eZw==
X-ME-Sender: <xms:knHcXNIJBnW99dYfSeSHP_qQJFachiQAFfzxRvmWD5ObD6ADMUkKkA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrleekgddugedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkeelnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd
X-ME-Proxy: <xmx:knHcXA4dz0TxUD5IaESR79ldWczKzJ5Zjje1eiWmCqfjHMq7djg5dw> <xmx:knHcXKtiRaTzXyCedHx7aslyF1MPaG0JGbhEHf-yub8awPZzq8crzw> <xmx:knHcXGZfqYkfWBBXCyiFbjstwgfSPuOg_HRy7VHDJ1xBQuYPg-hHpA> <xmx:k3HcXC3218mucbh3Yce6x984VhvpbTk53UtNE4_wvfpxkYHIo8yGlQ>
Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.89]) by mail.messagingengine.com (Postfix) with ESMTPA id 2D8AC10378; Wed, 15 May 2019 16:07:46 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <D046C8F2-D593-4E48-B2A5-2789A9FC4042@gmail.com>
Date: Wed, 15 May 2019 16:07:44 -0400
Cc: IESG <iesg@ietf.org>, draft-ietf-mptcp-rfc6824bis@ietf.org, Philip Eardley <philip.eardley@bt.com>, mptcp-chairs@ietf.org, multipathtcp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8DB494D-46AC-4113-A4EC-1D4703963B6C@cooperw.in>
References: <155777895763.23745.13998665596170215423.idtracker@ietfa.amsl.com> <D046C8F2-D593-4E48-B2A5-2789A9FC4042@gmail.com>
To: Alan Ford <alan.ford@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/0uAJ6UAJzSy-f3uqgaLwFuRoeaA>
Subject: Re: [multipathtcp] Alissa Cooper's Discuss on draft-ietf-mptcp-rfc6824bis-15: (with DISCUSS and COMMENT)
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 20:07:51 -0000
Hi Alan, > On May 14, 2019, at 1:05 PM, Alan Ford <alan.ford@gmail.com> wrote: > > Hi Alissa, > > Many thanks for your feedback here. This is a simple typo - the definition of B should affect bits D - H and not C - H. All other sections referring to this (e.g. the IANA considerations) correctly point to D - H, so we will correct this. Ok, this is helpful, but it still doesn’t give an indication of (a) what it takes for B to be set to 1, since this spec changed C but does not say B should be set to 1, or (b) which kinds of changes should be made in the future using the B flag versus using the version negotiation mechanism. Alissa > > The history of the extensibility bit goes back to security area concerns on the original 6824, and wanting to ensure we had a mechanism in the protocol to redefine bits of the handshake to allow an alternative security mechanism to be used in the future, without needing a full new version of the protocol to be defined. Whilst I would be happy to remove it from v1, the security area felt strongly about this in v0, and the flexibility that is potentially available by assigning this bit for this purpose seems to come at a small cost. > > Best regards, > Alan > >> On 13 May 2019, at 21:22, Alissa Cooper via Datatracker <noreply@ietf.org> wrote: >> >> Alissa Cooper has entered the following ballot position for >> draft-ietf-mptcp-rfc6824bis-15: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I have a question about the interaction between the protocol versioning and the >> way the flags B-H are defined. This doc specifies that B MUST be set to 0 and >> that future specs might require it to be set to 1, which could alter the >> meanings of the C-H flags. This is the same way that B is defined in RFC 6824. >> This spec goes on to define C and H differently from how they are defined in >> RFC 6824. Thus, both v0 and v1 implementations will have B set to 0, but they >> will have C and H defined differently. I guess it depends on how you interpret >> "extensibility flag," but my interpretation of this is that the version number >> negotiated using MP_CAPABLE is the actual extensibility mechanism that this >> specification is making use of, because although it changed C and H it did not >> change B. Is this right? >> >> If so, I'm wondering what the threshold is for defining new versions of this >> protocol versus using this extensibility mechanism based on the B flag. Given >> the way the version negotiation mechanism is defined -- requiring extra >> round-trips in the event of a fallback attempt, and it being subject to a >> downgrade attack -- I'm wondering if some guidance needs to be provided about >> which sorts of protocol changes are expected to be made using the B-flag >> mechanism versus using the version negotiation mechanism. I guess the drawback >> of using the B-flag mechanism is that once a future spec sets it to 1, from >> then on logic within implementations will be required to interpret potentially >> multiple different semantics of C-H. I guess this potentially raises another >> question, which is why the B flag isn't just deprecated given the addition of >> the version negotiation mechanism. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 3.7: s/the lost of MPTCP options/the loss of MPTCP options/ >> >> Appendix E should be titled "Changes from RFC 6824" >> >> >
- [multipathtcp] Alissa Cooper's Discuss on draft-i… Alissa Cooper via Datatracker
- Re: [multipathtcp] Alissa Cooper's Discuss on dra… Alan Ford
- Re: [multipathtcp] Alissa Cooper's Discuss on dra… Alissa Cooper
- Re: [multipathtcp] Alissa Cooper's Discuss on dra… Alan Ford