Re: [MEXT] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt

Hesham Soliman <hesham@elevatemobile.com> Mon, 01 December 2008 09:04 UTC

Return-Path: <mext-bounces@ietf.org>
X-Original-To: monami6-archive@megatron.ietf.org
Delivered-To: ietfarch-monami6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC3A3A68C2; Mon, 1 Dec 2008 01:04:40 -0800 (PST)
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FA6E3A68C2; Mon, 1 Dec 2008 01:04:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 zcZwGMOyX0sj; Mon, 1 Dec 2008 01:04:38 -0800 (PST)
Received: from smtp-2.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 9911A3A683A; Mon, 1 Dec 2008 01:04:37 -0800 (PST)
Received: from [124.190.106.160] (helo=[192.168.0.187]) by smtp-2.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1L74hE-0006Jy-Fl; Mon, 01 Dec 2008 20:04:31 +1100
User-Agent: Microsoft-Entourage/12.14.0.081024
Date: Mon, 01 Dec 2008 20:00:35 +1100
From: Hesham Soliman <hesham@elevatemobile.com>
To: Colin Perkins <csp@csperkins.org>
Message-ID: <C559F2E3.A7CA%hesham@elevatemobile.com>
Thread-Topic: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt
Thread-Index: AclTk0WdjZUk4daAZUWr985r+BYwTw==
In-Reply-To: <A70282C6-490B-433A-892E-CD516F9A7679@csperkins.org>
Mime-version: 1.0
Cc: TSV Dir <tsv-dir@ietf.org>, ietf@ietf.org, "mext@ietf.org" <mext@ietf.org>
Subject: Re: [MEXT] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org

>> 
>> => Well, I'm not sure how a NAT can do that. You mean the NAT will
>> parse the binding update message deep inside the IPv6 extension
>> header in the inner IP packet? This is where the original address
>> is preserved. To do that, a NAT would have to understand the
>> various MIPv6 options, and if it did, it would know not to do
>> that :) The inner header is IPv6, so a NAT should not touch that.
> 
> My understanding from the STUN work is that NATs have been observed
> which rewrite any sequence of four aligned bytes matching the source
> IP address, irrespective of its location within the packet (section
> 15.2 of RFC 5389).

=> Sounds freightning! May be we need to mandate encryption and hope that no
4-byte sequence matched the IP address? What do they do with encrypted
packets? How do they know they're encrypted?

Hesham




_______________________________________________
MEXT mailing list
MEXT@ietf.org
https://www.ietf.org/mailman/listinfo/mext