Inline [MSC]... ________________________________________ Von: Tcpinc [[email protected]]" im Auftrag von "David Mazieres [[email protected]] Gesendet: Sonntag, 3. August 2014 20:20 An: Scharf, Michael (Michael); marcelo bagnulo braun; [email protected] Betreff: Re: [tcpinc] Protect or not the TCP header
"Scharf, Michael (Michael)" <[email protected]> writes: > If tcpinc specifies yet another scheme to protect the TCP header > (i.e., other than TCP-AO), I think the interoperability with the > existing running code has to be considered and > documented. Specifically, I guess there could be deployment scenarios > where TCP-based authentication is already in place, but additional > tcpinc-like encryption is desirable. (Well, probably we are not > talking here about residential Internet access.) So as an example, tcpcrypt (section 4.4) specifically excludes options TSOPT (8), Skeeter (16), Bubba (17), MD5 (19), TCP-AO (29), and MAC (OPT2) from the header MAC computation. Hence, it is well defined how to compute a TCP-AO MAC after computing a tcpcrypt MAC. There might be other drawbacks to using TCP-AO in conjunction with tcpcrypt (e.g., making two MAC passes over the payload, wasted option space) and I'm not sure anyone has ever tried it, but the intention is to avoid making the two specs incompatible with one another. After all, there could be some [MSC] Sure, but IMHO more discussion is needed what happens of TCP-AO and a non-TCP-AO-based tcpinc header protection were used in parallel. TCP-AO is a Proposed Standard... fringe applications that require both. [MSC] As a non-native speaker, I had to look up the term "fringe". I am not sure if this term characterizes well the typical deployment of TCP-based authentication schemes. Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
