From: <philip.eardley@bt.com>
To: <alan.ford@gmail.com>
CC: <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45AAMTUIlAEfjIKAACijZfg
Date: Sat, 14 Jul 2018 11:08:25 +0000
Message-ID: <f75acf78bc4c4a419433569bf5acde4f@rew09926dag03b.domain1.systemhost.net>
References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net>
 <f64af1576d994d888a7b82fb75dc8318@rew09926dag03b.domain1.systemhost.net>
 <ACB25C6F-1E4B-45A5-82A1-E219ECEDD40E@gmail.com>
In-Reply-To: <ACB25C6F-1E4B-45A5-82A1-E219ECEDD40E@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/a1cxyBQ8IkU1fwzk51HK-A9WRsw>
Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
Precedence: list

Hi,

Apart from the pure clarifications, there are a few comments from me and Yo=
shi that may be worth discussing:

--
2:  As we have removed AddrID from MP_PRIO, we have a certain problem in th=
e situations like the followings.

Let's say a server has two address S1, S2 while the client is behind FW. Si=
nce the client is behind firewall, the server uses ADD_ADDR to send the inf=
o of S2 through S1, but it wants S2 to be used as a backup.

In this case, if MP_PRIO has addr id field, the server is able to specify S=
2 is a backup. However, since MP_PRIO doesn't have addr id any more, all th=
e server can do is to wait until the client establishes the connection with=
 S2. But, this connection doesn't look what the server wants.=20
I guess using 1 bit in ADD_ADDR might solve the issue.
--

One other high-level comment:  it would be very good if the bis code, imple=
mented in linux, could be released - to allow testing of the protocol chang=
es in the bis, for instance to make sure that no unexpected issues have bee=
n introduced

--

Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so that Hos=
t A's key is sent only on the ACK (not on the SYN)? Is this so it's only se=
nt when we know host B is MPTCP capable, which is therefore a slight securi=
ty improvement?  (Just send a link to earlier emails, if that's easier)

--

Section 3.4.1 ... The 'E' bit exists to provide reliability for this option=
 ...
Not sure - does this open security hole, where an attacker pretends an ADD-=
ADDR has been received? (the Echo doesn't include an hmac, so is easy to sp=
oof)

--

We're waiting for this IPR to get added on the tracker
* one is inherited from draft-paasch-mptcp-syncookies (which got include in=
 rfc6824bis) https://datatracker.ietf.org/ipr/2678/

--

-----Original Message-----
From: Alan Ford [mailto:alan.ford@gmail.com]=20
Sent: 11 July 2018 02:23
To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

Thank you for your feedback, Phil. All proposed changes look good and we wi=
ll wrap these into the next version.

@Everyone - we are however awaiting other WGLC feedback before doing a new =
revision!

Best regards,
Alan

> On 18 Jun 2018, at 14:59, philip.eardley@bt.com wrote:
>=20
> More comments:
> Section 3.5 -
> Option R (RST) - add (at the end of the bullet) "the Host A enters the=20
> CLOSED state directly" (I think)
>=20
> << If a host receives a packet with a valid MP_FASTCLOSE option, it
>   shall process it as follows :>>
> I think the text that follows (apart from the last bullet) is only releva=
nt for Option A, where the MP_FASTCLOSE is sent on an ACK - it doesn't appl=
y for option R (where it's sent on a RST). Anyway, things could be laid out=
 slightly differently so the section is clearer.=20
>=20
> Section 3.6
> I wonder if it would be more logical for this section to be before Fast c=
lose?
>=20
> This section could do with a read through. A few things:
> << As discussed in Section 3.5 above, the MP_FASTCLOSE option provides a
>   connection-level reset roughly analagous to a TCP RST. Regular TCP
>   RST options remain used to at the subflow-level to indicate the
>   receiving host has no knowledge of the MPTCP subflow or TCP
>   connection to which the packet belongs.>> Can this paragraph be=20
> deleted? at least I found it a bit confusing that this text is not about =
this section.
>=20
> "remain used to at" is ugly
>=20
> << However, in MPTCP, there may be many reasons for rejecting the
>   opening of a subflow, but these semantics cannot be carried in a
>   standard TCP RST. It would be beneficial for a host to the reasons
>   why its subflow has been closed with a RST, and thus whether it
>   should try to re-establish the subflow immediately, later, or never
>   again.  These semantics are carried in the MP_TCPRST option that can
>   be included on a TCP RST packet.>>
> I presume the new MP_TCPRST can be added to a RST, whenever it's created =
- the sentence seems to imply it's only when it wants to reject the opening=
 of a subflow (ie in response to MP_JOIN).=20
> I assume inclusion of the MP_TCPRST option is optional?
>=20
> potential better phrasing:
> A host sends a TCP RST in order to close a subflow or reject an attempt t=
o open a subflow (MP_JOIN). In order to inform the receiving host why a sub=
flow is being closed or rejected, the TCP RST packet MAY include the MP_TCP=
RST Option. The host MAY use this information to decide, for example, wheth=
er it tries to re-establish the subflow immediately, later, or never.=20
>=20
> <<   o  Unspecified error (code 0x0).  This is the default error implying
>      the subflow is not longer available.  The receiving host SHOULD
>      take account of the 'T' bit in deciding whether to re-estbalish
>      this subflow.  The presence of this option shows that the RST was
>      generated by a MPTCP-aware device.>>
>=20
> " The receiving host SHOULD take account of the 'T' bit in deciding wheth=
er to re-estbalish this subflow."
> Only this sub-bullet mentions the T bit, which may suggest that it should=
 not be taken account of with the other reason codes.  I think the sentence=
 should be deleted (using the T flag is mentioned earlier).=20
>=20
> <<enough ressources>>  enough resources
>=20
> Section 3.7
> I guess it's OK to refer to it as RST rather than TCP RST?
>=20
> << The case described above is a specialized case of fallback, for when
>   the lack of MPTCP support is detected before any data is acknowledged
>   at the connection level on a subflow.  >> "The case above" - I'm not=20
> sure which of the previous paragraph or paragraphs you're referring to.
> "specialised" - maybe "specific" [is it really specialised?] "for=20
> when" -> when
>=20
> S3.9.2
> << If the two communicating hosts immediately try to set up subflows
>   from all available addresses to all available addresses on the other
>   host, this could end up creating two subflows per path.  This is an
>   inefficient use of resources.>>
> is two subflows correct? Multiple I think " could end up creating two=20
> subflows per path" -> "could create multiple subflows over the same path"
>=20
> << If a host does not support TCP simultaneous open, it
>   is RECOMMENDED that some element of randomization is applied to the
>   time waited before opening new subflows, so that only one subflow
>   exists between a given address pair.  If, however, hosts signal
>   additional ports to use (for example, for leveraging ECMP on-path),
>   this heuristic need not apply.>>
> "time waited" - ugly phrase?
> "exists" -> is created
> "need not apply" -> is not appropriate
>=20
> Section 5 - Security
> This section needs updating to reflect the changes in the bis.:
>=20
> Add mention of ADD_ADDR, now with HMAC and reliability, Discuss the=20
> revised MP_CAPABLE I'm not sure if the new fast close option (option=20
> R) has any security impact?
> Discuss the MP_PRIO change (no off path address indication) Discuss=20
> downgrade attacks (to v0) during connection initiation
>=20
> Section 8 IANA
> << This document updates [RFC6824] and as such IANA is requested to
>   update the TCP option space registry to point to this document for
>   Multipath TCP>>
> This document obsoletes rather than updates...   I suspect this means all=
 the MPTCP options need to be included in this document, but we can leave I=
ANA to decide that.=20
>=20
> <<  |    C    |   Do not attempt to connect to   |    This document,    |
>   |         |          source address          |     Section 3.1      |
>>>=20
> I don't think this is a good summary of flag C's meaning.
>=20
> << The
>   contents of this sub-registry are to to this document, as follows:
>>>=20
> Is this sentence needed?
>=20
> Appendix B TCP Fast Open
> Maybe rephrae the title as "TCP Fast Open and MPTCP" or "Considerations a=
bout using TCP Fast Open and MPTCP"?
>=20
> This section could do with a read through, it could do with a few=20
> minor re-phrasings
>=20
>=20
> <<   TCP Fast Open (TFO) is an experimental TCP extension, described in
>   [RFC7413], which has been introduced with the objective of gaining
>   one RTT before transmitting data.>>
> " gaining one RTT"?  maybe: which allows data to be sent one RTT earlier =
than with regular TCP.=20
> << It achieves this by sending the SYN-
>   segment together with data>>
> re-phrase (I think data is referring ot the cookie - but you havent=20
> yet mentioned it - rather than user data)
>=20
> "resp." =3D ?
>=20
> << TFO and MPTCP can be combined provided that the total length of their
>   options does not exceed the maximum 40 bytes possible in TCP>>=20
> "their" is wrong, as there may be other options. -> "all the"
>=20
> << We also note that this does not entail a loss
>   of functionality, because TFO-data is always sent when only one path
>   is active.>>
> -> "TFO-data is only ever sent when only a single path is active"
> How do you guarantee this? Not sure I understand.=20
>=20
> << To solve this, the TFO data should not be considered part of the Data
>   Sequence Number space:>>
> Is this a SHOULD NOT?  Does it imply a change to rfc7413 (the tfo rfc)? I=
 guess this is really a suggestion to the implementer?
>=20
> Section B.3
> I assume this sub-section is an example (so no SHOULD or even MAY are=20
> needed)
>=20
> << client                                                         server
>     |                                                              |
>     |    S 0(0) <MP_CAPABLE>, <TFO cookie request>                 |
>     | -----------------------------------------------------------> |
>>>=20
> Can you explain the S 0(0) nomenclature/ please.
>=20
>=20
> Appendix D Finite state machine
> I presume we don't need similar FSM for fastclose?
>=20
>=20
> Section 2:
> Need to add sub-sections on closing subflow & fast close & fallback
>=20
> S2.7 - I think the third bullet about notable features could be=20
> slightly altered, with enhanced security for ADD_ADDR and MP_CAPABLE.=20
> You could also add a mention of rfc7430
>=20
>=20
> Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so=20
> that Host A's key is sent only on the ACK (not on the SYN)? Is this so=20
> it's only sent when we know host B is MPTCP capable, which is=20
> therefore a slight security improvement?  (Just send a link to earlier=20
> emails, if that's easier)
>=20
> Thanks
> phil
> -----Original Message-----
> From: Eardley,PL,Philip,TUD1 R
> Sent: 14 June 2018 11:56
> To: 'philip.eardley@bt.com' <philip.eardley@bt.com>;=20
> multipathtcp@ietf.org
> Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis
>=20
> A few comments as I work through the document, basically minor so far
>=20
> Section 3.1
> << Given the SYN exchange is different between v1 and v0
>   the exchange cannot be immediately downgraded, and therefore if the
>   far end has requested a lower version then the initiator SHOULD
>   respond with an ACK without any MP_CAPABLE option, to fall back to
>   regular TCP.>>
> I think it should say "to ensure the exchange cannot..."
>=20
>=20
> << The first 4 bits of the first octet in the MP_CAPABLE option
>   (Figure 4) define the MPTCP option subtype (see Section 8; for
>   MP_CAPABLE, this is 0), and the remaining 4 bits of this octet
>   specify the MPTCP version in use (for this specification, this is 1).
>>>=20
> "The first 4 bits of the first octet in the MP_CAPABLE option" Fig 4 show=
s two earlier octets (Kind & Length) - I know these arent the MP-CAPABLE op=
tion, but I think it might be worth spelling out what they are.=20
>=20
> Would it be better strictly to have "0x0" rather than "0"? (ie match=20
> the IANA registry)
>=20
> Section 3.4.1
> <<A set of four flags are present after the subtype and before the
>   Address ID.  Only the rightmost bit - labelled 'E' - is assinged
>   today.  The other bits are currently unassigned and MUST be set to
>   zero by a sender and MUST be ignored by the receiver.
>=20
>   The 'E' bit exists to provide reliability for this option.  Because
>   this option will often be sent on pure ACKs, there is no guarantee of
>   reliability.  Therefore, a receiver receiving a fresh ADD_ADDR option
>   (where E=3D0), will send the same option back to the sender, but not
>   including the HMAC, and with E=3D1.  The lack of this echo can be used
>   by the initial ADD_ADDR sender to retransmit the ADD_ADDR according
>   to local policy.
>>>=20
> 4 comments:
> Assinged /assigned
>=20
> The 'E' bit - better to say flag?
>=20
> Section 2.3 needs to be amended to show the reply /echo message for ADD-A=
DDR. I suggest the pic in S2.3 also shows the E value.=20
>=20
> Not sure - does this open security hole, where an attacker pretends an=20
> ADD-ADDR has been received? (the Echo doesn't include an hmac, so is=20
> easy to spoof)
>=20
> And in Fig 12
> |        Truncated HMAC (8 octets, if length > 10 octets)       |
>=20
> Could this be made more straightforward? Ie spell out when length is >10 =
octets ie IPv6 (if I understand it). This also seems to mean that IPv4 does=
n't include the HMAC, is this right??
>=20
> Thanks
> phil
>=20
> -----Original Message-----
> From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of=20
> philip.eardley@bt.com
> Sent: 05 June 2018 09:14
> To: multipathtcp@ietf.org
> Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
>=20
> This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send c=
omments by the end of June.=20
>=20
> Please note there are three IPR disclosures (we're working on getting the=
m added to the rfc6824bis page):=20
>=20
> * two are inherited from RFC6824  https://datatracker.ietf.org/ipr/search=
/?submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed   =20
> * one is inherited from draft-paasch-mptcp-syncookies (which got=20
> include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/
>=20
> Thanks,
> Phil & Yoshi
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp
>=20
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp