Subject: [Dime] HA-to-AAAH support/When ? HoA allocation considerations

From: Julien Bournelle <[email-masked]>
Date: Tue, 3 Oct 2006 12:52:37 +0200

Hi all,

 as promised, some considerations concerning triggering the mip6-authz
 process.

 As noted by gerardo, the IKEv2 responder may act both as a HA and as a
 VPN concentrator. In this case, it knows that it will be used as a HA
 while receiving a BU. So, we may think that the mip6-authz could be
 used at this point of time.

 However, we also have to consider the Home-Address (HoA) allocation. As you
 may know the MN may auto-assign its HoA or requests one. (cf.
 draft-ietf-mip6-bootstrapping-split-02.txt)

 If it wants to auto-assign its HoA, it has 2 possibilities:

  1/ It autoassignes its HoA and includes it in the CFG_REQUEST
  (INTERNAL_IP6_ADDRESS)i in the first IKE_AUTH message. 
  If the HA is ok, it replies with the CFG_REPLY
  with the same address.

   2/ The MN asks for the Home Prefix (CFG_REQUEST with
   MIP6_HOME_PREFIX). The HA sends the Home prefix in the CFG_REPLY.
   Then
   the MN uses a CREATE_CHILD_SA.

 This raises some questions:

 1/ Do we consider that it is the HA which decides if the MN is
 authorized to configure its HoA  (policy configuration at the HA) ? or do we
 consider that it is a per-MN policy and thus that the HA should request
 that to the MSA ?

 If we consider that the MSA should decide this, as the HoA is sent
 after the MN being authenticated by EAP. This implies that the
 mip6-authz app should be used before this last IKEv2 message.

 If the MN requests a HoA to the HA, we also have the following
 question:

 1/ do we allow the AAA server to allocate this address ? or do we need
 an AVP to carry the HoA from the AAA to the HA ?
 
 regards,

 Julien

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

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 4 Oct 2006 10:10:43 -0400

Hi Julien

Good questions. Please see my comments inline.

-Kuntal

> -----Original Message-----
> From: Julien Bournelle [mailto:[email-masked]]
> Sent: Tuesday, October 03, 2006 5:53 AM
> To: [email-masked]
> Subject: [Dime] HA-to-AAAH support/When ? HoA allocation
considerations
>  However, we also have to consider the Home-Address (HoA) allocation.
As
> you
>  authorized to configure its HoA  (policy configuration at the HA) ?
or do
> we
[KC>] We should allow the flexibility to either have this policy
provisioned at the HA or the HA requesting it from the MSA. So, we
should define the HA-MSA interaction for HoA auto-config policy and even
HoA pool/prefix information.
 
>  mip6-authz app should be used before this last IKEv2 message.
[KC>] Yes.

>  an AVP to carry the HoA from the AAA to the HA ?
[KC>] We need AVPs to convey two things: whether the MN is allowed to
auto-config its HoA, if yes, which prefix/pool-id the HA should use to
assign the HoA to the MN.

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 4 Oct 2006 10:23:06 -0400

Hi Jouni, regarding your comment:

> I'm not entirely sure what the above is supposed to mean.. but
> imho again depending on the operator's deployment either HA or
> AAA should be able to allocate the HoA.

When AAA assigns a HoA for a user (MN) it is normally a statically
configured HoA in the user's AAA profile in the MSA. I think we should
clarify this. We have stumbled upon the HoA-allocation-by-AAA issue too
many times in the past.

-Kuntal

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, October 03, 2006 6:25 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Dime] HA-to-AAAH support/When ? HoA allocation
> considerations
> 
> Hi Julien,
> 
> Just a quick comment or few inline..
> 
> > Sent: 3. lokakuuta 2006 13:53
> > To: [email-masked]
> >  as promised, some considerations concerning triggering the
> > mip6-authz  process.
> >
> >  As noted by gerardo, the IKEv2 responder may act both as a
> > HA and as a  VPN concentrator. In this case, it knows that it
> > will be used as a HA  while receiving a BU. So, we may think
> > that the mip6-authz could be  used at this point of time.
> >
> >  However, we also have to consider the Home-Address (HoA)
> > allocation. As you  may know the MN may auto-assign its HoA
> > or requests one. (cf.
> >  1/ Do we consider that it is the HA which decides if the MN
> > is  authorized to configure its HoA  (policy configuration at
> > the HA) ? or do we  consider that it is a per-MN policy and
> > thus that the HA should request  that to the MSA ?
> 
> Imho both.. depends on operator's deployment.
> 
> >  If we consider that the MSA should decide this, as the HoA
> > is sent  after the MN being authenticated by EAP. This
> > implies that the  mip6-authz app should be used before this
> > last IKEv2 message.
> >
> >  1/ do we allow the AAA server to allocate this address ? or
> > do we need  an AVP to carry the HoA from the AAA to the HA ?
> 
> I'm not entirely sure what the above is supposed to mean.. but
> imho again depending on the operator's deployment either HA or
> AAA should be able to allocate the HoA.
> 
> Cheers,
> 	Jouni
> 
> 
> >
> >  regards,
> >
> >  Julien
> >
> >

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 4 Oct 2006 10:28:55 -0400

Hi Julien,

I am not sure about this:

>  I'm also in favor of that but then we have the issue raised by
gerardo
>  concerning the fact that the IKEv2 responder may play 2 roles (VPN
>  concentrator and HA). How do the IKEv2-R know that the MN wants to
use
>  mip6 ?

IKEv2 transaction is taking place between the MN and the _HA_. So, why
are we wondering whether the MN intends to do mip6 or not?  

Nevertheless, we need to assume that the HA is contacting the AAA server
in the MSA for EAP auth also. If we cannot assume this, then we need two
separate AAA transactions with two separate domains i.e. EAP server
somewhere and AAA server in the MSA.

-Kuntal

> Sent: Wednesday, October 04, 2006 6:34 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation
> considerations
> 
> Hi jouni,
> 
> On Tue, Oct 03, 2006 at 01:24:59PM +0200,
[email-masked]
> wrote:
> <snip>
>  if we want both. This implies that the mip6-authz process occurs
during
>  the EAP authentication process (probably when the HA receives the
>  result of the EAP authentication from the AAAH).
> 
>  I'm also in favor of that but then we have the issue raised by
gerardo
>  concerning the fact that the IKEv2 responder may play 2 roles (VPN
>  concentrator and HA). How do the IKEv2-R know that the MN wants to
use
>  mip6 ?
>  I also agree with you. It also implies that the mip6-Authz App should
>  be used during EAP authentication process.
> 
>  Julien
> 
> >
> > Cheers,
> > 	Jouni
> >
> >
> > >
> > >  regards,
> > >
> > >  Julien
> > >
> > >
> --
> julien.bournelle at int-evry.fr
>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 4 Oct 2006 10:39:08 -0400

Hi Gerardo,

Regarding your comment:

> I think what is important from an operator perspective is that the
> address may be allocated by either AAA or HA. However, to get this, we
> do not need to start mip6-authz during EAP exchange, since it is a
> generic IKEv2 address assignment issue and not a MIP specific one.

I think it is important to verify whether the user is allowed to use a
particular HoA. For example, the user may intentionally or accidentally
set the INTERNAL_IP6_ADDRESS to someone else's statically assigned HoA.
The HA may not keep track of the statically assigned HoAs of all the
users belonging to an MSA. If the HA does not verify with the MSA (AAA)
the user will get an address which actually belongs to someone else. 

To circumvent the problem, in some deployments the prefix that can be
used to auto-configure HoAs by MNs is kept separate from the ones used
for static HoA assignment. The HA should have this knowledge either via
local config or via AAA transaction.

-Kuntal

> From: Gerardo Giaretta [mailto:[email-masked]]
> Sent: Wednesday, October 04, 2006 7:23 AM
> To: Julien Bournelle
> Cc: [email-masked]
> Hi Julien and Jouni,
during
> This is needed only for autoconfiguration. But autoconfiguration has
> been introduced in mip6-split for rfc3041 addresses and CGAs. Do we
> want the AAA to decide if theMN can use CGA? I'm not sure this is the
> case.
> 
> I think what is important from an operator perspective is that the
> address may be allocated by either AAA or HA. However, to get this, we
> do not need to start mip6-authz during EAP exchange, since it is a
> generic IKEv2 address assignment issue and not a MIP specific one.
> 
> --Gerardo
> 
gerardo
use

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 4 Oct 2006 18:15:50 -0400

Hi Rafa,

I am not sure why we are bringing scenarios that are outside the scope
of MIP6. In MIP6 IPsec/IKEv2 happens between the MN and the HA. PDG/VPN
etc. are outside the scope of what we are defining here i.e. HA-HAAA
Diameter interface, IMHO.

-Kuntal

> From: Rafa Marin Lopez [mailto:[email-masked]]
> Sent: Wednesday, October 04, 2006 1:14 PM
> To: Gerardo Giaretta
> Cc: [email-masked]
> > My original thought was that the MIP6 Authorization Application can
be
> > started and used at the reception of the first BU since it is from
> > that moment that the MN begins using MIP6 service. Based on this
> > consideration, I'm wondering if we can leave the HoA assignment to
the
> > Diameter EAP part, but this seems not so clean.
> 
> But in that case, you are already receiving MIP6 authorization
> information within Diameter EAP... correct?
> 
> >
> > The other issue is that the IKEv2 responder may be a HA, but may be
> > also a combined HA/PDG/VPN concentrator. Are we assuming that the
> > IKEv2 responder acts only as HA? If so, the MIPv6 authorization
> > application can start during IKEv2 exchange. But if not, how the
IKEv2
> > responder (i.e. HA/PDG/ VPN concentrator) knows that the user is a
MIP
> > user or not?
> 
> I have a question: is the assumption here that HA/PDG/VPN may need to
> ask authorization about different services (e.g. VPN parameters or/and
> MIP6 parameters) depending on MN requires?
> 
> Another question: how would HA/PDG/VPN know it has to use RFC 4072
with
> AUTHENTICATE_ONLY for MIP6 service?
> Initially, it looks that the a simple answer would be that HA/PDG/VPN
is
> configured to send AUTHENTICATE_ONLY no matter the service.
> 
> Thanks.
> 
> >
> > --Gerardo
> >
> > On 10/4/06, Chowdhury, Kuntal <[email-masked]>
wrote:
> >> > address may be allocated by either AAA or HA. However, to get
this,
> >> > address may be allocated by either AAA or HA. However, to get
this,
> >> "This email message and any attachments are confidential
information
> >> of Starent Networks, Corp. The information transmitted may not be
> >> used to create or change any contractual obligations of Starent
> >> Networks, Corp.  Any review, retransmission, dissemination or other
> >> use of, or taking of any action in reliance upon this e-mail and
its
> >> attachments by persons or entities other than the intended
recipient
> >> is prohibited. If you are not the intended recipient, please notify
> >> the sender immediately -- by replying to this message or by sending
> >> an email to [email-masked] -- and destroy all
copies
> >> of this message and any attachments without reading or disclosing
> >> their contents. Thank you."
> >>
> >
> ------------------------------------------------------
> Rafael Marin Lopez
> Faculty of Computer Science-University of Murcia
> 30071 Murcia - Spain
> Telf: +34968367645    e-mail: [email-masked]
> ------------------------------------------------------
> 
>

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Thu, 5 Oct 2006 09:50:43 +0200

Hi Kuntal,

> Diameter interface, IMHO.

Indeed I just asked the question: do we all agree that the we can
assume the HA acts only as HA and not as any other IKEv2 responder?

I think that from a deployment perspective there may be cases where
the IKEv2 responder may be a HA but also a VPN server. But if
everybody agrees to restrict the case where the HA acts just as HA, I
may be fine with that. I'm just raising a possible deployment issue.

--Gerardo

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 6 Oct 2006 00:38:07 -0400

Hi Gerardo,

I understand the deployment scenario that you have in mind. Collocation
of a VPN gateway with the HA is an implementation issue, albeit quite
possible.

I think IKEv2 exchange with a VPN/PDG is more related to NAS-HAAA
interface where the VPN/PDG is acting as the NAS. Mip6 related
parameters could be downloaded to the VPN/PDG (NAS) in such a case.

-Kuntal

> Sent: Thursday, October 05, 2006 2:51 AM
> To: Chowdhury, Kuntal
> Cc: Rafa Marin Lopez; [email-masked]
> > > >> > I think what is important from an operator perspective is
that
> > > >> > do not need to start mip6-authz during EAP exchange, since it
is
> > a
> > > >> I think it is important to verify whether the user is allowed
to
> > use a
> > > >> set the INTERNAL_IP6_ADDRESS to someone else's statically
assigned
> > HoA.
> > > >> The HA may not keep track of the statically assigned HoAs of
all
> > the
> > > >> users belonging to an MSA. If the HA does not verify with the
MSA
> > (AAA)
> > > >> To circumvent the problem, in some deployments the prefix that
can
> > be
> > > >> used to auto-configure HoAs by MNs is kept separate from the
ones
> > used
> > > >> for static HoA assignment. The HA should have this knowledge
either
> > via
> > > >> > > > >    MIP6_HOME_PREFIX). The HA sends the Home prefix in
the
> > > >> CFG_REPLY.
> > > >> > > > >  1/ Do we consider that it is the HA which decides if
the
> > MN
> > > >> > > > > is  authorized to configure its HoA  (policy
configuration
> > at
> > > >> > >  the EAP authentication process (probably when the HA
receives
> > > >> > This is needed only for autoconfiguration. But
autoconfiguration
> > has
> > > >> > been introduced in mip6-split for rfc3041 addresses and CGAs.
Do
> > we
> > > >> > want the AAA to decide if theMN can use CGA? I'm not sure
this is
> > the
> > > >> > case.
> > > >> >
> > > >> > I think what is important from an operator perspective is
that
> > > >> > do not need to start mip6-authz during EAP exchange, since it
is
> > a
> > > >> > >  concerning the fact that the IKEv2 responder may play 2
roles
> > (VPN
> > > >> > > > >  1/ do we allow the AAA server to allocate this address
?
> > or
> > > >> > > > > do we need  an AVP to carry the HoA from the AAA to the
HA
> > ?
> > > >> > > >
> > > >> > > > I'm not entirely sure what the above is supposed to
mean..
> > but
> > > >> > > > imho again depending on the operator's deployment either
HA
> > or
> > > >> > >  I also agree with you. It also implies that the mip6-Authz
App
> > > >> should

---

From: <[email-masked]>
Date: Thu, 12 Oct 2006 01:03:02 +0200

Hi Gerardo, 

> Sent: 5. lokakuuta 2006 10:51
> To: Chowdhury, Kuntal
> Cc: [email-masked]

I'm not guite sure whether restrictic that a HA cannot be a VPN server
as well is a good idea. As you said, there might deploymnet scenarios
where a HA is also a VPN server.

/Jouni

> > > >> > I think what is important from an operator 
> perspective is that
> > the
> > > >> > do not need to start mip6-authz during EAP exchange, 
> since it is
> > a
> > > >> I think it is important to verify whether the user is 
> allowed to
> > use a
> > > >> set the INTERNAL_IP6_ADDRESS to someone else's 
> statically assigned
> > HoA.
> > > >> The HA may not keep track of the statically assigned 
> HoAs of all
> > the
> > > >> users belonging to an MSA. If the HA does not verify 
> with the MSA
> > (AAA)
> > > >> To circumvent the problem, in some deployments the 
> prefix that can
> > be
> > > >> used to auto-configure HoAs by MNs is kept separate 
> from the ones
> > used
> > > >> for static HoA assignment. The HA should have this 
> knowledge either
> > via
> > > >> > > > >    MIP6_HOME_PREFIX). The HA sends the Home 
> prefix in the
> > > >> CFG_REPLY.
> > > >> > > > >    Then
> > > >> > > > >  1/ Do we consider that it is the HA which 
> decides if the
> > MN
> > > >> > >  the EAP authentication process (probably when the 
> HA receives
> > the
> > > >> > been introduced in mip6-split for rfc3041 addresses 
> and CGAs. Do
> > we
> > > >> > want the AAA to decide if theMN can use CGA? I'm not 
> sure this is
> > the
> > > >> > case.
> > > >> >
> > > >> > I think what is important from an operator 
> perspective is that
> > the
> > > >> > do not need to start mip6-authz during EAP exchange, 
> since it is
> > a
> > > >> > >  concerning the fact that the IKEv2 responder may 
> play 2 roles
> > (VPN
> > > >> > > > >  1/ do we allow the AAA server to allocate 
> this address ?
> > or
> > > >> > > > > do we need  an AVP to carry the HoA from the 
> AAA to the HA
> > ?
> > > >> > > >
> > > >> > > > I'm not entirely sure what the above is supposed 
> to mean..
> > but
> > > >> > > > imho again depending on the operator's 
> deployment either HA
> > or
> > > >> > >  I also agree with you. It also implies that the 
> mip6-Authz App
> > > >> should