RE: [SAFE] Addressing nested NAT issues for STUN control

"Dan Wing" <dwing@cisco.com> Fri, 26 October 2007 07:56 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 1IlK3f-0005U1-By; Fri, 26 Oct 2007 03:56:43 -0400
Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IlK3e-0005Tu-7X for safe-confirm+ok@megatron.ietf.org; Fri, 26 Oct 2007 03:56:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlK3d-0005Tm-UF for safe@ietf.org; Fri, 26 Oct 2007 03:56:41 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlK3X-0001TV-OV for safe@ietf.org; Fri, 26 Oct 2007 03:56:41 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2007 00:56:25 -0700
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 l9Q7uPVJ018788; Fri, 26 Oct 2007 00:56:25 -0700
Received: from dwingwxp01 ([10.32.240.196]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l9Q7uNPX004728; Fri, 26 Oct 2007 07:56:23 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>
References: <47209D16.7010902@ericsson.com> <092101c81740$7125fd40$c4f0200a@cisco.com> <47219865.9000103@ericsson.com>
Subject: RE: [SAFE] Addressing nested NAT issues for STUN control
Date: Fri, 26 Oct 2007 00:56:23 -0700
Message-ID: <135e01c817a5$b46093d0$c4f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
In-Reply-To: <47219865.9000103@ericsson.com>
Thread-Index: AcgXopTh+oAOjkUQTTWb3pWVMGBgjQAAlhxg
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1736; t=1193385385; x=1194249385; 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[SAFE]=20Addressing=20nested=20NAT=20issues=20for=20S TUN=20control |Sender:=20; bh=kVOLb8KzWzYv0CWXUceMgt+GsJBOKy9vUaf9u7AUaaw=; b=WcotPxK5HopRzlObdGpe/tqRxyQu80NoF/3ZYnTNp5mPrpadVYdo9zq9UbB4uMY/M75FlWsh C1tr0SNxI3KbLTHELZinxycLF3L2q5p9DfrXYPrBR8kyXBqNJouxAS41;
Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: safe@ietf.org
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

...
> Are you not misstating yourself here? Section 5.1 in the draft states
> the following:
> 
>   "After learning the public IP address of its outer-most NAT, the
>    endpoint sends a STUN packet to the STUN port (UDP/3478) of its
>    outer-most NAT's public IP address. "
> 
> And for the whole walk from out to in you only know the external IP
> address of the NAT.
> 
> I thought the issue with my example is that when stun client tries to
> send to 192.168.1.2/3478 it will only reach itself. Rather then being
> issues to send to the gateway address.

Either way, the STUN client has reached an incorrect conclusion:  the
STUN client is unaware of a NAT.  My proposal to use NAT-IDENTIFIER
prevents that incorrect conclusion.

> My initial reaction is that this is a big limitation. Nested 
> NATs seems to be the most common case when STUN control would provide 
> any serious benefit.

Let's separate (a) nested NATs with non-overlapping IP addresses from 
(b) nested NATs with overlapping IP addresses.  I believe STUN Control
works fine with (a), and you are pointing out that it doesn't work
well with (b).  (Let me know if I'm correct on that point.)

To resolve overlapping IP addresses, first we need to see how to
detect that, and then avoid doing STUN Control.  It might also be
possible, by doing more creative things, to have the outer-most
NAT contact the NATs on the inside by itself (and repeat that
procedure on each inner NAT).  I'm worried that could cause some
horrid security implications (packet expansion) and have not 
investigated it.  That is why I proposed in my previous email
a mechanism to use NAT-IDENTIFIER to detect NATs with overlapping
IP addresses.

-d


_______________________________________________
SAFE mailing list
SAFE@ietf.org
https://www1.ietf.org/mailman/listinfo/safe