On 8/1/2011 10:25 AM, David A. McGrew wrote:
...
But we lose all
TCP header MACing - e.g., someone can RST our connection. TCP AO
suggests that MACing TCP headers is important so crypto protocols should
do that (hence why we live in the transport layer).
True, but why not design tcpcrypt so that it make use of TCP-AO? That
seems like an approach that would work with the separation outlined above.
TCP-AO could easily support a mode where the TCP body was encrypted,
e.g., where the encryption algorithm were defined to use the connection
context (TCP header, IP pseudoheader) as context.
I had been planning on working that into the experimental TCP-AO NAT
doc, since it could be as useful as the NAT variant.
That won't help initialize the keys, as would be needed before the SYN
arrives for TCP-AO. That sort of in-band keying was excluded from TCP-AO
to keep the SYN header size down.
Joe
