Subject: Re: [multipathtcp] I-D Action:draft-ietf-mptcp-threat-02.txt

From: Erik Nordmark <[email-masked]>
Date: Wed, 07 Apr 2010 07:48:42 -0700

On 03/29/10 06:34 AM, marcelo bagnulo braun wrote:
> Hi,
>
> I have updated the draft to reflect what we agreed in the last meeting
> I have added the following section
>
> 7. Reccomendation
>
> The presented analysis shows that there is a tradeoff between the
> complexity of the security solution and the residual threats. In
> order to define a proper security solution, we need to assess the
> tradeoff and make a recommendation. After evaluating the different
> aspects in the MPTCP WG, our conclusion is that the default security
> mechanisms for MPTCP should be to exchange a key in the establishment
> of the first subflow and then secure following address additions by
> using a keyed HMAC using the exchanged key (i.e. similar to the one
> used by SCTP).
>
> In addition, our recommendation is that the MPTCP protocol should be
> extensible and it should able to accommodate multiple security
> solutions, in order to enable the usage of more secure mechanisms if
> needed.
>
>
> If people agree with this, i think the document is done.

Looks reasonable.

But what happens if a different connection is established with the same 
IP addresses and port numbers, and different keys?

I'm think of a case where host A (at IP address X) connects to IP 
address Y, and then disconnects in a way where Y ends up with TIME_WAIT 
state.
Host A then drops its DHCP lease on X and host B asks DHCP for an IP 
address and is assigned X.
Then when B (at IP address X) tries to connect to host Y (assuming the 
port numbers match the above TIME_WAIT state), will things behave 
different than TCP today?

Will the presence of the above key mean that B will fail to talk to IP 
address Y while the above TIME_WAIT state exists?

I guess I don't understand to what object the key is bound.

    Erik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 11 Apr 2010 15:54:03 +0200

Hi Erik

sorry for the delay

below...

El 07/04/10 16:48, Erik Nordmark escribió:
> But what happens if a different connection is established with the 
> same IP addresses and port numbers, and different keys?
>
Good question.
I think we shoudl distinguish two cases here:
- One case is the one that the security mechanism has no strong binding 
with the address/port pairs used in the connection. Such mechanisms 
include the cookie, the keyed hmac (where the key used is exchanged in 
the clear during connection setup),or an ssh type of usage of public key 
crypto. In this case, the binding between the security material and the 
address/port involved in the connection is limited to the fact that the 
material was exchnaged in the connection. In this case, i thonk it 
should be first come first serve. This means that if we have an ongoing 
connection with a given security material and a new one come, we should 
honour the first one. The reason for that is that the second one, even 
if it uses stronger crypto, the binding between the security material 
and the connection itself is equally weak.
- The other case is when the different security mechanisms have 
different level of binding with the addresses or ports. These may 
include CGAs, certificates, or manually configured shared keys. All 
these cases have a strong link between the crypto material and the 
address of the endpoint. So, if the first connection was established 
using a cookie and later on, a new connection using a CGA is initiated, 
i think we should discard the first one and go for the CGA one.

would that make sense?

> address Y, and then disconnects in a way where Y ends up with 
> TIME_WAIT state.
i would apply the same than above, so it could behave differently than 
today, if the second one is using strong security and the first not

> I guess I don't understand to what object the key is bound.
imho the key is bound to the address/port of each endpoint.
I think the thing is to understnad how strong is the binding between the 
two and differen security mechanisms have different bindings.

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 21 Apr 2010 11:45:17 -0700

> i think we should discard the first one and go for the CGA one.

How would the above handle state loss?

For example, A completes the 3-way TCP handshake with B, and then A 
crashes and looses all state. Then A comes back up and tries the same 
connection (same IP addresses and port numbers, but presumably a 
different cookie etc). Would that SYN result in a RST? Silently ignored?
(Note that the TCP RFCs don't specify any form of timeout on the above 
connected TCB on B; implementations or the application that uses TCP 
might have some timeout.)

    Erik