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

[<[e-mail]>]

Sri,
The reference in the draft is wrong (rfc5139). The correct reference would be rfc5491, but that uses xml encoding and might be too verbose. An alternative would be to use the binary encoding defined in rfc6225.

-Gabor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of ext Sri Gundavelli
Sent: Tuesday, July 19, 2011 10:43 PM
To: Patil Basavaraj (Nokia-CIC/Dallas); [e-mail]
Subject: Re: [MEXT] FW: New Version Notification for draft-bajko-mext-sod-02.txt

Raj:

Inline ...


On 7/19/11 2:03 PM, "[e-mail]" <[e-mail]>
wrote:

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

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, "[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
>> 
> 

_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext