On 10/30/2015 11:40 AM, David Mazieres wrote: > Joe Touch <[email protected]> writes: > >>> However, the fact that TCPINC does not protect headers does not mean >>> that TCP-ENO cannot be used to negotiate protocols other than TCPINC >>> that do protect the header. >> >> TCP-ENO can't protect the SYN headers except if there are already >> protections in place (ala TCP-AO). If that's the case, you don't need >> TCP-ENO. > > We should really subdivide this point to consider different levels of > protection. Certainly TCP-ENO does not rule out retroactively > authenticating SYN segments.
If you've acted on it there seems very little point in doing that. At best, you're authenticating whether to continue the connection, but SYN protection per se is gone. > However, the high-level model of TCP-ENO is to enable > application-specific authentication on top of generic transport-level > encryption. (realizing this is a side issue) then it ought to be called APP-ENO. > So first you set up a connection, then you make some > cryptographically verifiable assertions about who is at each endpoint of > the connection. If your goal is to protect against things like SYN-BOMB > attacks, ENO is never going to supplant AO. But AO certainly could be > part of an ENO encryption spec that protects against things like > off-path RST injection or desynchronization. Agreed. >> Let's suggest this for us both: >> >> - I update ENC-BTNS to use TCP-ENO > > Of course I'd be delighted to see this, particularly if there's any > chance of tcpm-tcp-syn-ext-opt or something similar becoming reality in > the near future. > >> - you update TCP-ENO to use RFC 6994 ;-) >> (at least until it becomes a standard) > > Well, this is a working group decision now that the ENO draft has been > adopted. Personally, I'd maybe prefer to see IANA's option assignment > lag behind reality rather than vice versa, but if a majority of the > working group feels the other way, I'd be happy to put in the work to > revise the draft. > > Note that in ENO's case, the biggest casualty of RFC 6994 would be > layering ENC-BTNS on top of ENO, at least until tcpm-tcp-syn-ext-opt. The only issue I see is whether to repurpose the ENO option on subsequent segments for ENC-BTNS or to use the AO variant. If we didn't reuse ENO, we'd have to decide whether to put the AO option in the SYN - I don't know if it's reasonable to start using a new option after the TWHS. I'll think further on that. > Having thought about this a bit, I think you can barely do it now and if > you consume two more bytes for an ExID it just won't work. That said, > you may have a different approach, or tcpm-tcp-syn-ext-opt may be closer > than I had expected, in which case it would be great to have an > encryption spec ready to take advantage of large SYN options. At that > point, it's also worth thinking more about how TFO fits into the > picture. I wish that TFO would allow AO-style session keys of the new connection using the TCP connection identifiers. E.g., TFO could avoid the need to rekey new connections in that case. Lots of stuff to consider... Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
