Re: [v4v6interim] [46translation] [BEHAVE] Proposal for new BEHAVE charter

Iljitsch van Beijnum <iljitsch@muada.com> Fri, 24 October 2008 06:09 UTC

Return-Path: <v4v6interim-bounces@ietf.org>
X-Original-To: v4v6interim-archive@ietf.org
Delivered-To: ietfarch-v4v6interim-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903B63A691E; Thu, 23 Oct 2008 23:09:25 -0700 (PDT)
X-Original-To: v4v6interim@core3.amsl.com
Delivered-To: v4v6interim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07F43A6358; Thu, 23 Oct 2008 23:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 nCpfbi++sYeW; Thu, 23 Oct 2008 23:09:23 -0700 (PDT)
Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id CB5443A689F; Thu, 23 Oct 2008 23:09:22 -0700 (PDT)
Received: from [192.168.0.195] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id m9O6A4Sn076306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Oct 2008 08:10:05 +0200 (CEST) (envelope-from iljitsch@muada.com)
Message-Id: <36D6478D-4C43-4517-92B5-FA1ECCA94EA7@muada.com>
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <A1BB57A1-8B5F-44FF-85BE-C533D0FAE85D@cisco.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Fri, 24 Oct 2008 08:10:24 +0200
References: <48F8539D.90608@ericsson.com> <48FB9C5E.8070402@gmail.com> <3E041E8D-8539-4A16-9188-86A1DCEEE62B@muada.com> <200810201358.29295.remi.denis-courmont@nokia.com> <8E5328A8-4937-41A8-A650-204795E074D1@muada.com> <5B78195C-1318-4325-8F98-BC19F59E1532@cisco.com> <01462145-8E18-465A-8989-D1C98D421DED@muada.com> <B5A2E7E1-7FAE-48B6-85E2-B1300DF1458D@cisco.com> <9E0384AB-A20B-44E7-8575-9275101FF920@muada.com> <49008B8E.9080408@ericsson.com> <49008F1E.3010804@cisco.com> <FABF6711-4591-4182-A1B4-002BC5F18B9D@cisco.com> <49009C8B.80707@cisco.com> <A1BB57A1-8B5F-44FF-85BE-C533D0FAE85D@cisco.com>
X-Mailer: Apple Mail (2.929.2)
Cc: v4v6interim@ietf.org, 46Translation <46translation@employees.org>, Behave WG <behave@ietf.org>
Subject: Re: [v4v6interim] [46translation] [BEHAVE] Proposal for new BEHAVE charter
X-BeenThere: v4v6interim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of coexistence topics for the 01-Oct-2008 v4-v6 coexistence interim meeting <v4v6interim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/v4v6interim>
List-Post: <mailto:v4v6interim@ietf.org>
List-Help: <mailto:v4v6interim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

On 23 okt 2008, at 18:06, Cullen Jennings wrote:

> If you want to be able hide that two uncorrelated sessions are  
> actually coming from the same internal host, well, I'm not sure I  
> see how to do this with 1:1 mappings.

Here's how:

For every new session, the NAT66 box creates a new 1-to-1 maping. So  
for every new session it must choose a new address from a pool map  
that address to the internal source address of the host in question.  
As long as the external addresses checksum to the same value as the  
internal address, the transports that use the normal checksum over the  
pseudo header are happy and don't have to be modified by the  
translator. In IPv6 sessions can of course be identified by the flow  
label so this will work for transports that the translator doesn't  
know. Since the mappings are 1-to-1, incoming sessions can still work  
with help from STUN. The translator does need to keep and time out  
state for translation mappings, though.

This will burn through very many addresses, but even with the checksum  
restriction this shouldn't be much of a problem if the translator  
"owns" a reasonable size prefix, i.e. the prefix is routed to the  
translator so no neighbor discovery is necessary. This kind of  
obfuscation would work really well with a very large prefix and very  
many hosts, such as a /48 for a large site, although in that case the  
state maintenance could be an issue.

There is still the issue that hosts can be recognized by the value  
that the addresses checksum to, but this can be solved by aggressively  
using RFC 3041 or by assigning all hosts checksum-equivalent addresses  
using DHCPv6.
_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim