Re: [tcpm] possible NAT support for TCP-AO
"Gregory M. Lebovitz" <gregory.ietf@gmail.com> Sat, 25 July 2009 23:22 UTC
Return-Path: <gregory.ietf@gmail.com>
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 0B22F3A6B99 for <tcpm@core3.amsl.com>; Sat, 25 Jul 2009 16:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level:
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044]
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 1xckBEPSYDZl for <tcpm@core3.amsl.com>; Sat, 25 Jul 2009 16:22:46 -0700 (PDT)
Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id DA0883A6B4C for <tcpm@ietf.org>; Sat, 25 Jul 2009 16:22:45 -0700 (PDT)
Received: by pzk29 with SMTP id 29so438353pzk.29 for <tcpm@ietf.org>; Sat, 25 Jul 2009 16:22:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:x-mailer:date:to :from:subject:in-reply-to:references:mime-version:content-type; bh=BZRxtlp59xyQ+c2RAce5nKnhRRpMR56jhF6pNytXmI0=; b=qeQ5lco2a+I7b5uPKfJk5dmX4dKQ2rSL+j4IBvQlShnp7SDwUEpFZTad9hj/1o/d5q m0eH6ecLE/1fUY9iJLB6Iez+Xe2WCnECu0tTIjfr/zevX+SmJk2vk1Sb5zaQ1683Fb3r AAyFvpDIzg/oef1SLUCCdgywUT2/2W0K2lT10=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:x-mailer:date:to:from:subject:in-reply-to:references :mime-version:content-type; b=iRHtJUXsAtFcmrKGVOZWfISXXtqeS8ftpospq6sjbooRcC0Y7dkH0VqxuRCt1mSCdz L7Iw+YD4wuWsWWrlPkhS8GwEb12xoLP9ZO39GkNhUJ9JLwIsWA4pEJZiO1KcJsEoDkYE sYZWvKt+aoV1RilNxOQhGypCCLypevja18E2M=
Received: by 10.114.191.1 with SMTP id o1mr7001395waf.108.1248564165057; Sat, 25 Jul 2009 16:22:45 -0700 (PDT)
Received: from Gregory-T60.gmail.com (nat-service4.juniper.net [66.129.225.151]) by mx.google.com with ESMTPS id m30sm9864509wag.34.2009.07.25.16.22.41 (version=SSLv3 cipher=RC4-MD5); Sat, 25 Jul 2009 16:22:43 -0700 (PDT)
Message-ID: <4a6b93c3.1ed6720a.33e5.0667@mx.google.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 25 Jul 2009 12:25:28 -0700
To: Joe Touch <touch@ISI.EDU>, tcpm Extensions WG <tcpm@ietf.org>
From: "Gregory M. Lebovitz" <gregory.ietf@gmail.com>
In-Reply-To: <4A5B9FEB.6080706@isi.edu>
References: <4A5B9FEB.6080706@isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: Re: [tcpm] possible NAT support for TCP-AO
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: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Sat, 25 Jul 2009 23:22:47 -0000
inline... At 01:58 PM 7/13/2009, Joe Touch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >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, I'm not against the idea. I see some issues (see more below). But I think it could work. My one big concern is that the BGP community has been waiting a VERY long time for this update, and I'd hate to drag out a last call, or RFC, for this issue which they don't care much about. But I think solving it in the long run is important. As a compromise between these two competing needs, might we consider this: - proceed to WG LC & RFC without the NAT solution. - in parallel, work on text for the NAT solution - do a rather quick rev of the first RFC to include the NAT solution (and the few bugs I'm sure we'll find as we move to implementations) ?? >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 This will be tough, as you won't always know. We could solve this later in a KMP system that provides NAT detection, and hands the answer down to the TCP stack config (I'm thinking of the way that NAT-T for IKE works wrt IPsec/ESP). But it could work. > add steps to the incoming/outgoing processing: > zero the corresponding IP/port when the flag indicates, > both on outgoing and incoming MAC calculation If both directions are behind NATs (a very probably case for non-routing protocol usage), then the uniqueness data defining the connection is reduced greatly, i.e. only the ISNs remain as unique. This affects the entropy of the KDF, where the connection data is used as the input to the function, in order to derive the traffic keys. If I'm not mistaken, it means that, in the unlikely event that the same ISN's are chosen for a different connection 5-tuple, then a replay attack could be accomplished. I can live with that risk trade-off, personally. But I'd want to make sure we call it out explicitly the NAT-T section where the mechanism is described, and then go into it more completely in the security considerations. section. >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 think what I described above fits under this point, if I understood Joe's point correctly. That's my .02, after a very quick read and response, Gregory. >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 >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.9 (MingW32) >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >iEYEARECAAYFAkpbn+sACgkQE5f5cImnZru8uwCeLaty+1z8+Qnrzg8L3G82SFO0 >4WEAoJ00Ww9omlO9ggb58lW064tDMqxl >=3Z2o >-----END PGP SIGNATURE----- >_______________________________________________ >tcpm mailing list >tcpm@ietf.org >https://www.ietf.org/mailman/listinfo/tcpm
- Re: [tcpm] possible NAT support for TCP-AO Joe Touch
- [tcpm] possible NAT support for TCP-AO Joe Touch
- Re: [tcpm] possible NAT support for TCP-AO Ron Bonica
- Re: [tcpm] possible NAT support for TCP-AO Gregory M. Lebovitz
- Re: [tcpm] possible NAT support for TCP-AO Eric Rescorla