Subject: [AAA-WG]: MN migration to new realm / draft-mobileip-08-alpha01

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 11 Oct 2001 12:21:29 -0400

Hi Pat,

Section 1.4 of draft-ietf-aaa-diameter-mobileip-08-alpha01 describes
how the AAAH handles the case where the MN has migrated to a new
foreign network and wants to keep the HA which has been allocated in
the previous foreign network.  What follows is the section I'm
referring to:

| 1.4  Allocation of Home Agent in Foreign Network
|
| [...]
|
| Figure 7 shows the message flows for a Mobile Node requesting to keep
| the Home Agent assigned in Foreign network 1 when it moves to foreign
| network 2. Upon reception of the AMR in Foreign network 2, the AAAF
| follows the procedures described earlier and forwards AMR to the
| Mobile Node's home network, i.e. its AAAH. If the Mobile Node was
| successfully authenticated the AAAH checks for the Origin-Host and
| the value of the Origin-Host of the previous request. If a AAAH
| deduces that the Mobile Node has moved to a new realm, it must check
| whether the Mobile can still use the previously assigned Home Agent.
|
|                 +---------------+ +---------------+ +-------------+
|                 |Foreign net 2  | |Foreign net 1  | |Home network |
|                 |               | |               | |             |
|    Mobile Node  |  FA      AAAF | |  HA     AAAF  | |    AAAH     |
|    -----------  | ----     ---- | | ----   ------ | |   ------    |
|                 +---------------+ +---------------+ +-------------+
|
|    <----Challenge----
|    Reg-Req (Response)->
|                     ---AMR--->
|                              ----------------AMR--------------->
|                                                   <-----HAR-----
|                                      <---HAR----
|                                      ----HAA--->
|                                                   ------HAA---->
|                              <---------------AMA----------------
|                     <--AMA----
|     <----Reg-Reply-----
|    Figure 7: Request to access Home Agent from new Foreign Network
|
| If the Mobile Node is allowed to keep the Home Agent the AAAH then
| sends a HAR, which contains the Mobile IP Registration Request
| message data encapsulated in the MIP-Reg-Request AVP and the MIP-
| Home-Agent-Address AVP with Home Agent address, as well as any
| optional KDC session keys, to the AAAF in foreign network 1.  Upon
| reception the AAAF in foreign network 1 will forward the HAR to the
| Home Agent if its local policy allows such service. If the AAAF does
| not permit such service, it MUST return a
| DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.

My question is with the sentence "If a AAAH deduces that the Mobile
Node has moved to a new realm, it must check whether the Mobile can
still use the previously assigned Home Agent."

The previous sentence says "the AAAH checks for the Origin-Host and
the value of the Origin-Host of the previous request".  But this
proposal implies that the AAAH maintains session-state and has
remembered the previous request.  From what I've been reading in the
mailing list, the AAAH isn't required to maintain session state.  

Question: How does an AAAH that doesn't maintain session state make
this "MN has moved to a new realm" deduction?  

Question: If the session-stateless AAAH could make such a deduction,
it would seem that the AAAH could not allow the MN to keep the old HA,
as the AAAH would be unable to route the HAR to the old foreign
network where the HA lives.  True?

Question: If the session-stateless AAAH cannot make such a deduction,
does that mean that the MN, if allowed to have a foreign HA, would
lose his connection if he migrated to a new foreign network?  

Question: If the current request went to a different AAAH than the
previous request, then even a session-stateful AAAH could not allow
the MN to keep the old HA, as the AAAH would be unable to route the
HAR to the old foreign network where the HA lives.  True?

Thanks,
Bob K.

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 11 Oct 2001 09:22:05 -0700

> | whether the Mobile can still use the previously assigned Home Agent.

Mobile IP has a previous Foreign Agent extension, and combined with the
Home Agent field of the registration requestion, this can be deduced.

> network where the HA lives.  True?

no, the HA is in the registration request.

> lose his connection if he migrated to a new foreign network?  

only if the local policy states this needs to happen.

> HAR to the old foreign network where the HA lives.  True?

see above.

PatC

---

From: "Bob Kopacz" <[email-masked]>
Date: Sat, 13 Oct 2001 07:52:57 -0400

Hi Pat,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Pat Calhoun
> Sent: Thursday, October 11, 2001 12:22 PM
> To: Bob Kopacz
> Cc: aaa-wg
> Subject: Re: [AAA-WG]: MN migration to new realm /
> draft-mobileip-08-alpha01
> 
> 

I'll have to bone up on what is in a Mobile-IP Registration Request.
But if I understand correctly, your thinking is that:

1. A stateless AAAH should parse the MIP-Reg-Request AVP to determine
if the MN has moved to a new domain, and

2. The MIP-Reg-Request contains sufficient information to make this
determination, and 

3. The MIP-Reg-Request contains sufficient information for the AAAH
to construct the Destination-Host (which contains a Diameter Identity)
and Destination-Realm, for the HAR which is to be sent to the old
foreign network where the HA lives.

Up to this point, the AAA server has been able to treat the MIP-Reg-Request
as opaque data; the FA extracted the goodies from the Reg-Req and presented
them as Diameter AVPs.  Would it be reasonable for the FA to extract
this further information so the AAAH wouldn't have to parse the
MIP-Reg-Request?

---

From: "Fredrik Johansson" <[email-masked]>
Date: Sun, 14 Oct 2001 12:38:14 +0200

Pat,

I'm not sure this will work, please see comments inline
/Fredrik

>Home Agent field of the registration requestion, this can be deduced.

The MIP-Previous-FA AVP was taken out of the draft when
we removed the optimization that you could get session keys from AAAf.
Of course it can be added again, so no major problem here.

>no, the HA is in the registration request.

Yes, the HA address is in the registration request, but the HA URI that
is to be put in the Destination-Host AVP is not and the AAAh has no way 
of mapping from HA address to HA URI for every possible HA in foreign 
networks. It just doesn't scale.

>> HAR to the old foreign network where the HA lives.  True?

dito

/Fredrik