Stephen Kent <[email protected]> writes: >> "... >> There are reasons why this is relevant from an IETF standards point of >> view. Because TLS, despite the name, is not really at the same layer as >> TCP, it will be difficult to use in conjunction with other layer-4 >> standards such as TCP minion, fast open, and multipath, while there are >> more or less straight-forward ways to extend tcpcrypt and other >> TCP-layer standards to benefit each other. > I always disliked the choice of name for TLS because, as you note, it > is not a transport later security mechansim; it rides above the > transport layer. > But, I lost that argument :-). > > That said, it is worth noting that TLS works over MPTCP, as Siri > demonstrates, > and is now supported in at least one commercial hardware front end in > this context. > Thus one ought not say that a TLS-based approach "... will be difficult > to use with ... multipath > ... "
I said benefit each other. Of course TLS can benefit from any TCP extensions including MPTCP, since it runs on top of TCP. But not vice versa. That's why currently MPTCP needs its own auth mechanism. My argument is that whether or not something is a small patch at the TCP layer or mostly layered on top of TCP is relevant from an IETF standards point of view. It affects not just the size of tcpinc implementations, but also the size of future RFCs that might want to integrate tcpinc and other TCP extensions. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
