On Nov 7, 2015, at 3:28 AM, David Mazieres <[email protected]> wrote: > 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. > […] > 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.
I guess one of the approaches I suggested in my last E-mail (before I had read yours) is basically equivalent to this, only with the pattern being 10xxxxxx (allowing for 1-64-byte sub options but consuming more primary sub-option space). Some flavor of this approach would be my preference, but I don’t have a strong intuition for whether the 10xxxxxx or 100xxxxx pattern is better. At any rate, to reiterate, having multiple TCP-ENO options floating around in one TCP header and expecting different implementations to do something sensibly consistent with them sounds terrifying, especially when the common - and thus only well-tested - case will almost certainly be only one option. B
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
