Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 5 Sep 2006 14:09:28 -0400

All,

Here is a scenario that may need to be covered. In some cases, local HA
assignment is optimal for transport efficiency perspective. Diameter
MIP4 application allows this. In such a case the ASP == MSP and the HA
is assigned locally (in the visited network). 

To enable this case, in the integrated scenario, the NAS/VAAA needs to
indicate it's capability to assign an HA in the local network to the
HAAA. The HAAA may allow or disallow this local HA assignment based on
policy of the MSA. 

The NAS/VAAA may need to include a hint in the AAA message to the HAAA
at the time of access authentication that it is capable of providing an
HA to the MN. This capability indication (hint) can be either sent via a
new MIP6 specific AVP or it can be conveyed via an existing AVP (I don't
know if one exists).

If we decide to include this (local HA assignment), and we decide to
include this mip6 specific hint in the NAS-HAAA communication, we may
have to choose the most appropriate option (1) vs. (2).

Comments?

-Kuntal

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2006 6:07 AM
> To: Gerardo Giaretta; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.
Service-Type
> 
> I must be missing something.
> 
> In the integrated scenario, what would the NAS put in Service-Type?
> 
> I think in the integrated scenario neither Port-Type or Service-Type
> needs to be touched.
> 
> As far as I understand the NAS is either executing EAP Application or
> NAS REQ.  It does not know whether the user will result in having
> subsequent Mobile IP service or not.
> 
> The only thing the AAA server can do is to send the MIPv6 attributes
as
> optional (M bit off) and hope that if the NAS does not understand the
> attributes it would have some logic to bootstrap a different way.
> 
> We could improve the situration somewhat.  We could have the NAS
> indicate that it supports MIPv6 bootstrapping by including hints in
the
> AR (a capability hint).   Where the NAS includes HA-IP address AVP
both
> indicating that it can support bootstrapping and if the HA-IP address
is
> not ALL-ZEROS or ALL ONES it provides a hint that it can support
dynamic
> HA assignement.
> 
> Ofcourse we could introduce the concept of capability hints more
> formally in Diameter -- This is missing today.
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Gerardo Giaretta [mailto:[email-masked]]
> > Sent: Tuesday, September 05, 2006 3:35 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.
> > Service-Type
> >
> > Hi Hannes,
> >
> > I agree with Jouni. I prefer (2) for NAS-AAAH and (1) for
> > AAAH-HA. In my understanding, there are no mandatory AVPs for
> > NAS-AAAH and therefore I don't see a need of a new
> > application; it's just a MIP-specific information that is
> > piggybacked in the network access authentication procedure.
> >
> > Concerning AAAH-HA, I think it is a much cleaner approach to
> > define a new application, since it does not anything to do
> > with network authentication.
> >
> > --Gerardo
> >
> > On 9/5/06, [email-masked]
> > <[email-masked]> wrote:
> > > Hi HAnnes,
> > >
> > > > -----Original Message-----
> > > > From: Hannes Tschofenig [mailto:[email-masked]]
> > > > Sent: 1. syyskuuta 2006 1:07
> > > > To: [email-masked]
> > > > Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs.
> > > > Service-Type
> > > >
> > > > Hi all,
> > > >
> > > > we have had long discussions about the App-ID vs.
> > > > Service-Type usage for
> > > > Diameter MIPv6 Bootstrapping.
> > > >
> > > > It is time to see what the group thinks. Please indicate
> > whether you
> > > > prefer (1) an App-ID or (2) a Service-Type solution for
> > > >
> > > > (a) NAS-to-AAAH communication (as required by the integrated
> > > > scenario; as one part of the solution component)
> > >
> > > I would prefer (2) for now.. or as long as the NAS-2-AAAH main
> > > function is to provide access authentication, where the backend
AAA
> > > may return
> > > MIP6
> > > bootstrapping info (as an enhancement) based e.g. on the user
> > > subscription profile. If we go for more stuff on NAS-2-AAAH like
> > > HoA/prefix etc then
> > > (1)
> > > might be better.
> > >
> > > > (b) HA-to-AAAH communication (as used by the split
> > scenario and the
> > > > integrated scenario)
> > >
> > > I would prefer (1) here. The use of EAP for MIP6 bootstrapping
> > > purposes and for 'normal' EAP-based access authentication are
> > > different applications imho. (although in IKEv2 vs 802.1X case
e.g.
> > > NAS-Port-Type could be used to make this distinction.. e.g.
> > how 3GPP
> > > WLAN stuff does it)
> > >
> > > > It might be useful to state a reason for your decision.
> > > >
> > > > Please also indicate whether some aspects are still
> > unclear to you.
> > > >
> > > > Ciao
> > > > Hannes
> > >
> > > Cheers,
> > >         Jouni
> > >
> > >
> > > >
> > > > _______________________________________________
> > > > DiME mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/dime
> > > >
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> >
> > _______________________________________________
> > 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: "Avi Lior" <[email-masked]>
Date: Tue, 5 Sep 2006 23:21:22 -0400

Hi Kuntal,

Neither option 1 or option 2 will work.  A new application id just wont
scale in the long run.  What if another 'capability' were to be added
for instance prepaid.  Since Diameter messages contain only one
Application ID,  you would have to create an Application Id that covered
both EAP, Prepaid and Mobile IP. And what if a third application were
added?  The approach is not scalable as the applications are increased
-- you would have to cope with all the different permutations of
Applications.  The same argument goes for ServiceType and PortType and
these are actually more problematic.

IMO the only thing we can do is to hint at the capability of the NAS.  

A proper solution should be concieved for this problem.

> From: Chowdhury, Kuntal [mailto:[email-masked]] 
> Sent: Tuesday, September 05, 2006 2:09 PM
> To: Avi Lior; Gerardo Giaretta; [email-masked]
> Cc: [email-masked]
> Here is a scenario that may need to be covered. In some 
> cases, local HA assignment is optimal for transport 
> efficiency perspective. Diameter
> MIP4 application allows this. In such a case the ASP == MSP 
> and the HA is assigned locally (in the visited network). 
> 
> To enable this case, in the integrated scenario, the NAS/VAAA 
> needs to indicate it's capability to assign an HA in the 
> local network to the HAAA. The HAAA may allow or disallow 
> this local HA assignment based on policy of the MSA. 
> 
> The NAS/VAAA may need to include a hint in the AAA message to 
> the HAAA at the time of access authentication that it is 
> capable of providing an HA to the MN. This capability 
> indication (hint) can be either sent via a new MIP6 specific 
> AVP or it can be conveyed via an existing AVP (I don't know 
> if one exists).
> 
> If we decide to include this (local HA assignment), and we 
> decide to include this mip6 specific hint in the NAS-HAAA 
> communication, we may have to choose the most appropriate 
> option (1) vs. (2).
> 
> Comments?
> 
> -Kuntal
> 
> 
> AAAH-HA. 
> > > In my understanding, there are no mandatory AVPs for NAS-AAAH and 
> > > therefore I don't see a need of a new application; it's just a 
> > > MIP-specific information that is piggybacked in the 
> network access 
> > > authentication procedure.
> > >
> > > Concerning AAAH-HA, I think it is a much cleaner approach 
> to define 
> > > a new application, since it does not anything to do with network 
> > > authentication.
> > >
> > > --Gerardo
> > >
> "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."
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 06 Sep 2006 14:16:43 -0400

I agree with Avi that defining a new application for MIP6
bootstrapping by assigning a new application identifier but borrowing
and modifying ABNF of existing applications (i.e., Diameter EAP and
NASREQ) will end up with "a lot of permutations in Diameter
specifications" problem in a future when other applications need to be
developed that use EAP for authentication purpose and requires new
mandatory AVPs for authorization purpose.  I don't agree with this
option.

I also agree with Avi that defining a new application for MIP6
bootstrapping on top of existing applications (Diameter EAP) without
defining a new application id but with defining new values for
existing AVPs or new optional AVPs has some issue, but this option
might not be as bad as the first option since backward compatibility
can be easily maintained unlike the first option.  However, there is a
forward compatibility problem (i.e., a Diameter message may be forwarded
to a AAA server that does not support the new application).  Besides
this problem, it might be worth pursuing this option because it works
in an optimized way (i.e., bootstrapping AVPs are piggybacked in
Diameter EAP or NASREQ message) as long as both NAS and AAA server
support the AVPs.

In order to deal with the forward compatibility problem of the second
option, a third option is to define a new application for MIP6
bootstrapping as a totally new authorization application that carries
new mandatory AVPs specific to that application.  This option can be
run when execution of the second option succeeds in authentication but
fails in carrying bootstrapping AVPs.

Regards,
Yoshihiro Ohba

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 7 Sep 2006 00:48:22 -0400

Hi Yoshi 

See inline....

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Wednesday, September 06, 2006 2:17 PM
> To: Avi Lior
> Cc: Chowdhury, Kuntal; Gerardo Giaretta; 
> [email-masked]; [email-masked]
> bootstrapping by assigning a new application identifier but 
> borrowing and modifying ABNF of existing applications (i.e., 
> Diameter EAP and
> specifications" problem in a future when other applications 
> need to be developed that use EAP for authentication purpose 
> and requires new mandatory AVPs for authorization purpose.  I 
> don't agree with this option.
> 
> I also agree with Avi that defining a new application for 
> MIP6 bootstrapping on top of existing applications (Diameter 
> EAP) without defining a new application id but with defining 
> new values for existing AVPs or new optional AVPs has some 
> issue, but this option might not be as bad as the first 
> option since backward compatibility can be easily maintained 
> unlike the first option.  However, there is a forward 
> compatibility problem (i.e., a Diameter message may be 
> forwarded to a AAA server that does not support the new 
> application).  Besides this problem, it might be worth 
> pursuing this option because it works in an optimized way 
> (i.e., bootstrapping AVPs are piggybacked in Diameter EAP or 
> NASREQ message) as long as both NAS and AAA server support the AVPs.
> 
> In order to deal with the forward compatibility problem of 
> the second option, a third option is to define a new 
> application for MIP6 bootstrapping as a totally new 
> authorization application that carries new mandatory AVPs 
> specific to that application.  This option can be run when 
> execution of the second option succeeds in authentication but 

Unless I am missing something I think your forward compatibility problem
has issues with it.

How would the NAS know to use the MobileIPv6 application id?  It doesn't
have any knowledge that MobileIPv6 bootstrapping is required?

If it selects that Application and the home network doesn't support
MobileIPv6 bootstrapping then the user will not get service.

And going on in the future when there are other Applications which will
the NAS select? 

> > Neither option 1 or option 2 will work.  A new application id just 
> > wont scale in the long run.  What if another 'capability' 
> were to be 
> > added for instance prepaid.  Since Diameter messages 
> contain only one 
> > Application ID,  you would have to create an Application Id that 
> > covered both EAP, Prepaid and Mobile IP. And what if a third 
> > application were added?  The approach is not scalable as the 
> > applications are increased
> cases, local 
> > > HA assignment is optimal for transport efficiency perspective. 
> > > Diameter
> > > MIP4 application allows this. In such a case the ASP == 
> MSP and the 
> > > HA is assigned locally (in the visited network).
> > > 
> > > To enable this case, in the integrated scenario, the 
> NAS/VAAA needs 
> > > to indicate it's capability to assign an HA in the local 
> network to 
> > > the HAAA. The HAAA may allow or disallow this local HA assignment 
> > > based on policy of the MSA.
> > > 
> > > The NAS/VAAA may need to include a hint in the AAA message to the 
> > > HAAA at the time of access authentication that it is capable of 
> > > providing an HA to the MN. This capability indication 
> (hint) can be 
> > > either sent via a new MIP6 specific AVP or it can be 
> conveyed via an 
> > > existing AVP (I don't know if one exists).
> > > 
> > > include this mip6 specific hint in the NAS-HAAA communication, we 
> > > may have to choose the most appropriate option (1) vs. (2).
> > > 
> > > Comments?
> > > 
> > > -Kuntal
> > > 
> > > 
> > > > indicate that it supports MIPv6 bootstrapping by 
> including hints 
> > > > in
> > > the
> > > > > In my understanding, there are no mandatory AVPs for NAS-AAAH 
> > > > > and therefore I don't see a need of a new 
> application; it's just 
> > > > > a MIP-specific information that is piggybacked in the
> > > network access
> 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."
> > > 
> >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 07 Sep 2006 08:45:17 -0400

Hi Avi,

On Thu, Sep 07, 2006 at 12:48:22AM -0400, Avi Lior wrote:

(snip)

> And going on in the future when there are other Applications which will

I think this specific issue you are raising is not specific to MIP6
bootstrapping application.

It seems that the issue of "application discovery" is generally
applicable to all applications, i.e., if NAS supports application X
but it does not know which AAA server or realm actually support the
application before running the application.

The application discovery issue should be discussed separately (this
maybe a new issue related to RFC3588bis).

Regards,
Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 7 Sep 2006 17:22:11 +0200

Hi,

> mandatory AVPs for authorization purpose.  I don't agree with this

 ok I understand what do you mean by "permutations" now.
 Personnally I don't think this is really an issue and I'm not sure we
 can avoid this. EAP is used for the first  A of AAA and the 2 others
 AA may need specific things depending on the application and differents
 servers may be deployed depending on this application.

> Diameter EAP or NASREQ message) as long as both NAS and AAA server

 I'm not in favor of having an app-id for the nas-aaah part of the mip6
 bootstrapping problem.

> fails in carrying bootstrapping AVPs.

 hmm, i guess i have to think more of this option but this would mandate
 now that all EAP Application server should know that maybe they are not
 doing this for network access and that maybe they are going to receive
 a special authorization request. And in this case, wouldn't it mean
 that network access should be treated as a special service and this
 would also require a new authorization application ?

 regards,

 Julien

-- 
julien.bournelle at int-evry.fr

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 07 Sep 2006 16:33:28 -0400

Hi Julien,

On Thu, Sep 07, 2006 at 05:22:11PM +0200, Julien Bournelle wrote:
>  can avoid this. 

Why you don't think this is not an issue?  It is true that Diameter
EAP was copied and modified from NASREQ, but I think we should stop
doing the same thing for future applications.  Otherwise, when either
Diameter EAP or NASREQ specification is revised, then the changes will
affect specifications of all copied applications.  To me this issue is
very similar to an obvious issue that can happen when defining a class
in C++ programming by copying and modifying other class instead of
using class inheritance.

> EAP is used for the first  A of AAA and the 2 others

Is there any pre-requisite that MIP6 bootstrapping needs to be
designed as a single authentication/authorization application or can
it be realized as two combined apllications (EAP/NASREQ + MIP6)?

Regards,
Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 12 Sep 2006 14:14:00 +0200

Hi yoshi,

 as a reminder for everybody, we are talking of the HA-AAAH interface.

On Thu, Sep 07, 2006 at 04:33:28PM -0400, Yoshihiro Ohba wrote:
> affect specifications of all copied applications.  

 well i don't think it's an issue because I think that even if an
 application wants to use EAP for Authentication purpose, an update of
 the RFC 4072 won't
 necessary imply an update of this new application.

 As you know, RFC4072 also do Authorization for network access and also
 defines accouting for the network access. Some of the AVPs defined in
 Diameter EAP are not necessary for mip6.

> To me this issue is

 I think before answering to this question, we should ask wether it
 makes sense to use RFC4072 -- only -- for Authentication. How do a AAA
 server would know that this particular DER request is --only-- for
 authentication and that it has to wait for a particular Authorization
 message (with another app-id) for a service.

 If we "push" a little what you propose, we could define an
 "Authentication based on EAP" Application (only doing Authentication) 
 used by other Application that would only define their messages for
 Authorization and Accounting (such as MIP6). That's why I talked to you
 in a previous mail about also consider network access as a special
 service and thus define Authz/Accounting messages for the "network
 access" service.

 regards,

  Julien

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 12 Sep 2006 11:53:10 -0400

>  as a reminder for everybody, we are talking of the HA-AAAH interface.

OK.

>  Diameter EAP are not necessary for mip6.

Sure, if an updated part of RFC 4072 is not used by a new application,
then this would not be an issue.  But can we safely conclude that any
future update for RFC 4072 will be nothing to do with MIP6 (or other
new applications)?

>  message (with another app-id) for a service.

A AAA server that receives DER does not need to know whether
additional authorization is needed as long as HA knows about it as 
I mentioned in http://www1.ietf.org/mail-archive/web/dime/current/msg00726.html.

However, if the AAA server somehow needs to know about it, the HA(NAS)
can indicate it by including Auth-Request-Type AVP in DER with
specifying "AUTHENTICATE_ONLY".

>  service and thus define Authz/Accounting messages for the "network

Yes, in the case of network access, you could use NASREQ for
authorization purpose in additon to Diameter EAP for authentication
purpose as specified in RFC 4072.

Regards,
Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 13 Sep 2006 10:52:55 +0200

Hi yoshi,

> future update for RFC 4072 will be nothing to do with MIP6 (or other

 I guess no.

 <snip>
> I mentioned in http://www1.ietf.org/mail-archive/web/dime/current/msg00726.html.

 I don't fully agree on that. If the AAA server thinks it's a NAS and it
 is doing AAA for network access, it may send unnecessary/inadequate AVP
 to the HA.

> specifying "AUTHENTICATE_ONLY".

 ok. I see. I forgot this possibility.
 So to sump up, the HA will use Diameter EAP with the Auth-Request-Type
 aVP set to AUTHENTICATE_ONLY and the App-ID set to 5. If it receives a
 success, it will switch to a Authorization/Accounting MIP6 Application
 with a new App-ID. Is that right ?

 I think it can work but we need to investigate a little more before
 moving with this. Points that I can see for now are:

 - The session-id must be shared between the Application.
 - We must be sure that messages will reach the same AAA server.
 - We may have trouble with RADIUS compatibility
  
 Anyone has an opinion on this way to solve our issue ? 

 Thanks yoshi,

 Julien

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 13 Sep 2006 09:43:06 -0400

Hi Julien,

On Wed, Sep 13, 2006 at 10:52:55AM +0200, Julien Bournelle wrote:

(snip)

>  - The session-id must be shared between the Application.

Why session-id must be shared?  

NASREQ usage for authorization purpose in RFC 4072 does not require
it.  Instead, User-Name AVP can be shared between the applications.
In case the NAS(HA) is not able to retrieve the username from EAP
messages, the AAA server can tell the NAS about the username by
carrying User-Name AVP in DEA message, as described in RFC 4072.

> - We must be sure that messages will reach the same AAA server.

Why Diameter EAP messages and Diameter MIP6 messages need to hit the
same AAA server?  

Again, NASREQ usage for authorization purpse in RFC 4072 does not
require NASREQ and Diameter EAP messages to use the same AAA server.
In general, authentication, authorization and accouting can use
different AAA servers, and there should be no exception to MIP6
bootstrapping, IMO.

>  - We may have trouble with RADIUS compatibility

This can be handled later.

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 14 Sep 2006 15:28:35 +0200

Hi yoshi,

> Why session-id must be shared?  

 Indeed that's a good question. At first I thought that we should have
 only one-session ID per client but if we separate Authentication from
 Authorization/Accouting, we could have 2.

> different AAA servers, and there should be no exception to MIP6

 yes you're right. I guess this could be handled by 2 separate servers.

 Thanks for your clarifications, I understand better what you propose.

 regards,

 Julien

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 15 Sep 2006 11:30:34 +0200

Hi yoshi,

 I have one more question concerning your approach.

 Considering the following scenario:

 MN <------> NAS <---4072 -(1)---> AAAH
 ^                                  ^
 |                                  |
 +----------> HA <---4072  (2)------+
 
 First, the MN is authenticated throught the NAS. The NAS uses Diameter
 EAP and asks the AAAH for AAA for network access.

 Then, the MN acquires the HA and uses IKEv2 with it. If we use your
 approach, the HA uses Diameter EAP with the AVP Auth-Request-Type set
 to AUTHENTICATE_ONLY.

 I was wondering if it won't cause trouble to the AAAH since it has
 already authenticated the MN through the NAS.

 Any comments on this ?

 regards,

 Julien

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 15 Sep 2006 05:56:52 -0400

Hi Julien,

>  already authenticated the MN through the NAS.

If the operational policy of AAAH allows MN to perform multiple
back-to-back authentication/authorization attempts via different
authenticators, then there should be no issue.

BTW, I have two questions.

- Do the EAP via NAS and the EAP via HA need to hit the same AAAH
server?  I guess not.

- Do the EAP via NAS and the EAP via HA need to use the same Idenity?
I guess not.

Regards,
Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Fri, 15 Sep 2006 12:07:37 +0200

> authenticators, then there should be no issue.

 ok. I think that if we move forward with your approach we should add a
 little text about this.

> - Do the EAP via NAS and the EAP via HA need to hit the same AAAH

 I don't think so.

> - Do the EAP via NAS and the EAP via HA need to use the same Idenity?

 I don't think so.

 regards,

 Julien

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Fri, 15 Sep 2006 17:25:13 +0200

Hi Julien,

maybe the MN does not need to use the same identity, but may use the
same identity. It really depends on the identity management policies
of the operator. So we should have a solution that works regardless
the identity used by the MN is the same during network access and mip6
authentication or not.

--Gerardo

---

From: "Avi Lior" <[email-masked]>
Date: Mon, 18 Sep 2006 15:07:44 -0400

I do have a question/comment.

In the second part where the HA authenticates you specify that the HA
uses AUTHENTICATE-ONLY.

I don't think that that should be necessarily true.  There may be
authorization attributes that could be delivered to the HA.  We
shouldn't limit that transaction to AUTHENTICATE-ONLY.

In fact it may be AUTHORIZE-ONLY but that depends on what your draft is
doing.

> From: Julien Bournelle [mailto:[email-masked]] 
> Sent: Friday, September 15, 2006 6:08 AM
> To: Yoshihiro Ohba
> Cc: Julien Bournelle; Avi Lior; [email-masked]
> Subject: Re: Authentication through 2 different "NAS" in the 
> same time ?
> 
> > >  First, the MN is authenticated throught the NAS. The NAS uses 
> > > Diameter  EAP and asks the AAAH for AAA for network access.
> > > 
> > > approach, the HA uses Diameter EAP with the AVP Auth-Request-Type 
> > > set  to AUTHENTICATE_ONLY.
> > > 
>  ok. I think that if we move forward with your approach we 
> should add a  little text about this.
> 
> > > > > > However, if the AAA server somehow needs to know 
> about it, the 
> > > > > > HA(NAS) can indicate it by including 
> Auth-Request-Type AVP in 
> > > > > > DER with specifying "AUTHENTICATE_ONLY".
> > > > > 
> > > > >  So to sump up, the HA will use Diameter EAP with the 
> > > > > Auth-Request-Type  aVP set to AUTHENTICATE_ONLY and 
> the App-ID 
> > > > > set to 5. If it receives a  success, it will switch to a 
> > > > > Authorization/Accounting MIP6 Application  with a new 
> App-ID. Is that right ?
> > > > > 
> > > > >  I think it can work but we need to investigate a little more 
> > > > > before  moving with this. Points that I can see for now are:
> > > > > 
> > > > NASREQ usage for authorization purpose in RFC 4072 does not 
> > > > require it.  Instead, User-Name AVP can be shared 
> between the applications.
> > > > Why Diameter EAP messages and Diameter MIP6 messages 
> need to hit 
> > > > the same AAA server?
> > > > 
> > > > > > > "Authentication based on EAP" Application (only doing 
> > > > > > > Authentication)  used by other Application that 
> would only 
> > > > > > > define their messages for  Authorization and Accounting 
> > > > > > > (such as MIP6). That's why I talked to you  in a previous 
> > > > > > > mail about also consider network access as a special  
> > > > > > > service and thus define Authz/Accounting messages 
> for the "network  access" service.
> > > > > > 
> > > > > > authorization purpose in additon to Diameter EAP for 
> > > > > > authentication purpose as specified in RFC 4072.
> > > > > > 
> > > > > > Regards,
> > > > > > Yoshihiro Ohba
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > >  regards,
> > > > > > > 
> > > > > > >   Julien
> > > > > > > 
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > > Yoshihiro Ohba
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I also agree with Avi that defining a new 
> application 
> > > > > > > > > > for MIP6 bootstrapping on top of existing 
> applications 
> > > > > > > > > > (Diameter EAP) without defining a new 
> application id 
> > > > > > > > > > but with defining new values for existing 
> AVPs or new 
> > > > > > > > > > optional AVPs has some issue, but this option might 
> > > > > > > > > > not be as bad as the first option since backward 
> > > > > > > > > > compatibility can be easily maintained unlike the 
> > > > > > > > > > first option.  However, there is a forward 
> > > > > > > > > > forwarded to a AAA server that does not support the 
> > > > > > > > > > new application).  Besides this problem, it 
> might be 
> > > > > > > > > > worth pursuing this option because it works 
> in an optimized way (i.e., bootstrapping AVPs are piggybacked 
> in Diameter EAP or NASREQ message) as long as both NAS and 
> AAA server support the AVPs.
> > > > > > > > > 
> > > > > > > > >  I'm not in favor of having an app-id for the 
> nas-aaah 
> > > > > > > > > part of the mip6  bootstrapping problem.
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > In order to deal with the forward compatibility 
> > > > > > > > > > problem of the second option, a third option is to 
> > > > > > > > > > define a new application for MIP6 
> bootstrapping as a 
> > > > > > > > > > totally new authorization application that 
> carries new 
> > > > > > > > > > mandatory AVPs specific to that application.  This 
> > > > > > > > > > option can be run when execution of the 
> second option succeeds in authentication but fails in 
> carrying bootstrapping AVPs.
> > > > > > > > > 
> > > > > > > > >  hmm, i guess i have to think more of this option but 
> > > > > > > > > this would mandate  now that all EAP 
> Application server 
> > > > > > > > > should know that maybe they are not  doing this for 
> > > > > > > > > network access and that maybe they are going 
> to receive  
> > > > > > > > > a special authorization request. And in this case, 
> > > > > > > > > wouldn't it mean  that network access should 
> be treated as a special service and this  would also require 
> a new authorization application ?
> > > > > > > > > 
> > > > > > > > >  regards,
> > > > > > > > > 
> > > > > > > > >  Julien
> > > > > > > > > > 
> > > > > > > > > > Regards,
> > > > > > > > > > Yoshihiro Ohba
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > Neither option 1 or option 2 will work.  A new 
> > > > > > > > > > > application id just wont scale in the long run.  
> > > > > > > > > > > What if another 'capability' were to be added for 
> > > > > > > > > > > instance prepaid.  Since Diameter 
> messages contain 
> > > > > > > > > > > only one Application ID,  you would have 
> to create 
> > > > > > > > > > > an Application Id that covered both EAP, 
> Prepaid and 
> > > > > > > > > > > Mobile IP. And what if a third application were 
> > > > > > > > > > > -- you would have to cope with all the different 
> > > > > > > > > > > permutations of Applications.  The same argument 
> > > > > > > > > > > goes for ServiceType and PortType and 
> > > > > > > > > > > > Here is a scenario that may need to be 
> covered. In 
> > > > > > > > > > > > some cases, local HA assignment is optimal for 
> > > > > > > > > > > > transport efficiency perspective. Diameter
> > > > > > > > > > > > MIP4 application allows this. In such a 
> case the 
> > > > > > > > > > > > ASP == MSP and the HA is assigned 
> locally (in the visited network).
> > > > > > > > > > > > 
> > > > > > > > > > > > To enable this case, in the integrated 
> scenario, 
> > > > > > > > > > > > the NAS/VAAA needs to indicate it's 
> capability to 
> > > > > > > > > > > > assign an HA in the local network to 
> the HAAA. The 
> > > > > > > > > > > > HAAA may allow or disallow this local 
> HA assignment based on policy of the MSA.
> > > > > > > > > > > > 
> > > > > > > > > > > > The NAS/VAAA may need to include a hint 
> in the AAA 
> > > > > > > > > > > > message to the HAAA at the time of access 
> > > > > > > > > > > > authentication that it is capable of 
> providing an 
> > > > > > > > > > > > HA to the MN. This capability indication (hint) 
> > > > > > > > > > > > can be either sent via a new MIP6 
> specific AVP or 
> > > > > > > > > > > > it can be conveyed via an existing AVP 
> (I don't know if one exists).
> > > > > > > > > > > > 
> > > > > > > > > > > > If we decide to include this (local HA 
> > > > > > > > > > > > assignment), and we decide to include this mip6 
> > > > > > > > > > > > specific hint in the NAS-HAAA communication, we 
> > > > > > > > > > > > > I think in the integrated scenario neither 
> > > > > > > > > > > > > Port-Type or
> > > > > > > > > > > > Service-Type
> > > > > > > > > > > > > needs to be touched.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > As far as I understand the NAS is either 
> > > > > > > > > > > > > executing EAP
> > > > > > > > > > > > Application or
> > > > > > > > > > > > > NAS REQ.  It does not know whether 
> the user will 
> > > > > > > > > > > > > result in having subsequent Mobile IP 
> service or not.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > The only thing the AAA server can do 
> is to send 
> > > > > > > > > > > > > the MIPv6 attributes
> > > > > > > > > > > > as
> > > > > > > > > > > > > optional (M bit off) and hope that if the NAS 
> > > > > > > > > > > > > does not
> > > > > > > > > > > > understand the
> > > > > > > > > > > > > We could improve the situration somewhat.  We 
> > > > > > > > > > > > > could have the NAS indicate that it supports 
> > > > > > > > > > > > > MIPv6 bootstrapping by including hints in
> > > > > > > > > > > > the
> > > > > > > > > > > > > indicating that it can support 
> bootstrapping and 
> > > > > > > > > > > > > if the
> > > > > > > > > > > > HA-IP address
> > > > > > > > > > > > is
> > > > > > > > > > > > > Ofcourse we could introduce the concept of 
> > > > > > > > > > > > > capability hints more formally in 
> Diameter -- This is missing today.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > I agree with Jouni. I prefer (2) 
> for NAS-AAAH 
> > > > > > > > > > > > > > and (1) for
> > > > > > > > > > > > AAAH-HA. 
> > > > > > > > > > > > > > In my understanding, there are no mandatory 
> > > > > > > > > > > > > > AVPs for NAS-AAAH and therefore I 
> don't see a 
> > > > > > > > > > > > > > need of a new application; it's just a 
> > > > > > > > > > > > > > MIP-specific information that is 
> piggybacked 
> > > > > > > > > > > > > > in the
> > > > > > > > > > > > network access
> > > > > > > > > > > > > > a new application, since it does 
> not anything 
> > > > > > > > > > > > > > to do with network authentication.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --Gerardo
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Service-Type usage for Diameter MIPv6 
> > > > > > > > > > > > > > > > Bootstrapping.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > It is time to see what the 
> group thinks. 
> > > > > > > > > > > > > > > > Please indicate
> > > > > > > > > > > > > > whether you
> > > > > > > > > > > > > > > > prefer (1) an App-ID or (2) a 
> Service-Type 
> > > > > > > > > > > > > > > > solution for
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > (a) NAS-to-AAAH communication 
> (as required 
> > > > > > > > > > > > > > > > by the integrated scenario; as 
> one part of 
> > > > > > > > > > > > > > > > the solution component)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I would prefer (2) for now.. or 
> as long as 
> > > > > > > > > > > > > > > the NAS-2-AAAH main function is 
> to provide 
> > > > > > > > > > > > > > > access authentication, where the backend
> > > > > > > > > > > > AAA
> > > > > > > > > > > > > > > may return
> > > > > > > > > > > > > > > MIP6
> > > > > > > > > > > > > > > bootstrapping info (as an 
> enhancement) based 
> > > > > > > > > > > > > > > e.g. on the user subscription 
> profile. If we 
> > > > > > > > > > > > > > > go for more stuff on
> > > > > > > > > > > > NAS-2-AAAH like
> > > > > > > > > > > > > > > HoA/prefix etc then
> > > > > > > > > > > > > > > (1)
> > > > > > > > > > > > > > > might be better.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > (b) HA-to-AAAH communication 
> (as used by 
> > > > > > > > > > > > > > > > the split
> > > > > > > > > > > > > > scenario and the
> > > > > > > > > > > > > > > > integrated scenario)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I would prefer (1) here. The use 
> of EAP for 
> > > > > > > > > > > > > > > MIP6 bootstrapping purposes and 
> for 'normal' 
> > > > > > > > > > > > > > > EAP-based access authentication are 
> > > > > > > > > > > > > > > > Please also indicate whether 
> some aspects 
> > > > > > > > > > > > > > > > are still
> > > > > > > > > > > > > > unclear to you.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Ciao
> > > > > > > > > > > > > > > > Hannes
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > >         Jouni
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 
> __________________________________________
> > > > > > > > > > > > > > > > _____ DiME mailing list [email-masked] 
> > > > > > > > > > > > > > > > 
> ____________________________________________
> > > > > > > > > > > > > > > ___ DiME mailing list [email-masked] 
> > > > > > > > > > > > > > >

---

From: "Avi Lior" <[email-masked]>
Date: Mon, 18 Sep 2006 15:10:01 -0400

I agree with Yoshi,  this should not be a problem.

One is performing an access authentication and authroization the other
is performing a MIP authentication and authorization.

> Sent: Friday, September 15, 2006 5:57 AM
> To: Julien Bournelle
> Cc: Yoshihiro Ohba; Avi Lior; [email-masked]
> If the operational policy of AAAH allows MN to perform 
> multiple back-to-back authentication/authorization attempts 
> via different authenticators, then there should be no issue.
> 
> - Do the EAP via NAS and the EAP via HA need to hit the same 
> AAAH server?  I guess not.
> 
> > > > > HA(NAS) can indicate it by including Auth-Request-Type AVP in 
> > > > Auth-Request-Type  aVP set to AUTHENTICATE_ONLY and the 
> App-ID set 
> > > > to 5. If it receives a  success, it will switch to a 
> > > > > > Authentication)  used by other Application that would only 
> > > > > > define their messages for  Authorization and 
> Accounting (such 
> > > > > > as MIP6). That's why I talked to you  in a previous 
> mail about 
> > > > > > also consider network access as a special  service and thus 
> > > > > > define Authz/Accounting messages for the "network  
> access" service.
> > > > > 
> > > > > > > > > I also agree with Avi that defining a new application 
> application id but 
> > > > > > > > > with defining new values for existing AVPs or new 
> > > > > > > > > optional AVPs has some issue, but this option 
> might not 
> > > > > > > > > be as bad as the first option since backward 
> > > > > > > > > compatibility can be easily maintained unlike 
> the first 
> > > > > > > > > option.  However, there is a forward compatibility 
> > > > > > > > > problem (i.e., a Diameter message may be 
> forwarded to a 
> application).  
> > > > > > > > > Besides this problem, it might be worth pursuing this 
> > > > > > > > > option because it works in an optimized way 
> > > > > > > >  I'm not in favor of having an app-id for the nas-aaah 
> > > > > > > > > In order to deal with the forward 
> compatibility problem 
> > > > > > > > > of the second option, a third option is to 
> define a new 
> > > > > > > > > authorization application that carries new mandatory 
> > > > > > > > > AVPs specific to that application.  This 
> option can be 
> > > > > > > > > run when execution of the second option 
> succeeds in authentication but fails in carrying bootstrapping AVPs.
> > > > > > > > 
> > > > > > > >  hmm, i guess i have to think more of this 
> option but this 
> > > > > > > > would mandate  now that all EAP Application 
> server should 
> > > > > > > > know that maybe they are not  doing this for network 
> > > > > > > > access and that maybe they are going to receive 
>  a special 
> wouldn't it mean  
> > > > > > > > that network access should be treated as a 
> special service and this  would also require a new 
> authorization application ?
> > > > > > > > 
> > > > > > > >  regards,
> > > > > > > > 
> > > > > > > >  Julien
> > > > > > > > > 
> > > > > > > > > Regards,
> > > > > > > > > Yoshihiro Ohba
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > application id just wont scale in the long 
> run.  What 
> > > > > > > > > > if another 'capability' were to be added 
> for instance 
> > > > > > > > > > prepaid.  Since Diameter messages contain only one 
> > > > > > > > > > Application ID,  you would have to create an 
> > > > > > > > > > Application Id that covered both EAP, Prepaid and 
> > > > > > > > > > Mobile IP. And what if a third application 
> were added?  
> > > > > > > > > > The approach is not scalable as the 
> applications are 
> > > > > > > > > > increased
> > > > > > > > > > permutations of Applications.  The same 
> argument goes 
> > > > > > > > > > for ServiceType and PortType and these are 
> actually more problematic.
> > > > > > > > > > 
> case the ASP 
> > > > > > > > > > > == MSP and the HA is assigned locally (in 
> the visited network).
> > > > > > > > > > > 
> scenario, the 
> > > > > > > > > > > NAS/VAAA needs to indicate it's 
> capability to assign 
> > > > > > > > > > > an HA in the local network to the HAAA. 
> The HAAA may 
> > > > > > > > > > > allow or disallow this local HA 
> assignment based on policy of the MSA.
> > > > > > > > > > > 
> > > > > > > > > > > conveyed via an existing AVP (I don't 
> know if one exists).
> > > > > > > > > > > 
> specific hint in 
> > > > > > > > > > > the NAS-HAAA communication, we may have to choose 
> > > > > > > > > > > the most appropriate option (1) vs. (2).
> > > > > > > > > > > 
> > > > > > > > > > > Comments?
> > > > > > > > > > > 
> > > > > > > > > > > -Kuntal
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > As far as I understand the NAS is 
> either executing 
> > > > > > > > > > > > EAP
> > > > > > > > > > > Application or
> > > > > > > > > > > > NAS REQ.  It does not know whether the 
> user will 
> > > > > > > > > > > > optional (M bit off) and hope that if 
> the NAS does 
> > > > > > > > > > > > not
> > > > > > > > > > > understand the
> > > > > > > > > > > > could have the NAS indicate that it 
> supports MIPv6 
> > > > > > > > > > > > bootstrapping by including hints in
> > > > > > > > > > > the
> > > > > > > > > > > > not ALL-ZEROS or ALL ONES it provides a 
> hint that 
> > > > > > > > > > > > it can support
> > > > > > > > > > > dynamic
> > > > > > > > > > > > HA assignement.
> > > > > > > > > > > > 
> > > > > > > > > > > > > In my understanding, there are no 
> mandatory AVPs 
> > > > > > > > > > > > > for NAS-AAAH and therefore I don't 
> see a need of 
> > > > > > > > > > > > > a new application; it's just a MIP-specific 
> > > > > > > > > > > > > information that is piggybacked in the
> > > > > > > > > > > network access
> > > > > > > > > > > > > Concerning AAAH-HA, I think it is a 
> much cleaner 
> > > > > > > > > > > > > approach
> > > > > > > > > > > to define
> > > > > > > > > > > > > a new application, since it does not 
> anything to 
> > > > > > > > > > > > > do with network authentication.
> > > > > > > > > > > > >
> > > > > > > > > > > > > --Gerardo
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > (a) NAS-to-AAAH communication (as 
> required 
> > > > > > > > > > > > > > I would prefer (2) for now.. or as 
> long as the 
> > > > > > > > > > > > > > NAS-2-AAAH main function is to 
> provide access 
> > > > > > > > > > > > > > authentication, where the backend
> > > > > > > > > > > AAA
> > > > > > > > > > > > > > may return
> > > > > > > > > > > > > > MIP6
> > > > > > > > > > > > > > > (b) HA-to-AAAH communication (as 
> used by the 
> > > > > > > > > > > > > > > split
> > > > > > > > > > > > > scenario and the
> > > > > > > > > > > > > > > integrated scenario)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I would prefer (1) here. The use of EAP for 
> > > > > > > > > > > > > > MIP6 bootstrapping purposes and for 
> 'normal' 
> different 
> > > > > > > > > > > > > > applications imho. (although in IKEv2 vs 
> > > > > > > > > > > > > > 802.1X case
> > > > > > > > > > > e.g.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Sep 2006 03:06:28 -0400

Hi Kuntal,

we need to support this scenario given that it is part of the integrated 
scenario design.

Regarding the capability mechanism: I recall the 1 year discussion in 
RADEXT when we made the proposal to provide a generic capability 
mechanism. I never saw it as a bad idea but others obviously had a 
different view about it.

Ciao
Hannes

Chowdhury, Kuntal schrieb:
> at the timeor the Authentication. Thus the HA will use
 >      Diameter EAP with the AVP Auth-Request-Type set to
 >      AUTHENTICATE_ONLY and then the HA will use this MIP6 Application
 >      for Authorization/Accounting of the Mobile IPv6 service. This new
 >      application will have its own App-ID.
 >
 >      This would avoid to update the application if 4072 is updated and
 >      this could be a way to proceed if other applications need EAP for
 >      Authentication but have different needs for the Authorization and
 >      Accounting part.
 >
 >  Please indicate wether you prefer (1) or (2).
 >
 >  As in the previous polling:
 >  - it might be useful to state a reason for your decision.
 >  - indicate wether some aspects are still unclear to you.
 >
 >  Regards,
 >
 >  Julien
 >

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Sep 2006 03:06:28 -0400

Hi Kuntal,

Ciao
Hannes

Chowdhury, Kuntal schrieb:
>>>> different appli of access authentication that it is capable of providing an

cations imho. (although in IKEv2 vs 802.1X case

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Sep 2006 03:06:52 -0400

Hi Yoshi,

~snip~

> purpose as specified in RFC 4072.

I wonder why the Diameter EAP authors have decided not to use this approach.

It would be interesting to learn something about their design decisions.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Sep 2006 03:07:00 -0400

Hi Yoshi,

~snip~

> - Do the EAP via NAS and the EAP via HA need to hit the same AAAH

There is no requirement to use the same server but in reality it is most
likely the same server.

> - Do the EAP via NAS and the EAP via HA need to use the same Idenity?
There is no requirement to use the identity for network access and for
MIP6 bootstrapping but in reality it is most likely the same for
operational and cost reasons. (With some of the work done in Wimax there
are pseudonyms being used but that's another story.)

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Sep 2006 03:07:05 -0400

Hi Yoshi,

> carrying User-Name AVP in DEA message, as described in RFC 4072.

To carry the User-Name AVP in the DEA message partially destroys the
benefit of user identity confidentiality in the EAP. This is a really
bad approach.

> different AAA servers, and there should be no exception to MIP6

I agree that it is not necessary to hit the same AAA server. In reality
you have to access the same database in the background because you need
to refer to the previous authentication session and the same user
profile. Doing this via the User-Name AVP is not good.

> This can be handled later.

I already see the problems looming on the horizon: Dynamic Authorization
Extensions for RADIUS

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 21 Sep 2006 14:30:02 +0300

> It would be interesting to learn something about their design

Diameter EAP was modeled as the Diameter counterpart of RFC3579+2548,
so it followed the RADIUS way of doing things: the mandatory AVPs are
about authentication and basic Diameter functionality, and then you
add whatever authorization AVPs your specific service needs (which
would depend on what you're doing, e.g. 802.1X/11 would be different
from IKEv2 etc.). And the authorization AVPs are piggybacked in the 
same messages (essentially first request and the success response).

One important reason why it was done this way was the need 
for RADIUS translation. This might be relevant for MIP6 as well 
(cf. draft-chowdhury-mip6-radius).

Interestingly enough, 3GPP "Wm" reference point (TS 29.234) does
use RFC 4072 in AUTHENTICATE_ONLY mode, and then does authorization
using NASREQ. I have no idea why they did it this way, though.

Best regards,
Pasi