Subject: [tcpinc] draft-ietf-tcpinc-tcpeno-02 posted

From: David Mazieres <[email-masked]>
Date: Thu, 30 Jun 2016 00:05:06 -0700

We've just posted the latest revision of TCP-ENO here:

        https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/

It makes the following changes to the wire protocol:

* Reflects the new ExID we have been allocated, and specifies
  implementations MUST NOT use the old option kind 69 unless/until it is
  assigned by IANA.

* SYN-ACK segments from passive openers must now always contain a
  general suboption with b=1.  This was driven by Christoph's point that
  sites like Baidu employ load balancers that just echo whatever unknown
  options are found in TCP SYN segments, which would have been bad with
  the previous version of ENO.

* Given that different "b" bits are now required from both ends, the
  role negotiation is much simpler and there is no more "p" bit.

* Also in response to a point made by Christoph, the draft is now clear
  that hosts must continue to send non-SYN form ENO options until they
  receive a non-SYN segment.  (Otherwise, an interpretation of the
  previous draft could have caused problems when the third leg of a TCP
  handshake was lost.)

* There are no more reserved initial suboption bytes.  Instead, the
  general suboption just has five bits (two of which are reserved for
  future use).  This just makes exposition a lot simpler.  But we still
  have future extensibility, because now all but the first general
  suboption in an ENO option MUST be ignored.

* The length word now only has 8 bits of length.  If we ever do get
  really large options, who knows what that will look like, so better to
  reserve the top 4 bits for future use than try to anticipate what
  might be useful.

* The forward secrecy requirement has been tweaked, since as Yoav
  pointed out, a protocol spec cannot guarantee forward secrecy, only
  permit implementations to achieve it.  Instead we just say
  confidentiality MUST NOT depend on long-lived secrets, and
  implementations SHOULD provide forward secrecy.

In addition, we made a bunch of changes to the structure and text:

* Shorter intro, with requirements in a separate section.

* There's a new terminology section.

* Separate normative and non-normative text by section.  E.g., the
  handshake examples and much of the rationale have been moved out of
  normative specification section into their own sections.

* The experiments section was pared down to the actual experiment we
  will actually be performing.

* The security considerations section has been significantly revised,
  including a much sterner warning about the weaknesses of opportunistic
  encryption, more clarity on the importance of the transcript, and a
  citation to RFC4086 for randomness.
  
Feedback welcome!

Thanks,
David