[tcpm] TCP-AO: A position on NAT-T support

["Gregory M. Lebovitz" <[e-mail]>]

The question about whether or not TCP-AO should be designed for 
NAT/NAPT traversal (NAT-T) has been bandied about some on the list. 
My position: we SHOULD NOT design to support NAT-T. If NAT-T is a 
requirement for an application, then TCP-AO is the wrong choice for 
authentication protection. The application will need to be tunneled 
over IPsec using IKE+ESP. The logic for this position follows.

1. NAT-T Support is an Appropriate Requirement
NATs exist. We may not want or like them, but they are there in the 
network. Applications want to fulfill the simultaneous requirements 
of being confidential and authenticated AND traversing NATs. The 
standards must allow for the apps to do both simultaneously. On its 
own, the requirement is sane and healthy.

2. Not Every Protocol MUST Fill Every Requirement
The IETF MUST give every app a way to simultaneously traverse NATs 
AND be authenticated. However, it does not necessarily follow that 
every protocol must have a way to simultaneously provide apps with 
NAT-T and authentication. As long as at least one or more protocols 
does allow a specific app to accomplish NAT-T + Authentication, we 
have succeeded. In other words, we need not burden every protocol 
with every use case. In the case of TCP connections, IKE+ESP can 
simultaneously provide NAT-T and Authentication, though at a costs of 
more processing and layering and configuration complexity.

3. Designing for NAT-T in TCP-AO without tunneling MAY be impossible
Supporting NAT-T means we design with the expectation that IP's and 
ports will be changed in flight. However, we do not relax other 
security requirements like replay protection. We need to solve for 
both inter-connection replay attacks and intra-connection replay 
attacks. In order to do this, we need to compute the integrity MAC 
across something that includes message uniqueness at time "T", and do 
so in a way that it would be almost impossible for the uniqueness to 
be duplicated at some other time T-n. Today in AO we are going to use 
Initial Sequence Numbers combined with Extended Sequence Numbers and 
a MAC over the 5 tuple to ensure uniqueness of the session. In 
essence, we use I/ESNs + src/dst IP + proto + src/dst Port as a 
"connection ID". In order to support NAT-T we must remove src/dst IP 
+ src/dst Port from this calculation, because they may change after 
NATing. What do we replace it with? After reviewing the few options 
that do not include tunneling, one concludes that a fairly large (8 
octets in ESP's case) unique Connection_ID integer is required to be 
included in the Option header, covered by the MAC, along with 
something else connection specific, like ISN. However, due to size 
constraints on TCP Option header lengths, most agree we cannot afford 
8 octets for a Connection_ID field unless we also agree to change the 
size of the Data Offset field itself in the TCP header. changing TCP 
header fields is too big a hassle to be practically considered; the 
cost-benefit analysis makes no sense in this case.

4. Tunneling Works, and a Specification Exists
If we can't change the bits in AO to allow for NAT-T directly, then 
we fall back to creating a tunneling mechanism. In a tunneling 
mechanism we MAC over the original IPs/Proto/Ports, and then we 
encapsulate all that into another header that we know will easily get 
through NATs, like UDP. We negotiate all this using a Key Management 
Protocol (KMP). This would give us something like 
APP-in-TCP-in-IP-in-FOO-in-IP. We process the MAC over the inner 
packet and its 5-tuple, and leave the outer FOO-IP untouched. And it 
works; NAT won't break things and we get integrity checking that 
allows us to leverage the 5-tuple for connection identification 
uniqueness. The downside is that the tunnel adds a processing stack 
layer above the original solution, and complexity to the overall 
configuration. The routing community has been averse to adding 
another stack above the BGP-TCP, given that processing models for 
BGP-TCP are now so well understood and so highly tuned on networking 
devices. And it has been averse to the added complexity of the 
tunneling mechanism. Should we conquer the tunneling aversion, we 
already have a specified way to do integrity checks with a NAT-T 
supporting tunneling mechanism: IKE+ESP with NULL-encryption. Since 
we have a solution to the "create-a-tunnel" problem already, we need 
not create another one.

5. Summary of Options to support NAT-T
  - Add Connection_ID field to AO and make the required change to the 
Data Offset field in the TCP header. There appears to be VERY little 
appetite for this option.
  - Tunnel the IP+TCP in something in deployments where you need 
NAT-T. In this case, employ tunnel and integrity check using IKE+ESP-NULL.

6. Recommendation:
Do nothing wrt NAT-T support in TCP-AO. Add a section to TCP-AO spec 
instructing those needing NAT-T to either tunnel in IKE + ESP-NULL, 
or re-architect to remove the NAT and use TCP-AO.

Thoughts?

Gregory

+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m 

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm