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

From: jouni korhonen <[email-masked]>
Date: Wed, 10 Jun 2009 12:55:36 +0300

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 <[email-masked]>
> Date: June 10, 2009 12:26:53 PM GMT+03:00
> To: [email-masked]
> 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.
>
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 10 Jun 2009 19:45:34 +0800

Hi, Jouni:
When the HA support Multiple CoA feature, why should the AAA server  care this feature?
If the AAA server neglectsthis feature or does not authorize the use of CoA, does it mean 
mutiple CoA registration will fail or something else?
If I miss anything, please correct me.

Regards!
-Qin
----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 10, 2009 5:55 PM
Subject: [Dime] Fwd: New Version Notification fordraft-korhonen-dime-mip6-feature-bits-01

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

---

From: jouni korhonen <[email-masked]>
Date: Wed, 10 Jun 2009 16:39:13 +0300

Hi Qin,

It is yet another subscription related policy decision.  An operator  
might, for some reason, to have such functionality to be disabled. If  
you go back to draft-ietf-dime-mip6-split-12, you can find all these  
feature vector flag bits there.

If the AAA does not authorize the use of MCoA the HA shall act as it  
would not support MCoA in the first place.

Cheers,
	Jouni

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Jun 2009 14:49:30 -0700

Hi Jouni,

I have a comment on the "VPN Gateway feature". There is no document
that describes what it means for a Mobile IPv6 home agent to act as a
VPN gateway. The IKEv2 exchange between the MN and the HA [RFC 4877
and 5026] already supports mutual authentication, address assignment
and setting up of tunnel mode ESP SAs. Are you referring to this as
VPN mode? But isn't this regular Home agent functionality?

Or is there a separate IPsec VPN that is first setup and then Mobile
IPv6 is run on top of the IPsec tunnels?

Vijay

On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen<[email-masked]> 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:
>
>> 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.
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Jun 2009 14:51:53 -0700

I have another question.

Why does encrypting the payload traffic between the MN and the HA need
AAA authorization?

Vijay

---

From: Qin Wu <[email-masked]>
Date: Thu, 11 Jun 2009 09:05:42 +0800

Thank you for your clarification!

---

From: jouni korhonen <[email-masked]>
Date: Thu, 11 Jun 2009 09:03:45 +0300

Hi Vijay,

> VPN mode? But isn't this regular Home agent functionality?

The "VPN mode" is when you use HA IKEv2/IPsec functionality purely for  
conventional VPN remote access purposes without any mobility. That  
type of deployment is shortly referenced in draft-ietf-dime-mip6-split  
Section 4.1. I recall this functionality was originally requested by  
Gerardo.

> IPv6 is run on top of the IPsec tunnels?

As shortly described in split document:

    In some deployment scenarios, the HA may also act as an IKEv2
    Responder for a conventional IPsec VPN access.  The challenge in  
this
    case is that the IKEv2 responder may not know if IKEv2 is used for
    Mobile IPv6 service or for IPsec VPN access service.  A network
    operator needs to be aware of this limitation.  One solution already
    supported by IKEv2 is to use different responder identities when
    operating as a conventional IPsec VPN gateway or as a HA.  The MN  
can
    then indicate the preferred responder type using the appropriate IDr
    payload in the IKE_AUTH message.

But yeah, now that feature bits are taken into a separate document,  
the connection between the above and the new feature bit is rather  
weak. Either we need more text and/or reference in the draft-korhonen- 
dime-feature-bits or just remove the bit all together. Since the  
difference between conventional IKEv2 IPsec VPN gateway part and HA's  
IKEv2 IPsec functionality is rather small, I would keep the feature  
bit and enhance the text instead.

Jouni

>> stuff so
>>> has

---

From: jouni korhonen <[email-masked]>
Date: Thu, 11 Jun 2009 09:28:10 +0300

Hi Vijay,

> Why does encrypting the payload traffic between the MN and the HA need

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.

Jouni

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 15 Jun 2009 17:32:40 -0700

Hi Jouni,

On Wed, Jun 10, 2009 at 11:03 PM, jouni korhonen<[email-masked]> wrote:
> conventional VPN remote access purposes without any mobility.

Again, what does this mean? When you run IKEv2 as described in RFC
4877 and 5026, you are creating tunnel mode security associations for
a *Mobile IPv6 tunnel*. In the "VPN" mode, does the mobile node switch
of the Mobile IPv6 stack?

Or does the Home Agent behave an IPsec VPN gateway for pure IPsec
clients, i.e., there is no Mobile IPv6 stack on these clients.

> That type of
> deployment is shortly referenced in draft-ietf-dime-mip6-split Section 4.1.
> I recall this functionality was originally requested by Gerardo.

It doesn't make sense to me. :) This looks more like co-locating a
Mbile IPv6 home agent and an IPsec VPN gateway and supporting both
Mobile IPv6 mobile nodes and plain IPsec clients at the same time.

There has to be more to this scenario than just the short paragraph in
draft-ietf-dime-mip6-split.

>   Responder for a conventional IPsec VPN access.  The challenge in this
>   operating as a conventional IPsec VPN gateway or as a HA.  The MN can
> But yeah, now that feature bits are taken into a separate document, the
> connection between the above and the new feature bit is rather weak. Either
> we need more text and/or reference in the draft-korhonen-dime-feature-bits
> or just remove the bit all together. Since the difference between
> conventional IKEv2 IPsec VPN gateway part and HA's IKEv2 IPsec functionality
> is rather small, I would keep the feature bit and enhance the text instead.

It is not "rather small" in my opinion. I don't understand how
supporting plain IPsec clients can be a feature on a Mobile IPv6 home
agent. :)

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 15 Jun 2009 17:39:56 -0700

Hi Jouni,

On Wed, Jun 10, 2009 at 11:28 PM, jouni korhonen<[email-masked]> wrote:
> 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

---

From: jouni korhonen <[email-masked]>
Date: Tue, 16 Jun 2009 13:27:44 +0300

Hi Vijay,

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

> Hi Jouni,
>
> On Wed, Jun 10, 2009 at 11:03 PM, jouni korhonen<[email-masked] 
> > wrote:
>> Hi Vijay,
>>
>>

VPN mode is plain RFC4306 + 4303 etc. You end up implementing that  
machinery there in any case, so why not allow using a HA as a VPN  
gateway as well. In this case, there is no mobility involved.

> clients, i.e., there is no Mobile IPv6 stack on these clients.

Yes.

> Mobile IPv6 mobile nodes and plain IPsec clients at the same time.

Yes, it is about co-location. To me it makes sense as much as  
IKEv2+IPsec with MIP6 ;)

> draft-ietf-dime-mip6-split.

Yes, agree.

>> the

Well.. feature in a sense that you have both functionalities in the  
same box anyway. Stretching my memory on the requirements, this came  
from the cases where an I-WLAN PDG and a HA were to be bundled together.

Jouni

>
>
> Vijay
>
>>
>> Jouni
>>
>>
>>>
>>>
>>> Vijay
>>>
>>> On Wed, Jun 10, 2009 at 2:55 AM, jouni korhonen<[email-masked] 
>>> >
>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I have updated the additional feature bits draft. I did remove  
>>>> some stuff
>>>> so

---

From: jouni korhonen <[email-masked]>
Date: Tue, 16 Jun 2009 13:53:46 +0300

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<[email-masked] 
> > wrote:
>> Hi Vijay,
>>
>> decision.

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.

> 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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 Jun 2009 12:39:00 -0700 (PDT)

Hi Jouni,
  I have no comment on your points below except this one:
Well.. feature in a sense that you have both functionalities in the same box anyway. Stretching my memory on the requirements, this came from the cases where an I-WLAN PDG and a HA were to be bundled together.

I don't think ePDG and HA can be bundled together in 3GPP architecture. HA is at the PDN Gateway an entity above PDG.

Regards,

Behcet

----- Original Message ----
From: jouni korhonen <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, June 16, 2009 5:27:44 AM
Subject: Re: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01

Hi Vijay,

> of the Mobile IPv6 stack?

VPN mode is plain RFC4306 + 4303 etc. You end up implementing that machinery there in any case, so why not allow using a HA as a VPN gateway as well. In this case, there is no mobility involved.

Yes.

>> I recall this functionality was originally requested by Gerardo..
> 

Yes, it is about co-location. To me it makes sense as much as IKEv2+IPsec with MIP6 ;)

Yes, agree.

> supporting plain IPsec clients can be a feature on a Mobile IPv6 home

Well.. feature in a sense that you have both functionalities in the same box anyway. Stretching my memory on the requirements, this came from the cases where an I-WLAN PDG and a HA were to be bundled together.

Jouni

---

From: jouni <[email-masked]>
Date: Wed, 17 Jun 2009 23:32:00 +0300

Hi Behcet,

I-WLAN PDG is not exactly the same as ePDG. And one can implement  
boxes that are not entirely the same as drawn is some SDO architecture.

Cheers,
	Jouni

On Jun 17, 2009, at 10:39 PM, Behcet Sarikaya wrote:

> I don't think ePDG and HA can be bundled together in 3GPP  
> architecture. HA is at the PDN Gateway an entity above PDG.
>
> Regards,
>
> Behcet
>
>
>