Subject: [multipathtcp] Alissa Cooper's Discuss on draft-ietf-mptcp-rfc6824bis-15: (with DISCUSS and COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Mon, 13 May 2019 13:22:37 -0700

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"

---

From: Alan Ford <[email-masked]>
Date: Tue, 14 May 2019 18:05:19 +0100

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.

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 <[email-masked]> wrote:
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 15 May 2019 16:07:44 -0400

Hi Alan,

> On May 14, 2019, at 1:05 PM, Alan Ford <[email-masked]> wrote:
> 
> Hi Alissa,
> 

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

---

From: Alan Ford <[email-masked]>
Date: Wed, 22 May 2019 16:12:21 +0100

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 <[email-masked]> wrote:
> 
> Hi Alan,
>