Subject: [Dime] RE: HA-to-AAAH draft/support of RFC 4285

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 04 Apr 2007 15:58:01 -0700

Hi Julien,

Sorry for the delay. Have been really busy this week. 
Let me ask you this: Aside from authentication, are the two 4285 and IKEv2
any different? i.e. do they both try to achieve authentication with the AAA
server, while delivering exact same of parameters and functionality?

If yes, then the option 2 may not be too bad. 
Still I prefer option 1, since its seems that some of AAA signaling goes in
the middle of IKEv2 signaling and that may complicate the timings and other
things unnecessarily.
It seems to be easier to have two commands that carry an overlap of AVPs,
than trying to carry different AVPs over different times and conditions over
the same command.

Hope this helps,

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Saturday, March 31, 2007 5:10 AM
To: [email-masked]
Cc: Gerardo Giaretta; Madjid Nakhjiri; Hannes Tschofenig
Subject: HA-to-AAAH draft/support of RFC 4285

Hi all,

 as discussed during the DiME WG meeting, we have to support the
RFC4285 in our Diameter Application for mip6.

 Let me reexplain briefly the situation:

 MN ----------- HA/AAAclient ----------------AAA server

 Our application defines the protocol between the AAAclient located in
 the HA and the AAA server.

 Between, the MN and the HA, we use:

 A/ either IKEv2 with EAP to setup IPsec SAs (to protect mip6 signalling).

 B/ or RFC 4285 aka Mobile IPv6 Authentication Option (could be compared
to what is used in mip4).

 In A/, EAP is used for authentication, our Diameter Application will carry
 EAP packets and will deliver specific mip6 AVPs. At the end of the AAA
process,
 IPsec SAs are setup and the MN can send its mip6 Binding Update.

 In B/, the MN has a pre-shared key with the AAA server. It sends its mip6
Binding Update signed using this pre-shared key to the HA. Our
Diameter Application
is then used to perform Authentication by the AAA server (owner of the
pre-shared
key).

 So, to sum up, we have two different MN-HA interaction (IKEv2-EAP and
RFC4285)
and one Diameter Application between HA and AAA. To solve this, we
have two options
in our Application:

 Option 1: we define 2 different commands: one command to deal with EAP and
one command to deal with RFC 4285.

 Option 2: we define one command and one generic Authentication AVP.

 I'd like to hear your opinion on this.

 My personal feeling is that I would prefer Option 1. The reason is
that I think it's cleaner
for the server to know from the command-code the associated
authentication method. More especially when we have EAP type
authentication.

 Regards,

 Julien

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

---

From: "Julien Bournelle" <[email-masked]>
Date: Wed, 11 Apr 2007 09:27:48 +0200

Hi madjid, all,

 sorry for the delay too :)

> server, while delivering exact same of parameters and functionality?

 In IKEv2, we setup IPsec SAs and then the MN sends the BU. Moreover,
we have multiple EAP round trip to be handled by the AAA application.
(kind of Diameter EAP)

 In 4285, we send the BU and then we do AAA operations. (kind of
Diameter Mobile IPV4)

> than trying to carry different AVPs over different times and conditions over

 That's also my opinion. Let see if others have opinion on this.

 Regards,

 Julien

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 13 Apr 2007 11:51:38 -0700

So it seems that the IKEv2 and 4285 hit the AAA server at two different
times, before versus after BU and it would make sense to separate the
commands.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:[email-masked]] 
Sent: Wednesday, April 11, 2007 12:28 AM
To: Madjid Nakhjiri
Cc: [email-masked]; Gerardo Giaretta; Hannes Tschofenig
Subject: Re: HA-to-AAAH draft/support of RFC 4285

Hi madjid, all,

 Regards,

 Julien