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

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 9 Nov 2010 09:23:26 +0800

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: jouni korhonen <[email-masked]>
Date: Tue, 9 Nov 2010 05:21:27 +0200

Ryuji,

Thanks for the review! See my comments inline.

> I can't find any technical issues in the protocol definition. 

Good.

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

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

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

> 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