[SAFE] an idea on nested nats with overlapping addresses
Jonathan Rosenberg <jdrosen@cisco.com> Mon, 03 December 2007 08:02 UTC
Return-path: <safe-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6GA-0003ac-7j; Mon, 03 Dec 2007 03:02:34 -0500
Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1Iz6G8-0003a1-FQ for safe-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 03:02:32 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz6G2-0003ZR-9T for safe@ietf.org; Mon, 03 Dec 2007 03:02:26 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz6G1-00051d-Rj for safe@ietf.org; Mon, 03 Dec 2007 03:02:26 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Dec 2007 00:02:25 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lB382PMx012775 for <safe@ietf.org>; Mon, 3 Dec 2007 00:02:25 -0800
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lB382P1f023284 for <safe@ietf.org>; Mon, 3 Dec 2007 08:02:25 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:24 -0800
Received: from [10.21.87.30] ([10.21.87.30]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 00:02:24 -0800
Message-ID: <47530F91.8040502@cisco.com>
Date: Sun, 02 Dec 2007 15:03:29 -0500
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: safe@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Dec 2007 08:02:24.0954 (UTC) FILETIME=[D70579A0:01C83582]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1831; t=1196668945; x=1197532945; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20<jdrosen@cisco.com> |Subject:=20an=20idea=20on=20nested=20nats=20with=20overlapping=20address es |Sender:=20; bh=X6c/FXmuG/q2L577qXQZ9qJjG4gTbsdY0A3eN7vpbVw=; b=Uf759BBEneasGCS6Mr/9OHQZUm1h2gObri/DR3Sv6OlR+fuk15zGYUCRQILPSuHwdOQL/4SX 2yV3+g/2pSn6hJNhSYmly8M3dmVk7vuaz4UBSmM+R0gbp1JzXpyetkP4;
Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: 1.9 (+)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Subject: [SAFE] an idea on nested nats with overlapping addresses
X-BeenThere: safe@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Self-Address Fixing Evolution <safe.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/safe>, <mailto:safe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/safe>
List-Post: <mailto:safe@ietf.org>
List-Help: <mailto:safe-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/safe>, <mailto:safe-request@ietf.org?subject=subscribe>
Errors-To: safe-bounces@ietf.org
One of the limitations of stun control is it doesn't work when there are nested NAT with overlapping address space. There isn't an easy solution for this case, but here is one idea. The client includes its own source IP in the Binding Request that gets sent to the outermost NAT. If an intervening NAT notices that this address matches its own outside IP address, a conflict is detected. Oftentimes, the nat obtained its outside IP from DHCP to the next NAT. So, the NAT that detected the conflict redoes DHCP to obtain a new IP address. If any stun-control compliant NAT does the following two things: 1. when providing DHCP responses, provide a random IP address from within the address pool 2. when receiving a packet from the inside, whose destination IP matches the netmask of the internal network, but does NOT correspond to an existing host, forward towards the outside This would cause the address space to self-organize into non-overlapping segments. There are clearly issues with this appraoch: 1. other sessions in progress would be killed when nat bindings change (though maybe the nat can obtain an additional IP via DHCP rather than replacing its existing one) 2. might cause packets targeted for a private IP to hit a network with public addresses (via the second rule). If we modify the rule so that forwarding only occurs across interfaces with private IPs, this fixes it but only allows nesting where all intermediate address spaces are private. Just a thought... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ SAFE mailing list SAFE@ietf.org https://www1.ietf.org/mailman/listinfo/safe
- [SAFE] an idea on nested nats with overlapping ad… Jonathan Rosenberg