Subject: [AAA-WG]: [issue] Need more explanation about handling MN handoffs

From: "Bob Kopacz" <[email-masked]>
Date: Mon, 4 Mar 2002 23:19:50 -0500

Issue :                 Need more explanation about handling MN handoffs
Submitter name:         Bob Kopacz 
Submitter email address:[email-masked] 
Date first submitted:   03-04-2002 
Reference: 
Document:               draft-mobileip-09 
Comment type:           Technical 
Priority:               1 
Section: 

Rationale/Explanation of issue: 

  I may be missing something significant here, but ...
  
  This issue has to do with how an AAAF and AAAH, when given a Home
  Agent's IP address, derive the domain/realm/DiameterIdentity
  information needed by the Diameter AAA servers.

  This issue may also have some bearing on the relationship between a
  DiameterIdentity and a FQDN.

  Unfortunately I don't have a good solution to present, so I'm
  indicating what the problems are, as indicated by "-->".  It may
  be that the solution is to enhance the Mobile IP protocol to
  provide more information in the Registration Request.

  THE AAAF's PROBLEM:
  ------------------
  Section 1.4. Allocation of Home Agent in Foreign Network, says
  the following:

    > 1.4  Allocation of Home Agent in Foreign Network
    > 
    > [...]
    > 
    > In the event that the mobile node requests a home agent in the
    > foreign network, and the AAAF authorizes its use, the AAAF MUST set
    > the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
    > This could happen when the AAA request is sent to "extend" a mobile
    > node's current session.
    > 

  -->(1) I think some text needs to be added to describe how the AAAF
  determines if the HA is in a foreign network.

  That is, I am guessing the method is along these lines: 

    Suppose a MN initially connects, is allocated an HA, and later
    undergoes a handoff to a new FA and new AAAF.  Depending on the MN's
    new point of attachment, the new FA and AAAF may or may not be in
    the same foreign domain as before, or the foreign domain may
    be same but the AAAFs are different, or the handoff may involve
    the same AAAF as before.

    In the AMR, the new AAAF is provided with the MN user's NAI and the
    HA's IP address.  Say the MN user is "[email-masked]" and the specified
    HA IP address is 1.2.3.4.

    The new AAAF does a reverse DNS lookup of tbe HA's IP address,
    1.2.3.4, and the DNS response is that IP address 1.2.3.4 corresponds 
    to an FQDN of "homeagent86.westcoast.spinach.com".

    Now the AAAF extracts the realm part of the NAI, "donut.com", and
    pre-pends a dot, coming up with ".donut.com".  The AAAF then checks
    if this ".donut.com" string is a trailing substring of the
    "homeagent86.westcoast.spinach.com" FQDN.  It isn't, so the AAAF
    concludes the HA is in a foreign network and sends the
    Home-Agent-In-Foreign-Network flag with a value of one.  If the tail
    of the FQDN matched ".donut.com", the AAAF would conclude the HA was
    in the home network.

  -->(2) This may or may not be anywhere close to the AAAF's method.  
  At any rate, the method should be described in sufficient detail 
  for an AAAF implementation.

  -->(3) If this DNS reverse lookup is indeed the AAAF's method to
  make this "home-agent-is-in-a-foreign-network" determination, then
  this introduces a delay into the handoff, and should probably be
  noted.

  THE AAAH's PROBLEM
  ------------------
  Section 1.2 Inter-Realm Mobile IP, says the following:

    > 
    > 1.2  Inter-Realm Mobile IP
    > 
    > [...]
    > 
    > If the Mobile Node was successfully authenticated, the AAAH checks if
    > the Home Agent was located in the foreign realm, by checking the
    > Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP.  If
    > the flag is enabled, then the Home Agent is located in the foreign
    > realm then AAAH sends an HAR message to AAAF which contains a MIP-
    > Reg-Request AVP.

  Continuing the example, suppose the AAAF has determined that the
  HA is in a foreign network, and has forwarded the AMR to the home
  realm.  The AAAH receives the AMR, and the AMR indicates the HA's
  address is 1.2.3.4, the Home-Agent-In-Foreign-Network flag is ON,
  and the User-Name is "[email-masked]".

  -->(4) Now the AAAH wants to send an HAR to the HA.  But Diameter
  routes by Destination-Realm and Destination-Host, not by IP address,
  so the AAAH has to somehow come up with the HA's DiameterIdentity
  for the Destination-Host AVP of the HAR, and the HA's realm for the
  Destination-Realm of the HAR.  

  AAAH's 1st Problem: How to discover the HA's DiameterIdentity:
  
  If the AAAH maintains session-state, then this HA identity
  information can be part of the cached session-state information,
  and there may be no problem.  But there is a problem if either
  (a) the AAAH is not session-stateful, or (b) the AAAH is
  session-stateful but has no session-state info because the handoff
  AMR is received by a different AAAH than the AAAH which received
  the original AMR for the session.

  So if we have case (a) or (b), the hapless AAAH is holding the HA's
  IP address, and needs to come up with the HA's realm and
  DiameterIdentity.  The method might be along these lines:

    The AAAH can do a reverse lookup of the IP address 1.2.3.4, and
    again DNS returns an FQDN of "homeagent86.westcoast.spinach.com"

    *If* the DiameterIdentity is the same as the FQDN, then the AAAH
    constructs the HAR's Destination-Host = 
    "homeagent86.westcoast.spinach.com". (An aside: I haven't kept up
    with the recent DiameterIdentity thread, but I thought the
    DiameterIdentity needed to be something like "FQDN+extra", so that
    multiple Diameter applications could run on the same box.  In
    which case the FQDN isn't sufficient).

    AAAH's 2nd Problem: How to discover the HA's Realm:

    The AAAH still needs to derive the HAR's Destination-Realm, from
    the FQDN.  The realm is probably either "westcoast.spinach.com"
    or "spinach.com".  Does the AAAH have a way to know for sure, or
    is the best-guess algorithm to say that the realm is what
    follows the next-to-last dot of the FQDN, e.g. "spinach.com".

  -->(5) Again, this may or may not be anywhere close to what the
  AAAH needs to do to surmise the HA's realm and identity.  At any
  rate, the method should be described in sufficient detail to
  implement an AAAH.

  -->(6) If this DNS reverse lookup is indeed part of the AAAH's
  method, then this introduces a delay (maybe a 2nd delay depending on
  what the AAAF had to do) into the handoff, and should probably be
  noted.

  -->(7) It seems the AAAF and AAAH are both starting from scratch
  with the HA's IP address, and duplicating efforts and delays. Maybe
  the AAAF's DNS-lookup results (or whatever useful knowledge the AAAF
  possesses) could be passed along to the AAAH.

---

From: Johan Johansson <[email-masked]>
Date: Tue, 05 Mar 2002 13:05:43 +0100

>    of the FQDN matched ".donut.com", the AAAF would conclude the HA was
Is this the intended interpretation of piggybacked in

Realm
      The string in the NAI that immediately follows the '@' character.
      NAI realm names are required to be unique, and are piggybacked on
      the administration of the DNS namespace.

This has rather important consequences for what configurations of realms 
and nais would be legal.

>  this introduces a delay into the handoff, and should probably be
The last time this matter was discussed our mobile ip implementers 
disliked the idea for the very same reason and I thought I sent a 
message to the list about it but I can't seem to locate it in the 
archive so I guess I didn't.

>    which case the FQDN isn't sufficient).
Draft 10 states FQDN only but does not state that it needs to be 
registered in DNS as was stated at least at some time during the 
discussion. The idea is to use aliasing if I recall correctly so that 
each process could use its own FQDN. Even if it is indeed registered in 
DNS, which seems likely in a production system, I'm not quite sure how 
you could tell which identity to use.

>    follows the next-to-last dot of the FQDN, e.g. "spinach.com".
Probably not since this excludes subrealming. How about the 
next-to-first dot instead?

>  possesses) could be passed along to the AAAH.
A possible and slight optimization, but in my opinion the fundamental 
flaw is to not have the only entity capable of carrying the information 
across all scenarios actually do so, i.e. the MN. If this is politically 
infeasible we must look at suboptimal solutions of course.

j

---

From: David Spence <[email-masked]>
Date: Wed, 06 Mar 2002 11:24:24 -0500

I think this is a real showstopper issue.

The problem goes to the core of how Diameter identifies nodes and does
message forwarding.  In order for Diameter MobileIPv4 to support handoffs
correctly, the Diameter identities and realms of various Diameter nodes
involved in the service need to be known.  To solve this issue properly,
changes may need to be made to the Mobile IPv4 protocol itself.  Given the
close interdependence of Mobile IPv4 when used to support CDMA2000 and the
Diameter MobileIPv4 application, it puzzles me why "IP Mobility Support for
IPv4" (RFC 3220) was allowed to progress to Proposed Standard independently
of "Diameter Mobile IPv4 Application"
(draft-ietf-aaa-diameter-mobileip-09.txt).  Nevertheless, I believe that the
only good way to solve the problems of Diameter MobileIPv4 is to add some
data elements to the Mobile IPv4 protocol itself.

---

From: Tony Johansson <[email-masked]>
Date: Tue, 12 Mar 2002 17:25:38 -0800

Hi David and All,

I see two solutions:

Alt 1) Add new Mobile IPv4 subtypes, like HA-NAI, FA-NAI (by using the MIER
draft).

Alt 2) Or solve it without any new requirements on Mobile IPv4. Like some what
the proposed below, thus require the AAAF to look up the Home Agent realm and
host identity, e.g. using reverse DNS look up. The AAAF could the pass the realm
and the host identity  to the AAAH.

I certainly agree with you that Alt 1 would be the best solution. However, I have
no idea how much extra delay that would cause. So, may be the only realistic way
forward, within reasonable time, is Alt 2.

Comments please

/Tony

---

From: David Spence <[email-masked]>
Date: Wed, 13 Mar 2002 14:01:09 -0500

I just don't know if alt 2 really works.  You can map an IP address to a
host name, but you have no assurance that the host name it maps to is a
Diameter identity.  There may be multiple host names that map to the IP
address, and if so, how can you tell which one is the Diameter identity
you're looking for?  Further, even if you could determine the Diameter
identity, there is no general algorithm for extracting the realm from it. 
That is why Diameter has both host name and realm AVPs.

If we need to do something quickly in order to get a PS out, perhaps we
could admit that the PS doesn't adequately address all the issues involved
with supporting an HA in the foreign network and defer a thoughtful solution
to some of these issues until after the PS is submitted.

---

From: Tony Johansson <[email-masked]>
Date: Wed, 13 Mar 2002 12:35:37 -0800

Hi David,

David Spence wrote:

> Diameter identity.

Why not ? The Diameter identity is a FQDN, which can you can map an IP address to.
Right ?!

from base-10:

       "The DiameterIdentity format is derived from the OctetString AVP
         Base Format.  It uses the UTF-8 encoding and has the same
         requirements as the UTF8String:

            DiameterIdentity  = fqdn

         A Diameter node must be uniquely identified by its
         DiameterIdentity, which contains the fqdn of the Diameter node.
         If multiple Diameter nodes run on the same host, each Diameter
         node MUST be assigned a unique DiameterIdentity. If a Diameter
         node can be identified by several FQDNs, one single FQDN should
         be picked at startup, and used as the only DiameterIdentity for
         that node, whatever the connection it is sent on. TheDiameterIdentity
         value is used to uniquely identify a Diameter
         node for purposes of duplicate connection and routing loop
         detection."

So, from Bob's example below you would be able to get the fqdn host name from a reverse
DNS loop up, i.e. "homeagent86.westcoast.spinach.com", which you then can use to create
the Destination-Host AVP = homeagent86.westcoast.spinach.com and the Destination-Realm
AVP = westcoast.spinach.com, since the lookup is based on longest-match-from-the-right.
Right?

/Tony

> There may be multiple host names that map to the IP

---

From: Johan Johansson <[email-masked]>
Date: Wed, 13 Mar 2002 22:30:18 +0100

>Why not ? The Diameter identity is a FQDN, which can you can map an IP address to.
Yes, but the problem is in the other direction.

To put it in mathematical terms: the mapping from FQDN to IP address is 
not injective and thus can not be inverted. In other words, which of the 
possible 3 FQDNs for IP address X is the correct identity?

j

---

From: Tony Johansson <[email-masked]>
Date: Wed, 13 Mar 2002 13:45:12 -0800

> possible 3 FQDNs for IP address X is the correct identity?

Okay, but will somebody actually need 3 different FQDNs for the same IP address?! At
least, I don't see why we would need multiple FQDNs to the same IP address in an HA.
So, how about adding a statement in the MIP-09 that you can only have one FQDN per IP
address in an HA.

Would that be okay?

/Tony

---

From: John Schnizlein <[email-masked]>
Date: Wed, 13 Mar 2002 16:52:37 -0500

Since RFC 1912 says "For every IP address, 
there should be a matching PTR record in the in-addr.arpa domain."
And RFC 1133 says "PTR’s should use official names and not aliases.",
it seems reasonable to expect an IP address to map to just one host name.

Where do the other two come from?

John

At 04:30 PM 3/13/2002, Johan Johansson wrote:
>Tony Johansson wrote:
>
>>>I just don't know if alt 2 really works.  
>>>You can map an IP address to a host name, but you have no 
>>>assurance that the host name it maps to is a Diameter identity.
>>
>To put it in mathematical terms: the mapping from FQDN to IP address is not injective and thus can not be inverted. In other words, which of the possible 3 FQDNs for IP address X is the correct identity?

---

From: Johan Johansson <[email-masked]>
Date: Wed, 13 Mar 2002 23:06:16 +0100

This whole multiple FQDN business was introduced in the discussion on 
Diameter identity to allow multiple Diameter processes on the same host. 
Of course, if we as Tony suggests in another email make the restriction 
that if a machine is running a HA Diameter process it must not run any 
other Diameter process, we are safe. I would prefer not to make this 
restriction but if it is the only way to make this work we don't have 
much choice.

j

John Schnizlein wrote:

>And RFC 1133 says "PTR's should use official names and not aliases.",

---

From: Tony Johansson <[email-masked]>
Date: Wed, 13 Mar 2002 14:38:14 -0800

Johan Johansson wrote:

> restriction

Why would you prefer not to do this restriction? Would you really run multiple Diameter processes in an HA?!

> but if it is the only way to make this work we don't have
> much choice.
>
> j
>
> John Schnizlein wrote:
>

---

From: Steve Rich <[email-masked]>
Date: Wed, 13 Mar 2002 17:43:20 -0500

Maybe not for an HA per se, but I can see the need/desire to run
multiple Diameter servers on a single host.

I would hope that a restriction of this nature not be imposed.

Thanks,
sjr

---

From: Tony Johansson <[email-masked]>
Date: Wed, 13 Mar 2002 15:28:07 -0800

I agree. I ONLY want to impose this for the HA, with something like the following new section:

"1.9 DiameterIdentity discovery of the Home Agent

This application requires that the Home Agent MUST only have one FQDN per IP address. This is required to guarantee that the AAAF and AAAH can determine the DiameterIdentity of the Home Agent, since only the Home
Agents IP address will be known in all subsequent re-authentications through the AAA infrastructure."

If we can't agree on this restriction, then the  AAAF and AAAH will have a hard time to find the right HA and route the requests to the right HA when the MN do handoffs.

Regards,

/Tony

---

From: Johan Johansson <[email-masked]>
Date: Thu, 14 Mar 2002 01:07:06 +0100

It's getting pretty late here so I'll temporarily ignore your previous 
question Tony, but for now, are there any suggestions on how to solve 
what Bob called the "AAAH's 2nd Problem", i.e. how is the realm deduced 
from this? For ha4.ericsson.com there is apparently no problem, but what 
about ha2.eab.ericsson.com? Do we mandate this to be eab.ericsson.com or 
do we mandate this to be ericsson.com or do we do something completely 
different? Picking eab.ericsson.com would have the advantage that if you 
use longest match from right to lookup routes you would still get a 
match on ericsson.com.

I really wish an effort to get an extension into MobileIP had been made 
when we discussed this the first time in October. Now, just as half a 
year ago, *any* other solution is preferred due to time constraints. I 
think that any of the suboptimal solutions we must come up with should 
at the very least not limit future modifications of the protocol to 
solve the problem the right way. Or do we play by a completely new set 
of rules if we change the version number in messages to 2?

j

Tony Johansson wrote:

> This application requires that the Home Agent MUST only have one FQDN 
> per IP address. This is required to guarantee that the AAAF and AAAH 
> can determine the DiameterIdentity of the Home Agent, since only the 
> Home Agents IP address will be known in all subsequent 
> re-authentications through the AAA infrastructure."
>
> If we can't agree on this restriction, then the  AAAF and AAAH will 
> have a hard time to find the right HA and route the requests to the 
> right HA when the MN do handoffs.
>
> Regards,
>
> /Tony
>
> Steve Rich wrote:
>
>>  > Why would you prefer not to do this restriction? Would you really 
>> run multiple Diameter processes in an HA?!
>>  >
>>  > > >>To put it in mathematical terms: the mapping from FQDN to IP 
>> address is not injective and thus can not be inverted. In other 
>> words, which of the possible 3 FQDNs for IP address X is the correct 
>> identity?
>>  > > >>
>>  > > >
>>  >
>>

---

From: David Spence <[email-masked]>
Date: Thu, 14 Mar 2002 12:12:05 -0500

> Why not ? The Diameter identity is a FQDN, which can you can map an IP address to.

Wrong.  There may be a many-to-one mapping of host names to IP address. 
Each IP address typically has a single PTR record that points to a single
host name.  From that host name, there is no general mechanism to discover
other host names that point to the same IP address.  So it may not be
possible to locate the host name you're looking for given the IP address. 
Even if you could retrieve a whole list of host names that map to an IP
address, how would you know which of them is the Diameter identity you're
looking for?

> AVP = westcoast.spinach.com, since the lookup is based on longest-match-from-the-right.

Wrong again unless the base spec mandates that the
longest-match-from-the-right convention MUST be followed.  It might simplify
Diameter if we made that requirement.

---

From: Tony Johansson <[email-masked]>
Date: Thu, 14 Mar 2002 11:14:49 -0800

In the continued mail discussion yesterday I proposed the following resriction in the HA:

This application requires that the Home Agent MUST only have one FQDN per IP address. This is

required to guarantee that the AAAF and AAAH can determine the DiameterIdentity of the Home
Agent,
since only the Home Agents IP address will be known in all subsequent re-authentications
through
the AAA infrastructure."

However, I just got reminded that you may have multiple interfaces on the HA, ie. one
Diameter client interface and one HA interface. So, in such a case a reverse DNS lookup on
the HAs IP address wouldn't really point you to the right FQDN anyway :(

So, do we need to add some new requirements on Mobile IP to get this right?

The Mobile IP GNAI draft
(http://search.ietf.org/internet-drafts/draft-ietf-mobileip-gnaie-05.txt) would acctually fit
very well to our needs. The draft defines two new extensions to Mobile IP, FA_NAI and HA_NAI.
Adding one more "HA_Diameter_NAI" to this draft and we would have all info needed in the
Diameter infrastructure without any extra DNS look up delays... The NAI structure would also
give use the hostname and realm (hostname@realm) problem solved.

The BIG question is how long time it would take to get this done in the MIPwg?  Pat, any
comments on this ?

/Tony

---

From: "Bob Kopacz" <[email-masked]>
Date: Fri, 15 Mar 2002 13:56:41 -0500

Hi Tony,

Here's an idea which may help solve many of the problems with a foreign
HA, i.e. the MN handoff problems (issue#299), and the problems with
securing AAAH-generated keys (issue#301).

I'll note the new requirements in square brackets along the way.

Initial MN connection:
----------------------

1. Suppose the MN initially connects to FA1 in ForeignNetwork1, and
requests that an HA be allocated in either the home or foreign network.

2. The FA1 sends an AMR to his local AAAF1 in ForeignNetwork1.  

3. AAAF1 decides that HA1 (in ForeignNetwork1) is a good candidate HA
and forwards an AMR with a Candidate-HA(value=HA1) AVP to the home
network.  AAAF1 includes his realm & identity in the Originating-AAAF
AVP, per issue#266.

4. AAAH1 in the home network decides that a foreign HA is just fine.

[AAAH1 must be a session-stateful AAA server].

5. If AAAH1 is generating any session keys destined for the HA and wants
to secure them, the AAAH1 sets up a DSA with AAAF1, and sends
CMS-encrypted keys in the HAR.

6. AAAH1 sends the HAR to AAAF1, not to HA1.  That is, the HAR carries a
Destination-Realm(value=AAAF1's realm), Destination-Host(value=AAAF1's
identity), and a new grouped AVP called the HA-Identity AVP which has
two members, HA-Realm(value=HA1's realm) and the HA-Identity(value=HA1's
identity, from the AMR's Candidate-HA AVP).

[The HAR is destined to AAAF1, not HA1].

[An HAR sent to a foreign network, because of a foreign HA, is always
sent to an AAAF, not an HA, and always includes an AVP which carries the
HA's identity].

7. If there are any CMS-secured keys in the HAR, then AAAF1 decrypts
them.

8a. Case 1: AAAF1 hosts both FA1 and HA1... AAAF1 may be the AAA server
hosting HA1, in which case AAAF1 can send the HAR to HA1 (after
replacing the Destination-Host and Destination-Realm to target HA1, and
removing the HA-Identity AVP, and generating the HA/FA key if
necessary).

8b. Case 2: AAAF1 hosts FA1 but not HA1... There may an AAAF2 (also in
ForeignNetwork1) which is hosting HA1, in which case AAAF1 sends the HAR
to AAAF2.  Then AAAF2 sends the HAR to HA1 (after doing the same sort of
HAR-massaging that AAAF1 did above).

9. In either case, if the destination-AAAF generates an FA-HA key and
wants to return it secured to the origin-AAAF (AAAF1), then the
destination-AAAF sets up a DSA with AAAF1 a la issue#266, and passes
a CMS-encrypted FA-HA key in the HAA.

10. When AAAH1 receives the HAA, it updates its session-state
information for this session.  The AAAH's session-state info contains,
among other things:

- AAAF1's realm and identity
- HA1's realm and identity
- HA1's IP address

MN handoff to FA2 in ForeignNetwork2
------------------------------------

(The handoff could also be to another FA in ForeignNetwork1, but I
thought I'd describe the potentially most-troublesome circumstance).

1. Suppose the MN migrates to FA2 in ForeignNetwork2.  

2. FA2 creates an AMR and sends this to his local AAAF, AAAF3, in
ForeignNetwork2.

3. AAAF3 adds an Originating-AAAF(value=AAAF3's realm+identity) to the
AMR, and forwards the AMR to the home network.

4. The AMR must (somehow) be received by AAAH1, who is the AAAH holding
the session-state info for this MN packet session.  

There are a couple ways to ensure that this AMR makes its way to AAAH1:

4a. Require that each realm is authorized/authenticated by exactly one
AAAH.  So while a home network may have multiple AAAH's, the realms are
partitioned over the set of home network AAAH's.

or 

4b. If the home realm has multiple AAA servers AAAH1, AAAH2, ..., AAAHn,
then [this needs further thought, but one idea (a bad idea that works)
is that, when the AMR is received by an AAAH in the home network, the
AMR hot-potatoes around the AAAHs until it ends up at some AAAH who
recognizes this session, i.e. AAAH1]

5. When AAAH1 receives the AMR, it looks for a session that matches the
AMR's User-Name, MN IP address, and HA IP address.  AAAH1 finds this
session, and retrieves HA1's identity and AAAF1's identity.  Now the
AAAH knows all the good stuff, and things can proceed along the lines of
steps 5-10 in the preceding "Initial MN Connection" section.

Variation:
----------
A minor variation on this scheme is for AAAF2's identity to be stashed
as part of AAAH's session-state info, so that AAAH could send the HAR
directly to AAAF2 rather than dog-legging it through AAAF1.  This could
happen if either AAAF1 included both HA1's identity and AAAF2's identity
in the initial AMR, or if AAAF2 returned his identity in the HAA.

What do you think? I've got an even worse idea which I will also write
up and send along.

Bob K.

---

From: Tony Johansson <[email-masked]>
Date: Fri, 15 Mar 2002 14:18:44 -0800

Hi Bob,

I agree in principle with all of your statements below and I've been
thinking about this within the same lines.

All, any strong objection / comments against these imposed restrictions /
requirements. If not, I will continue to work on some new text for this.

Please, find some more comments embedded...

Thanks a lot,

/Tony

> I'll note the new requirements in square brackets along the way.

We could also re-use the Candidate-HA AVP.

> MN handoff to FA2 in ForeignNetwork2

Issue#282 (Base-11) would make it possible to ask a re-direct server to
which AAAH the user belongs to...

> steps 5-10 in the preceding "Initial MN Connection" section.

This sounds like a better solution to me.

> What do you think? I've got an even worse idea which I will also write

Okay, I'm may looking forward to it ;-)

---

From: "Bob Kopacz" <[email-masked]>
Date: Sat, 16 Mar 2002 12:07:03 -0500

Hi Tony,

> -----Original Message-----
> From: Tony Johansson [mailto:[email-masked]]
> Sent: Friday, March 15, 2002 5:19 PM
> To: Bob Kopacz
> Cc: Johan Johansson; David Spence; aaa-wg
> Subject: Re: [AAA-WG]: [issue] Need more explanation about handling MN
> handoffs
> 
> Hi Bob,
> 

I was just floating an idea for you guys to chew on.  I didn't submit
any text because I didn't want to promote this partly-baked thought as 
an issue quite yet; not until I got at least one positive feedback.

> We could also re-use the Candidate-HA AVP.

I thought about that, but after a handoff, the HA is not longer a candidate,
he's an elected official.  So at that point the Candidate-HA AVP can be used,
but it's a bit of a misnomer.

Is there any virtue in creating two or three generic AVPs, called
"Host-Identity" and "Host-Realm" and maybe "Host-IP-Address"?  These
AVPs would be members of a grouped AVP which carries the identity
information for one of the participants in the mobile session. e.g.

   MIP-Originating-Foreign-AAA ::= < AVP Header:... >
                                    { Host-Realm }
                                    { Host-Identity }

   MIP-Candidate-Home-Agent     ::= < AVP Header:... >
                                    { Host-Realm }
                                    { Host-Identity }

   MIP-Foreign-Agent            ::= < AVP Header:... >
                                    { Host-Realm }
                                    { Host-Identity }

   MIP-Home-Agent               ::= < AVP Header:... >
                                    { Host-Realm }
                                    { Host-Identity }
                                    [ Host-IP-Address ]

And then eliminating the non-grouped AVPs which purport to carry the
all you need to know about a node, but actually carry only the
identity but not the realm.

> > steps 5-10 in the preceding "Initial MN Connection" section.

This solves the problem that the AAAH has in trying to map the HA's IP
address into a DiameterIdentity & realm.  It still doesn't solve the
problem for the originating AAAF (after a handoff), who wants to do the
same mapping.

I'll float another idea here (groping for solutions): The AAAF, when
receiving the AMR from the FA after a handoff, doesn't try to do the
reverse DNS (to map the HA IP's address into HA Identity and HA Realm).
The AAAF just sends the AMR on to the stateful AAAH.  The AAAH returns
the HA Identity & Realm in the AMA.  The originating AAAF now has the
desired info, and can make his policy decisions, albeit late in the game.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 21 Mar 2002 08:36:34 +0100

I don't realy like the idea of starting to add restrictions to the protocol
now when we have been working so hard the past year to have a flexible
solution that can handle multiple AAA-h. I believe that we at least should
give it a try in the Mobile IP wg and try to use the gnaie-draft. I've
talked to Phil Roberts (mip wg chair) and he seems to be positive to such a
solution.

If we start to impose the restrictions, then we might as well go back and
clean up the rest of the protocol.

/Fredrik

>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Tony Johansson
>Sent: den 15 mars 2002 23:19
>To: Bob Kopacz

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 21 Mar 2002 11:50:07 -0500

Hi Fredrik,

> From: Fredrik Johansson [mailto:[email-masked]]
> Sent: Thursday, March 21, 2002 2:37 AM
> To: Tony Johansson; Bob Kopacz
> Subject: RE: [AAA-WG]: [issue] Need more explanation about handling MN
> handoffs
> 

I agree with you that this problem is best solved with some help from 
the Mobile IP protocol.  I was just tossing out ideas.

Bob K.

---

From: Tony Johansson <[email-masked]>
Date: Sun, 24 Mar 2002 23:30:03 -0800

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