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

From: "Caitlin Bestler" <[email-masked]>
Date: Tue, 2 Sep 2008 18:08:23 -0400

Gregory Lebovitz wrote:
> 
> 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.
> 

I agree.

TCP-AO should be kept simple and focused very specifically
on being a drop-in replacement for TCP-MD5. There should be
no expansion of its functionality unless it can be shown that
the additional application scenarios are NOT served by other
security solutions, and that the changes to the other
services would not be practical.

In my opinion that criteria would not be met by TCP-AO as
a whole, if there were not already applications finely tuned
to this specific security model. But those are *existing*
applications. New features are not used by existing applications,
and so the applications are free to use solutions other than
TCP-AO. We should encourage them to do so, rather than expanding
TCP-AO to be yet another "full service" security solution.

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

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 7 Sep 2008 18:42:18 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Gregory M. Lebovitz
> Sent: Friday, August 29, 2008 6:46 PM
> To: [email-masked]
> Subject: [tcpm] TCP-AO: A position on NAT-T support
> 
> 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.
> 
> 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?

To your Recommendation, I would also add that, in the future, it may
be deemed important to make TCP-AO work, and that at this point in
time it seemed the best path forward would be an additional 8 bytes
of connection-id, and say such a design is 'for future study'.

Tunneling brings another drawbacks which you didn't mention -- it
breaks VJ header compression and breaks ROHC (RFC3095 and successors).  
Compressing headers is important on bandwidth constrained links (e.g.,
satellite, mobile wireless).

-d

> 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 
>