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

Folks,
   The extended feeling which I get after watching some of the
conversation is that we seem to be in a cherry picking mode of what to
include/exclude in the digest (MAC) computation. (psuedo header, TCP
options etc.,)

So, if we are going down that route, then I would argue it may be
worthwhile to debate "how much" to include in general, i.e, is it
worthwhile to include selective portions OR part of the data portion of
the TCP data in the MAC computation instead of he entire data.?
Rationale and reasoning follows :-

- performance sensitive applications (in cases there are no hardware
assists for computing the crypto)
- the very reason of NAT (which you mnetion), yes, I am talking about
NAT ALG's which can muck around the data portion of the payload.

My point is that it boils down to how much flexibility one wants to
provide with the TCP AO. 

-Anantha

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> Behalf Of Adam Langley
> Sent: Monday, July 28, 2008 11:07 AM
> To: Joe Touch
> Cc: tcpm@ietf.org
> Subject: 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
> 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm