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. Indeed, it even requires that encryption specs at least authenticate the negotiation transcript. However, the high-level model of TCP-ENO is to enable application-specific authentication on top of generic transport-level encryption. 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. > 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. 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. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
