Subject: Re: [multipathtcp] Reconsidering MPTCP connection establishement

From: "Ford, Alan" <[email-masked]>
Date: Wed, 1 Sep 2010 12:58:02 +0100

Yes, this proposal would tie the generation of each peer's ISN to both the tokens used.

However, this nevertheless seems like a good idea. As briefly mentioned at IETF78, we were already looking at ways to remove the ISN from the handshake, possibly by generating it as a truncated hash of the token.

This improves on that by providing SYN-Cookie-style protection (if desired) while reducing the MP_CAPABLE option length.

In the simple idea proposed below, in order for the passive listener to re-derive its token, it gets sent for the first X (where X is between 2^31 and 2^32) bytes of data as the upper bits of the DSN. I can't help wondering if that weakens the security of the token for future MP_JOIN handshakes (although we are of course going to improve the security mechanism anyway). 

It would be preferable if there was a way for the passive listener to re-derive its token including a secret. But since it has to be re-derivable from data that the initiator has sent, the initiator must have the token or be able to also undertake this hashing. So unless we could use the Timestamp for this, I can't see a way of achieving this. Hmm.

This proposal sounds like it will work, and seems neat, although I think we need to consider the security implications in a little more detail before adopting it.

Regards,
Alan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Yoshifumi Nishida
> Sent: 01 September 2010 07:56
> To: [email-masked]
> Cc: multipathtcp
> Subject: Re: [multipathtcp] Reconsidering MPTCP connection establishement
> 
> Hello,
> 
> I think It's an interesting idea.
> My little concern is that this seems to require the initiator and the
> passive listener to have a common function to convert token from
> initial data seqnum,
> Does this imply we need to have a common function for all mptcp
> implementations?
> 
> Thanks,
> --
> Yoshifumi Nisihda
> [email-masked]
> 
> 2010/8/31 Olivier Bonaventure <[email-masked]>:
> > Hello,
> >
> >
> > Current TCP stacks implement different variants of TCP syn cookies and
> > these SYN cookies are important on servers. The current proposed MPTCP
> > specification is not friendly with syn cookies as there is additional
> > state to be stored by the passive listener (tokens, initial data
> > sequence numbers).
> >
> > In order to preserve the ability of supporting syn cookies with MTCP,
> > I'd suggest the following change to the MPTCP specification :
> >
> > 1- remove the initial data sequence number from the MPTCP_CAPABLE
> > option. This option would become
> >
> >                           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=MP_CAPABLE|   Length=6    |       Sender Token            :
> >      +---------------+---------------+-------------------------------+
> >      : Sender Token (4 bytes total)  |
> >      +-------------------------------+
> >
> >
> > 2- Force the initiator and the passive listener to put a DSN_MAP option
> > in the first segment that they sent.
> >
> > 3- a- Choose the initial data sequence number of the initiator as the
> > concatenation of the sender token followed by the receiver token (or any
> > easily invertible function of these two tokens)
> >   b- Choose the initial data sequence number of the passive listener as
> > the concatenation of the receiver token followed by the sender token (or
> > any easily invertible function of these two tokens)
> >
> >
> > By using this, a MPTCP capable implementation that wants to support syn
> > cookies only need to store one additional bit of information, the fact
> > that MPTCP has been requested. This can be easily added to the linux and
> > freebsd stacks and should be easy on other stacks as well.
> >
> > When a passive listener receives a syn segment, it chooses a token at
> > random (or by using some special computation with a secret if it wants
> > to) and returns it in the syn+ack. It does not need to store it since it
> > will be able to easily recover it from the DSN_MAP found in the first
> > segment sent by the initiator. The passive listener uses the
> > acknowledgement field to verify that the initiator has correctly
> > received the initial sequence number that it choose and sent in the
> SYN+ACK.
> >
> > It seems to me that this change simplifies mptcp and preserves the
> > ability of using syn cookies on servers which is very important.
> >
> >
> >
> > Olivier
> > _______________________________________________
> > multipathtcp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> >
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 1 Sep 2010 16:43:36 -0700

Hi Alan,
I also think this looks a good idea.
But, I feel at least we had better disable this logic when the passive
listener doesn't use SYN cookie.
We might need one bit in MP_CAPABLE that indicates the use of SYN
cookie, or might need other good signaling methods for this.

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: "Ford, Alan" <[email-masked]>
Date: Thu, 9 Sep 2010 13:17:40 +0100

Hi Olivier, all,

I've been thinking about this a bit more, and am a bit uncomfortable with this idea of having the token sent regularly (as part of the sequence number) for a long time (potentially the whole length of the connection).

I first looked at this problem thinking "how do we make MPTCP compatible with existing TCP SYN Cookies?". However, since we're still in the process of designing MPTCP we can be more flexible, and therefore we can say "how can we build SYN-Cookie-like behaviour into MPTCP?"

The answer may be to echo the tokens again in the first pure ACK, with a new option, i.e:

A->B: SYN + MP_CAPABLE (Token A)
B->A: SYN/ACK + MP_CAPABLE (Token B)
A->B: ACK + MP_ECHO (Token A + Token B)

If the ISNs are generated by a hash, e.g. SHA-1, of the tokens, the ones present in the ACK can be verified. If a server wishes to use this for a SYN-cookie-like mechanism, it MUST generate its token through a verifiable cryptographic mechanism (so it can verify it when it comes back in the MP_ECHO).

This way, we get the benefit of SYN cookies without changing anything beyond adding in one extra option in one packet, and the token remains rarely used after this initial exchange.

Any thoughts?

Cheers,
Alan

> Behalf Of Ford, Alan
> Sent: 01 September 2010 12:58
> To: Yoshifumi Nishida; [email-masked]
> Cc: multipathtcp
> However, this nevertheless seems like a good idea. As briefly mentioned at
> IETF78, we were already looking at ways to remove the ISN from the handshake,
> possibly by generating it as a truncated hash of the token.
> 
> This improves on that by providing SYN-Cookie-style protection (if desired)
> while reducing the MP_CAPABLE option length.
> 
> In the simple idea proposed below, in order for the passive listener to re-
> derive its token, it gets sent for the first X (where X is between 2^31 and
> 2^32) bytes of data as the upper bits of the DSN. I can't help wondering if
> that weakens the security of the token for future MP_JOIN handshakes
> (although we are of course going to improve the security mechanism anyway).
> 
> It would be preferable if there was a way for the passive listener to re-
> derive its token including a secret. But since it has to be re-derivable from
> data that the initiator has sent, the initiator must have the token or be
> able to also undertake this hashing. So unless we could use the Timestamp for
> this, I can't see a way of achieving this. Hmm.
> 
> This proposal sounds like it will work, and seems neat, although I think we
> need to consider the security implications in a little more detail before
> adopting it.
> 
> Regards,
> Alan
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 09 Sep 2010 14:28:50 +0200

Alan,
> I've been thinking about this a bit more, and am a bit uncomfortable with this idea of having the token sent regularly (as part of the sequence number) for a long time (potentially the whole length…

As the sequence number changes after each transmission, there is no
regular transmission of the token. Only the first segment contains the
token inside the data sequence number.

> A->B: ACK + MP_ECHO (Token A + Token B)

This is a possibility as well.

> This way, we get the benefit of SYN cookies without changing anything beyond adding in one extra option in one packet, and the token remains rarely used after this initial exchange.

This increases the number of options in the first ACK segment, but is
not a crowded segment and thus this should not be a problem

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

---

From: "Ford, Alan" <[email-masked]>
Date: Thu, 9 Sep 2010 13:54:52 +0100

Olivier,

> token inside the data sequence number.

As I had understood your proposal, you would generate the ISNs as
follows:
ISN-A = TokA + TokB
ISN-B = TokB + TokA
Where the ISNs are therefore 64 bits, from the two 32-bit tokens.

This would lead to the most significant 32 bits of the ISN, for the
first 2^32 bytes of the connection, being the token.

Whatever method is used, the passive listener must be able to derive its
token back from the sequence number, so it can't be encrypted.

Or have I misunderstood your ISN generation ideas?

Regards,
Alan

---

From: Joe Touch <[email-masked]>
Date: Thu, 09 Sep 2010 08:35:16 -0700

FWIW, I doubt you will want to use hashes to generate anything 
per-connection unless the connection has true security (authentication 
or encryption).

The overhead for non-secure connections would be quite high.

Joe

On 9/9/2010 5:17 AM, Ford, Alan wrote:
>>> 2010/8/31 Olivier Bonaventure<[email-masked]>:
>>>> Hello,
>>>>
>>>>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 13 Sep 2010 03:30:03 -0700

Hi Alan,

I think I don't fully understand your idea yet, but I have the
following thoughts on this. Please correct me if I'm misunderstanding
something.
 If cookie is not enabled, I think it would be better there is no
relationship between ISN and tokens.
 If cookie is enabled and if we have a way to regenerate tokens, I
don't see a strong reason why we have to verify it.

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 14 Sep 2010 00:09:51 -0700

Hi,
I sometimes think that token exchange can be initiated after 3 way-handshake.
what is the rationale to do this during 3 way handshake?
--
Yoshifumi Nishida
[email-masked]

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 14 Sep 2010 09:27:04 +0200

Yoshifumi,

> what is the rationale to do this during 3 way handshake?

doing the token exchange after the 3-way handshake could be tricky as
the token the placed inside options and options are not reliably
delivered by TCP (e.g. a middlebox could remove the token option on one
of the path)

If we exchange the tokens during the 3-way exchange, then at least the
SYN are acknowledged explicitely since they consume one sequence number

Olivier

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Sep 2010 09:30:27 +0200

If i understadn what you are asking correctly, at least from a 
security perspective, having the token exchanged at the connection 
establishment imposes the attacker to be along the path during that 
particular packet exchange. If you delay that, all the time that you 
delay it, it is a vulnerability window during which the attacker could 
send its own token

Regards, marcelo

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 14 Sep 2010 00:54:58 -0700

Hi Olivier,
it might a bit tricky, but I'm not sure it's harmful.
if a middlebox removes token option, it probably will remove other
mptcp options.
which means in any case, we have to fall back to normal TCP.
--
Yoshifumi Nishida
[email-masked]

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 14 Sep 2010 01:10:04 -0700

Hi Marcelo,
I agree, but, In my feeling, we could implement challenge-response
type scheme to exchange tokens and it might mitigate the vulnerability
for delaying.
--
Yoshifumi Nishida
[email-masked]

2010/9/14 marcelo bagnulo braun <[email-masked]>:
>  If i understadn what you are asking correctly, at least from a security
> perspective, having the token exchanged at the connection establishment
> imposes the attacker to be along the path during that particular packet
> exchange. If you delay that, all the time that you delay it, it is a
> vulnerability window during which the attacker could send its own token
>
> Regards, marcelo
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Sep 2010 10:19:59 +0200

> type scheme to exchange tokens and it might mitigate the vulnerability

mmm, during the conection establishment or after?

I mean, the key question is how do you bind the security material to the 
connection?
If you exchange the security material during the connection 
estbalishment, an attacker can mess with this initial packet, but if he 
missed that oportunity, then he is out of luck. If you delay that, then 
all the time you delay it it is time the connection is exposed to 
attacks afaict.

Regards, marcelo
> --
> Yoshifumi Nishida
> [email-masked]
>
> 2010/9/14 marcelo bagnulo braun<[email-masked]>:

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 14 Sep 2010 01:56:40 -0700

Hi,

> mmm, during the conection establishment or after?

It's after connection establishment.

> If you exchange the security material during the connection estbalishment,
> an attacker can mess with this initial packet, but if he missed that
> oportunity, then he is out of luck. If you delay that, then all the time you
> delay it it is time the connection is exposed to attacks afaict.

Yes, you can attack anytime in this case.
maybe I miss some points, but what I thought was if a node receives
token-update request, it sends some random value with the response.
If a peer sends back this random value properly, the node can take the
token as valid one.
This might not be strong enough, but might "mitigate" the
vulnerability against off-path attacks.

Thanks,
--
Yoshifumi Nishida
[email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Sep 2010 13:01:33 +0200

> token-update request, it sends some random value with the response.
No, my understanding is that the token is the same for all subflows and 
it is defined in the establishment of the first subflow (i.e. the 
connection setup) that is what provides stronger security features.

Regards, marcelo

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 15 Sep 2010 00:07:24 -0700

Hi Marcelo,

2010/9/14 marcelo bagnulo braun <[email-masked]>:
>>> estbalishment,
> No, my understanding is that the token is the same for all subflows and it
> is defined in the establishment of the first subflow (i.e. the connection
> setup) that is what provides stronger security features.

I guess this is a bit controversial point, but is it true for
long-lived sessions?
Also, if we want to support syn cookie-friendly mechanism, we might
need to have weaker tokens.
I'm thinking that updating token mechanism might be useful for this.

Thanks,
--
Yoshifumi Nishida
[email-masked]

>>>>> security

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Sep 2010 09:19:53 +0200

El 15/09/10 9:07, Yoshifumi Nishida escribió:
> I guess this is a bit controversial point,
I am not sure what do you mean by controversial...

>   but is it true for
AFAICT, this is true for all mptcp connections

> need to have weaker tokens.
what do you mean by weaker?

> I'm thinking that updating token mechanism might be useful for this.
i am fine with changing the token mechanism.
I think we are really in the minimum level of security we can have for 
this. I don't think we can make it weaker than a token exchanged at the 
moment of the connection establsihment. Actually, the result of the 
threat disucssion was that it needs to be stronger than a simple token, 
and options like using a keyed HMAC with a key exchanged during the 
connection establishment were considered

Regards, marcelo