Re: [tcpm] possible NAT support for TCP-AO

[Ron Bonica <[e-mail]>]

Joe,

If TCP-AO were for the exclusive use of BGP, I wouldn't worry so much
about NAT. Nobody (to the best of my knowlege) runs BGP across a NAT
boundary.

If TCP-AO is being designed for non-BGP applications also, the tweaks
that Joe describes make perfect sense. They appear to be simple enough
and shouldn't take too long to document.

                                   Ron

Joe Touch wrote:
> Hi, all,
> 
> Based on a discussion on a different list with Dan Wing, I'd like to
> revisit thinking about NATs in the context of the current AO, which uses
> traffic keys derived from the socket pair and ISN pair. We might be able
> to now support NATs as follows, e.g.:
> 
> 	add the following flags to the MKT:
> 
> 		localNAT flag - indicates whether the local IP/port are
> 			zeroed before MAC calculation
> 
> 		remoteNAT flag - indicates whether the remote IP/port
> 			are zeroed before MAC calculation
> 
> 	add steps to the incoming/outgoing processing:
> 		zero the corresponding IP/port when the flag indicates,
> 		both on outgoing and incoming MAC calculation
> 
> That's basically it. A client behind a NAT would have a MKT with
> localNAT true, and a server for that client would need to have a MKT
> with remoteNAT true. This does require careful MKT configuration.
> Although I wouldn't expect both localNAT and remoteNAT to be true, there
> isn't a particular reason it needs to be prohibited.
> 
> Here's the security impact:
> 
> 	- no impact to other connections (AFAICT)
> 
> 	- SYN/SYN-ACKs limited only as much as the MKT TCP connection
> 	ID is, i.e., as a small range or single value rather than
> 	wildcard for either address or port
> 
> 	- connections are reasonably well-protected once established,
> 	much like BTNS (due to use of both ISNs in the traffic keys)
> 
> 	- reduced entropy for the traffic keys from a given MKT,
> 	since their input could be limited to the ISN pair in the
> 	worst case
> 
> I did NOT include this in TCP-AO-05, but it's simple enough to add if
> useful. I'd like to ask that we think about this before Stockholm, and
> discuss it on the list if possible in advance.
> 
> Joe
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm
.