[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
- [MEXT] FW: DISCUSS and COMMENT: draft-ietf-mext-n… Hesham Soliman
- Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-me… Basavaraj.Patil
- Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-me… Christian.Kaas-Petersen
- Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-me… Alexandru Petrescu
- Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-me… Alexandru Petrescu
- Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-me… Hesham Soliman
- Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-me… Hesham Soliman
- Re: [MEXT] FW: DISCUSS and COMMENT: draft-ietf-me… Basavaraj.Patil