Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec

Ryuji Wakikawa <ryuji.wakikawa@gmail.com> Tue, 09 November 2010 01:23 UTC

Return-Path: <ryuji.wakikawa@gmail.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 45FDF3A69FF for <mext@core3.amsl.com>; Mon, 8 Nov 2010 17:23:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 z-DE2a8ATaQy for <mext@core3.amsl.com>; Mon, 8 Nov 2010 17:23:27 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 76BFE3A69FE for <mext@ietf.org>; Mon, 8 Nov 2010 17:23:27 -0800 (PST)
Received: by ywp6 with SMTP id 6so4270290ywp.31 for <mext@ietf.org>; Mon, 08 Nov 2010 17:23:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=QqqJVzjkCo6M4KcUw8065SgiHw25ysqM8R8Vc7+s/Y0=; b=jH5bzQ6K/yFw6Q57i8kA2R7BZRMTha4CJS5Mps/Hv6z3p8eD6ahKBakSE7cWFBLHtN ZS/Ztl5PqSV5eQ/rqfbQ/C3zIkUsvYqjKLuhcSy36JZPmRFvc3iyKgGPPP6LUbp4czxE 2IWUn2RNkFq+QliZkIQr495ylgjAL2KtEJQi0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=NRvvSS2RaKU4ivDsqnw2wqZzD7ceaM1GZ68G8G4VN1bj2cy2xtz0ZpXVEp05IjNYrV m992YFSvAaMgasyoTV2OsEtvmZ4+fg7Ma/VkpdyWGqf6RMlACAXSn4c3Iiia/ZpgElzI RezsUeesnaLCAsREymEh1p4rJwpxoa4PncvMM=
Received: by 10.151.41.3 with SMTP id t3mr5114055ybj.36.1289265827866; Mon, 08 Nov 2010 17:23:47 -0800 (PST)
Received: from dhcp-4246.meeting.ietf.org (dhcp-4246.meeting.ietf.org [130.129.66.70]) by mx.google.com with ESMTPS id q18sm109907ybk.3.2010.11.08.17.23.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 17:23:32 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1F69EFEC78@NALASEXMB04.na.qualcomm.com>
Date: Tue, 09 Nov 2010 09:23:26 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E705C674-5323-4E3D-96A4-F9C0F4E4DF22@gmail.com>
References: <BF345F63074F8040B58C00A186FCA57F1F69EFEC78@NALASEXMB04.na.qualcomm.com>
To: "Laganier, Julien" <julienl@qualcomm.com>
X-Mailer: Apple Mail (2.1081)
Cc: "draft-korhonen-mext-mip6-altsec@tools.ietf.org" <draft-korhonen-mext-mip6-altsec@tools.ietf.org>, "mext@ietf.org" <mext@ietf.org>
Subject: Re: [MEXT] Reviews of draft-korhonen-mext-mip6-altsec
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: Tue, 09 Nov 2010 01:23:30 -0000

Hi Jouni and Raj,

I quickly reviewed draft-korhonen-mext-mip6-altsec-06.txt. 

This document is well-written and can be easily read. 
I can't find any technical issues in the protocol definition. 

Here are some questions/comments.

1. How to define data traffic selector for encryption? 
IPsec has IPsec policy DB to decide which traffic should be applied encryption.
How can we apply encryption for certain data traffics? Is this up to implementation?

2. In Background.
In the early era of MIP6, signaling message was carried in IP header options. 
One of big reasons we can apply SSL for MIP security is that MIP has message type.
Nowadays, there are specs not even using MH message type.
RFC5844 carries MH encapsulated in UDP. Now you also carry MH messages in UDP. 

3. In 5.7.3, why not adding one entry for MNP. It can support NEMO without big change;-)

4. When I first read it, I prepared for many questions about RO signaling. At the very last of draft, it said RO is out of scope:-)
Can you explicitly mention it a bit earlier? Maybe you can add one sentence at the definition of  Binding Management Messages in Section2.

Non of alternate security mechanism (RFC4285 and this) support RO signaling. Is it MEXT WG strategy for alternate security discussion?
Although I am not such fun of RO, I want some clarification on this.

regards
ryuji


On 2010/09/24, at 3:30, Laganier, Julien wrote:

> Folks,
> 
> The chairs have received a request from the authors of http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec  that their draft be adopted as one of the WG deliverables for our "alternative security mechanisms" work item.
> 
> Before we go ahead with this, the chairs would like to solicit at least three thorough review of the document to ensure that the has an adequate understanding of the proposal and its implications. 
> 
> Please support the WG process by volunteering as a reviewer.
> 
> --julien & marcelo
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext