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

[<[e-mail]>]

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