Re: [MEXT] FW: New Version Notification for draft-bajko-mext-sod-02.txt

[<[e-mail]>]

Sri,

Comments inline: 

On 7/17/11 2:43 PM, "ext Sri Gundavelli" <[e-mail]> wrote:

>Raj:
>
>I've reviwed this draft. Clarifying questions.
>
>
>
>1. New Mobility option
>
>> data contains a location in XML format as defined in RFC5139
>
>I'm bit surprised on the need to carry Civic Location info. I thought it
>is
>intended for human interpretation. Ex: Building 24, 2nd Floor, in front of
>Starbucks, when this location info in this format is carried in MIP
>binding
>option, how can the home agent make use of it realistically ? I'm not
>sure,
>beyond the "S" flag the draft proposes, if this new mobility option is
>needed ? The draft is also not clear on the aspect of negotiation. It
>appears to be more a request in the form of "S" flag in the draft.

The location is geolocation in lat/long terms. Format could be similar to
what is being specified in geopriv or LOST.
The intent is that the geolocation aspect of the MN in the BU will/may
provide sufficient indication to the HA if security for the data plane is
needed. Geolocation info of the MN is one of the parameters which can aid
the HA in making a decision about switching on security for the traffic
and hence the option in this I-D.


>
>
>2. Use of IKEv2/RFC 4877
>
>If the MN is in a location where it decides to enable security protection
>for the data traffic, it can certainly establish an IPsec SA for the
>tunnel
>mode ESP. Wondering, if this needs to be achieved over a MIP control plane
>and the advantages with that approach ? Even if this needs to be
>determined
>after the MIP session set up, still there needs to be IKEv2 protocol
>exchange for creating the SA ? Nothing stops either the HA or the MN to
>create an SA for the tunnel mode ESP.

I guess you are missing the point. An MN may create an IPsec SA for the
data plane as well using IKEv2. But it is not required that traffic
actually flow via this SA. MIP6 does not have a policy or mechanism as to
when security for the data plane is applied. This I-D is addressing the
issue by providing a means by which security for traffic can be switched
on. An MN may create an Ipsec SA at the time of registration for the data
plane as well but it is not required that traffic be secured with that SA.
 
>
>
>3. General question
>
>The HA is providing IP mobility service for the mobile node's home
>address.
>From the mobile node, or a correspondent node perspective, the home agent
>is
>just a pass through device. Securing the MN-HA link can certainly protects
>all the traffic for some part of the path segment, but it is not
>sufficient.
>If the argument is that, this is also a consideration for mobility
>service,
>as Julien/Raj or some one commented when it was presented, but I could not
>agree either way in my head, if this is really a service that the home
>agent
>needs to offer, or if it should be between the traffic flow end points.

You can consider the HA as an entity which resides in your home network.
Securing the link between the MN and the HA when it is attached via a
public access network or in a domain which can be viewed as untrusted is
sufficient in many cases. This I-D is not attempting to solve e2e security
for the traffic.

>
>4. Granularity/Traffic Selectors for Protection
>
>The mobile node may decide not to secure all traffic, as there is some
>pandora/youtube or other garbage traffic, which does not require
>protection.
>The approach here seems to be enable or disable data plane security. Why
>not
>try this with the DSMIP traffic flow selectors, as part of access
>selection
>for a flow, adding a bit to turn or off security might be an option ? You
>get the granularity for traffic protection as well.

You could have finer granularity using flow mobility classifiers. However
this I-D is more focused on providing a mechanism whereby security for the
user plane traffic is switched on either by the MN or the HA at runtime.

-Raj

>
>
>Regards
>Sri
>
>
>
>
>
>
>
>
>On 7/13/11 2:40 PM, "[e-mail]"
><[e-mail]>
>wrote:
>
>> 
>> We have posted a new version of the I-D. This does not incorporate the
>> review comments from Julien L., Kent Leung, Stefano Faccin and Jouni
>> Korhonen. We hope to do that in Rev 3 of the I-D in the next few weeks.
>> 
>> -Raj
>> 
>> On 7/11/11 6:10 PM, "ext [e-mail]"
>> <[e-mail]> wrote:
>> 
>>> A new version of I-D, draft-bajko-mext-sod-02.txt has been successfully
>>> submitted by Basavaraj Patil and posted to the IETF repository.
>>> 
>>> Filename:     draft-bajko-mext-sod
>>> Revision:     02
>>> Title:         Security on Demand for Mobile IPv6 and Dual-stack Mobile
>>> IPv6
>>> Creation date:     2011-07-12
>>> WG ID:         Individual Submission
>>> Number of pages: 9
>>> 
>>> Abstract:
>>>   Mobile IPv6 and Dual-stack Mobile IPv6 protocols require the
>>>   signaling messages between the mobile node and home agent to be
>>>   secured.  However security for the user plane/traffic is optional and
>>>   is a choice left to the mobile node.  This document proposes
>>>   extensions to Mobile IPv6 signaling which enables the user plane
>>>   traffic to be secured on a need or on-demand basis.  The mobile node
>>>   or the home agent can request at any time security for the user plane
>>>   traffic.  Security for user plane traffic can be triggered as a
>>>   result of policy or, mobility or, at the user&#39;s choice.
>>> 
>>>                
>> 
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext
>