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

From: "Gerardo Giaretta" <[email-masked]>
Date: Wed, 4 Oct 2006 16:51:21 +0200

Hi Kuntal,

I agree with your point that the HoA assignment procedure may be
controlled by the AAA..

I'm just trying to figure out how the two applications (Diameter EAP
application based on rfc4072 and Diameter MIP6 Authorization
Application) will work together and when we need to start the exchange
of MIP6 Authorization Application.

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.

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?

--Gerardo

On 10/4/06, Chowdhury, Kuntal <[email-masked]> wrote:
> 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
>
>
> > -----Original Message-----
> > From: Gerardo Giaretta [mailto:[email-masked]]
> > Sent: Wednesday, October 04, 2006 7:23 AM
> > To: Julien Bournelle
> > Cc: [email-masked]
> > Subject: Re: [Dime] HA-to-AAAH support/When ? HoA allocation
> > considerations
> >
> > Hi Julien and Jouni,
> >
> > > > >  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 ?
> > > >
> > > > Imho both.. depends on operator's deployment.
> > >
> > >  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).
> > >
> >
> > 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
> >
> > >  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 ?
> > >
> > > >
> > > > >  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 ?
> > > >
> > > > 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.
> > >
> > >  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
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > DiME mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > > >
> > >
> > > --
> > > julien.bournelle at int-evry.fr
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> >
> > _______________________________________________
> > DiME mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dime
>
>
> "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."
>

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 04 Oct 2006 14:14:20 -0400

Hi Gerardo,

> Diameter EAP part, but this seems not so clean.

But in that case, you are already receiving MIP6 authorization 
information within Diameter EAP... correct?

> responder (i.e. HA/PDG/ VPN concentrator) knows that the user is a MIP

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.

>> "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:48:24 +0200

Hi Rafa,

> information within Diameter EAP... correct?

Yes, and I think this is the main issue.

> MIP6 parameters) depending on MN requires?

I think yes, at least from a deployment perspective.

> configured to send AUTHENTICATE_ONLY no matter the service.

That would be a solution. But the HoA assignment is still an open issue.

--Gerardo