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

[Sri Gundavelli <[e-mail]>]

On 7/20/11 11:02 AM, "[e-mail]" <[e-mail]> wrote:

> 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


Thanks Gabor for the clarification.

Sri



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