Subject: [tcpm] TCP Long Options - Why not as payload in SYNs?

From: Michael Scharf <[email-masked]>
Date: Mon, 14 Jul 2008 14:14:24 +0200

Hi all,

I wonder whether "modern" TCP stacks indeed process application
payload data in SYN segments.

Even though RFC 793 explicitly allows payload in SYN segments, there
are TCP stacks that just seem to ignore it. Couldn't this offer an
opportunity to transport long TCP options in the payload of SYN
segments, instead of expanding the header option space?

Sorry if this question has already been answered elsewhere.

Michael
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Adam Langley" <[email-masked]>
Date: Mon, 14 Jul 2008 06:48:43 -0700

> Sorry if this question has already been answered elsewhere.

I don't have the necessary menagerie of operating systems needed to
gather good data. But Linux's net/ipv4/tcp_input.c [1] says

5188                         /* Now we have several options: In theory there is
5189                          * nothing else in the frame. KA9Q has an option to
5190                          * send data with the syn, BSD accepts
data with the
5191                          * syn up to the [to be] advertised window and
5192                          * Solaris 2.1 gives you a protocol error. For now
5193                          * we just ignore it, that fits the spec precisely
5194                          * and avoids incompatibilities. It would
be nice in
5195                          * future to drop through and process the data.

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/ipv4/tcp_input.c;h=cad73b7dfef07798ddc0b8debba24c9aad94c53b;hb=HEAD

And that suggests that it's not just those OSes which ignore SYNs with
payloads - it's also those which reject the packet completely. Having
to retransmit SYNs in such cases is sufficiently common, and
sufficiently painful that I think it's a non-starter.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Jul 2008 08:02:17 -0700

>> segments, instead of expanding the header option space?

See Usenix 2008, "A TCP-layer Name Service for TCP Ports"
http://www.usenix.org/events/usenix08/tech/full_papers/freire/freire_html/index.html

The authors, Sergio and Andre (cc'd), therein combine options in the SYN 
payload with other mechanisms in a port-names solution. I have spoken 
with them about cleanly separating the idea of data as payload option 
space (i.e., removing other features that are distinct, e.g., use of 
port 0, changing ports after the SYN, etc.), and basically we came up with:

	set a conventional option that says where the
	payload option ends, within the SYN segment
	(typically the end of that segment)

	wait for an ACK indicating that option is set
	(could be set in advance), indicating the
	options will be processed correctly
		NB - the option is set in advance when
		a sender speaks the option but has no
		long options to send, or has long options
		to send and is doing so. EITHER WAY
		the option MUST occur, or the handshake
		will fail.

	if the ACK does not confirm the ability to
	process options in the data, then RST the
	connection and retry without data options

Note that this works only for the SYN segment, and it isn't clear how it 
might interoperate with SYN cookies. It also ALWAYS consumes option 
space, and MUST occur in the existing options.

...
> payloads - it's also those which reject the packet completely.

AFAICT, ACKing the SYN and not the data is compliant, but rejecting the 
SYN entirely doesn't appear to be - it should be called a bug, IMO.

Joe

---

From: Michael Scharf <[email-masked]>
Date: Mon, 14 Jul 2008 17:03:08 +0200

> sufficiently painful that I think it's a non-starter.

This comment is probably over 10 years old (Linux kernel version
2.0.3x or earlier). This is why I asked for the behavior of "modern"
stacks (and, of course, "modern" middlebox implementations).

Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Jul 2008 08:20:17 -0700

PS - if there's interest in this, we could pull together an I-D in time 
for Dublin, but it won't (didn't) make the individual deadline...

Joe

---

From: "Adam Langley" <[email-masked]>
Date: Mon, 14 Jul 2008 09:16:04 -0700

On Mon, Jul 14, 2008 at 8:02 AM, Joe Touch <[email-masked]> wrote:
> AFAICT, ACKing the SYN and not the data is compliant, but rejecting the SYN
> entirely doesn't appear to be - it should be called a bug, IMO.

Sorry, that was written too early in the morning. The problematic
cases, of course, are where the host ignores a SYN with a payload, and
where it accepts such data as application level data. A host which
ACKed the SYN and ignored the payload provides for easy backwards
compatibility.

AGL

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 14 Jul 2008 15:45:27 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Michael Scharf
> Sent: Monday, July 14, 2008 5:14 AM
> To: [email-masked]
> Subject: [tcpm] TCP Long Options - Why not as payload in SYNs?
> 
> Hi all,
> 

Any stack that uses SYN Cookies, or wants the option to, will reject
any SYN that has payload.

If a stack were to decide to accept SYNs with Payload as part of an
optional enhancement then it would need a new method of defending from
SYN floods. Generally, any stack that obligates itself to retain state
in its memory on the basis of a single received SYN is a sitting duck
for a Denial of Service attack.

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Jul 2008 12:58:07 -0700

Caitlin Bestler wrote:
...
> any SYN that has payload.

Why couldn't it ACK the SYN but not the data, and compute the cookie 
based on the header only (as with an 'empty' SYN?)

As I noted before, rejecting a SYN just because it has data seems out of 
spec.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Jul 2008 14:03:24 -0700

Hi, all,

Sorry if my response below was cryptic. Let me clarify...

> based on the header only (as with an 'empty' SYN?)

Note that this is a valid response only where the data is NOT 
interpreted as extended option space.

AFAICT, SYN cookies are incompatible with long options, and yes, 
rejecting them is the appropriate response if cookies are required for 
all connections.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Jul 2008 14:57:33 -0700

...
> rejecting them is the appropriate response if cookies are required for 

PS - one conclusion that we could draw here is that:

- we can show that there are NO versions of extending TCP options that 
are truly backward compatible
	i.e., that use a single SYN

- we can also show that there are NO versions of extending TCP options 
that are compatible with SYN cookies
	as long as the ISN is the same length, there's only so much
	place for state

Overall, that may imply that we cannot extend the TCP option space in a 
backward compatible way, at which point maybe we're back to Mark 
Allman's "let's double all the fields" proposal, i.e., a 'clean slate' 
TCPv2...

Joe

---

From: Christian Huitema <[email-masked]>
Date: Mon, 14 Jul 2008 15:00:04 -0700

> rejecting them is the appropriate response if cookies are required for

Also, SYN cookies are only one specific defense against SYN flooding attacks. They are a good defense if the main worry is the memory consumed by connection state. They have however two drawbacks: they do nothing about "back flood", i.e. saturating the output NIC and link with SYN-ACK; and they diminish the robustness of the connection set-up for all applications where the first message comes from the server.

When experimenting with these attacks, I found that we can achieve a good defense with a combination of "short" state information in memory for the "half open" connections, and rate limiting of the number of SYN that a system is willing to process. Cookies would not help much, if at all.

-- Christian Huitema

---

From: "Sergio Freire" <[email-masked]>
Date: Mon, 14 Jul 2008 23:45:50 +0100

Hi Joe et all,
Yes, I think it would be a great idea to write an I-D concerning the use of
TCP options in the payload.. what is the deadline?
Sergio

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: segunda-feira, 14 de Julho de 2008 16:20
To: Joe Touch
Cc: [email-masked]; [email-masked]; Sérgio Freire
Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs?

PS - if there's interest in this, we could pull together an I-D in time for
Dublin, but it won't (didn't) make the individual deadline...

Joe

Joe Touch wrote:
> The authors, Sergio and Andre (cc'd), therein combine options in the 
> SYN payload with other mechanisms in a port-names solution. I have 
> spoken with them about cleanly separating the idea of data as payload 
> option space (i.e., removing other features that are distinct, e.g., 
> use of port 0, changing ports after the SYN, etc.), and basically we came
up with:
> Note that this works only for the SYN segment, and it isn't clear how 
> it might interoperate with SYN cookies. It also ALWAYS consumes option 
>> And that suggests that it's not just those OSes which ignore SYNs 
>> with payloads - it's also those which reject the packet completely.
> 
> AFAICT, ACKing the SYN and not the data is compliant, but rejecting 
> the SYN entirely doesn't appear to be - it should be called a bug, IMO.
> 
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Jul 2008 15:47:45 -0700

The deadline was last week for new individual submissions, but if useful 
we could just issue it when it's done anyway.

The question is whether the WG has interest... otherwise, we could wait 
until after the IETF ;-)

Joe

Sérgio Freire wrote:
> Hi Joe et all,
> Yes, I think it would be a great idea to write an I-D concerning the use of TCP options in the payload.. what is the deadline?
> Sergio
> 
> 
> PS - if there's interest in this, we could pull together an I-D in time for Dublin, but it won't (didn't) make the individual deadline...
> 
> Joe
> 
> Joe Touch wrote:
>> Adam Langley wrote:
>> use of port 0, changing ports after the SYN, etc.), and basically we came up with:
>>

---

From: "Adam Langley" <[email-masked]>
Date: Mon, 14 Jul 2008 16:42:25 -0700

On Mon, Jul 14, 2008 at 2:57 PM, Joe Touch <[email-masked]> wrote:
> - we can show that there are NO versions of extending TCP options that are
> truly backward compatible

I believe that's true if you're talking about extending the options in
a SYN packet.

> - we can also show that there are NO versions of extending TCP options that
> are compatible with SYN cookies

Well, it's reasonable for stacks to disable certain features when
using SYN cookies. Until very recently, I believe that Linux would
forget about SACK permitted options in the SYN when cookies were in
use. It got around that by using the TCP timestamp as extra cookie
space. (I'm informed that BSD uses the same timestamp/cookie trick.)
If SYN cookies are only enabled when some attack heuristic is met,
that's a reasonable thing to do.

Extensions which involve SYN options thus need to cope with the case
where they are ignored by a host under attack. (I've a draft, that
I'll probably post tomorrow, that does exactly that.)

AGL

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Jul 2008 17:35:10 -0700

Adam Langley wrote:
...
> I'll probably post tomorrow, that does exactly that.)

I don't think that's tenable. SYNs are where the presence of all 
capabilities are negotiated. TCP has no semantics for turning 
capabilities on after a connection is negotiated.

If you ignore options in the SYN, you're saying "I can't do that 
capability for the entirety of this connection". For options that are 
optional (i.e., that are disabled if not ACKd), that works fine, but 
then disables the feature for the rest of the connection.

For options that initiators want to require (e.g., TCP-AO, for one), if 
you ignore the option in the SYN-ACK, or forget that it was negotiated, 
the option will not work and the connection will be dropped.

That says you've hit a case where SYN cookies don't support TCP, not 
where your options aren't supported by SYN cookies, IMO.

Joe