Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01

[jouni korhonen <[e-mail]>]

Hi Vijay ;)

On Jun 16, 2009, at 3:39 AM, Vijay Devarapalli wrote:

> Hi Jouni,
>
> On Wed, Jun 10, 2009 at 11:28 PM, jouni korhonen<[e-mail] 
> > wrote:
>> Hi Vijay,
>>
>> On Jun 11, 2009, at 12:51 AM, Vijay Devarapalli wrote:
>>
>>> I have another question.
>>>
>>> Why does encrypting the payload traffic between the MN and the HA  
>>> need
>>> AAA authorization?
>>
>> IMHO payload traffic encryption is a potential place for a policy  
>> decision.
>> An operator may want to control it depending on the deployment and  
>> the
>> subscription in situations where the the same HA could be used for  
>> various
>> types of deployments. As you know e.g. certain SDOs purposely  
>> forbid the use
>> of payload encryption in their environment where as that might not  
>> make
>> sense in other type of deployment.
>
> Let me see if I understand this. Lets say the home operator (MSP) that
> provides the home agent does not want the mobile node to use payload
> encryption. Isn't this better enforced on the home agent itself? The
> home agent can refuse create CHILD SAs for payload protection.

The same HA may serve multiple providers and within a provider  
multiple services. Provisioning this information dynamically into a HA  
is not how I would like to see this managed. As a result of this  
policy decision the HA would refuse to CHILD SA creation for payload  
protection. There could also be a notification of this to the MN in a  
BA, but it is left out of this draft.


>
>
> In another case, lets say the client is roaming and is attached to
> some visited network and is accessing a home agent in the home
> network. I can understand the visited network wanting to prevent
> payload encryption. But how does this work if the home agent is
> talking to the AAA server in the home network? Does the AAA server,
> based on the fact that the client is coming from a specific visited
> network, the payload traffic should not be encrypted?

The challenge in the visited network case here is how the HA/AAA would  
even know that the MN is "roaming". There are ways of doing that  
though like analyzing CoAs (done today rather widely) or based on  
network access authentication (if available). In managed networks  
where "roaming" as a concept fits better, the policy decision would be  
based on roaming contracts and the subscription profile.

>
>
> Can you give me an example where this kind of control would help?


You roam into area where encryption is not seen as a good thing.. The  
AAA could turn this off for you if you forget or cannot change the  
setting yourself.

Jouni



>
>
> Vijay
>
>
>>
>> Jouni
>>
>>>
>>>
>>> Vijay
>>>
>>> On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen<[e-mail] 
>>> >
>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have updated the additional feature bits draft. I did remove  
>>>> some stuff
>>>> so
>>>> that the draft now only reserves MIP6-Feature-Vector flag bits and
>>>> nothing
>>>> more. I'll forward the draft soon to RFC editor so if anyone has
>>>> comments,
>>>> please be quick :)
>>>>
>>>> Cheers,
>>>>       Jouni
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: IETF I-D Submission Tool <[e-mail]>
>>>>> Date: June 10, 2009 12:26:53 PM GMT+03:00
>>>>> To: [e-mail]
>>>>> Subject: New Version Notification for
>>>>>  draft-korhonen-dime-mip6-feature-bits-01
>>>>>
>>>>>
>>>>> A new version of I-D, draft-korhonen-dime-mip6-feature- 
>>>>> bits-01.txt has
>>>>> been successfuly submitted by Jouni Korhonen and posted to the  
>>>>> IETF
>>>>> repository.
>>>>>
>>>>> Filename:        draft-korhonen-dime-mip6-feature-bits
>>>>> Revision:        01
>>>>> Title:           Diameter MIP6 Feature Vector Additional Bit  
>>>>> Allocations
>>>>> Creation_date:   2009-06-10
>>>>> WG ID:           Independent Submission
>>>>> Number_of_pages: 5
>>>>>
>>>>> Abstract:
>>>>> During the Mobile IPv6 Split Scenario bootstrapping the Mobile  
>>>>> IPv6
>>>>> Home Agent and the Authentication, Authorization, and Accounting
>>>>> server may exchange a set of authorized mobility capabilities.   
>>>>> This
>>>>> document defines new mobility capability flags that are used to
>>>>> authorize per Mobile Node route optimization, Multiple Care-of
>>>>> Address and user plane traffic encryption support.  Furthermore,  
>>>>> this
>>>>> document also defines a capability flag of indicating whether the
>>>>> Home Agent is authorized to act as a stand alone Virtual Private
>>>>> Network gateway.
>>>>>
>>>>>
>>>>>
>>>>> The IETF Secretariat.
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>
>>
>>