Subject: [tcpm] Extending TCP option space

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 31 Aug 2011 16:57:00 +0300

Hi,

TCP's option space has been under increasing demand recently, with new option-space hungry extensions such as MPTCP, and some recent ideas in the research domain. In the past there have been some discussion about mechanisms to extend the option space, and an extension option was proposed in draft-eddy-tcp-loo, but since then these efforts have died down. I'm wondering if there would be any interest in the tcpm community to resume this work.

I recall that re-segmenting middleboxes were mentioned as one potential problem for such extension, and there might be other problems. Nevertheless, I would find it useful, if there was an RFC that a) documented the known problems with option space extension; and b) defined an option format and assigned the needed type codes, to enable experimentations with larger than 40-byte option space.

Thoughts?

- Pasi

---

From: Tim Shepard <[email-masked]>
Date: Wed, 31 Aug 2011 10:26:54 -0400

Several years ago, I posted to the TCPM list a ha-ha-only-serious
proposal that what we need is a single new minimal size option called
IAMACAHYAT which could be exchanged on the SYN and SYN-ACK packets.

This would be used to allow both ends to signal to each other that
they are fully prepared to negotiate further options on later
segments.

There was a belief at least among some that unexpected options on
anything other than the SYN are dangerous because there might be
stacks out there that handle them badly, like crashing.  So we seemed
to be stuck requiring all new options to somehow fit in the
SYN/SYN-ACK exchange.

And now that I think of it, perhaps it would have been good if MPTCP
had not filled up most all of the remaining option space on the SYN
with its new options but had instead required use of the IAMACAHYAT
option on the initial SYN/SYN-ACK exchange, and then did its
own option negotiation on later packets.

I think this sort of hack could help quite a bit.

(Though I understand that for some things we might very much want the
 new options to fly on the initial SYN SYN-ACK exchange to avoid
 having to wait another round trip for the negotiation to happen.)

			-Tim Shepard
			 [email-masked]

---

From: "SCHARF, Michael" <[email-masked]>
Date: Wed, 31 Aug 2011 16:44:11 +0200

Hi Pasi,

> TCP's option space has been under increasing demand recently, with new

> option-space hungry extensions such as MPTCP, and some recent ideas in

> the research domain. In the past there have been some discussion about

> mechanisms to extend the option space, and an extension option was 
> proposed in draft-eddy-tcp-loo, but since then these efforts have died

> down. I'm wondering if there would be any interest in the tcpm 
> community to resume this work.
> 
> I recall that re-segmenting middleboxes were mentioned as one 
> potential problem for such extension, and there might be other 
> problems. Nevertheless, I would find it useful, if there was an RFC 
> that a) documented the known problems with option space extension; and

> b) defined an option format and assigned the needed type codes, to 
> enable experimentations with larger than 40-byte option space.
> 
> Thoughts?

actually, I happened to argue in favor of a) in hallway discussions
during the last IETF meetings. Maybe someone should just start to put
together some text, at least for a)... (And I think it would really make
sense to raise awareness among researchers that TCP option space in SYNs
is a really scarce resource.)

Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Aug 2011 08:46:16 -0700

FWIW, I had offered to summarize the reasons why this has failed in the 
past (and, IMO, simply isn't useful to pursue).

Again, let me know.

Joe

On 8/31/2011 7:44 AM, SCHARF, Michael wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Aug 2011 08:58:44 -0700

> they are fully prepared to negotiate further options on later

Whether this works or not - as per middlebox interactions - is less 
important than it not solving the problem.

In a nutshell:

	- extending option space after then TWHS is trivial
		define a new option, confirm it with a SYN exchange,
		and either the SYN gets dropped (some midboxes),
		the option is dropped (others), or it works.

		if the SYN is retransmitted, retransmit without the
		option and tell the user it failed ;-(

	- extending the SYN option space is the real issue anyway
		- put in an option and extend the options right then
			this breaks under 'ignore unknown options',
			since the end of the options will be mis-
			read as data

		- put in an option and use the data in the SYN
			this breaks under 'ignore unknown options',
			since the option-as-data will be mis-
			read as data

		- put in something that breaks if unknown
			this is the same as using a new transport
			protocol number, and won't pass through NATs

If anyone sees a way around #2, please speak up. My recollection is that 
we've dragged this dog around the block every few years, and realize the 
same thing:

	TCP SYN option space cannot be extended

There may be use to extending the space after the SYNs (someone can 
propose that), but doing it in the SYNs doesn't appear to be possible.

> to be stuck requiring all new options to somehow fit in the

Options are exchanged reliably only during connection establishment. 
There is no TWHS after that. So starting a new option after the 
connection starts seems difficult at best - however, it fails to solve 
the key issue:

	- starting after the SYN has no real use given you can
	start the option during the SYN with 2 bytes

	- extending the SYN option space isn't helped by starting
	after the SYN

Another suggestion was to set an option that can affect future TCP 
connections, but this is a problem because:
	a) hosts that restart could use new stacks that don't
	support the option, and have no way to safely ignore it
	b) IP addrs can be/are shared among endpoints (behind NATs,
	or via L2 muxing)

> own option negotiation on later packets.

Option negotiation on subsequent packets needs to build in enough of a 
state machine to consider what happens when packets are replayed or come 
out of order. The TWHS already handles that, but there doesn't appear to 
be a good way to do that once a connection is established.

Joe

---

From: Tim Shepard <[email-masked]>
Date: Wed, 31 Aug 2011 12:08:06 -0400

> propose that), but doing it in the SYNs doesn't appear to be possible.

I think the space could be extended on the SYN-ACK if there was
something on the SYN that indicated that the initiator could handle
it.  Just not on the initial SYN.   (Middle boxes: grumble.
Simultaneous open: uh huh.)

			-Tim Shepard
			 [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Aug 2011 09:12:44 -0700

> Simultaneous open: uh huh.)

It's the SYN that's the real problem. Sure, once you confirm, the 
SYN-ACK is fair game as are all subsequent packets.

Joe

---

From: Mark Allman <[email-masked]>
Date: Wed, 31 Aug 2011 12:15:47 -0400

> to be stuck requiring all new options to somehow fit in the

Well,

  - It is 2011.  If something crashes because of the arrival of an
    unknown option it probably has bigger problems.

  - In particular, in a study a few years back [*] we found that an
    unknown option in the SYN caused connection failures in 0.2% of the
    cases.  And, further, unexpected [**] options plopped on a packet
    after the 3WHS caused connection failure rates of 3%.  I'd bet that
    by now that is likely even lower.  But, at least that is some data.

allman

[*] Alberto Medina, Mark Allman, Sally Floyd.  Measuring the Evolution
    of Transport Protocols in the Internet.  ACM Computer Communication
    Review, 35(2), April 2005. 
    http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps

[**] "Unexpected" took two forms.  (1) the timestamp option, even though
     we did not put a TS in the SYN and (2) an unspecified junk option.

---

From: Rick Jones <[email-masked]>
Date: Wed, 31 Aug 2011 09:25:50 -0700

> Simultaneous open: uh huh.)

So, active side says "I understand an extended set of options and can 
confirm them on my ACK of your SYN-ACK" and then when the passive side 
understands it, it gets to initiate options by introducing them with the 
SYN-ACK, which themselves are accepted or not via the active side's ACK 
of the passive sides SYN-ACK?

It becomes rather a rather kludgy layer violation, but how flexible are 
IPv6 optional headers?

rick jones

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Aug 2011 09:35:28 -0700

On 8/31/2011 9:25 AM, Rick Jones wrote:
> SYN-ACK,

Yes.

> which themselves are accepted or not via the active side's ACK

You get more option space at that point. You don't (IMO) get to start 
another round of option negotiation - that's a 4WHS.

> It becomes rather a rather kludgy layer violation, but how flexible are

That won't work through a NAT, AFAICT. NATs wouldn't know to look for 
the option, and thus would interpret the TCP header conventionally (and 
thus misinterpret the extended option space as data).

Joe

---

From: Rick Jones <[email-masked]>
Date: Wed, 31 Aug 2011 09:58:29 -0700

> another round of option negotiation - that's a 4WHS.

Is there anything technical standing in the way of letting the server 
introduce an option on the SYN-ACK that gets accepted by the client via 
an option carried in the ACK of the SYN-ACK?

> thus misinterpret the extended option space as data).

I wasn't thinking of putting TCP options in the data portion of the TCP 
segment, I was thinking of stuffing them into an IPv6 extension header. 
(and got my terms wrong at first)  With a "see the appropriate IPv6 
extension header for more TCP options" option in the TCP header.  Abuse 
Destination Options perhaps?  Or add something new akin to the 
Fragmentation Header?

rick jones

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Aug 2011 10:08:08 -0700

> an option carried in the ACK of the SYN-ACK?

Yes. You need a 4th state - a SYN-ACK-ACK to know that the SYN-ACK's new 
options are confirmed.

However, even if you did that, you still didn't increase the space of 
the first SYN -- and *that* is where the challenge lies.

> Destination Options perhaps? Or add something new akin to the

It could easily be a new option, but the problem is that some stacks 
might be very difficult to modify to support this. They expect that all 
IP options are processed before TCP touches the packet.

It would be very difficult to set the option at the IP layer to operate 
on different TCP connections differently too. Can't see how to do that 
at all, FWIW.

It also might interact with NATs badly, AFAICT.

Joe

---

From: William Allen Simpson <[email-masked]>
Date: Wed, 31 Aug 2011 14:13:00 -0400

> TCP's option space has been under increasing demand recently, with new option-space hungry extensions such as MPTCP, and some recent ideas in the research domain. In the past there have been some d…
Already done, already tested.  RFC-6013.

> I recall that re-segmenting middleboxes were mentioned as one potential problem for such extension, and there might be other problems. Nevertheless, I would find it useful, if there was an RFC that…
I'm using options 31 and 32.  See
   https://tools.ietf.org/html/draft-simpson-tcpct-api-04

> Thoughts?
Always happy to have additional experimenters.  Not talkers, implementers.

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 31 Aug 2011 15:04:36 -0400

> of the passive sides SYN-ACK?

Actually, this is the way that the SLO option works in the
document that Pasi mentioned.  It comes in on the ACK at
the end of the 3WHS in order to indicate options that should
be processed as if the SYN bit was set.  I'd been using that
around 2004/2005 in Linux and it was mostly a matter of redirecting
the options processing to a different function within the kernel
if SLO appeared on the ACK.

-- 
Wes Eddy
MTI Systems

---

From: Michio Honda <[email-masked]>
Date: Thu, 1 Sep 2011 04:14:15 +0900

Hi, 

We have some middlebox data for this topic.  

>  https://tools.ietf.org/html/draft-simpson-tcpct-api-04
In our middlebox measurement of 142 paths, all re-segmenting middleboxes don't allow TCP options (they are transparent proxies) except for one path.  However, this path did not re-segment packets when options were present.  

Another problem is consistency of retransmissions.  
We observed some middleboxes that cache segments and probably use these for retransmissions.  
Our test performs retransmissions with different payload from the original segment.  
On some paths, retransmitted segments did not reach the receiver.  
Therefore, if we retransmit segment with different option kinds or values in the payload, it might not reach the receiver.  

Middleboxes that aware of known option are also problematic.  
We observed some middleboxes that pass options and modifying sequence numbers.  
If we put SACK block in payload, such middleboxes won't rewrite sequence numbers in payload.  

I also performed SYN with payload test, which transmits such SYN to 500 websites in Alexa Top sites. 
494 sites responded to regular SYN
483 accepted SYN with payload (i.e., returned regular SYN/ACK) 
10 did not responded.  
1 reset the connection.   

Thanks,
- Michio

---

From: Jerry Chu <[email-masked]>
Date: Wed, 31 Aug 2011 12:27:59 -0700

On Wed, Aug 31, 2011 at 10:08 AM, Joe Touch <[email-masked]> wrote:
> However, even if you did that, you still didn't increase the space of the
> first SYN -- and *that* is where the challenge lies.

But that is mostly academic if one considers the last handshake in the 4WHS to
be an extension of the 3WHS for completing the option negotiation, no? The
endhosts won't seem to care which side initiates a particular option, nor which
round of HS is the option negotiated, except it will cost one
additional roundtrip.
(Well if a given option is not required before the data phase then it can be
piggyback'ed on data pkt to get the reliable delivery.)

It may break middleboxes that assume options are always initiated by the active
open side though.

Jerry

> It could easily be a new option, but the problem is that some stacks might
> be very difficult to modify to support this. They expect that all IP options
> are processed before TCP touches the packet.
>
> It would be very difficult to set the option at the IP layer to operate on
> different TCP connections differently too. Can't see how to do that at all,
> FWIW.
>

---

From: Jerry Chu <[email-masked]>
Date: Wed, 31 Aug 2011 12:37:54 -0700

On Wed, Aug 31, 2011 at 12:14 PM, Michio Honda <[email-masked]>wrote:

> >> I recall that re-segmenting middleboxes were mentioned as one potential
> problem for such extension, and there might be other problems. Nevertheless,
> I would find it useful, if there was an RFC that a) documented the known
> problems with option space extension; and b) defined an option format and
> assigned the needed type codes, to enable experimentations with larger than
> 40-byte option space.
> >>
> In our middlebox measurement of 142 paths, all re-segmenting middleboxes
> don't allow TCP options (they are transparent proxies) except for one path.
>  However, this path did not re-segment packets when options were present.
>
> Therefore, if we retransmit segment with different option kinds or values
> in the payload, it might not reach the receiver.
>

What's the difference between the two above (responded to vs accepted)?

Thanks,

Jerry

---

From: Michael Welzl <[email-masked]>
Date: Wed, 31 Aug 2011 21:38:48 +0200

> 500 websites in Alexa Top sites.

Poor them! Did it ever occur to you how much rubbish must get shot at  
these sites?   :-)   They must get the strangest traffic, originating  
from all over the world!

(yes of course I'm aware that most or all of these are not represented  
by one single poor computer standing in a terminal room somewhere...  
it's still a funny thought to me)

Michael

---

From: Michio Honda <[email-masked]>
Date: Thu, 1 Sep 2011 04:49:11 +0900

On Sep 1, 2011, at 4:37 AM, Jerry Chu wrote:

> 
> 
> On Wed, Aug 31, 2011 at 12:14 PM, Michio Honda <[email-masked]> wrote:
> Hi,
> 
Sorry, it means that 494 responded to regular SYN (no payload) with regular SYNACK.   
In this 494,  483 responded to SYN including payload  with regular SYNACK.  

Thanks,
- Michio

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Aug 2011 13:21:13 -0700

Hi, Jerry,

On 8/31/2011 12:27 PM, Jerry Chu wrote:
> On Wed, Aug 31, 2011 at 10:08 AM, Joe Touch<[email-masked]>  wrote:
...
> be an extension of the 3WHS for completing the option negotiation, no?

You need to distinguish between the SYN-ACK, the first message received 
after the SYN-ACK, the message sent, and the other messages sent and 
received. You can't simply transition from SYN-RECEIVED or SYN-SENT to 
ESTABLISHED - you need another state.

That other state is the problem - NATs don't implement it yet, so you 
will have trouble traversing it. If the messages between get split, do 
the options get copied, etc.

This is the (continuing) problem with state coordination after the 3WHS. 
It requires more states, which is incompatible with any middlebox 
(relay, NAT, etc.) that doesn't have those states. It also makes it very 
difficult to implement, and can require a lot of care to avoid impacting 
the robustness of the current state diagram (not to mention dealing with 
simultaneous opens).

> The
> endhosts won't seem to care which side initiates a particular option,

Agreed.

 > nor which

Disagreed as per above.

> piggyback'ed on data pkt to get the reliable delivery.)

If it were only that simple. TCP signalling is not reliable; it is the 
data that is reliable.

> It may break middleboxes that assume options are always initiated by the active

That's a completely different issue that may further complicate things...

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Aug 2011 13:26:50 -0700

On 8/31/2011 11:13 AM, William Allen Simpson wrote:
...
> https://tools.ietf.org/html/draft-simpson-tcpct-api-04

Thanks for letting us know. I'll let IANA to mark those as (further) 
unauthorized uses.

In the meantime, please stop and use the experimental options until you 
get an assignment, IMO.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Aug 2011 13:44:06 -0700

Some further clarification:

> Already done, already tested. RFC-6013.

This extends options after then SYN exchange. That has always been 
trivial, but doesn't address the SYN space.

I.e., this is Wed Eddy's LO, not SLO.

>> enable experimentations with larger than 40-byte option space.

Experiments SHOULD be using options 253 and 254, as per RFC 4727; i.e., 
those option numbers are already available for experiments.

Joe

---

From: Jerry Chu <[email-masked]>
Date: Wed, 31 Aug 2011 14:05:50 -0700

Hi Joe,

> ESTABLISHED - you need another state.

Guess it depends on what you're trying to achieve. Since it takes two sides to
agree upon an option, it may be less important which side initiates an option
negotiation hence the space of the first SYN.

Options initiated by SYN-ACK will be ack'ed by a pure ack or piggy'ed back
through a data segment but either way it won't hold off data transmission from
the active side because it already knows what options have been agreed upon.

>
> That other state is the problem - NATs don't implement it yet, so you will
> have trouble traversing it. If the messages between get split, do the
> options get copied, etc.

Correct NAT won't understand this passive-open side initiated option negotiation
but I wonder if it's any worse than an unknown option. Ok, unknown option on
data segments will suffer a higher (3% per Mark Allman) failure rate. If one
avoids tagging the 1st data segment with options then one must rely exclusively
on a pure ACK, which is not reliably delivered so one can not use this
mechanism for options that must be negotiated reliably.

>
> This is the (continuing) problem with state coordination after the 3WHS. It
> requires more states, which is incompatible with any middlebox (relay, NAT,
> etc.) that doesn't have those states. It also makes it very difficult to
> implement, and can require a lot of care to avoid impacting the robustness
> of the current state diagram (not to mention dealing with simultaneous
> opens).

See above.

> If it were only that simple. TCP signalling is not reliable; it is the data
> that is reliable.
>

Yup.

Jerry

>>> might
>>> on

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Aug 2011 14:15:06 -0700

On 8/31/2011 2:05 PM, Jerry Chu wrote:
...
> negotiation hence the space of the first SYN.

The point is that if the first SYN doesn't indicate option support, then 
the 3WHS isn't going to synchronize the endpoints as to whether that 
option is supported. That's true regardless of which side initiates the 
connection.

> the active side because it already knows what options have been agreed upon.

An option initiated by a SYN-ACK either:
	- was indicated in the SYN, and so confirms it to the initiator
	and the final ACK of the 3WHS confirms it to the responder

	- was initiated in the SYN-ACK
	which means either:
		A- the initiator didn't support it
		B- the initiator didn't have room to say it supported it

A needs a NACK.

B needs an ACK.

That happens during the 3WHS.

Another 4th message needs to complete the exchange, and needs to be 
reliably retransmitted if lost, etc. - that's what the TCP state machine 
is for.

You can claim your implementation fudges around it, but you effectively 
need that state - with the timeouts, retransmissions, etc. - to make 
sure that last message is sent properly.

AND how do you know when you can now use the option? When you're out of 
that last 4th state. Not before.

> mechanism for options that must be negotiated reliably.

For a general option, it may not be much different. BUT you're 
redefining the option/data boundary with this option, which DOES 
interact badly with NATs that, e.g., ignore unknown options but still 
manipulate TCP packets.

Joe

---

From: Jerry Chu <[email-masked]>
Date: Wed, 31 Aug 2011 16:29:36 -0700

On Wed, Aug 31, 2011 at 2:15 PM, Joe Touch <[email-masked]> wrote:
> The point is that if the first SYN doesn't indicate option support, then the
> 3WHS isn't going to synchronize the endpoints as to whether that option is
> supported. That's true regardless of which side initiates the connection.

I still think the final ack can be fudged to close the option
negotiation loop. (See
below.) But I just realized this thread seems to assume there is
plenty room left for
more options in SYN-ACK, and why is that?

> Another 4th message needs to complete the exchange, and needs to be reliably
> retransmitted if lost, etc. - that's what the TCP state machine is for.

The final ack will serve this purpose.

>
> You can claim your implementation fudges around it, but you effectively need
> that state - with the timeouts, retransmissions, etc. - to make sure that
> last message is sent properly.
>
> AND how do you know when you can now use the option? When you're out of that
> last 4th state. Not before.

The active open side will have all the knowledge about what options/values the
passive open side proposes after receiving SYN-ACK option so is done with option
negotiation hence can begin the data transmission phase. The passive open side
will be waiting for the final ack of the 3WHS, either in the form of a
pure ack, or
as part of a data segment (i.e., the 1st data segment from the active
open side).
But either way the option will have been negotiated reliably too for the passive
open side. More importantly, both sides will have the same understanding of
options to use before the data phase.

>>> will
> For a general option, it may not be much different. BUT you're redefining
> the option/data boundary with this option, which DOES interact badly with
> NATs that, e.g., ignore unknown options but still manipulate TCP packets.

Just realized the reliable delivery of options I was concerned about is not an
issue. See above.

Jerry

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Aug 2011 16:37:18 -0700

On 8/31/2011 4:29 PM, Jerry Chu wrote:
...
> below.)

You can do a lot of things that end up creating an additional state, and 
you can lie to everyone that such state doesn't exist (a counter keeps 
track of the SEQNO of the SYN/ACK to know which ACK to check, etc.) - 
but it's got to be there.

 > But I just realized this thread seems to assume there is
> plenty room left for

I think we expect that would be true only because the SYN had the "I 
understand long options" flag. At that point, the SYN/ACK can use the 
feature, in addition to acking it.

However, this is NOT the case if the SYN/ACK introduces the option. 
Whatever segment introduces the option cannot use it yet.

> The final ack will serve this purpose.

You need to flag that ACK as being handled differently from other ACKs - 
that's state. You also need to not use the option until the last ACK 
confirms it. That's state on the other end.

Any intermediate node that doesn't emulate that state can mess things up 
- esp. if that ACK comes out of order to a subsequent packet that uses 
the option.

The whole point of the state machine is to ensure that certain actions 
are gated on the handshake of certain packets.

> options to use before the data phase.

Who says the final ACK can't include data? or the other segments (SYN, 
SYN/ACK)?

Who says the final ACK can't be reordered with data that is going across?

This is what the states are for, and why you basically need to add one 
to make this work (and why a NAT that doesn't have that state will cause 
things to fail).

Joe

---

From: Jerry Chu <[email-masked]>
Date: Wed, 31 Aug 2011 17:21:59 -0700

On Wed, Aug 31, 2011 at 4:37 PM, Joe Touch <[email-masked]> wrote:
>>> the
> You can do a lot of things that end up creating an additional state, and you
> can lie to everyone that such state doesn't exist (a counter keeps track of
> the SEQNO of the SYN/ACK to know which ACK to check, etc.) - but it's got to
> be there.

Ok, perhaps my continue calling this kludge 3WHS set you off so let's call it
4WHS then :).

> However, this is NOT the case if the SYN/ACK introduces the option. Whatever
> segment introduces the option cannot use it yet.

Ok.

>>>> through a data segment but either way it won't hold off data
>>>> transmission
>>>> from
>>> reliably
> Any intermediate node that doesn't emulate that state can mess things up -
> esp. if that ACK comes out of order to a subsequent packet that uses the
> option.
>
> The whole point of the state machine is to ensure that certain actions are
> gated on the handshake of certain packets.

Ok. Perhaps the question is complexity (added states..., etc) vs usefulness,
both can be subjective though.

>>> need

Yes the options need to be present in all segments from the active open until
there is clear indication to the active open side that the passive open side has
exit 3WHS (probably what you alluded previously as the 4th state).

Jerry

>
> This is what the states are for, and why you basically need to add one to
> make this work (and why a NAT that doesn't have that state will cause things
> to fail).
>
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 Aug 2011 17:27:27 -0700

On 8/31/2011 5:21 PM, Jerry Chu wrote:
...

Yes.

So this is the "4WHS". Note that:

	- it doesn't increase the space in the SYN
	which has always been the show-stopper

	- it adds a state to TCP
	which can be a problem in both local complexity
	and NAT traversal

  Pushing the flag into the SYN makes the option available faster *and* 
avoids the 4th state. What's the reason for waiting until SYN/ACK to 
send the option?

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 31 Aug 2011 21:52:56 -0300

On 08/31/2011 12:58 PM, Joe Touch wrote:
> connection starts seems difficult at best -

Stick the option to a given SEQ. Whenever you retransmit that SEQ, you
retransmit the option. And when that SEQ is ACKed, that means the option
arrived to the other end (assuming no packet scrubber stripped the
option, obviously).

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Wed, 31 Aug 2011 21:56:40 -0300

> Simultaneous open: uh huh.)

Simultaneous opens are not reliable, anyway -- See Section 5.1 (page 46)
of http://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 31 Aug 2011 21:59:10 -0300

>     unknown option it probably has bigger problems.

+1

>     by now that is likely even lower.  But, at least that is some data.

Do you recall (of the top of your head) what caused the connection
failures when an option that wasn't negotiated during the 3WHS was
included once the connection was established?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 31 Aug 2011 22:01:52 -0300

> It becomes rather a rather kludgy layer violation, but how flexible are

The problem in this case is whether they will be (may be even more)
unreliable... (e.g., firewalls and the like dropping them)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 31 Aug 2011 22:05:07 -0300

Hi, Joe,

On 08/31/2011 02:08 PM, Joe Touch wrote:
> on different TCP connections differently too. 

Well, you can allways setsockopt() them.

> It also might interact with NATs badly, AFAICT.

Particularly with NAT64.

Thanks,

---

From: Rick Jones <[email-masked]>
Date: Wed, 31 Aug 2011 18:11:41 -0700

> unreliable... (e.g., firewalls and the like dropping them)

I suppose, but there would be little if any chance of them being 
misinterpreted, which I believe was one of Joe's big concerns about 
anything that shoved options into the nominal data portion of the TCP 
segment.

rick jones

---

From: Michio Honda <[email-masked]>
Date: Thu, 1 Sep 2011 11:48:09 +0900

Not that much, only several of such segments; SYN with 128 byte payload, SYN with 128 payload + unknown option, and 512 byte payload variant of these tests.  Results are not varied depending on the payload or and presence of unknown option. 

Cheers,
- Michio

On Sep 1, 2011, at 4:38 AM, Michael Welzl wrote:

> Poor them! Did it ever occur to you how much rubbish must get shot at these sites?   :-)   They must get the strangest traffic, originating from all over the world!
> 
> (yes of course I'm aware that most or all of these are not represented by one single poor computer standing in a terminal room somewhere... it's still a funny thought to me)
> 
> Michael
>

---

From: Tim Shepard <[email-masked]>
Date: Wed, 31 Aug 2011 23:01:07 -0400

> arrived to the other end (assuming no packet scrubber stripped the

That hack is problematic if the TCP connection will carry no data in
that direction.  (The sequence number will always be that same
sequence number on every packet sent going the other way, including
the FIN (if we ever get around to sending a FIN).

			-Tim Shepard
			 [email-masked]