[MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal

Hesham Soliman <hesham@elevatemobile.com> Thu, 19 February 2009 03:30 UTC

Return-Path: <hesham@elevatemobile.com>
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 6CA6C3A67DF for <mext@core3.amsl.com>; Wed, 18 Feb 2009 19:30:25 -0800 (PST)
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 J2eUF53n5++t for <mext@core3.amsl.com>; Wed, 18 Feb 2009 19:30:24 -0800 (PST)
Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by core3.amsl.com (Postfix) with ESMTP id 8971F3A672F for <mext@ietf.org>; Wed, 18 Feb 2009 19:30:23 -0800 (PST)
Received: from [211.27.108.142] (helo=[10.0.0.21]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.63 #1 (Debian)) id 1LZzcO-0007MQ-Nt; Thu, 19 Feb 2009 14:30:33 +1100
User-Agent: Microsoft-Entourage/12.15.0.081119
Date: Thu, 19 Feb 2009 14:30:25 +1100
From: Hesham Soliman <hesham@elevatemobile.com>
To: "mext@ietf.org" <mext@ietf.org>
Message-ID: <C5C31D81.B953%hesham@elevatemobile.com>
Thread-Topic: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal
Thread-Index: AcmRYrn9Oi5m4+57iEyWrCYRX2CktwA36z8r
In-Reply-To: <C5C1A63D.B8CE%hesham@elevatemobile.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-nemo-v4traversal
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/mail-archive/web/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>
X-List-Received-Date: Thu, 19 Feb 2009 03:30:25 -0000

Folks,

Please take a look the Pasi's comment below and my response and let me know
if anyone has comments on this before I submit the draft. This should be the
final comment on the doc. Does the text in section 3.2 make sense? If not,
does the explanation below make sense? If not please suggest text.


> Section 3.2:
>>   Securing these messages requires the mobile node to have a
>>   security association with the home agent, using IPsec (AH or ESP)
>>   and based on the mobile node's IPv4 care-of address as described
>>   in [RFC3775].  Since the mobile node needs to encapsulate all IPv6
>>   traffic sent to the home agent into IPv4 while located in an
>>   IPv4-only visited network, this SA would match all packets if the
>>   selectors were based on the information in the outer header.
> 
> This looks strange (when using tunnel mode IPsec, the selectors select
> the packets to be protected before the outer header is added -- so the
> last sentence is weird) -- what are the IPsec SPD entries, and what
> does the resulting packet look like?
> 

=> I was confused by the snippet above and then went back to see why I added
this a long time ago. Basically the scenario here is that a MN can send the
prefix solicitation and receive advertisement from its HA, while located in
a foreign link. These messages may be sent before a home address is
allocated. So, if a MN is located in an IPv4 network, it would have to
negotiate the SA using IPv4 and it's IPv4 address is one of the selectors.
The inner IPv6 packet would probably contain a link local in the src address
since there is no global IPv6 address available to the MN. In 3775/6, the
(un-encapsulated message) is protected by a transport mode SA. In DSMIP, if
we do a transport mode SA on the outer header, then this SA would apply to
all traffic since everything is tunnelled back to the HA. And the outer
header is identical for all packets.

Does this make sense to you? If so, I can clarify the text according to this
logic. If not, please let me know what I missed.

Hesham