Re: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE)

[<[e-mail]>]

Dear all,

any comments to my proposal from two weeks ago?

BR

Markus

> -----Original Message-----
> From: Amend, Markus
> Sent: Montag, 4. September 2017 14:17
> To: [e-mail]
> Subject: RE: [multipathtcp] A proposal for MPTCP Robust session
> Establishment (MPTCP RobE)
> 
> Dear all,
> 
> Based on feedback at IETF99, regarding MPTCP RobE proposal
> (https://datatracker.ietf.org/meeting/99/materials/slides-99-mptcp-a-
> proposal-for-mptcp-robust-session-establishment-mptcp-robe), I completely
> reconsider the original approach, I presented. Remember, the "Downgrade"-
> approach (see slides) was preferred from my side, because it combines
> robustness and a huge latency reduction.
> 
> The main feedback I got was:
> 
>   (1) Relying on SYN-Key-A as identifier to combine potential initial flows, raise
> several issues
>     (1.1) not available in RFC6824bis anymore
>     (1.2) security, because
>         (1.2.1) Key-A is transmitted many times
>         (1.2.2) can be abused by accident/intend
>   (2) Separate robustness and latency functionality
>   (3) To much computing resources needed on receiver side to detect
> duplicate Key-A
>   (4) Do it in the application layer library (build a shim layer); not in the
> MPTCP standard and/or implementation to reduce complexity
> 
> With the following reworked proposal (based on the "Downgrade" approach,
> see slides), I try to address all of the points above.
> 
> With Fig. 1, the flow diagram for the new proposal is depicted. It is referred
> to MPTCP version 0, but should be equivalent to probable version 1
> (RFC6284bis), just without a SYN-MP_CAPABLE containing Key-A.
> To reach robustness, several separate MPTCP initial flows are initiated at the
> beginning, in the following denoted as "potential initial flows". In step SA1
> and SA2, respectively SB3 and SB4, standard MPTCP initial flow procedure is
> applied, so no change so far. With occurring SA3/SA4 the requester "Host A"
> has to decide which potential initial flow will be used further as initial flow
> (e.g. the first which returns) and what shall happen with the other potential
> flows. Either it can break all but one (e.g. sending RST at SA6.1) OR recycle
> them (step SA6.2). Thereby, it is a full client side decision to use robustness
> only or benefit from latency reduction as well and can be toggled separately
> by e.g. sysctl globally and/or socket option.
> Until SA6.1, it doesn't require any MPTCP standard modification!
> 
>               Host A                                  Host B
>      ------------------------                       ----------
>      Address A1    Address A2                       Address B1
>      ----------    ----------                       ----------
>          |             |                                |
>          |            SYN + MP_CAPABLE(Key-A)           |
>  (SA1)   |--------------------------------------------->|  (SB1)
>          |             |    SYN + MP_CAPABLE(Key-A')    |
>  (SA2)   |             |------------------------------->|  (SB2)
>          |             |                                |
>  (SA3)   |<---------------------------------------------|  (SB3)
>          |          SYN/ACK + MP_CAPABLE(Key-B)         |
>  (SA4)   |             |<-------------------------------|  (SB4)
>          |             |   SYN/ACK + MP_CAPABLE(Key-B') |
>          |             |                                |
>          |        ACK + MP_CAPABLE(Key-A, Key-B)        |
>  (SA5)   |--------------------------------------------->|  (SB5)
>          |             |             RST                |
>  (SA6.1) |             |------------------------------->|  (SB6.1)
> robust   |             |                                |
> ness     |             |                                |
> -------------------------------------------------------------------
> latency  |             |                                |
> red.     |             | ACK + MP_JOIN_CAP(Key-A, HMAC) |
>  (SA6.2) |             |------------------------------->|  (SB6.2)
> 
>    Key-B_fast_hash = crc16(Key-B) & 0x3FF               -> (10bit)
>    HMAC_keys =  HMAC(Key-A+Key-B+Key-B')                -> (>=96bit)
>    HMAC =  (HMAC_keys & ~0x3FF) | Key-B_fast_hash       -> (size same as
> HMAC_keys)
> 
> Figure 1: Example Use of MPTCP RobE (for MPTCP version 0)
> 
> For not wasting resources by breaking all but one and benefit in addition
> from a huge latency reduction (see MPTCP RobE proposal, p.12,14+15,17),
> one can make use of a new proposed MPTCP option "MP_JOIN_CAP",
> illustrated in Fig. 2. According to Fig. 1, A1<->B1 is assumed as initial flow at
> SA3 and A2<->B1 shall be recycled at SA6.2 (SA6.1 is skipped therefore).
> Instead of sending an MP_CAPABLE in the third ACK, an MP_JOIN_CAP is
> sent, which includes Key-A of the selected initial flow A1<->B1 and an HMAC,
> coding Key-A, Key-B, Key-B' in a determined way (see Fig. 1 bottom).
> 
>                    1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +---------------+---------------+-------+-------+---------------+
> |     Kind      |    Length     |Subtype|       |    ADDR_ID    |
> +---------------+---------------+-------+-------+---------------+
> |                    Sender's Key-A (64 bits)                   |
> |                                                               |
> |                                                               |
> +---------------------------------------------------------------+
> |                        HMAC (>=96 bits)                       |
> |                                                               |
> |                                                               |
> :                                                               :
> +---------------------------------------------------------------+
> Figure 2: Multipath Join Capable (MP_JOIN_CAP) Option (for Third
> MP_CAPABLE ACK)
> 
> For the MP_CAPABLE, ADDR_ID is set to zero (like RFC6824) and for
> MP_JOIN_CAP it is sent with.
> 
> Which boundary conditions can happen:
> 
> 1. Like Fig. 1, A1<->B1 is assumed as initial flow and MP_CAPABLE receives
> first at Host B (SB5), A2<->B1 shall be recycled and ACK is sent with
> MP_JOIN_CAP
>    If MP_JOIN_CAP is received it has to iterate once (like MP_JOIN) the
> connection list and check for Key-A availability. If a Key-A connection is
> found, it is validated against HMAC value. The validation has two reasons,
> firstly several Key-A can exist, because different Hosts choose same Key-A by
> accident. Furthermore no one can join a connection by just recording/brute-
> forcing Key-A and duplicate the request. (solves point (1) from the feedback)
> 
> 2. Like 1., but MP_JOIN_CAP arrives before the MP_CAPABLE at Host B
> 
>     2.1 draft-ietf-mptcp-rfc6824bis-09
>         Based on Key-A, it will iterate over the connection list, but it will not
> match, because Key-A from formerly selected initial flow hasn't arrived yet.
> So it will continue with a fast iterate only over the connections, which are still
> in establishment phase, using the 10bit Key-B_fast_hash (crc16(Key-B) &
> 0x3FF). If it matches against a (precomputed) existing Key-B_fast_hash in the
> connection list, it will validate with the HMAC(Key-A+Key-B+Key-B') again to
> ensure legitimation. If successful, both, the initial flow and the MP_JOIN_CAP
> flow, can be immediately established. This is true, because without the
> knowledge of Key-B, Host A couldn't calculate the HMAC. So it is clear, that
> host A had received the SYN/ACK (SB3).
> This also mitigates the requirement of a reliable ACK (draft-ietf-mptcp-
> rfc6824bis-09, p.15) exchange, because only one
> MP_CAPABLE/MP_JOIN_CAP needs to reach receiver side.
> 
>     2.2 MPTCP version 0 (RFC6824)
>         Can match based on Key-A, like 1., same effort as for a MP_JOIN.
> 
> 3. A2<->B1 is selected as initial flow, because according SYN/ACK returns
> earlier at Host A.
>     It is the same as 1. and 2., just the other way round :-)
> 
> With these boundary conditions it has been shown, that no additional
> computing resources are required (see feedback (3)), compared to todays
> MPTCP, with a minimal exception of 2.1.
> 
> With such a simple approach, and by adding an inconspicuous simple MPTCP
> option MP_JOIN_CAP, MPTCP would be extended towards robustness and if
> desired, latency reduction can be enabled on top, but obviously requires
> receiver support. Negotiation is inherently given by the new MP_JOIN_CAP
> which is either accepted or not. If not, the standard MP_JOIN process can be
> applied.
> 
> Because of such a simplicity and the massive benefit by optional latency
> reduction, I still believe it fits best in the MPTCP layer itself and not in an
> application shim layer (see feedback (4)).
> 
> Due to the separation of robustness and latency reduction functionality, it
> offers the chance to implement "robustness" in plain TCP as well. It could
> look the same like in Fig. 1, (SA1)-(SA6.1), just without MP_CAPABLE option.
> But be aware, it needs some kind of path management, which is already
> present in MPTCP, but not in TCP. Furthermore I assume "robustness" is a
> topic more related to taps working group, whereas "latency reduction" is
> related to MPTCP obviously and depends on "robustness"!
> 
> BR
> 
> Markus