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

[Julien Laganier <[e-mail]>]

Hi Sri,

On Tue, Jul 19, 2011 at 10:29 PM, Sri Gundavelli <[e-mail]> wrote:
> 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 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.

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

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