Subject: [multipathtcp] A five-way handshake for mptcp subflows

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 22 Nov 2010 22:19:06 +0100

Hello,

In the current draft, a mptcp subflow is established by exchanging
information in the payload. Using the payload to exchange hashes has the
advantages of being able to exchange unlimited data compared to the
limited size of the tcp options. However, from a security viewpoint, it
is not clear that sending the complete hash has benefits over exchanging
a truncated hash, see

  http://tools.ietf.org/html/rfc2104
  http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf

The current draft defines the subflow establishment as follows :

              Host A                                     Host B
     ------------------------                   ------------------------
     Address A1    Address A2                   Address B1    Address B2
     ----------    ----------                   ----------    ----------
         |             |                            |             |
         |         SYN + MP_CAPABLE(Key-A)          |             |
         |----------------------------------------->|             |
         |<-----------------------------------------|             |
         |       SYN/ACK + MP_CAPABLE(Key-B)        |             |
         |             |                            |             |
         |      ACK + MP_CAPABLE(Key-A, Key-B)      |             |
         |----------------------------------------->|             |
         |             |                            |             |
         |             |        SYN + MP_JOIN(Token-B, R-A)       |
         |             |----------------------------------------->|
         |             |<-----------------------------------------|
         |             |      SYN/ACK + MP_JOIN(Token-A, R-B)     |
         |             |                            |             |
         |             |  HMAC(Key=(Key-A+Key-B), Msg=(R-A+R-B))  |
         |             |----------------------------------------->|
         |             |<-----------------------------------------|
         |             |  HMAC(Key=(Key-B+Key-A), Msg=(R-B+R-A))  |
         |             |                            |             |

R-A and R-B are random nonces that are chosen by A and B. Combined with
the HMACs, this creates a four-way handshake that does not fit in the
three way handshake used by TCP.

It is however possible to fit this four-way handshake in TCP's three way
handshake by using a RST segment as follows :

              Host A                                     Host B
     ------------------------                   ------------------------
     Address A1    Address A2                   Address B1    Address B2
     ----------    ----------                   ----------    ----------
         |             |                            |             |
         |         SYN + MP_CAPABLE(Key-A)          |             |
         |----------------------------------------->|             |
         |<-----------------------------------------|             |
         |       SYN/ACK + MP_CAPABLE(Key-B)        |             |
         |             |                            |             |
         |      ACK + MP_CAPABLE(Key-A, Key-B)      |             |
         |----------------------------------------->|             |
         |             |                            |             |
         |             |        SYN + MP_JOIN(Token-B, R-A)       |
         |             |----------------------------------------->|
         |             |<-----------------------------------------|
         |             |      RST + MP_JOIN(Token-A, R-B)         |
         |             |                                          |
         |             |SYN Token B, HMAC(Key=(Key-A+Key-B),
Msg=(R-A+R-B))  |
         |             |----------------------------------------->|
         |             |<-----------------------------------------|
         |             |  SYN+ACK HMAC(Key=(Key-B+Key-A), Msg=(R-B+R-A))  |
         |             |                            |             |
         |             |        ACK    	            |             |
         |             |----------------------------------------->|

We could discuss about the number of options to be placed inside the
second SYN and whether host B needs to maintain state after having sent
the RST segment, but this could be possible way to exchange the same
information as in the current draft by using options instead of payload.

Note that given the utilisation of NATs, the IP addresses and port
numbers used by the second SYN used to open a subflow are not guaranteed
to be the same as those used for the first SYN that triggered a RST.

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: "Ford, Alan" <[email-masked]>
Date: Wed, 24 Nov 2010 09:29:50 -0000

Hi Olivier, all,

> The current draft defines the subflow establishment as follows :

It would be possible to do this with a 3-way handshake if a 32-bit
truncated HMAC was sufficient - if so, the second payload HMAC in the
above exchange could be used in place of Token-A in the SYN/ACK+MP_JOIN,
and the first HMAC could be placed in a TCP option in the first ACK,
instead.

That's a rather neater solution than using a RST, I feel :)

The two issues are whether that length of HMAC is sufficient (it could
be longer in the TCP option in the ACK A->B, but not in the B->A
SYN/ACK), and whether it is useful for middleboxes such as IDSs to
correlate MPTCP subflows by observing the tokens in both directions.

Regards,
Alan

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 24 Nov 2010 11:05:06 +0100

Alan,

>From a security viewpoint one questiont o be answered is whether Host B
should perform a computation upon reception of the first SYN to open a
subflow since it needs to reply with a segment that contains a HMAC

              Host A                                     Host B

There is a (small) risk of DoS attack which is mitigate by the fact that :
- the attacker must know Token-B
- host B can rate limit the number of SYN+MP_JOIN that it accepts for a
given MPTCP connection

Concerning the space for the options, we currently have
- MSS : 4 bytes
- WScale : 3 bytes
- SACK permitted : 2 bytes
- Timestamp : 10 bytes

There are thus only roughly 20 bytes available in the SYN segment for
additional options. One possibility to preserve option space would be to
use the RFC1323 timestamps that are placed in the SYN and SYN+ACK
segments as the R-A and R-B nonces. Using random numbers in the
timestamp option is compatible with RFC1323 and does not prevent an
MPTCP implementation to measure the rtt of the SYN/SYN+ack exchange.

>From an implementation viewpoint, this would imply that MPTCP must use
RFC1323, but this looks reasonable and furthermore the current
implementation in the Linux kernel already requires the timestamp option
to estimate its required buffers anyway.

Olivier

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 24 Nov 2010 17:08:10 -0800

Hi Olivier,

IMO, one potential risk of this method is it might be possible for
attackers to make victims calculate HMAC many times by doing something
like below, when token-B is stolen. In the current proposal, attackers
need to wait the completion of 3 way handshake.
The simple solution for this might be the followings
   1: require sender to echo back R-B in the second SYN
   2: receiver checks if R-B is valid before HMAC calculation
   3: if HMAC calculation fails once, receiver makes R-B invalid forever.

  --> SYN + MP_JOIN(Token-B, R-A)
  <--     RST + MP_JOIN(Token-A, R-B)
  --> SYN + Token B, HMAC(dummy)
  --> SYN + Token B, HMAC(dummy)
  --> SYN + Token B, HMAC(dummy)

Another risk is if reset is filtered by any chance, this method cannot
be used. although I'm not sure this is crucial or not yet..
I will think about this more.

Thanks,
--
Yoshifumi Nishida
[email-masked]

2010/11/22 Olivier Bonaventure <[email-masked]>:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>