Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02

[Bob Briscoe <[e-mail]>]

John,

I've got a bit behind in this conversation - I'm on another part of 
my job at the mo. So apologies that my response to this old posting 
on this thread arrives out of order.

At 20:53 26/09/2014, John Leslie wrote:
>Bob Briscoe <[e-mail]> wrote:
> > At 15:50 26/09/2014, John Leslie wrote:
> >>Bob Briscoe <[e-mail]> wrote:
> >...
> >>   I'd like to remind folks of two other drafts:
> >>
> >>- draft-ietf-tcpm-fastopen "allows data to be carried in the SYN" packet.
> >>  Something like this is inevitable; and _will_ put application-layer
> >>  data in the inital SYN (to reduce experienced latency).
> >
> > This is referenced from both drafts.
>
>    Yes. I felt a need to emphasize it...
>
> > You have to be careful using fast open as well as putting TCP options
> > in the payload. I've written the following into
> > draft-briscoe-syn-op-sis, and a similar rule will be needed in
> > draft-touch-tcpm-tcp-syn-ext-opt:
> >
> >" If an upgraded TCP client includes the TCP Fast Open option
> >" [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra
> >" TCP options after the end of the payload.
>
>    Indeed, that is a good way to ensure that the SYN receiver is aware
>of the sender's intent to place something _after_ the data intended to
>be passed to the application.
>
> >" An upgraded TCP client MUST NOT place any TCP option in the TCP header
> >" of a SYN that might cause a TCP server to pass user-data directly to
> >" the application before the 3-way handshake completes.
>
>    This is correct, if a bit hard for the reader to grok...

I wanted to state it both for the specific case of TFO and in general 
terms in case some other option is invented in future that passes 
data to the app before the 3WHS completes.


> >>- draft-nishida-tcpm-apaws "can provide protection against old duplicates"
> >>  without using timestamps. (Timestamps will eat up ten bytes in _every_
> >>  packet.) This should reduce the demand for option space in the SYN.
> >
> > Most certainly agree. See quoted text under the next point...
> >...
> >> Hopefully I don't need to draw attention to draft-touch-tcpm-edo.
> >> This seems to be moving towards consensus on how to increase the option
> >> space on every packet _after_ the initial SYN.
> >>
> >> Thus, in most cases, for today's traffic there is little need to
> >> worry about extending the option space in the initial SYN. There seems
> >> to be plenty of time to experiment...
> >
> > Not sure I'm so relaxed. Quoting
> > <http://tools.ietf.org/html/draft-briscoe-tcpm-syn-op-sis-02#section-1.1>
> >
> >" 1.1. Motivation for Adoption (to be removed before publication)
>
>    (I think the point deserves to be made in the published RFC.)

These paras are about what the IETF's wider agenda should be and 
where this draft fits in, which isn't appropriate in an RFC. And they 
are not timeless, which an RFC should also avoid.


> >"   It is recognised that there could be potential for compressing
> >"   together multiple options in order to mitigate the option space
> >"   problem.  However, it seems inevitable that ultimately more option
> >"   space will be needed, particularly given that many of the TCP options
> >"   introduced recently consume large numbers of bits in order to provide
> >"   sufficient information entropy, which is not amenable to compression.
>
>    I agree on the ultimate need. But it will necessarily be postponed
>until we finish Experimental status and move to Proposed Standard.
>
> >"   Extension of TCP option space on a SYN requires support from both
> >"   ends.  This means it will take many years before the facility is
> >"   functional for most pairs of end-points.  Therefore, given the
> >"   problem is already becoming pressing, a solution needs to start being
> >"   deployed now.
>
>    (No objection to that text.)
>
> >> For any Experimental-status document, I recommend:
> >>
> >> - that the various on-the-wire formats be kept as similar as possible;
> >>
> >> - that any acknowledgment of extra option space in an initial SYN
> >>   include a checksum or hash of the extra options to ensure that both
> >>   ends have the same view of what options have been signaled;
> >
> > Not convinced on this one. Each TCP option has its own way for the
> > 'server' to confirm whether it supports an option requested by the
> > client.
>
>   And this one should also have its own way. I see so many things that
>could get in the way that I _strongly_ recommend some checksum/hash.
>
> > And support for the option to extend the option space is confirmed by
> > the server.
>
>    One bit of information (support-yes-or-no) just isn't sufficient,
>IMHO.

I believe you're trying to recover some determinism because of the 
non-determinism I've introduced. If so, I strongly believe that it's 
better to lessen the original non-determinism (e.g. by a larger magic 
number), rather than to add more message exchanges.

If both achieve the same higher level of determinism, I'd much rather 
use the one that avoids adding more branches to the protocol logic.


> > So it seems redundant for the server to feedback yet another
> > confirmation via a checksum of all the extra options requested.
>
>    Redundancy is your friend when complexity multiplies.

I believe the opposite is true. If you provide two different ways to 
say the same thing, you create more complexity - to check they are 
both saying the same thing. And if they are not, you have to decide 
which one not to believe. This makes the spec and the code more complex.


> >> IMHO, Bob's SYN-U cases are best condensed into a single format
> >> where the SYN sender explicitly notes the position in the payload to be
> >> occupied by additional TCP options, and guarantees that no application-
> >> layer data will follow these.
> >
> > Good point about the guarantee.
> >
> >> The receiving endpoint would search for the extra options whether or
> >> not it found the SYN-U option in the initial SYN,
>
>    (Did I write that?? I was thinking MAY...)
>
> > This won't work. This would require every server to hold a list of
> > valid TCP options and their valid length fields. This list is large,
> > and the list of future options yet to be defined is even larger (and
> > obviously unknown).
>
>    But that's exactly what you solve in you "non-deterministic" version.

I think you've read something into it that isn't there.

The draft doesn't say an implementation has to "search for the extra 
options". Perhaps you didn't mean that? It specifies a deterministic 
location for the SYNOPSIS option that tells you where the other extra 
TCP options start.

The draft doesn't say or imply that an implementation has to know 
anything about any valid TCP options. Maybe you've wrongly jumped to 
that conclusion?

Was it the last bullet in the quoted list below that made you think this?:

"  an upgraded server MUST determine whether there is a
    SynOpSis TCP option at the end of the packet by checking all the
    following conditions:

    o  The Kind value is the SynOpSis Kind value;

    o  The length is 8;

    o  The next 4 octets match the magic number;

    o  The sum of the value of the EOO field, and all the length fields
       found by walking along the TCP options at the end of the payload
       exactly reaches the end of the packet.
"

Perhaps I need to spell out what that means...

First note that the implementation only needs to continue down this 
list of tests if all the previous tests have passed. So it will only 
have to do the last test if, at the end of the payload, there is 
arbitrary user-data that happens to contain exactly the same bytes as 
a SYNOPSIS TCP option (i.e. it has passed the first three tests).

The only assumption the fourth test makes about TCP options is that 
their length field is at the second octet, and that the number in 
that field specifies the length of the TCP option in octets. This 
should be true for all TCP options, past and future.

"Walking along the TCP options" means that the implementation:
* looks at the byte where the SYNOPSIS option says the first length 
field will be (one byte forward from where the extra options start),
* jumps forward by the value in this byte to the byte where the next 
length field would be if there was a TCP option there,
* and so on.

And if there really are TCP options there, stepping along the bytes 
where the length fields should be will land on the length field of 
the SYNOPSIS option at the end packet.

On the other hand, if it's just user-data that happens to have bytes 
that look like a SYNOPSIS option at the end, there will be some 
arbitrary byte in the location where the extended options offset 
(EOO) would be if it was a SYNOPSIS option. Even though that byte is 
not really an offset, there will be some number in that byte. If that 
number is taken to be an offset, it will point to somewhere else in 
the segment.

One byte forward from there will be another byte where the first 
length field seems to be, even though it's just an arbitrary byte in 
user-data. So jumping forward by the value in that byte will find 
another arbitrary byte and so on.

If this process eventually lands beyond the point where the length 
field of the SYNOPSIS option is, the implementation knows with 
certainty that there aren't really TCP options there; it's just been 
following arbitrary bytes in arbitrary user-data.

Altho this took a long time to say, these tests require minimal 
cycles. They just involve reading a byte at a location and using it 
as an offset to the next location, then checking whether that is 
still within the payload. It cannot continue for long, because it's 
always going in one direction (because an option length is defined as 
an unsigned int).

> >...
> >> and reply including a checksum/hash of the options it found. (The
> >> receiving endpoint MUST find some confirmation that these options
> >> were intended, or _it_ bears the responsibility to reverse any
> >> action on the extended options and pass the payload where it
> >> otherwise would have gone.)
> >
> > No need for all this - see above and see drafts.
>
>    Your non-deterministic version does this with a magic-number. That
>is an obvious weakness. I intended to draw attention to the issue --
>not propose a particular solution.
>
>    But obviously: if the SYN sender sends a SYN-U which the receiver
>doesn't get because a meddlebox removed it, the sender can learn of
>the problem when a returned checksum fails -- but the receiver won't
>know of the problem until the sender aborts.

In syn-op-sis the sender will learn of the problem without the 
checksum approach. If a middlebox removes the SYNOPSIS option, the 
server will respond to the SYN-U with a regular SYN/ACK, not a SYN/ACK-U.

This is why step 3 is needed in Table 1. And the required client 
behaviour is formalized in the five bullets at the end of section 2.1.

With the explicit variant of the dual-handshake is used (Section 6), 
because a middlebox might removing the SYNOPSIS option, the draft 
requires the client behaviour to be the same as for the implicit variant.

Search for the text "a middlebox might strip the SynOpSis TCP option" 
in the syn-op-sis draft.


>    The receiver might choose to delay sending fastopen data in every
>case where no SYN-U was received -- or there are other possibilities.
>Pick your poison...
>
> >> I'm not sure this entire middlebox-transit idea is worth the trouble;
> >> but it probably deserves to be an optional part of the experiment.
> >
> > The reason I came up with syn-op-sis is to be able to be near-certain
> > that it will get through current middleboxes. I think the group will
> > find such near-certainty to be liberating, compared to the minefield
> > we currently have to tip-toe through.
>
>    But it does add complexity. I won't pre-judge what balance of
>complexity the WG may chooose.

Fully agree.


> > The only case I can think of where there could be a blockage is where
> > a split TCP connection holds back any payload on the SYN until the
> > 3WHS completes.
>
>    ... which _will_ happen... :^(
>
> >> The SYN-U sender MUST deal with the danger of its additional options
> >> being passed to the application as data. For legacy receivers it can do
> >> this by aborting before the end of the three-way handshake. But there
> >> must be coordination with tcpm-fastopen to protect against such data
> >> being passed to the application before the SYN-U sender can abort.
> >> (This is not a trivial consideration!)
> >
> > Altho certainly not a trivial consideration, it is trivial to be safe
> > against this - see the rule already in the syn-op-sis draft, quoted
> > above, which is careful to be specific about TFO, as well as
> > generalising to anything in the future that might be like TFO (e.g.
> > tcpcrypt uses the TCP payload for control messages).
>
>    I expect fastopen to see widespread use -- and I expect it to be
>programmed by different folks that program syn-op-sis. Our warning
>label (IMHO) needs to be rather prominent...
>
> >> The question of separating payload data to go to the application
> >> from extended TCP options clearly requires action by the SYN receiver.
> >> This is fairly simple if the SYN sender can ensure that _none_ of the
> >> payload data should go to the application (and thus not use fastopen
> >> at all): of course the connection must still be aborted if the SYN
> >> receiver doesn't acknowledge separating out the extended options.
> >>

I've already dealt with the points about TFO in the rest of your 
email in my other recent email on this thread.

> >> IMHO, the SYN sender should never use SYN-U unless extra option
> >> space in the SYN is needed; and it's probably better to never use
> >> SYN-U for connections where latency of setup is the over-riding factor.
> >> But YMMV. I wonder whether such overlap is worth the trouble to try
> >> to design into the protocol.

You're allowed your humble opinion. However, if you analyse the 
SYNOPSIS protocol, you will conclude with absolute certainty that the 
upgraded SYNOPSIS connection has no latency cost. So if a SYN-U gets 
options through middleboxes, I predict it will be used whether or not 
the extra space is needed.

> >
> > In the syn-op-sis spec there is a choice between two variants of the
> > protocol (I recommend the choice can be made by implementers, not the
> > IETF).
>
>    Hmm...
>
>    This is a dangerous idea. Experimental results get hopelessly cloudy
>when implementations are _fundamentally_ different...

I've put forward two pairs of variants. For the first pair of 
variants, I have asked the IETF to decide between them (so I put the 
one I least recommend in an Appendix). But for the other pair of 
variants, I realised that the choice of variants can be left to the 
implementer, so I put it in the body (Section 6).

I didn't come to these conclusions without a lot of thought (whereas 
up to draft-01 I hadn't fully thought this through)...

The only difference in the section 6 variant is the SYN-L. It became 
clear to me that this is not a fundamental difference when I realised 
that a middlebox could reduce the SYN-L to a SYN and it would turn 
the protocol into the other variant. So the rest of the protocol is identical.

The reason for allowing either at run-time is that the SYN-L variant 
is more likely to be preferred after most servers have been upgraded, 
but not at the start of deployment (explained in the Appendix linked below).


> > The choice I've recommended removes any risk of extra latency
> > on the upgraded connection. I've included a discussion of the
> > tradeoff between them in Appendix B.1:
> > <http://tools.ietf.org/html/draft-briscoe-tcpm-syn-op-sis-02#appendix-B.1>
> >

Regards


Bob

>--
>John Leslie <[e-mail]>

________________________________________________________________
Bob Briscoe,                                                  BT