Subject: [multipathtcp] SYN with join option

From: Sébastien Barré <[email-masked]>
Date: Sat, 06 Mar 2010 12:46:50 +0100

Hi,

Again, a small note, now about the JOIN option in the SYN (ideas coming 
as the implementation of v4 support progresses).

I would suggest that we specify in the draft that the JOIN option MUST 
be the first of the TCP options.
The reason for this is that the JOIN option is special in that it must 
be read *before* attaching the SYN to an existing connection. All other 
options are read when we now that the segment belongs to one of our 
connexions, or listening sockets at least.

In that particular case, in case the segment is not acceptable, we want 
to drop it as fast as possible, normally even before having parsed the 
options. This is to minimize the amount of processing we pay for 
segments that we will drop, and could be easily forged by an attacker.

If the position of the JOIN option is fixed with a MUST in the draft, 
then we can very efficiently find whether it is present, and decide if 
the SYN is valid or not.

thoughts ?

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre

---

From: Costin Raiciu <[email-masked]>
Date: Sat, 6 Mar 2010 13:55:26 +0000

Hi Sebastien,

That could make sense as an optimization, but I am not sure its needed . The amount of extra processing parsing options is not big; after all, how many options can you fit in the 40B space?

I am concerned that changing option ordering might break some middleboxes. I remember Murari saying that at microsoft they had issues when they introduced a new option because the option layout was changed; there were nops before options which crashed a few home gateways.

In any case, if we use this optimization it should be just an implementation thing and not in the spec. As far as I know, ordering options is not something that is usually done, so I wouldn't rely on ordering being kept by nats, etc.

Cheers,
Costin

On 6 Mar 2010, at 11:46, Sébastien Barré wrote:

> Hi,
> 
> Again, a small note, now about the JOIN option in the SYN (ideas coming as the implementation of v4 support progresses).
> 
> I would suggest that we specify in the draft that the JOIN option MUST be the first of the TCP options.
> The reason for this is that the JOIN option is special in that it must be read *before* attaching the SYN to an existing connection. All other options are read when we now that the segment belongs to one of our connexions, or listening sockets at least.
> 
> In that particular case, in case the segment is not acceptable, we want to drop it as fast as possible, normally even before having parsed the options. This is to minimize the amount of processing we pay for segments that we will drop, and could be easily forged by an attacker.
> 
> If the position of the JOIN option is fixed with a MUST in the draft, then we can very efficiently find whether it is present, and decide if the SYN is valid or not.
> 
> thoughts ?
> 
> Sébastien.
> 
> -- 
> Sébastien Barré
> Researcher,

---

From: Sébastien Barré <[email-masked]>
Date: Sun, 07 Mar 2010 12:20:15 +0100

Hi Costin,

> That could make sense as an optimization, but I am not sure its needed . The amount of extra processing parsing options is not big; after all, how many options can you fit in the 40B space?
You're right. I've sent the mail a bit too fast. Thinking more about it, 
it is not very clean to force that join option as being the first one, 
and as you say that could break some (poorly implemented) middleboxes. 
And the cost of finding the join option even if it is last is not that 
high, because, we can simply ignore earlier options as a first step, and 
jump to the join option directly. Other options can then be parsed 
later. IPv6 does already something similar with extensions headers.
> In any case, if we use this optimization it should be just an implementation thing and not in the spec.
Well, this particular optimization I was speaking about did require a 
change in the spec, because it was assuming the option be first. But 
anyway I finally agree that we should not assume that.

regards,

Sébastien.
>  As far as I know, ordering options is not something that is usually done, so I wouldn't rely on ordering being kept by nats, etc.
>
> Cheers,
> Costin
>