Re: [tcpm] Review of draft-ietf-tcpm-tcp-auth-opt-01

Some points from the discussion:

Regarding NATs:

Your reasoning, as I understood it, for not including an option to
exclude the pseudoheader and port numbers for NAT traversal was that
the host needs these items to lookup the correct key anyway.

There are several situation where this is not the case. (I'll point
out that I see TCP-AO as being useful outside the domain of securing
BGP sessions between backbone routers)

1) A host installs a key on a listening socket with a wildcard
address. Thus, one can only connect to the socket if you know the key.
The key probably rotates based on time. This is currently, usually
done based on "port knocking" - which has always struck me as a messy
solution. The resulting, ESTABLISHED connection knows the port numbers
and IP addresses without having to establish it before hand.

2) An unauthenticated connection is established and the userland code
wishes to upgrade to TCP-AO. Again, since the connection is
established the keyset to use are implicit. I didn't know that the
NONE mac was designed for upgrading like this. In my Linux patches
there's a TCP_AUTH_LATCH option which means "accept unsigned packets
until the first signed packet, then require signatures".

In both of these cases, excluding port numbers and/or pesudoheaders is
needed given the deployment of NAT boxes which change these headers.

Keyids:

I agree that keeping the cryptography in the MAC is a good thing.
There is an implementation issue about the number of keys that a
kernel may have to store (80ish bytes per key * 256 keys * number of
configured hosts), but that's not a spec problem.

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm