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

[Bob Briscoe <[e-mail]>]

John,

At 15:50 26/09/2014, John Leslie wrote:
>    Alas, I haven't found time to completely read any of these drafts;
>but I think an overview would be valuable...
>
>Bob Briscoe <[e-mail]> wrote:
> >...
> > To be absolutely clear:
> > a) SYN-EOS OOB client sends a SYN and an OOB segment to complement
> > it, using same src & dst ports. The OOB segment has SYN=0, ACK=0 and
> > the seqno is the same as the ISN of the SYN.
>
>    This is draft-touch-tcpm-tcp-syn-ext-opt. Two packets are sent: one
>is a SYN; the other isn't.
>
> > b) SYN-EOS DS client sends 2 complementary SYNs, using same dst port,
> > but different src ports and different ISNs.
>
>    This is also draft-touch-tcpm-syn-ext-opt. Two packets are sent:
>both are SYNs. Joe asks us to work out which approach is better.
>
> > c) syn-op-sis client sends 2 alternative SYNs, using same dst port,
> > but different src ports and different ISNs.
>
>    This is draft-briscoe-tcpm-syn-op-sis. One packet is sent, but Bob
>expects a totally separate packet to be sent proposing a separate
>connection, and only one of these connections will completely open.
>
> > a & b use the word 'complement', which means an upgraded server needs
> > to have received both segments to start an upgraded connection.
>
>    I agree with Bob here.
>
> > c uses the word 'alternative', which means a server can start a
> > connection when it receives either, and the upgraded handshake only
> > completes if it's an upgraded server.
>
>    Likewise...
>
>    And I note that there's no _need_ to specify anything about the
>overlap between the two proposed connections.
>
>    I like this a lot better, because I never trust that two packets
>will always reach the same endpoint. Meddleboxes and muddleboxes are
>too common and too varied in their world-views.
>
>    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.

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.  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.
"
See <http://tools.ietf.org/html/draft-briscoe-tcpm-syn-op-sis-02#section-2.4.1>


>- 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)

    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.

    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.
"


> >>Probably the best way to decide is to implement both, get them in
> >>parallel into the olde wilde internets and see what sticks better!
> >
> > Before going to the trouble of implementation, some middlebox
> > traversal testing of the proposed packet formats might weed out the
> > field. I have a suspicion that the OOB segment won't get very far in
> > many cases - it's unlikely that all firewalls and intrusion detection
> > systems will allow the unusual ACK=0, SYN=0 and the same seqno as the SYN.
>
>    I agree with Bob that we don't need formal Experimental status to
>test how often an OOB packet will fail to pass a middlebox.
>
>    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 support for the option to extend the option space is 
confirmed by the server. So it seems redundant for the server to 
feedback yet another confirmation via a checksum of all the extra 
options requested.


>- that any timing questions be specifically explored as part of the
>   experiment. (This includes _whether_ there should be any overlap
>   between the experimental SYN and the legacy SYN.)

Good point.


>- that an explicit allocation of one (or more, possibly) dedicated
>   option number be requested from IANA.
>
>====
>
>   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,

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).

If the server has to check every sequence of bytes starting at every 
byte within the payload for a match with all possible TCP options, 
when searching through any arbitrary payload, it will continually 
return loads of false matches (and it will consume excessive cycles).

This also doesn't provide any path to add new options.

>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.


>    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.

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.


>    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 believe that much deserves to be settled _before_ tcpm-fastopen
>is published as an RFC. (NB that document currently has been approved
>for publication, but is waiting on a Point-Raised writeup.)
>
>    The fastopen mechanism calls for the SYN sender to request a
>Fast Open Cookie, which the SYN receiver will generate and return in
>the SYN-ACK. In a _future_ connection, the SYN sender can send that
>cookie, and all payload data will go to the application _before_ the
>three-way handshake completes. Thus there is no way to use both
>fastopen and SYN-U in the same connection. This is unfortunate!!!

As above, syn-op-sis contains text solving this already. And the same 
approach can be used by the other drafts.


>    (Note that fastopen will be Experimental; and deficiencies can be
>fixed before it reaches Proposed Standard: it's just best to consider
>overlaps like this before the RFC is published.)
>
>====
>
>    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.
>
>    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.

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). 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>

BTW, I spend most of my time these days working on a project to 
remove latency from protocols.

Cheers


Bob


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

________________________________________________________________
Bob Briscoe,                                                  BT