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

Raj:

Inline ...


On 7/19/11 2:03 PM, "[email protected]" <[email protected]>
wrote:

> 
> Sri,
> 
> Comments inline: 
> 
> On 7/17/11 2:43 PM, "ext Sri Gundavelli" <[email protected]> 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.
> 

The format I expected is some thing like this. I thought the 5139 is not
covering this. If that is the covered there, its fine.

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |N|     Latitude Degrees        |    Minutes    |    Seconds    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |E|     Longitude Degrees       |    Minutes    |    Seconds    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



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

> but it is not required that traffic be secured with that SA.

I understood the principle of moving this nego (enable/disable to MIP
control plane. But, I did not understand the last line. If there is SA for
tunnel mode ESP, can the HA not drop the traffic not protected with the
negotiated IPsec 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.
> 

Ok.


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

Ok. I assume this on/off switch can still allow some out of band policy on
what flows are protected. I guess I was not clear on how this impacts the
Ipsec/IKE configuration ...



Sri





> -Raj
> 
>> 
>> 
>> Regards
>> Sri
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 7/13/11 2:40 PM, "[email protected]"
>> <[email protected]>
>> 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 [email protected]"
>>> <[email protected]> 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
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/mext
>> 
>