Return-Path: 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 6703A120233; Wed, 22 May 2019 08:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Id_mE33rZ5FS; Wed, 22 May 2019 08:12:46 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 0F442120270; Wed, 22 May 2019 08:12:32 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id 7so2621233wmo.2; Wed, 22 May 2019 08:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iMh9WTI2YmSPeekG4cMKw5rZIVi/i2B8se2b+VSuhNU=; b=o6/ppijcWNqttLZaxHYq/ImrhjoLZ8cGeas0VLr/DUfIoPVU8EwYVmDxmPbLmLWfa/ fkaNECRXcBWvHqUqXQfXHQcgPZK3LZhbeTt07ahOHBnt7qshPWlZK4CIzQtMKjk7TaWh nHgYULbuFPB6jwlitafq51bXjMWPtbj36MOovUTX41f04pczEOHy/yYbk2fKYCR0kaRe Pf7gswBI226WwOO4kDpE8Bd2KfTFbIGU0C72xN/kTUYsBZau+apUcv/yDcwJF/4xhssA iN3ITnWPMUHy2YHtUKbE/kvDnILSHahGiPmKf6yrgeVrjxqIT2AzZ8kSujQiAIhQ60ND 5jcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iMh9WTI2YmSPeekG4cMKw5rZIVi/i2B8se2b+VSuhNU=; b=BEx9+hnaWW3ZUIbHu9Bm1WTgXKar1inQpw6NiGnn2y3XC38c2JlpM9zoDSwxkbl3vu LkS43diy1yXkJipJBBdl5jw8fAf1J/cm8LHi46UsFQZcCbtjB6IxBIKJjNijulllpOow Tgl5sQ9kAysVYH1eED37jjbNOwtzVOPutn63hf9g3nDkjB5iDk6cqWFUIADbkDlDuc0k MInX3Rfdaxk1RIRM6fD5l6jyDFduaEYyPgCrRIPlMCAvhsqpP8RuqiI5AyOovRY4Alq0 UjTfHN4+GQkZEaRwqkziuRXjL5HDvMAjiJH5ydPsOCuGgXSR696oZH/RDePkC1/IEOyT F26Q== X-Gm-Message-State: APjAAAWoE+VFFVDNTM3fbnxd2cAVFfA7VXTBGR0qVDYM/lN7fj/cFbkW YK6e0C0k+FOx2CDO0IHArkM= X-Google-Smtp-Source: APXvYqyObVdKeaJKqRzR5bzHmGVUAOODdVGKA/+9q/HIIJAwUrtv1AFmEYO2Z+J5TZmwnX3RSEuPaw== X-Received: by 2002:a7b:c7d5:: with SMTP id z21mr7974396wmk.56.1558537950438; Wed, 22 May 2019 08:12:30 -0700 (PDT) Received: from [172.20.10.2] (188.29.164.191.threembb.co.uk. [188.29.164.191]) by smtp.gmail.com with ESMTPSA id g2sm27039316wru.37.2019.05.22.08.12.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 08:12:29 -0700 (PDT) From: Alan Ford Message-Id: <0DE4B06F-AB03-496E-9399-3048BEF31C5F@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_86834E9A-2257-4867-8AA3-735E39586BDF" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 22 May 2019 16:12:21 +0100 In-Reply-To: Cc: IESG , draft-ietf-mptcp-rfc6824bis@ietf.org, Philip Eardley , mptcp-chairs@ietf.org, multipathtcp@ietf.org To: Alissa Cooper References: <155777895763.23745.13998665596170215423.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 15:13:00 -0000 --Apple-Mail=_86834E9A-2257-4867-8AA3-735E39586BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alissa, Thanks, I have gone with the following text in the -16 rev, I hope this = is sufficient: It is expected, but not mandated, that this flag would be used as part of an alternative security mechanism that does not require a full version upgrade of the protocol, but does require redefining some elements of the handshake. Thanks also to all other IESG members for their nits and minor comments, = all have been included in the -16 revision. Best regards, Alan > On 15 May 2019, at 21:07, Alissa Cooper wrote: >=20 > Hi Alan, >=20 >> On May 14, 2019, at 1:05 PM, Alan Ford wrote: >>=20 >> Hi Alissa, >>=20 >> 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. >=20 > Ok, this is helpful, but it still doesn=E2=80=99t 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. >=20 > Alissa >=20 >>=20 >> 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. >>=20 >> Best regards, >> Alan >>=20 >>> On 13 May 2019, at 21:22, Alissa Cooper via Datatracker = wrote: >>>=20 >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-mptcp-rfc6824bis-15: Discuss >>>=20 >>> 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.) >>>=20 >>>=20 >>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-mptcp-rfc6824bis/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> 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? >>>=20 >>> 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. >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Section 3.7: s/the lost of MPTCP options/the loss of MPTCP options/ >>>=20 >>> Appendix E should be titled "Changes from RFC 6824" >>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_86834E9A-2257-4867-8AA3-735E39586BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Alissa,

Thanks, I = have gone with the following text in the -16 rev, I hope this is = sufficient:
      It is expected, but
      not mandated, that this flag would be used as part of an
      alternative security mechanism that does not require a full
      version upgrade of the protocol, but does require redefining some
      elements of the handshake.
Thanks also = to all other IESG members for their nits and minor comments, all have = been included in the -16 revision.

Best regards,
Alan

On 15 May 2019, at 21:07, = Alissa Cooper <alissa@cooperw.in> wrote:

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=E2=80=99t 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.htmlfor 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"





= --Apple-Mail=_86834E9A-2257-4867-8AA3-735E39586BDF--