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, 07 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
- [tcpm] TCP-AO: A position on NAT-T support Gregory M. Lebovitz
- Re: [tcpm] [BULK] TCP-AO: A position on NAT-T sup… Caitlin Bestler
- Re: [tcpm] TCP-AO: A position on NAT-T support Dan Wing