 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
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<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 needAAA 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 makesense 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
VijayJouniVijayOn 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 stuffso 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-01A new version of I-D, draft-korhonen-dime-mip6-feature- bits-01.txt has been successfuly submitted by Jouni Korhonen and posted to the IETFrepository. Filename: draft-korhonen-dime-mip6-feature-bits Revision: 01Title: Diameter MIP6 Feature Vector Additional Bit AllocationsCreation_date: 2009-06-10 WG ID: Independent Submission Number_of_pages: 5 Abstract:During the Mobile IPv6 Split Scenario bootstrapping the Mobile IPv6Home Agent and the Authentication, Authorization, and Accountingserver may exchange a set of authorized mobility capabilities. Thisdocument defines new mobility capability flags that are used to authorize per Mobile Node route optimization, Multiple Care-ofAddress and user plane traffic encryption support. Furthermore, thisdocument 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