"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