"Scharf, Michael (Nokia - DE)" <michael.sch...@nokia.com> writes:

> While TCPM discusses large SYN options (for a long time already), all
> known solutions have downsides. I do not believe that a non-TCPM
> document should speculate on the feasibility solutions.

Michael, what do you think of the new proposed wording?

   Various proposals exist to increase the maximum space for options in
   the TCP header.  Though these proposals are highly experimental--
   particularly those that apply to SYN segments--TCP-layer encryption
   could significantly benefit from the availability of increased SYN
   option space.  In particular, if future TEPs can perform key
   agreement by embedding public keys or Diffie-Hellman parameters
   within suboption data, it will simplify protocols and reduce the
   number of round trips required for connection setup.  With large
   options, the 32-byte limit on length bytes could prove insufficient.
   This draft intentionally aborts TCP-ENO if a length byte is followed
   by an octet in the range 0x00-0x9f.  Any document updating TCP's
   option size limit can also define the format of larger suboptions by
   updating this draft to assign meaning to such currently undefined
   byte sequences.

Our goal is not to second-guess TCPM, but rather to provide TCPM with a
data point that they have a "customer" for large SYN options in the
unlikely event that some proposal is ever deemed realistic.  I could
make the wording even stronger, as in:

   These proposals are highly experimental--with those that apply to SYN
   segments particularly unlikely to be adopted any time soon--but
   TCP-layer encryption could significantly benefit from the
   availability of increased SYN option space.

But that could be seen as second-guessing TCPM in the other
direction--telling TCPM we *don't* expect them to standardize large SYN
options anytime soon.  (Of course, it's true that I don't expect them to
do that, but it might not be my place to say so in an RFC unless you
sign off on the language...)

As always, concrete suggestions on wording are appreciated.

Thanks,
David

_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Reply via email to