Subject: RE: [AAA-WG]: Issue #299 and #301

From: "Bob Kopacz" <[email-masked]>
Date: Mon, 1 Apr 2002 17:17:40 -0500

Hi Tony,

At this time, I have nothing more to offer in terms of an issue#299
solution, but I have another related snag, the solution to which can be
part of the issue#299 solution.

This problem isn't with the MN-handoff, but is with the initial AMR for
a mobile session, and has to do with the problem of mapping the HA's IP
address to the HA's identity.

Here we go:

Suppose a MN initially hooks up with an FA in some foreign network, and
the MN knows his HA's IP address in the home network.  So the AMR
carries a MIP-Home-Agent-Address AVP, and is routed to some AAAH in the
home network.

When the AAAH receives this AMR, the AAAH will want to send an HAR to
the HA, and will need the HA's identity for the HAR's Destination-Host
AVP.

If the targeted HA is a direct peer of the AAAH, then this is no problem.
The AAAH just looks into his peer table for a peer with an IP address
matching the value of the AMR's MIP-Home-Agent-Address AVP.

But if the HA is not a direct peer of the AAAH, then the AAAH has to
somehow map the HA's IP address to the HA's identity.

Three ideas pop into mind:

1. Require that all home-network HAs be direct peers of all the
home-network AAAHs.

or

2. Require an MN who remembers his HA's IP address between sessions to
also remember the HA's identity between sessions, and send both of these
HA identification items in the Registration Request.  The FA would
extract both of these items from the Registration Request, and send
them as Diameter AVPs in the initial AMR.

or

3. Indicate that the AAAHs must have some mechanism, not specified in
the protocol, of mapping the home-network's HA IP addresses into
DiameterIdentities.

Bob K.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tony Johansson
> Sent: Monday, March 25, 2002 2:30 AM
> To: aaa-wg
> Cc: Bob Kopacz; Fredrik Johansson; Johan Johansson; David Spence; Pat R.
> Calhoun
> Subject: [AAA-WG]: Issue #299 and #301
>
>
> All,
>
> During, the AAA working group meeting at IETF53 I presented the
> issues #299 and
> #301 and two alternative ways in which we could workout a solution to the open
> issues - see below:
>
> Alt1: Clarifications / new requirements without any new dependencies to MIP.
> ------------------------------------------------------------------------------
>
> AAAH
> - Require that each subdomain of a realm is authorized/authenticated
> by exactly
> one AAAH. So while a home network may have multiple AAAH's, each
> subdomain will
> have exactly one AAAH.
>
> - Or, require that, if the home realm has multiple AAA servers to
> which the same
> user can be routed to, then there MUST be a synchronization
> mechanism between the AAAH servers. However, the specific synchronization
> mechanism is beyond the scope of this spec.
>
>  AAAF
> - How to map HA IP address to HA FQDN is still open. Reverse DNS look
> up is not
> at all a straightforward solution for this…
>
>
> Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft.
> -----------------------------------------------------------------------------
>
> AAAH
> - Require that the MN support the GNAIE draft, updated to include the
> definition
> of a AAAH NAI.  When sending a MIP RegReq, this AAAH NAI
> would be included to guarantee that a registered user always ends up
> in the same
> initial AAAH.
>
> AAAF
> - The mapping of the HA IP address and HA FQDN, Host and realm would be
> automatically solved, since this would be included in the MIP RegReq as well.
>
> There was a very clear and strong consensus that alternative 2 would be by far
> the best solution. However, this means more work and dependencies
> to the MIP working group and the goal is set to have the Diameter MIPv4 appl.
> draft in working group last call by the April 2nd. Looking at the
> GNAIE draft, I done see that much work needs to be done to make it fulfill our
> needs, so to me it could easily be done in time, but the big
> question is how quickly could it be pushed through the MIP working
> group and go
> to last call?  I have sent the question MIP wg and I hope to soon get answer
> back.
>
> Regards,
>
> Tony
>
>
>
>

---

From: Tony Johansson <[email-masked]>
Date: Mon, 01 Apr 2002 15:35:39 -0800

Hi Bob,

Please have a look at the proposed text that I just sent out (which for some reason
got lost the first time I tried earlier today :(

/Tony

---

From: Tony Johansson <[email-masked]>
Date: Mon, 01 Apr 2002 17:50:13 -0800

I vote for #2 below, which can be fixed by adding something like the following in
the draft-johansson-mip-aaa-nai-00.txt:

" 4. HA Identity subtype

  ...

  A mobile node, which request a specific HA IP address at the
  initial authentication MUST also provide the HA Identity subtype

  ... "

/Tony

---

From: Johan Johansson <[email-masked]>
Date: Tue, 02 Apr 2002 17:09:56 +0200

I thought #2 was required already? #1 is interesting since it touches on 
what network configurations are even possible. I'll go over some 
different network scenarios and put together an issue. The only thing I 
am quite certain of right now is that the suggested configuration for 
hierarchical networks does *not* work, at least not as expected. The 
intuitive configuration makes the AMRs end up at the HAs for instance. 
More on this later.

j

Tony Johansson wrote:

>>>at all a straightforward solution for this...
>>>
>>>