Subject: Re: [multipathtcp] A Second Layer of Security

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Dec 2010 08:57:14 -0800

On 12/15/10 05:59 AM, Ford, Alan wrote:
> Hi all,
>
> This is something that I mentioned in the call yesterday, but wasn't
> central to the discussions. However, I feel it's worth raising in email
> in case of strong opinions.
>
> In regular TCP, protection against blind injections of spoofed data lies
> with ensuring the packet header has the correct static (addresses,
> ports, etc) and dynamic (sequence number) information. It is the
> sequence number that removes the threat from a time-shifted attack.
>
> In MPTCP, we have the connection-level sequence number, but as it stands
> this does not provide the same level of protection against time-shifted
> attacks that it does in regular TCP. This is because an attacker could
> connect to a server, receive data, glean the DSN in use, and use this to
> inject data towards the other host.

Why would you need to share send the DSN before you know that the new
subflow is from the same peer as the existing connection?

    Erik

---

From: "Ford, Alan" <[email-masked]>
Date: Thu, 16 Dec 2010 17:09:41 -0000

Hi Eric, all,

> subflow is from the same peer as the existing connection?

The scenario is that where a weakness is exploited in the security
mechanism. In the original token-based approach, this weakness was the
way that anyone observing a token could connect as a new subflow. With
the HMAC approach this threat is greatly reduced but still exists if an
observer sees the first SYN handshake of a connection.

We cannot just say that a client must send data before it can receive it
(to prove its knowledge of DSN), since in many cases - such as a large
download from a web server - there may never have any data to send in
the upstream. But what I was wondering was whether it would be
worthwhile to say that a client must send a DSN_MAP with zero length to
prove it has up-to-date knowledge of its DSN, before it can receive
data.

However, the trouble with anything based on sequence numbers is that it
just increases the complexity of the guessing game, and makes the
security mechanism less deterministic. Marcelo, for example, has
commented on a number of occasions that it is maybe better to have a
deterministic security mechanism where the weaknesses are clear, rather
than one that in some cases is better but in others is no better. I'd be
inclined to agree, but was wondering whether there were any other views
on this.

Regards,
Alan

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 18 Dec 2010 02:38:21 -0800

Hi Alan,

In case that we use subflows as backup, we might want to send a kind
of keep-alive messages to them periodically.  (just like SCTP does)
In such case, I think including DSN info in keep-alive ACK packet
won't be a big overhead and can be useful in some cases.

Thanks,
--
Yoshifumi Nishida
[email-masked]

2010/12/16 Ford, Alan <[email-masked]>:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>