I never saw any response to my Nov 6 E-mail on "specific ways to evolve the TCP-ENO spec". I would especially like to hear any of the spec's authors address these particular concerns at the end of the E-mail, especially the first, which seems like a potentially significant protocol bug:
On 11/6/15 10:26 PM, Bryan Ford wrote: >Now for two issues that my closer read-through brought up, which are >at least partially orthogonal to the symmetric-mode support: > >1. The current section 3.1 doesn’t really state clearly where the “p” >bit comes from in Figure 4. It’s not included in the general sub >option specified in section 3.3, so I assume each endpoint is supposed >to “infer” both its own p-bit and the other endpoint’s p-bit. >Presumably it’s easy for each endpoint to decide the value of its own >p-bit, but how does each endpoint determine the intended value of the >other endpoint’s p-bit? For example, if I consider myself an active >opener (p=0), then do I decide that the other endpoint’s p-bit is a 1 >if the first TCP packet I get from them is a SYN-ACK, and decide the >other endpoint’s p-bit is a 0 if the first packet I get from them is a >SYN without an ACK (presumably indicating a simultaneous open)? If >so, I see a problem with race conditions. For example, my SYN >(without ACK) reaches my partner but his SYN (without ACK) gets >dropped on its way to me. The next packet he sends me (e.g., a >retransmission) will be a SYN-ACK, because he is by then aware of my >SYN. But he’ll correctly perceive my p-bit to be 0, and thus go into >tie-breaker mode, whereas I’ll think his p-bit is a 1 because I saw a >SYN-ACK first, and horrible confusion ensues. Perhaps it would be >better to avoid risk of such confusion simply by deleting the ‘z’ bit >from the sub option packet and instead just including an explicit ‘p’ >bit right next to the ‘b’ bit? > >2. Section 3 currently specifies that only one variable-length sub >option per ENO option is allowed, but that multiple ENO options can be >used if needed to contain multiple variable-length ENO sub options. I >understand the tradeoffs discussed in section 6.4 but frankly the >current solution makes my skin crawl. I think the ENO spec should be >defined such that it should never, ever be necessary to have more than >one ENO option in a single packet. This doesn’t necessarily mean >adding a whole extra byte to every variable-length sub option. Two >possible ways to avoid that are: (a) when v=1, use the next 3 bits to >choose from a few possible sub-option lengths: e.g., >0,1,2,4,8,16,32,64. A sub option that needs 5 bytes gets encoded with >3 padding bytes (oh well). (b) when v=1, use the next bit (u?) to >encode whether this is the “last” suboption (u=0) or not-the-last >suboption (u=1). When u=1 (a non-last suboption), the bottom 6 bits >encode the length of this (non-last) sub option, and the sub option >itself is coded starting in the next byte with v=1,u=0. This approach >would be just as space-efficient as the current proposal in the >presumably common case of only one variable-length sub option, and >would add one extra byte of overhead (for the v=1,u=1 length byte) for >each *additional* variable-length option encoded before that last >option. Thanks Bryan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
