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

"Dan Wing" <dwing@cisco.com> Mon, 08 September 2008 01:42 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0E03A6958; Sun, 7 Sep 2008 18:42:22 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B71CB3A68F0 for <tcpm@core3.amsl.com>; Sun, 7 Sep 2008 18:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.253
X-Spam-Level:
X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-3.207, BAYES_50=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, TVD_STOCK1=3.753]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Klq+8gL05tEL for <tcpm@core3.amsl.com>; Sun, 7 Sep 2008 18:42:18 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1BBDD3A68E4 for <tcpm@ietf.org>; Sun, 7 Sep 2008 18:42:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.32,354,1217808000"; d="scan'208";a="44713189"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 08 Sep 2008 01:42:18 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m881gIMW028900; Sun, 7 Sep 2008 18:42:18 -0700
Received: from dwingwxp01 ([10.32.240.194]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m881gIFc000614; Mon, 8 Sep 2008 01:42:18 GMT
From: "Dan Wing" <dwing@cisco.com>
To: "'Gregory M. Lebovitz'" <gregory.ietf@gmail.com>, <tcpm@ietf.org>
References: <48b8a650.1cba720a.6f95.27a7@mx.google.com>
Date: Sun, 7 Sep 2008 18:42:18 -0700
Message-ID: <064c01c91154$21222260$c2f0200a@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AckKQipECXFzb5+ASPOtbQjlNrdIxQHEYwAg
In-Reply-To: <48b8a650.1cba720a.6f95.27a7@mx.google.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6374; t=1220838138; x=1221702138; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:=20RE=3A=20[tcpm]=20TCP-AO=3A=20A=20position=20on= 20NAT-T=20support |Sender:=20; bh=DfLGjC7FtiOUmik2rxfYHGYd/UUCdM9MnfSRqeStAH8=; b=gp7Xhb++bF+gTUq0gm33blbjnpX89tu7MXL0tXgzIypn860Yenbh1pC2n0 gHDBfQ//l5cNLPLdpuEnPJwTmE+JFIuNUn9JDyRTTX5JXEqtiDtQhUYMoFuN XCcg4QJW/V;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
Subject: Re: [tcpm] TCP-AO: A position on NAT-T support
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

 

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> Behalf Of Gregory M. Lebovitz
> Sent: Friday, August 29, 2008 6:46 PM
> To: tcpm@ietf.org
> 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.
> 
> 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?

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