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

[Sri Gundavelli <[e-mail]>]

Hi Julien,




On 7/19/11 8:09 AM, "Julien Laganier" <[e-mail]> wrote:

> Hi Sri,
> 
> With the risk of repeating myself: the role of IKE is to negotiate
> security associations between hosts. The security associations permits
> the enforcement of the security policy. This draft is concerned with a
> mechanism allowing the MN and the HA to agree on the security policy
> that governs exchange of data traffic between them.
> 

Sure, I understand that part about moving the decision logic to MIP control
plane, and control the IPsec layer ...


> I am also not sure why there would be a need for more granularity. I
> understood that the motivation between the draft is to be able to turn
> on and off the IP layer (IPsec) protection of data traffic based on
> the protection offered by an access network to which the MN attaches,
> typically at layer 2 (e.g., 802.11). I don' t know why what traffic
> gets or does not get protected would need to be negotiated dynamically
> based on the context in which the MN is, e.g., a hotel hotspot vs. a
> corporate Wi-Fi. To me that seems (semi-)static...
> 

Enabling security on the data sessions comes at high-resource requirement on
the gateway. If the access network where the mobile node is attached to does
not provide any security service, the MN can decide to turn on the security,
but allowing that on select streams will be useful. Do I care, if my youtube
stream goes unsecure, but I may care for my SIP flow. It can be a on/off
switch too .., any case its not orthogonal to the base principle of, MN and
HA agree on the security policy for the data traffic between them, as we
talk above ...






Sri




> --julien
> 
> On Mon, Jul 18, 2011 at 8:14 PM, Sri Gundavelli <[e-mail]> wrote:
>> Hi Julien,
>> 
>> Thanks for your response. Two points:
>> 
>> - The exchange of security policy in this draft, the semantics appear to be
>> a boolean in nature. I'm ignoring the  new civic location info option to be
>> carried in the request, as I cannot realistically tie any security policy
>> around that data element containing a street address. Unless, I
>> misunderstood.
>> 
>> - If I look at our IPsec implementation (should be close to any other
>> standard implementation), the security policy configured on the Ipsec peers,
>> allows the requestor to ask security services, say  X and Y. Now, the peer
>> can ask for X, Y, or X+Y. Translating this to MIPv6 usage, the mobile node
>> can ask for SA's for the control plane security and additionally the SA's
>> for data plane security. Now, if this is about moving the decision point of
>> data plane security to MIP control plane from the Ipsec layer, each time
>> there is an IKEv2 request, the request needs to be passed to the MIP control
>> plane, which seems to be one more level of indirection. Its not clear to me,
>> how it needs to be implemented. May be extending PF_Key interface to allow
>> Ipsec module to get authorization from MIPv6 is another approach.
>> 
>> The draft needs to have a paragraph on the motivation covering these
>> aspects, the limitations in the current decoupled SA negotiation model.
>> 
>> Also, providing some granularity around traffic selection for protection
>> will be more useful, as supposed to securing all data traffic, as I say in
>> point #4 below.
>> 
>> I'm not opposing or supporting this draft, just trying to understand.
>> 
>> 
>> Sri
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 7/18/11 11:47 AM, "Julien Laganier" <[e-mail]> wrote:
>> 
>>> Hi Sri,
>>> 
>>> Thanks for reviewing the draft. Re: point #2 below, IKEv2 is a mean
>>> for HA and MN to negotiate IPsec Security Association. My
>>> understanding of this draft is that it provides a mean for HA and MN
>>> to negotiate the IPsec Security Policy that govern exchange of data
>>> traffic between these two. As such the two are not exclusive or
>>> redundant, but complimentary.
>>> 
>>> What do you think?
>>> 
>>> --julien
>>> 
>>> On Sun, Jul 17, 2011 at 12:43 PM, 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.
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> 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
>>>> 
>> 
>>