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

From: <[email-masked]>
Date: Wed, 13 Jul 2011 21:40:08 +0000

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-masked]"
<[email-masked]> 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.
>
>

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 17 Jul 2011 12:43:56 -0700

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-masked]" <[email-masked]>
wrote:

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: Julien Laganier <[email-masked]>
Date: Mon, 18 Jul 2011 11:47:47 -0700

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

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Jul 2011 20:14:20 -0700

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

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Jul 2011 08:09:54 -0700

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.

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

--julien

---

From: <[email-masked]>
Date: Tue, 19 Jul 2011 21:03:48 +0000

Sri,

Comments inline: 

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

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

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

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Jul 2011 22:29:11 -0700

Hi Julien,

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

> 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

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Jul 2011 22:42:41 -0700

Raj:

Inline ...

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

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

> sufficient in many cases. This I-D is not attempting to solve e2e security

Ok.

> 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

---

From: <[email-masked]>
Date: Wed, 20 Jul 2011 18:02:05 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of ext Sri Gundavelli
Sent: Tuesday, July 19, 2011 10:43 PM
To: Patil Basavaraj (Nokia-CIC/Dallas); [email-masked]
Subject: Re: [MEXT] FW: New Version Notification for draft-bajko-mext-sod-02.txt

Raj:

Inline ...

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

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

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

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

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

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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 21 Jul 2011 09:10:27 -0700

On 7/20/11 11:02 AM, "[email-masked]" <[email-masked]> 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

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

---

From: Julien Laganier <[email-masked]>
Date: Mon, 25 Jul 2011 11:30:47 -0700

Hi Sri,

> plane, and control the IPsec layer ...

I might be a bit pedantic here, but to make sure we' re on the same
page. We are not _moving_ any logic to MIP control plane. The SPD
logic remains where it is, in the IPsec layer. What this document is
about is a way for MIPv6 nodes to agree whether or not the SPD
specifies protection of data traffic as specified in RFC 3776.

> HA agree on the security policy for the data traffic between them, as we

I understand the use case you describe. In this case the user data
traffic protection consists of applying ESP to only part of the
traffic by setting X to the appropriate values (e.g. SIP) in the
examples documented in RFC 3776. From then on the mechanism described
in this draft can be used to turn ON and OFF that protection of data.
In other words, the details of user data protection needs not to be
agreed dynamically. What needs to be agreed on is whether or not the
user data protection is needed in the first place. It might not on
some radio accesses (e.g. cellular)

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 25 Jul 2011 12:38:51 -0700

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

an SA for data traffic wouldn' t be created if the SPD doesn' t
require data traffic to be protected by an SA...

> tunnel mode ESP, can the HA not drop the traffic not protected with the

As above, the SA wouldn' t be created if SPD doesn' t required data
traffic protection. If SPD requires data traffic protection, an SA
will be created.

--julien