Subject: [multipathtcp] Token on add / remove address?

From: <[email-masked]>
Date: Thu, 26 Aug 2010 12:05:32 +0100

The MP_JOIN Option includes the receiver's token. However, the ADD_ADDR & REMOVE_ADDR Options don't - I was wondering why not? Isnt the token needed to provide some protection against potential attacks?

Thanks
phil

---

From: "Ford, Alan" <[email-masked]>
Date: Thu, 26 Aug 2010 12:13:54 +0100

The ADD and REMOVE address options are only sent once a connection is
active, so the security is ensuring sequence numbers are within the
expected window, as with all other packets. The token security was
already applied when the new subflow was added, and thus regular TCP
sequence number protection takes over.

I feel this is sufficient, but would be interested to hear other views!

Regards,

Alan

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 26 August 2010 12:06
To: [email-masked]
Subject: [multipathtcp] Token on add / remove address?

The MP_JOIN Option includes the receiver's token. However, the ADD_ADDR
& REMOVE_ADDR Options don't - I was wondering why not? Isnt the token
needed to provide some protection against potential attacks?

Thanks

phil

---

From: <[email-masked]>
Date: Thu, 26 Aug 2010 17:31:10 +0100

ADD address - this is just information, actually starting a subflow needs the JOIN option - so maybe this is ok?

REMOVE address - this immediately has an impact in that triggers closure of all subflows using the address. maybe this should be better protected? or would you say that an attacker could send a FIN anyway, so no change in threat?
-----Original Message-----
From: Ford, Alan [mailto:[email-masked]]
Sent: 26 August 2010 12:14
To: Eardley,PL,Philip,DEE1 R; [email-masked]
Subject: RE: [multipathtcp] Token on add / remove address?

The ADD and REMOVE address options are only sent once a connection is active, so the security is ensuring sequence numbers are within the expected window, as with all other packets. The token security was already applied when the new subflow was added, and thus regular TCP sequence number protection takes over.

Regards,
Alan

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 26 August 2010 12:06
To: [email-masked]
Subject: [multipathtcp] Token on add / remove address?

Thanks
phil

---

From: "Ford, Alan" <[email-masked]>
Date: Thu, 26 Aug 2010 18:19:35 +0100

Yes, on ADD address the protection of the handshake is still to happen.

REMOVE we assume the connection is sound; however, I agree it is a more
powerful signal, and therefore for added security we do propose a
liveness check in the draft to ensure we do not remove paths that are
still alive and valid (assuming that would be a malicious attacker's
intention).

From: [email-masked] [mailto:[email-masked]] 
Sent: 26 August 2010 17:31
To: Ford, Alan; [email-masked]
Subject: RE: [multipathtcp] Token on add / remove address?

ADD address - this is just information, actually starting a subflow
needs the JOIN option - so maybe this is ok?

REMOVE address - this immediately has an impact in that triggers closure
of all subflows using the address. maybe this should be better
protected? or would you say that an attacker could send a FIN anyway, so
no change in threat?

	-----Original Message-----
	From: Ford, Alan [mailto:[email-masked]] 
	Sent: 26 August 2010 12:14
	To: Eardley,PL,Philip,DEE1 R; [email-masked]
	Subject: RE: [multipathtcp] Token on add / remove address?

	The ADD and REMOVE address options are only sent once a
connection is active, so the security is ensuring sequence numbers are
within the expected window, as with all other packets. The token
security was already applied when the new subflow was added, and thus
regular TCP sequence number protection takes over.

	I feel this is sufficient, but would be interested to hear other
views!

	Regards,

	Alan

	The MP_JOIN Option includes the receiver's token. However, the
ADD_ADDR & REMOVE_ADDR Options don't - I was wondering why not? Isnt the
token needed to provide some protection against potential attacks?

	Thanks

	phil

---

From: Christoph Paasch <[email-masked]>
Date: Fri, 27 Aug 2010 11:28:56 +0200

Hi all,

Concerning the REMOVE_ADDR:

What if the sender of this REMOVE_ADDR wants to remove the address, even if it 
is still reachable?
He could close all subflows using this address, and stop listening on this 
address. Then he will send out the REMOVE_ADDR over another subflow.

The peer will probably try to reopen subflows to this address, as soon as the 
connection has been closed.
Then, when the peer receives the REMOVE_ADDR, what will he do? He cannot send 
TCP Keepalives, because there is no active subflow established to this 
address. Should he wait to check if we can establish TCP subflow? This may 
take quite some time, waiting for the TCP establishment to timeout.

Maybe we should not do the liveness check, and add the token to the 
REMOVE_ADDR? This way, we will have a faster removal of the address.

Or we add to the draft, that if no subflow is established to the concerning 
address, we remove the address immediatly from the list without any 
reachability-tests.

Regards,
Christoph

--
Christoph Paasch

Alcatel-Lucent
Software Design Engineer
IP Division

www.rollerbulls.be
--

---

From: "Ford, Alan" <[email-masked]>
Date: Fri, 27 Aug 2010 10:42:47 +0100

Hi Christoph,

You say:

"if no subflow is established to the concerning address, we remove the
address immediatly from the list without any reachability-tests."

That is the intention of this test, and I shall make it clearer in the
text. The TCP keepalive is there to verify that the TCP subflow is not
still active. If it is active, it should be closed cleanly with a FIN
exchange. If the peer tries to immediately re-establish the subflow, the
SYNs can be ignored by the implementation.

Another corner case occurs to me, however, in that a middlebox may
respond to the keepalive when the end host has lost the subflow.
However, the DATA_ACK will ensure that no data is lost and that the
connection will continue, and over time the subflow will naturally
close. This is not as optimal, however, and could be a case against this
keepalive check. I don't feel that the token is a sufficiently useful
protection, however, since we already have the sequence number checks
which require fresh data, rather than the token which is static. A
better security mechanism (which could be an extension rather than core
to the spec) could be extended to support authenticating these control
messages.

Regards,
Alan

> From: Christoph Paasch [mailto:[email-masked]]
> Sent: 27 August 2010 10:29
> Cc: Ford, Alan; [email-masked]
> Subject: Re: [multipathtcp] Token on add / remove address?
> 
> Hi all,
> 
> What if the sender of this REMOVE_ADDR wants to remove the address,
even if
> it