Subject: [tcpm] Further comments on extending option space

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 13 Oct 2014 18:21:36 +0200

Hi Joe, hi Bob,

I've just read both of your drafts and have a couple of thoughts that I would 
like to write down before I forget them... I hope that's helpful otherwise just 
ignore them :-)

1) I think I would prefer a 'clean' approach using a new option. If such a new 
option would cause a middlebox to drop the packet, the kind of happy eyeball 
approach of Bob would maybe be helpful; but i guess that's a general question 
for all new options.

2) What's about putting the EDO length option as the first (or last) option in 
the payload more or less as proposed in Bob's approach (if we require it to be 
present in each segment anyway as discussed in the previous mail thread). This 
way it could not be removed by a middlebox...

3) If we require the option on each segment we could add one more field in the 
EDO request option indicating if the endpoint would actually like to use the 
extended option space at some point or not. That means the initiator basically 
can say I support the option but don't need it and the other host can then 
complete the negotiation or not (or the initiator says I support the option and 
would like to use it and the other host negotiates it and also indicated if it 
needs the space or not).

One quick question for Bob: Is there a specific reason that you've put the 
syn-op-sis option at the end (and not at the beginning) of the payload?

Mirja

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Oct 2014 10:16:10 -0700

Hi, Mirja,

On 10/13/2014 9:21 AM, Mirja Kühlewind wrote:
> Hi Joe, hi Bob,
> 
> I've just read both of your drafts and have a couple of thoughts that I
> would like to write down before I forget them... I hope that's helpful
> otherwise just ignore them :-)
> 
> 1) I think I would prefer a 'clean' approach using a new option. If such
> a new option would cause a middlebox to drop the packet, the kind of
> happy eyeball approach of Bob would maybe be helpful; but i guess that's
> a general question for all new options.

We certainly need to consider middlebox behavior, but we do also need to
temper that based on what's been deployed, not merely what we think
might ever be deployed.

> 2) What's about putting the EDO length option as the first (or last)
> option in the payload more or less as proposed in Bob's approach (if we
> require it to be present in each segment anyway as discussed in the
> previous mail thread). This way it could not be removed by a middlebox...

All options are in the "payload" area, i.e., in the area after the base
TCP header. The header is what indicates what portion of that payload is
an extension to that base header. For the purposes of
backwards-compatibility with legacy endpoints, it doesn't matter whether
extension space comes from the front or rear of that space.

> 3) If we require the option on each segment we could add one more field
> in the EDO request option indicating if the endpoint would actually like
> to use the extended option space at some point or not.

Options often consume space in both directions, sometimes asymmetrically
(e.g., SACK). Just as with SACK, sometimes endpoints turn on options
that don't get used actively.

> That means the
> initiator basically can say I support the option but don't need it and
> the other host can then complete the negotiation or not (or the
> initiator says I support the option and would like to use it and the
> other host negotiates it and also indicated if it needs the space or not).

You'd need to extend the TWHS to make this happen. I.e., during one
exchange you're saying what you CAN do, then in the next exchange you
say what you WILL do. TCP doesn't have that capability now; to do so
would require adding states to the TCP handshake, which is much more
than a "minor" (as in "tcp*m*") extension.

> One quick question for Bob: Is there a specific reason that you've put
> the syn-op-sis option at the end (and not at the beginning) of the payload?

I'll let Bob answer that in detail if desired; AFAICT, it's largely to
allow middleboxes that don't understand the extension to be able to
parse and process the data field. I think this is a mistake, because at
some point in that field the data is corrupted, and it is just making a
bet that such boxes should be supported until they silently fail. I'd
prefer they just fail from the start.

Joe

---

From: John Leslie <[email-masked]>
Date: Tue, 14 Oct 2014 08:41:54 -0400

Joe Touch <[email-masked]> wrote:
> On 10/13/2014 9:21 AM, Mirja K??hlewind wrote:
>> 

   It's exactly the "what's been deployed" question which should prompt
us to write an Experimental RFC to gather sufficient data on what actual
issues we're facing.

   Mirja suggests getting a dedicated option for experimental use -- I
believe that is entirely justified. It should be easy for any middlebox
to know whether it's dealing with endpoints which expand the TCP Option
space.

   If middleboxes drop packets which use EDO, we've got a simple path:
do without expanded option space until the middleboxes are fixed.

   If a middlebox ignores our EDO option, we know there will be trouble
if it also tries to act on other TCP Options (because it won't know
where to look for them).

   And if a middlebox ignores our EDO option, there will also be trouble
if it tries to change anything in the payload. (It's perfectly OK for
it to change the TCP headers _before_ the payload; but when it sets
out to do _anything_ to the payload itself, serious damage is likely.)

   (Arguably, of course, even changing TCP ports is a layer violation;
but there's no chance of stopping middleboxes from doing it. Fortunately
TCP ports are in the TCP header, not the payload.)

   We have been having discussions where folks have considered _parts_
of the problem: generally responses have been "That won't happen here!"

   That response doesn't inspire confidence. :^(

   I'd like to suggest that we look into _detecting_ middlebox damage
which makes changes to the _payload_.

   We've narrowed our vision too much, IMHO, when we assume that any
middlebox behavior will become apparent during the three-way handshake.
We _should_ know that different middleboxes can be in the path during
the life of a TCP connection: thus different problems may show up
later in the life of a connection. Or, even within the same connection,
a middlebox might change what algorithms it uses. (Can you spell
"software update"?)

====

   In order to have _a_ proposal (I'm not really particular which way
we go about this), I'll suggest a checksum over the payload for the
receiving endpoint to verify before passing anything to the application.

--
John Leslie <[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Tue, 14 Oct 2014 09:38:39 -0400

>> to use the extended option space at some point or not.

   (I actively dislike requiring an EDO option in each segment; and I
don't believe it fully solves the problem it sets out to solve: but
that's not the issue here.)

> that don't get used actively.

   _Some_ options do these things.

>> That means the initiator basically can say I support the option
>> but don't need it

   That should pretty much _always_ be the case -- the exception being
when the initiator will abort the connection if the other endpoint
doesn't support this option.

>> and the other host can then complete the negotiation or not

   Options do not necessarily need to be "negotiated".

>> (or the initiator says I support the option and would like to
>> use it and the other host negotiates it and also indicated if it
>> needs the space or not).

   This is a confusing statement.

   There indeed can be cases where either endpoint _supports_ an option
but has no expectation of invoking it, and other cases where the endpoint
intends to use the option if the other end supports it.

   But this really isn't a "negotiation" issue. No "money" changes hands.

   Over time, one naturally expects a protocol like TCP to define options
which will be used in "special" cases: and whether such cases will be
seen in any particular connection tends to be unknown at handshake time.

   In a different world, we would have said nothing about such options
until they are "needed" and hoped the other endpoint would accept them.
But in _this_ world, we mostly announce our support on the initial SYN
and leave the option unused.

   Thus, IMHO, the "negotiation" paradigm doesn't fit well, since at
the time the option is passed, there is insufficient information about
the need to use it.

   Instead, I like a paradigm of "capabilities".

   Each endpoint announces what options it "supports" -- meaning that
it knows how to interpret it if the other end uses it. (Presumably it
also knows how to use it if the other end supports it.)

> say what you WILL do.

   Joe is correct that a three-way handshake would be required.

> TCP doesn't have that capability now; to do so would require adding
> states to the TCP handshake, which is much more than a "minor" (as in
> "tcp*m*") extension.

   ;^)

   (Actually, we could design a separate three-way-handshake for options
where that distinction is important; but I'm hard-pressed to think of
a case where it would be worth the trouble.)

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Oct 2014 09:19:01 -0700

> to know whether it's dealing with endpoints which expand the TCP Option

MPTCP already has experience with an "unknown option", and there was an
extensive study I cited from 2011.

...
> of the problem: generally responses have been "That won't happen here!"

I've cited a study that indicated what happens and where.

,,,
> which makes changes to the _payload_.

TCP isn't a diagnostic tool. If we want an option to do that - and we've
had a few before that we deprecated (checksums, in particular) - that's
OK for that option.

But I don't support the idea of building that sort of diagnostic into
each option we develop.

> middlebox behavior will become apparent during the three-way handshake.

You complained about others raising issues based on speculation. The
study I cited doesn't say that options are passed during the TWHS but
later changed. Middlebox paths can change after a connection starts, but
in many cases this affects the entire connection (e.g., NAT will just
fail). Do you have evidence of middleboxes that drop after the TWHS or
that can be inserted after a connection is established?

> the life of a TCP connection:

Based on what? I have not seen anyone do more than speculate about such
boxes.

> thus different problems may show up

Based on what? Are you aware of a middlebox that continues to process
established connections after a reboot?

> receiving endpoint to verify before passing anything to the application.

That might be a useful *independent* option, but I see no justification
for including that as part of EDO.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Oct 2014 09:34:32 -0700

> that's not the issue here.)

The only reason for using EDO in every segment is to handle the
*conjectured* case of:

	- a middlebox that gets inserted after the TWHS

	- that ALSO allows the connection to continue

	- that ALSO silently drops EDO

We have no evidence of this spectre. I would be glad to allow EDO to be
optional, and to have a *separate* payload and/or option checksum for
*diagnostics*.

> doesn't support this option.

I don't agree that this should be the case. However, we're talking about
how TCP currently works. Can you provide an example of a current option
with this property?

>    Options do not necessarily need to be "negotiated".

Except for those mandated by RFC793, can you give an example?

IMO, they necessarily need to be negotiated to deal with legacy
endpoints. TCP ignores options it doesn't understand (RFC1122 Sec.
4.2.2.5). It is safe to proceed with a connection only when SYN options
negotiate support for that option; otherwise, an unknown option can have
unknown impact on the connection later.

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 14 Oct 2014 19:25:01 +0100

MIrja, Joe,

At 18:16 13/10/2014, Joe Touch wrote:
>Hi, Mirja,
>
>On 10/13/2014 9:21 AM, Mirja KÃ¼hlewind wrote:
> > Hi Joe, hi Bob,
> >

I take a different view. I am trying to design a 
way for middleboxes to work properly in the 
future, that can also be deployed through the middleboxes we already have.

>an extension to that base header.

I think Mirja is suggesting that a TCP Option 
before the Data Offset ('outer') that points to 
extended option space beyond the Data Offset 
('inner') is fragile. If the outer option is 
stripped, then the inner options turn into 
potentially corrupt user-data. I.e. the outer and 
inner do not share the same fate.

In the syn-op-sis approach, the extra space and 
the option that creates the extra space are both 
beyond the Data Offset (both inner). So they share fate.

>For the purposes of
>would require adding states to the TCP handshake,

Surely you can negotiate the ability, then signal 
whether you use the capability on a segment by 
segment basis? I'm warey that this conversation 
has got a bit abstract, so I might be misunderstanding you.

>which is much more

I am conscious that all this option-space 
extension activity stretches the definition of the word "minor" (see below).

>prefer they just fail from the start.

I suspect that what Joe says might happen with 
some middleboxes, ie. the start of the payload 
looks like they would expect, but they suddently 
find some unexpected bytes so they drop the packet.

However, I'd like to experiment, because I 
suspect many of these app-layer boxes will parse 
up to whatever point they need to, then stop. So 
they won't ever notice the unexpected bytes at 
the end. For instance, my employer's Web filter 
(that I'm sitting behind right now) looks for the 
URL that is the argument to the HTTP GET command 
in order to decide whether to block the page. It 
doesn't parse all the HTML, and it may not even 
parse all the HTTP after the GET. These filters 
are widely used to protect children from porn 
etc, and they are widely used for less noble (usually commercial) purposes.

On 7 out of the 142 paths tested in Michio Honda 
et al "Is it Still Possible to Extend TCP?" there 
was a box that silently dropped packets to port 
80 that contained unexpected data instead of 
valid HTTP. The unexpected data was commands that 
the experimenters' had written into the payload 
to control their echo-responder. They hadn't 
expected that these commands would disrupt the 
experiment. I don't know of any experiments that 
have included expected data followed by unexpected data.

Whatever, in draft-03 of syn-op-sis (that I'm 
still working on), I've put the extension options 
at the front by default, and made the trailer 
mode optional (so experiments can be conducted to find if it is needed).

_______________
Here's a taster of draft-...-syn-op-sis-03: It 
provides extra options space on every segment, 
not just the SYN, as promised. However, it's 
actually gone in a significantly different 
direction. It's no longer 'just' extending 
options space. I've realised there is a need for 
two different types of options:
* segment transmission control options (e.g. MSS, SACK);
* stream transmission control options (e.g. TCPcrypt, TCP-AO).

If you have a proxy at L4 or above in the middle 
of a path, you might have different segmentation 
on the two sections of the path, so each section 
needs its own segment control options. However, 
the ordered byte-stream is the same e2e, so you 
want the stream control options to work e2e, 
which can be achieved by encapsulating them in the TCP Data.

Then you gain unlimited space in the TCP Data for 
the stream control options, which relieves the 
pressure on the traditional option space for 
segment control options. Also, for all the 
options at the start of the connection it doesn't 
matter whether they are segment or stream 
control; they can be placed either inside or 
outside the TCP Data, which gives a lot of flexibility over space usage.

That's a taster... Rather than write more here, 
I'll concentrate on writing it into the draft and get it posted.

All this seems to go beyond a "minor" extension. 
However, one can look at it as articulating a 
division within TCP that has crept into the 
protocol over the years, and turning that division into an explicit feature.

I've completely rewritten draft-03 about 4 times 
now, because I kept thinking of ways to overhaul 
it to make it simpler. I expect to post it soon - 
I'm happy with the protocol itself, which is now 
completely written up - but I'm taking care to 
write a full "Design Rationale" section, which takes a lot longer.

Bob

>Joe

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Oct 2014 11:41:54 -0700

...
> I think Mirja is suggesting that a TCP Option before the Data Offset
> ('outer') that points to extended option space beyond the Data Offset
> ('inner') is fragile. If the outer option is stripped, then the inner
> options turn into potentially corrupt user-data. I.e. the outer and

I don't understand this.

DO extends the TCP header into the front of the payload.

Any TCP option that extends that space in any way needs to be in that area.

DO can't be stripped. The options it makes space for can. Regardless of
how a TCP option extends the DO space, if that happens mid-connection
(again, a hypothetical only), the extension space will be interpreted as
user data. It doesn't matter whether the additional space is at the
front or end of the post-DO payload.

> In the syn-op-sis approach, the extra space and the option that creates
> the extra space are both beyond the Data Offset (both inner). So they
> share fate.

Even if that were true, it would mean that user data would be corrupted
by both the option and the extension. A middlebox that goes around
removing options it doesn't understand won't parse space beyond DO.

> Surely you can negotiate the ability, then signal whether you use the
> capability on a segment by segment basis? I'm warey that this
> conversation has got a bit abstract, so I might be misunderstanding you.

Option capability MUST be negotiated during the TWHS.

Whether individual options are used on a segment depends on a lot of
things - whether that makes sense, whether having segments without the
option compromises the capability (e.g., not using TS compromises PAWS),
etc.

I think we generally all agree on this. However, the above appeared to
propose a different semantics for options in the SYN, i.e., the TWHS
doesn't concurrently negotiate capability AND whether the capability is
needed in the future.

...
> I suspect that what Joe says might happen with some middleboxes, ie. the
> start of the payload looks like they would expect, but they suddently
> However, I'd like to experiment, because I suspect many of these
> app-layer boxes will parse up to whatever point they need to, then stop.
> So they won't ever notice the unexpected bytes at the end. For instance,
> my employer's Web filter (that I'm sitting behind right now) looks for
> the URL that is the argument to the HTTP GET command in order to decide
> whether to block the page. It doesn't parse all the HTML, and it may not
> even parse all the HTTP after the GET. These filters are widely used to
> protect children from porn etc, and they are widely used for less noble
> (usually commercial) purposes.

Sure, and they might even parse HTTPS to the point of finding the SNI.

> On 7 out of the 142 paths tested in Michio Honda et al "Is it Still
> Possible to Extend TCP?" there was a box that silently dropped packets
> to port 80 that contained unexpected data instead of valid HTTP. The
> unexpected data was commands that the experimenters' had written into
> the payload to control their echo-responder. They hadn't expected that
> these commands would disrupt the experiment. I don't know of any
> experiments that have included expected data followed by unexpected data.
> 
> Whatever, in draft-03 of syn-op-sis (that I'm still working on), I've
> put the extension options at the front by default, and made the trailer

If we do think that this case is common, then we can easily have all the
extensions (SYN and otherwise) use space at the end of the segment. It
can be something most variants can easily support in a flag, FWIW - I
doubt we actually need the entire extension space indicated so far.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Oct 2014 13:16:44 -0700

On 10/14/2014 11:41 AM, Joe Touch wrote:
....
...
> doubt we actually need the entire extension space indicated so far.

PS - if this is true, it is also likely true for not only SYN packets
but the first data packet too. The first data packet need not be the SYN
(and often isn't AFAICT).

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 14 Oct 2014 22:36:17 +0100

Joe,

>front or end of the post-DO payload.

I am not saying DO might be stripped.

Syn-op-sis does not involve any additional TCP options in the TCP 
option space, ie the space between the end of the 20B base TCP header 
and the max 60B Data Offset. This makes each syn-op-sis segment 
/inherently/ robust against option stripping.

All the additional options of syn-op-sis are beyond the Data Offset, 
including the option that creates the additional space for the other 
options. So they all share the same fate.

Whereas, in EDO the option that creates the space beyond DO is not 
itself beyond DO. So the option that creates the space is at risk of 
being stripped without stripping the space it created. The two do not 
/inherently/ share the same fate.

Yes, checks can be added to EDO to check for option stripping (e.g. 
deferring use of extra space until after the SYN/ACK). But this has 
to assume that stripping behaviour remains consistent through the 
flow. Whereas, with syn-op-sis, each individual segment is robust 
against option stripping, all by itself.

I think this is what Mirja was referring to.

>by both the option and the extension.

* The syn-op-sis client ensures that it aborts the connection to a 
legacy server before it passes this corrupt TCP Data to the app.
* And a syn-op-sis server catches this corrupt TCP data and removes 
the options before passing the remaining payload to the app.

This only relies on the endpoints, which are stateful, to maintain 
consistent behaviour throughout the connection. Half-way through a 
connection, a server isn't suddenly going to forget that it supports 
syn-op-sis and start passing corrupt data to the app.

Whereas it is not so certain that the experienced middlebox behaviour 
will remain consistent throughout a connection. It might not be the 
same middlebox in both directions, and the path might change to pass 
through a different middlebox part-way through a connection.

>A middlebox that goes around

That's exactly the behaviour that syn-op-sis exploits.

>doesn't concurrently negotiate capability AND whether the capability is

I didn't read Mirja's suggestion like that.
I think you & I are agreeing anyway.

>can be something most variants can easily support in a flag,

Yup. It's do-able,...

...but it's not completely straightforward. For instance, when I 
tried to design against resegmentation, I suggested a "sent payload 
size" field in an email to you. The idea was that the receiver could 
reconstruct where the segment boundaries had been originally - in 
order to find where the options had been put originally.

However, the sender has to place the 'sent payload size' field at the 
start of the segment it refers to. If it places it at the end of each 
segment, the receiver has to wait until the very end of the stream 
before it can work backwards to find where all the segments were - 
not a lot of use.

>FWIW - I

TCP is 33 years old. There's no point upgrading it now unless we 
ensure enough space for another 30-50 years at least.

When you start using options to transfer keys (e.g. TCPcrypt) they 
get pretty big (and uncompressable of course). I know it's hard to 
predict what key sizes will be needed (let alone what algorithms will 
have been broken) over such timescales. However, I would be 
embarrassed if we couldn't carry a 4096-bit (512B) key in newly 
enlarged option space.

TCPcrypt currently has to do its main key exchange in the payload, 
which is messy. We should be ensuring that TCP supports whatever 
might need to be done in the option space without each new option 
having to hack a solution when the space is too small.

I take the view that we might as well allow the set of options to be 
as large as the largest possible segment. That turns out not to be 
hard or wasteful anyway.

Bob

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Oct 2014 15:14:09 -0700

On 10/14/2014 2:36 PM, Bob Briscoe wrote:
> Syn-op-sis does not involve any additional TCP options in the TCP option
> space, ie the space between the end of the 20B base TCP header and the
> max 60B Data Offset. This makes each syn-op-sis segment /inherently/
> robust against option stripping.

Oh, right - you've encoded the option opaquely in the data.

That's not a TCP option anymore. TCP options are fields defined by the
option structure defined in RFC793. You're defining a new way to signal
the presence of options using a magic number.

That's a lot of obfuscation in the absence of re-encoding the user data
to avoid collision AND in the absence of a checksum.

> options. So they all share the same fate.

Agreed.

> itself beyond DO. 

Right, because it's a TCP option.

> So the option that creates the space is at risk of

Correct.

> deferring use of extra space until after the SYN/ACK). But this has to
> assume that stripping behaviour remains consistent through the flow.

Yes. Again, TCP is not a diagnostic tool.

> Whereas, with syn-op-sis, each individual segment is robust against
> option stripping, all by itself.
>

You have to prohibit use of TFO (and maybe some others, e.g., TCPCT)
with syn-op-sys in that case.

> * And a syn-op-sis server catches this corrupt TCP data and removes the
> options before passing the remaining payload to the app.
> 
> will remain consistent throughout a connection. It might not be the same
> middlebox in both directions, and the path might change to pass through
> a different middlebox part-way through a connection.

We have no evidence of middleboxes that suddenly appear on a path
asymmetrically AND allow a connection to continue.

However, if we did, we'd also have to consider devices that split
segments without understanding options but which don't copy options (one
of the cases described in the study).

That breaks syn-op-sis in two ways:

	- user data is corrupted with the extended options
	- user data is interpreted as extended options incorrectly

Note that a middlebox that splits segments but uses the options only on
the first segment is likely to pass EDO uncorrupted and unaffected
(presuming the extension is within the first segment).

> ...but it's not completely straightforward. For instance, when I tried
> to design against resegmentation, I suggested a "sent payload size"
> field in an email to you. The idea was that the receiver could
> reconstruct where the segment boundaries had been originally - in order
> to find where the options had been put originally.
> 
> before it can work backwards to find where all the segments were - not a
> lot of use.

Right - the EDO still stays in the DO space, but the extension is at the
tail. If we add the "original segment length" within EDO, then the
receiver might be able to reconstitute the segment if split.

However, because EDO would still be inside the DO space, the typical
split would copy it into the first segment only.

--

Note that I still think this is inappropriate for EDO. If we want TCP
integrity restoration, we ought to design an option to achieve this.
However, it presents a problem of how to process options that span
segments when the ACK and header flags may differ.

This turns TCP into a two-layer protocol - one layer for resegmentation
and a different one for the control info. That seems silly - if we want
that level of robustness, we ought to design a tunnel protocol
specifically for that purpose.

I repeat:

	TCP is not a diagnostic tool.

> TCP is 33 years old. There's no point upgrading it now unless we ensure
> enough space for another 30-50 years at least.
> 
> When you start using options to transfer keys (e.g. TCPcrypt) they get
> pretty big (and uncompressable of course). I know it's hard to predict
> what key sizes will be needed (let alone what algorithms will have been
> broken) over such timescales. However, I would be embarrassed if we
> couldn't carry a 4096-bit (512B) key in newly enlarged option space.

Well, you can barely do so now.

EOO and EPOO are both one byte, so you can jump over roughly 1K of user
payload (EOO). We already send packets larger than 1K, and if the key +
user data is larger than 1K then EPOO is too small.

They need to be roughly 14 bits (unless we consider jumbograms, at which
point they need to be 30 bits).

> TCPcrypt currently has to do its main key exchange in the payload, which
> is messy.

IMO, TCPcrypt is messy. TCP isn't out there to support EVERYTHING. Just
like IP doesn't.

> We should be ensuring that TCP supports whatever might need to
> be done in the option space without each new option having to hack a
> solution when the space is too small.

Sometimes the answer to "I want to do that in TCP" can - and should - be
"NO".

> I take the view that we might as well allow the set of options to be as
> large as the largest possible segment. That turns out not to be hard or
> wasteful anyway.

You'd burn 14 bytes total if you did that (EOO and EPOO need to be 30
bits each).

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 20 Oct 2014 02:15:16 +0100

Joe,

>with syn-op-sys in that case.

Nope (we've been through that argument, and I recall you suddenly 
'got it' at one point).

>         - user data is interpreted as extended options incorrectly

I have developed syn-op-sis. The sender includes options within the 
reliable ordered data stream prefixed by a framing option at the 
original segment boundaries. Then the receiver can reconstruct the 
original segment boundaries, and extract the options that applied at 
that boundary. It has a number of nice properties, not least reliable 
ordered delivery of options even in the fairly common case when there 
is no user-data in one direction.

The majority of known options can shift into the TCP datastream: MSS, 
SACK-ok, WS, MPTCP, TFO, AO, tcpcrypt.

Certain options (specifically timestamp and SACK) are inherently 
about transmission of individual segments so they have to remain in 
the main TCP header. These (and any new options with similar 
properties) would still not traverse middleboxes that both resegment 
and do not forward unrecognised options.

However, new options like those in the longer list above would 
traverse middleboxes, even if they resegment and even if they don't 
forward unrecognised options.

At risk of confusing everyone, I have renamed the file and the scheme 
from syn-op-sis to inner-space. I have just posted 
draft-briscoe-tcpm-inner-space-00

>(presuming the extension is within the first segment).

Yup.

>split would copy it into the first segment only.

That's what I've done. TCP is (of course) already a 2-layer protocol 
- headers at L4 and app-data at L7. I've tunnelled the control 
options within the app-data in such a way that the receiver can 
extract them before passing the app-data to the app.

>         TCP is not a diagnostic tool.

If one starts from the premise that resegmentation within the path is 
a fault, then separating segmentation into a sub-layer of TCP would 
be 'diagnostics'.

If one starts from the premise that resegmentation ought to be 
possible on a normal path, then a separate segmentation layer in TCP 
is 'robust protocol design'.

>point they need to be 30 bits).

When I wrote the above about tcpcrypt, I had already realised the 
fields in syn-op-sis needed to be larger. Their sizes in the new 
inner-space draft are now as you suggest - just posted.

>IMO, TCPcrypt is messy. TCP isn't out there to support EVERYTHING. Just

At the moment, I agree that tcpcrypt is trying to do something that 
makes it very messy and complex.

I believe, implementing 'tcpcrypt-v2' within inner-space would allow 
tcpcrypt to be decoupled from the TCP state machine, and greatly 
simplify it. It would be more like a structured version of TLS, 
meaning that the control channel would be in-band (and therefore 
subject to encryption) but it would be identified as the control 
channel by TCP, rather than having to identify /itself/ as the 
control channel like TLS does.

>Sometimes the answer to "I want to do that in TCP" can - and should - be

I don't see tcpcrypt as any different in this respect to TCP-AO. I am 
trying to restructure TCP so that it makes this sort of thing 
natural, safe and easy to do simply and correctly.

>You'd burn 14 bytes total if you did that (EOO and EPOO need to be 30

See the new inner-space draft. By default it caters for 16-bit max IP 
payload, with a jumbo extension for 32-bit max payload size. Overhead 
is in the hundredths of a percent.

Cheers

Bob

---

From: Joe Touch <[email-masked]>
Date: Mon, 20 Oct 2014 12:04:06 -0700

...
> Nope (we've been through that argument, and I recall you suddenly 'got
> it' at one point).

You mentioned putting TFO in the extension space for the extended SYN.
You still have the problem of the legacy SYN - if that uses TFO, you'd
be trying to stop a connection after user data were passed to the app.

I.e., you have to prohibit TFO on the legacy SYN.

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Oct 2014 17:52:12 +0000

Joe,

>I.e., you have to prohibit TFO on the legacy SYN.

Nope. Because the payload in the legacy SYN isn't polluted with 
control options. So it can be passed to the app.

It doesn't matter that an upgraded server will then pass the payloads 
of both the legacy and the upgraded SYN to the app. Because TFO is 
required to be turned on only if the app can cope with duplicate SYNs.

Bob

(Sorry for delayed response - been travelling)

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Oct 2014 11:00:02 -0700

On 10/27/2014 10:52 AM, Bob Briscoe wrote:
> Nope. Because the payload in the legacy SYN isn't polluted with control
> options. So it can be passed to the app.
> 
> It doesn't matter that an upgraded server will then pass the payloads of
> both the legacy and the upgraded SYN to the app. Because TFO is required
> to be turned on only if the app can cope with duplicate SYNs.

Apps shouldn't have to deal with these issues, IMO.

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 27 Oct 2014 18:18:58 +0000

Joe,

>Apps shouldn't have to deal with these issues, IMO.

Inner Space is not changing anything in that respect. Your issue is with TFO.

FWIW, I think TFO is worth this tradeoff. I was very concerned about 
the safety of TFO in this respect and spent some time with Yuchung 
developing wording to make the RFC clearer. Problem is that most Web 
admins won't read the RFCs. They will read a potted summary written 
by some half-clueless Web performance blogger. The best we can do is 
ensure the explanation is in the first few lines of the abstract. But 
at least harm and blame should land on the same doorstep (the server 
operator) in this case.

Bob

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Oct 2014 11:33:14 -0700

...
> Inner Space is not changing anything in that respect. Your issue is with

I don't have that issue with TFO with my SYN extension, though.

AFAICT, it's an interaction between TFO and a dual-stack approach.

Joe