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

[John Leslie <[e-mail]>]

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

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

====

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

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

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

- 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. The receiving endpoint would search for
the extra options whether or not it found the SYN-U option in the
initial SYN, 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.)

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

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

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

--
John Leslie <[e-mail]>