Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
Hi Jouni,
On Wed, Jun 10, 2009 at 11:28 PM, jouni korhonen<jouni.nospam at gmail.com> 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.
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?
Can you give me an example where this kind of control would help?
Vijay
>
> Jouni
>
>>
>>
>> Vijay
>>
>> On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen<jouni.nospam at gmail.com>
>> 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 <idsubmission at ietf.org>
>>>> Date: June 10, 2009 12:26:53 PM GMT+03:00
>>>> To: jouni.nospam at gmail.com
>>>> 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
>>> DiME at ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>
>
>
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.