Wednesday, Tero brought up the prospect of middleboxes reordering
back-to-back unknown options. This would currently mess up the ENO
transcript. Obviously middleboxes can process and manipulate options
they know about. The question is whether anyone has knowledge of a
middlebox that would flip the order of two, back-to-back, options of the
same, unknown kind. It's hard to see a rationale for such behavior.
Then again, rationality is not the best predictor middlebox behavior.
Hence, I'm wondering if anyone has any concrete data or knows of a box
that would do this in practice.
Depending on the likelihood of such reordering, I see several ways to
proceed.
1. If it truly never happens in practice, then we can leave ENO as-is
and add a clause to the effect that middleboxes MUST NOT reorder ENO
options with respect to one another.
2. If it happens extremely rarely, then the transcript can
lexicographically sort host A's ENO options. The order of options
is meaningful in host B, however, so there we don't sort. Since
host B SHOULD send only one ENO option except in weird fringe cases
(such as simultaneous open), we can figure that two unlikely things
are really unlikely to happen simultaneously.
3. Use bytes of the form 1000xxxx (general suboptions with v=1) as
no-ops, and specify that multiple ENO options must be
lexicographically sorted. This sacrifices other uses of bytes
128-143, but has the advantage that in the common case it requires
no extra bytes. Another advantage is that if we ever get truly
large SYN options, this would potentially allow more than 256 bytes
of ENO options.
4. We could add a length byte to every variable-length suboption,
allowing multiple variable-length suboptions to be packed into the
same ENO option. Then we limit hosts to sending only one ENO option
in a SYN segment. The cost is an extra byte of precious option
space in the common case, and limitation to 254 ENO bytes if we ever
get large SYN options.
5. Use bytes of the form binary 100xxxxx (that's general suboption and
reserved cs values, with v=1) as markers for a 1-32 byte suboption
(where the length of variable data is 1 + xxxxx). This has the
advantage that you only need the byte if you have more than one
variable-length suboption, and the disadvantage that bytes 128-159
might have been useful for something else in the future. Another
disadvantage, if we ever get large SYN options, is that all but the
biggest variable-length suboption is now limited to 32 bytes.
6. Like the previous, but certain values of xxxxx could mean "a length
byte follows." This has the disadvantage that the most likely value
of xxxxx is 32, yet 32 is a nice number for ECDHE parameters if we
ever get large SYN options. Also, again all ENO suboptions are
limited to 254 total bytes.
My preference, in order of decreasing appeal, is: 1, 2, 3, 6, 5, 4, with
a big distance between the first three (1, 2, 3) that I'm basically okay
with, and the last three (6, 5, 4) for which I would require some
convincing. However, now that the document belongs to the working
group, I'm soliciting opinions from everyone.
Obviously my preference is heavily motivated by the hope that we someday
get large TCP options. Though it seems unlikely in the near future,
history is littered with examples of people underestimating maximum
parameter values. Particularly given that large options would make us
want to embed public-key-like values into SYN segments, and that each
individual ENO option will still be 256 bytes, I'd like to preserve the
ability to have more than one ENO option per SYN segment.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
