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

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