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

jouni korhonen <jouni.nospam@gmail.com> Tue, 09 November 2010 03:21 UTC

Return-Path: <jouni.nospam@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 7E11628C18E for <mext@core3.amsl.com>; Mon, 8 Nov 2010 19:21:26 -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 94iWYVT9aX5K for <mext@core3.amsl.com>; Mon, 8 Nov 2010 19:21:24 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 96B7028C246 for <mext@ietf.org>; Mon, 8 Nov 2010 19:21:11 -0800 (PST)
Received: by gxk27 with SMTP id 27so2751000gxk.31 for <mext@ietf.org>; Mon, 08 Nov 2010 19:21:34 -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=UuwcX+qzoieicT0FVFHQHwjidUMSGetpxsZPST4jV98=; b=tOxkfRKej15dTQwQ2k6Bgn+/mUtVVN7x9+1AJbb1tn2t733L/zW+//Nd0lGpic/p3/ TI28Vx0CB6NowDC4IbfPM1+P37OiT9gDQHzyzFIr1ed0aIDcjAT/aVkSOubkBOD71NQL yON9tPMH2Uvtsj5P14CP3xwODzGxXowUD4M7g=
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=os7LB3SFzhmiEwvtgCpcwMfL10T8KqZvqX/x5VBMe1yRnpbgIKqogQFjNRBVy3Q5G8 JwaAwJSGLRwjEkbnq/mdq0uIJMFMo8A8rcXOLZ7hEb69JJKA5Ny0gVzqtMh8s8Ea1pJv Y+5rXdXipRgH7I2K7OTWL+cLyFyL/OGjdfI7Q=
Received: by 10.150.144.3 with SMTP id r3mr9774053ybd.351.1289272894179; Mon, 08 Nov 2010 19:21:34 -0800 (PST)
Received: from dhcp-67f0.meeting.ietf.org (dhcp-67f0.meeting.ietf.org [130.129.103.240]) by mx.google.com with ESMTPS id n48sm503829yha.7.2010.11.08.19.21.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 19:21:33 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: jouni korhonen <jouni.nospam@gmail.com>
In-Reply-To: <E705C674-5323-4E3D-96A4-F9C0F4E4DF22@gmail.com>
Date: Tue, 09 Nov 2010 05:21:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <50EFFA71-595D-40C7-BB60-A0E0938858C6@gmail.com>
References: <BF345F63074F8040B58C00A186FCA57F1F69EFEC78@NALASEXMB04.na.qualcomm.com> <E705C674-5323-4E3D-96A4-F9C0F4E4DF22@gmail.com>
To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
X-Mailer: Apple Mail (2.1078)
Cc: "draft-korhonen-mext-mip6-altsec@tools.ietf.org" <draft-korhonen-mext-mip6-altsec@tools.ietf.org>, "Laganier, Julien" <julienl@qualcomm.com>, "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 03:21:27 -0000

Ryuji,

Thanks for the review! See my comments inline.


On Nov 9, 2010, at 3:23 AM, Ryuji Wakikawa wrote:

> 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. 

Good.

> 
> 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?

It is up to the implementation. Currently our implementation just uses xfrm framework to put policies in place.

> 
> 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. 

Right. 


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

True. This could be added.


> 
> 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.

Good point. We will lift that closer to the beginning of the document.


> 
> 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.

In general RO has not really been deployable (I don't want to say deployed since MIP6 does not really have a track record of being deployed at all :) in the systems architectures that intend to use MIP6. They plain mandate reverse tunneling and I do not see this changing in the near future.

Regarding our proposal, it could actually be extended to cover RO rather easily. We just did not want go there.

- JOuni


> 
> 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
> 
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext