Subject: [AAA-WG]: updated text proposal to issue #299 and #301

From: Tony Johansson <[email-masked]>
Date: Tue, 09 Apr 2002 12:53:15 -0700

All,

Thanks a lot for all the previous comments. Here is an updated text
proposal to issue #299 and #301. Since I have made various changes
through out section 1.2, 1.3 and 1.4, I've added the whole sections
below.

And as always, comments are appreciated.

/Tony

----------------------------------------------------------------------

1.2  Inter-Realm Mobile IP

   When a Mobile Node node requests service by issuing a Registration
   Request to the foreign agent, the foreign agent creates the AA-
   Mobile-Node-Request (AMR) message, which includes the AVPs defined in

   section 2.1.  The Home Address, Home Agent, Mobile Node NAI and other

   important fields are extracted from the registration messages for
   possible inclusion as Diameter AVPs.  The AMR message is then
   forwarded to the local Diameter server, known as the AAA-Foreign, or
   AAAF.

                   Visited Realm                    Home Realm
                     +--------+                     +--------+
                     |abc.com |       AMR/AMA       |xyz.com |
                     |  AAAF  |<------------------->|  AAAH  |
                  +->| server |    server-server    | server |
                  |  +--------+    communication    +--------+
                  |         ^                         ^
                  | AMR/AMA |      client-server      | HAR/HAA
                  |         |      communication      |
                  v         v                         v
          +---------+      +---------+              +---------+
          | Foreign |      | Foreign |              |  Home   |
          |  Agent  |      |  Agent  |              |  Agent  |
          +---------+      +---------+              +---------+
                            ^
                            | Mobile IP
                            |
                            v
                           +--------+
                           | Mobile |
                           | Node   | [email-masked]
                           +--------+
                      Figure 1: Inter-Realm Mobility

   Upon receiving the AMR, the AAAF follows the procedures outlined in
   [DIAMBASE] to determine whether the AMR should be processed locally,
   or if it should be forwarded to another Diameter server, known as the

   AAA-Home, or AAAH.  Figure 1 shows an example in which a mobile node
   ([email-masked]) requests service from a foreign provider (abc.com). The
   request received by the AAAF is forwarded to xyz.com's AAAH server.

   Figure 2 shows the message flows involved when the foreign agent
   invokes the AAA infrastructure to request that a mobile node be
   authenticated and authorized. Note that it is not required that the
   foreign agent invoke AAA services every time a Registration Request
   is received from the mobile, but rather only when the prior
   authorization from the AAAH expires [MIPCHAL]. The expiration time of
the
   authorization is communicated through the Authorization-Lifetime AVP
   in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH.

   Mobile Node   Foreign Agent       AAAF          AAAH      Home Agent
   -----------   -------------   ------------   ----------   ----------
                 Advertisement &
        <--------- Challenge

   Reg-Req&MN-AAA  ---->

                      AMR------------>
                      Session-Id = foo

                                     AMR------------>
                                     Session-Id = foo

                                                   HAR----------->
                                                   Session-Id = bar

                                                     <----------HAA
                                                   Session-Id = bar

                                       <-----------AMA
                                       Session-Id = foo

                        <------------AMA
                        Session-Id = foo

        <-------Reg-Reply

              Figure 2: Mobile IP/Diameter Message Exchange

   The foreign agent (as shown in Figure 2) MAY provide a challenge,
   which gives it direct control over the replay protection in the
   Mobile IP registration process, as described in [MIPCHAL].  The
   mobile node includes the Challenge and MN-AAA authentication
   extension to enable authorization by AAAH. If the authentication data

   supplied in the MN-AAA extension is invalid, AAAH returns the
   response (AMA) with the Result-Code AVP set to
   DIAMETER_AUTHENTICATION_REJECTED.

   A mobile node, which has been previously authenticated and
   authorized, MUST always include the assigned home agent in the HA
   Identity subtype of the AAA NAI extension, and the authorizing Home
   AAA server in the AAAH Identity subtype of the AAA NAI extension, in
   the registration request message [AAANAI] which is sent to the FA
   every time the Mobile Node needs to re-authenticate. So, in the event

   that the AMR generated by the FA is for a session that was previously

   authorized, it MUST include the Destination-Host AVP, with the
   identity of the AAAH found in the AAAH-NAI, and the MIP-Home-Agent-
   Host AVP with the identity and realm of the assigned HA found in the
   HA-NAI.

   If the mobile node was successfully authenticated, the AAAH checks if

   the home agent was located in the foreign realm, by checking Home-
   Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. Other
   AVP's like the MIP-Home-Agent-Host AVP and the MIP-Originating-
   Foreign-AAA AVP may also be used to verify the location of the home
   agent. If the home agent is located in the foreign realm, then the
   AAAH sends an HAR message to the home agent, which contains a MIP-
   Reg-Request AVP.

   If the home agent was not located in the foreign realm, the AAAH
   checks for the MIP-Home-Agent-Address AVP and if present the MIP-
   Home-Agent-Host AVP. If one was specified, the AAAH checks that the
   address is that of a known home agent and that the Mobile Node is
   allowed to request this particular home agent, and that the home
   agent's identity is included in the MIP-Home-Agent-Host AVP. If no
   home agent was specified, and if the MIP-Feature-Vector has the Home-

   Agent-Requested flag set, and if allowed by policy in the home realm,

   the AAAH SHOULD allocate a home agent on behalf of the Mobile Node.
   This can be done in a variety of ways, including using a load
   balancing algorithm in order to keep the load on all home agents
   equal. The actual algorithm used and the method of discovering the
   home agents is outside the scope of this specification.

   The AAAH then sends an Home-Agent-MIP-Request (HAR), which contains
   the Mobile IP Registration Request message data encapsulated in the
   MIP-Reg-Request AVP, to the assigned or requested Home Agent. The
   AAAH MAY allocate a home address for the mobile node, while the Home
   Agent MUST support home address allocation. In the event the AAAH
   handles address allocation, it includes it in a MIP-Mobile-Node-
   Address AVP within the HAR.  The absence of this AVP informs the Home

   Agent to perform the allocation.

   During the creation of the HAR, the AAAH MUST use a different session

   identifier than the one used in the AMR/AMA (see Figure 2). If the
   AAAH is session-stateful, it MUST send the same session identifier
   for all HARs initiated on behalf of a given mobile node's session.
   Otherwise, if the AAAH is session-stateless, it will manufacture a
   unique session-id for every HAR.

   A mobile node's session is identified via its identity in the User-
   Name AVP, the MIP-Mobile-Node-Address and the MIP-Home-Agent-Address
   AVPs. This is necessary in order to allow the session state machine,
   defined in the base protocol [DIAMBASE], to be used unmodified with
   this application. Therefore, an STR from a foreign agent would free
   the session from the foreign agent, but not the one towards the home
   agent (see figure 3).

           STR, Session-Id = foo       STR, Session-Id = bar
           --------------------->      <--------------------
      +----+      +------+      +------+                    +----+
      | FA |      | AAAF |      | AAAH |                    | HA |
      +----+      +------+      +------+                    +----+
           <---------------------      --------------------->
           STA, Session-Id = foo       STA, Session-Id = bar
            Figure 3: Session Termination and Session Identifiers

   Upon receipt of the HAR, the home agent first processes the Diameter
   message. The home agent processes the MIP-Reg-Request AVP and creates

   the Registration Reply, encapsulating it within the MIP-Reg-Reply
   AVP. In the creation of the Registration Reply the Home Agent must
   include the HA NAI and the AAAH NAI, which will be created from the
   Origin-Host AVP and Origin-Realm AVP of the HAR. If a home address is

   needed, the home agent MUST also assign one and include the address
   in both the Registration Reply and within the MIP-Mobile-Node-Address

   AVP.

   The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA
   returned to the AAAH.

   Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer
   (AMA) message, includes the Accounting-Multi-Session-Id that was
   present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-
   Address AVPs in the AMA message, enabling appropriate firewall
   controls for the penetration of tunneled traffic between the Home
   Agent and the Mobile Node.

1.3  Support for Mobile IP Handoffs

   Given the nature of Mobile IP, a mobile node MAY receive service from

   many foreign agents during a period of time. However, the home realm
   should not view these handoffs as different sessions, since this
   could affect billing systems. Furthermore, many foreign agents do not

   communicate, which makes it quite difficult for AAA information to be

   exchanged between these entities. Therefore, it MUST be assumed that
   a foreign agent is not aware that a registration request from a
   mobile node has been previously authorized.

   A handoff registration request from a mobile node will cause an AMR
   to be sent to its AAAF. The AMR will include a new session
   identifier, and MAY be sent to an AAAF in the visited network other
   than the AAAF, which received the previous AMR. However, with the
   usage of the AAA NAI, this AMR is guaranteed to be received by the
   AAAH to which the user is currently registered.

   Since the AAAH may be session-stateless, it is necessary for the
   resulting HAR received by the HA to be identified as a continuation
   of an existing session. If the HA receives an HAR for a mobile node,
   with a new session identifier, and the HA can guarantee that this
   request is to extend service for an existing service, then the HA
   MUST be able to modify its internal session state information to
   reflect the new session identifier.

   It is necessary for accounting records to have some commonality
   across handoffs in order for correlation to occur.  Therefore, the
   home agent MUST send the same Accounting-Multi-Session-Id AVP value
   in all HAAs for the mobile's session.  That is, the HA generates a
   unique Accounting-Multi-Session-Id when receiving an HAR for a new
   session, and returns this same value in every HAA for the session.
   This Accounting-Multi-Session-Id AVP will be returned to the foreign
   agent by the AAAH in the AMA. Both the foreign and home agents MUST
   include the Accounting-Multi-Session-Id in the accounting messages.

           ACR, Session-Id = foo         ACR, Session-Id = bar
       Accounting-Multi-Session-Id = a   Accounting-Multi-Session-Id = a

           --------------------->      <--------------------
      +----+      +------+      +------+                    +----+
      | FA |      | AAAF |      | AAAH |                    | HA |
      +----+      +------+      +------+                    +----+
           <---------------------      --------------------->
           ACA, Session-Id = foo       ACA, Session-Id = bar

            Figure 4: Accounting messages w/ Mobile IP Application

1.4  Allocation of Home Agent in Foreign Network

   The Diameter Mobile IP application allows a home agent to be
   allocated in a foreign network, as required in [MIPREQ, CDMA2000].
   When a foreign agent detects that the mobile node has a home agent
   address equal to 0.0.0.0 or 255.255.255.255 in the Registration
   Request message, it MUST add a MIP-Feature-Vector AVP with the Home-
   Agent- Requested flag set to one. If the home agent address is equal
   to 255.255.255.255, then the foreign agent also MUST set the Home-
   Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home

   agent address is set to 0.0.0.0, the foreign agent MUST set the Home-

   Address-Allocatable-Only-in-Home-Realm flag equal to zero.

   When the AAAF receives an AMR message with the Home-Agent-Requested
   flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm
   flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available

   flag in the MIP-Feature-Vector AVP to inform the AAAH that it is
   willing and able to assign a Home Agent for the Mobile Node. When
   doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP

   and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home-
   Agent-Host AVP contains the identity of the home agent that would be
   assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP
   contains the identity of the AAAF.

   In the event that the mobile node has been previously authorized by
   the AAAH and now needs to be re-authenticated, and requests to keep
   the assigned home agent in the foreign network, the mobile node MUST
   include the HA NAI and the AAAH NAI in the registration request to
   the FA. Upon receipt, the FA will create the AMR including the MIP-
   Home-Agent-Address AVP, the Destination-Host AVP based on the AAAH
   NAI and instead of the MIP-Candidate-Home-Agent-Host AVP include the
   MIP-Home-Agent-Host AVP based on the home agent NAI. If the AAAF
   authorizes the use of the requested home agent, the AAAF MUST set the

   Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.

   When the AAAH receives an AMR message, it first checks the
   authentication data supplied by the mobile node, according to the
   MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether
   to authorize the mobile node.  If the AMR indicates that the AAAF has

   offered to allocate a Home Agent for the mobile node, i.e. the
   Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or

   the AMR indicates that the AAAF has offered a previously allocated
   Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign-
   Network is set in the MIP-Feature-Vector AVP, then the AAAH must
   decide whether its local policy would allow the user to have a Home
   Agent in the foreign network or to keep the Home Agent in the foreign

   network. If so, and after checking authorization from the data in the

   AMR message, the AAAH sends the HAR message to Home Agent by
   including the Destination-Host AVP set to the value found in the
   AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if

   the HA has been previously allocated and authorized by the AAAH. If
   the HA has not been previously allocated by the foreign domain, the
   HAR sent by the AAAH does not contain the MIP-Home-Agent-Address.

   The HAR sent by the AAAH back to the foreign realm with the
   Destination-Host AVP set to the home agent's identity, may not
   necessarily be received by the same AAAF, which sent the AMR.
   Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA
   AVP from the AMR message to the HAR message. In cases when another
   AAAF receives the HAR, the new AAAF will use the MIP-Originating-
   Foreign-AAA AVP for policy decisions, such as determining if the FA-
   HA Key should be encrypted or not. If on the other hand, the AAAH
   local policy determines that the MN-HA Key and the MN-FA Key must be
   encrypted and no security association is known to the home agent, the

   AAAH SHOULD send the HAR to the originating AAAF by including the
   Destination-Host AVP set to the value found in the AMR's MIP-
   Originating-Foreign-AAA AVP and copy the MIP-Home-Agent-Host AVP or
   the MIP-Candidate-Home-Agent-Host AVP found in the AMR.

                           Visited                           Home
                            Realm                           Realm
                          +--------+ ------- AMR -------> +--------+
                          |  AAAF  | <------ HAR -------- |  AAAH  |
                          |        |                      |        |
                     +--->| server | ------- HAA -------> | server |
                     |    +--------+ <------ AMA -------- +--------+
                     |         ^  |
                     |         |  |
             HAR/HAA |     AMR |  | AMA
                     v         |  v
             +---------+       +---------+
             |   Home  |       | Foreign |
             |  Agent  |       |  Agent  |
             +---------+       +---------+
                                       ^
                  +--------+           |
                  | Mobile |<----------+
                  | Node   |  Mobile IP
                  +--------+
              Figure 5: Home Agent allocated in Visited Realm

   Upon receipt of a HAA from the Home Agent in the visited realm, the
   AAAF forwards the HAA to the AAAH in the home realm. The AMA is then
   constructed, and issued to the AAAF, and finally to the FA. If the
   Result-Code indicates success, the HAA and AMA MUST include the MIP-
   Home-Agent-Address and the MIP-Mobile-Node-Address AVPs.

   Mobile Node   Foreign Agent    Home Agent        AAAF         AAAH
   -----------   -------------  -------------   ----------    ----------

      <----Challenge----
    Reg-Req (Response)->
                         ------------AMR------------->
                                                     -----AMR---->
                                                     <----HAR-----
                                      <-----HAR------
                                      ------HAA------>
                                                     -----HAA---->
                                                     <----AMA-----
                       <-------------AMA------------
       <---Reg-Reply----
               Figure 6: Mobile IP/Diameter Message Exchange

   If the Mobile Node moves to another Foreign Network, it MAY either
   request to keep the same Home Agent within the old foreign network,
   or request to get a new one in the new foreign network. If the AAAH
   is willing to provide the requested service, the mobile node will
   have to be serviced by two AAAFs.

   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 the identity of the
   foreign and home agent to determine whether the user is in a third
   realm. If this is the case, the AAAH must check whether the mobile is

   still permitted to 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.
   Furthermore, the AAAH MUST always copy MIP-Originating-Foreign-AAA
   AVP from AMR and include it in the HAR when a third foreign domain is

   involved, since the AAAF will use the MIP-Originating-Foreign-AAA AVP

   for policy decisions, such as determining if the FA-HA Key should be
   encrypted or not. 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.

   If the AAAH local policy determines that the MN-HA Key must be
   encrypted and no security association is known to the home agent, the

   AAAH MUST send the HAR to the AAAF in foreign network 1, which
   originally assigned the HA in foreign network 1, by including its
   identity in the Destination-Host AVP.

   When the AAAF receives a HAA, the AAAF will forward the HAA back to
   the AAAH.  If successful, the HAA MUST include the MIP-Home-Agent-
   Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send

   back an AMA to the AAAF in foreign network 2.

   If the old Foreign Network does not permit the use of its Home Agent
   when the Mobile Node moves to a new foreign network, the AAAH or AAAF

   MUST return an AMA with the Result-Code AVP set to
   DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the
   Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile

   Node with an appropriate error. The Mobile Node MAY attempt to
   request that a new Home Agent and Address be allocated. When the AAAH

   transmits such an error, it MUST issue a Diameter Abort-Session-
   Request message to the Home Agent to enable it to release any
   resources.

....

2.1  AA-Mobile-Node-Request

....

   The foreign agent (or home agent in the case of a co-located
   mobile mode)uses information found in the Registration
   Request to construct the following AVPs that are to be
   included as part of the AMR:

....

          home agent NAI (MIP-Home-Agent-Host AVP)
          home AAA server NAI (Destination-Host AVP [DIAMBASE])

...

   If the mobile node includes the home agent NAI and the home AAA
   server NAI [AAANAI], the foreign agent MUST include the MIP-Home-
   Agent-Host AVP and the Destination-Host AVP in the AMR.

 Message Format

      <AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
                                   < Session-ID >
                                   { Auth-Application-Id }
                                   { User-Name }
                                   { Destination-Realm }
                                   { Origin-Host }
                                   { Origin-Realm }
                                   { MIP-Reg-Request }
                                   { MIP-MN-AAA-Auth }
                                   [ Destination-Host ]
                                   [ Origin-State-Id ]
                                   [ MIP-Mobile-Node-Address ]
                                   [ MIP-Home-Agent-Address ]
                                   [ MIP-Home-Agent-Host]
                                   [ MIP-Feature-Vector ]
                                   [ MIP-Originating-Foreign-AAA ]
                                   [ Authorization-Lifetime ]
                                   [ Auth-Session-State ]
                                   [ MIP-FA-Challenge ]
                                   [ MIP-Candidate-Home-Agent-Host ]
                                 * [ AVP ]
                                 * [ Proxy-Info ]
                                 * [ Route-Record ]

....

4.12 MIP-Home-Agent-Host AVP

   The MIP-Home-Agent-Host AVP (AVP Code TBD) if of type Grouped, and
   contains the identity of the assigned Home Agent. If present in
   the AMR, the AAAH MUST copy the MIP-Home-Agent-Host AVP into the HAR.

      MIP-Home-Agent-Host ::= < AVP Header: TBD >
                               { Destination-Realm }
                               { Destination-Host }
                             * [ AVP ]

....

5.3  Distributing the Mobile-Home Session Key

....

   If, on the other hand, the home agent is to be allocated in the
   visited realm, the AAAH transmits the HAR to the foreign home agent,
   where, prior to delivery to the home agent, it is perused by the AAAF

   hosting the home agent. If the session key needs to be encrypted the
   AAAH will encrypt the MIP-HA-to-MN Key AVP in a CMS-Encrypted-Data
   AVP using the security association with the home agent or with the
   AAAF associated with the home agent. If no security association is
   known the home agent, the AAAH will check if a security association
   can be established using DSA messages defined in the CMS application
   [CMS] with the originating host found in the MIP-Originating-Foreign-

   AAA AVP and if the DSA establishment is successful, the AAAH will
   encrypt the MIP-HA-to-MN Key AVP with the established security
   association. On the other hand, if no security association exists and

   the DSA establishment fails, the AAAH MUST return a Result-Code AVP
   with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.

....

11.1 Normative

....

[AAANAI]       F.Johansson, T.Johansson, "AAA NAI for Mobile IPv4 Exten

               sion", draft-johansson-mip-aaa-nai-01.txt, IETF work in
               progress, September 2002.

[MIPCHAL]      C. Perkins, P. Calhoun, "Mobile IP Challenge/Response
               Extensions". RFC 3012. November 2000.

....

11.2 Informative

....

[CMS]          P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security

               Application", draft-ietf-aaa-diameter-cms-sec-05.txt,
               IETF work in progress, November 2001.

....

---

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 10 Apr 2002 10:10:22 -0400

Hi Tony,

> From: [email-masked] on behalf of Tony Johansson
> [[email-masked]]
> Sent: Tuesday, April 09, 2002 3:53 PM
> To: [email-masked]
> Subject: [AAA-WG]: updated text proposal to issue #299 and #301
>
> All,
>

OK. Here's some comments to appreciate :)

>  authorization from the AAAH expires [MIPCHAL]. The expiration time of the

It seems there will never be a security association between the AAAH and
the foreign HA.  Because when the AAAH wants to secure an MN-XX
session key, the AAAH sets up an SA with the AAAF (according to the
previous sentence), not the HA.  So if this is true, you can strike
the phrase "and no security association is known to the home agent"
from the previous sentence.

What do you think of the following thought: In the interest of reducing
the number of round-trips, the AAAH never bothers to try to set up a DSA
with an FA or HA.  That is, the FA or HA isn't required to support CMS,
while the AAAF is required to support CMS, so why waste a round trip on a
likely DSA-rejection by the mobility agent?

And so the rule for an HAR, when there is a foreign HA, is:
- If the AAAH is not encrypting session keys, then the Destination-Host of
the AAAH's HAR is the HA.
- If the AAAH is encrypting session keys, then the Destination-Host of the
AAAH's HAR is the AAAF hosting the HA, and the HAR carries an AVP with the
HA's identity (either the MIP-Candidate-Home-Agent-Host AVP or the
MIP-Home-Agent-Host AVP).

If the above makes sense, then the previous paragraph of proposed text
can be replaced by the following:

  "If the AAAH's local policy determines that the MN-HA Key and/or the
  MN-FA Key must be encrypted, the AAAH sends the HAR to the originating
  AAAF by including the Destination-Host AVP set to the value found in
  the AMR's MIP-Originating-Foreign-AAA AVP, and copying the
  MIP-Home-Agent-Host AVP or the MIP-Candidate-Home-Agent-Host AVP found
  in the AMR.  If necessary, the AAAH first sets up a DSA with the
  originating AAAF.

  "If the AAAH's local policy determines that no keys need to be
  encrypted, then the HAR is sent by the AAAH back to the foreign realm
  with the Destination-Host AVP set to the home agent's identity.  This
  HAR may not necessarily be received by the same AAAF which sent the
  AMR.  Therefore the AAAH MUST always copy the
  MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR
  message.  In cases when another AAAF receives the HAR, the new AAAF
  will use the MIP-Originating-Foreign-AAA AVP for policy decisions,
  such as determining if the FA-HA Key should be encrypted or not."

>                    |    +--------+ <------ AMA -------- +--------+

Here is where I am still a bit confused.

If the AAAH is session-stateful, then the AAAH can retrieve the
destination AAAF's (in the first visited network) identity & realm
from his state information, and send the HAR with a Destination-Host
AVP with a value set to this destination AAAF's identity.

But if the AAAH is not session-stateful, then how does the AAAH know
the destination AAAF's identity?  I asked this question is an earlier
email (04-April), and you commented that "the AAAH can be session
stateless using some back-ended mechanism, which is beyond the scope
of this protocol, to retrieve necessary info."  But I didn't understand
your comment; can you flesh it out a bit more for me?

I suppose that the AAAH could be session-stateless, but maintain a
cache of his existing SAs with AAAFs, and include the { foreign HA
identity, hosting AAAF identity } pairs as part of this cache.  If so,
then the AAAH would likely know the destination AAAF's identity,
because the AAAH would *likely* have set up a DSA with this AAAF back
when the MN was in the first-visited foreign network, so the AAAH
would likely find a { foreign HA identity, hosting AAAF identity }
match in his cache for the targeted HA.

>  with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.

If you go with the idea of reducing round-trips by not attempting to
set up a DSA with the FA, then the above paragraph should be slightly
revised.

>              progress, September 2002.

Replace "September 2002" by "March 2002" (?).

>              IETF work in progress, November 2001.

Replace "November 2001" by "April 2002" (?).

---

From: Johan Johansson <[email-masked]>
Date: Wed, 10 Apr 2002 17:37:55 +0000

>match in his cache for the targeted HA.
I still haven't received any answer to why we don't pass around the 
identity of the AAAF if that is what we are after in the first place 
instead of the AAAH. The AAAF can be retrieved from the appropriate AVP 
and placed in a GNAI extension instead of the AAAH's identity. If this 
is echoed back each time the problem is solved, right?`Since there is no 
real reason for the AAAH to stay the same across handovers we end up 
doing less work in total by removing the use of the AAAH GNAI.

j

---

From: Tony Johansson <[email-masked]>
Date: Wed, 10 Apr 2002 19:51:54 -0700

Hi Bob,

Thanks a lot for your comments. Please find mine inline...

/Tony

> likely DSA-rejection by the mobility agent?

Oh, I see the misunderstanding. I did mean to say the if you don't have an SA to
the HA you should try to establish a DSA and most likely be rejected and waste
an extra round trip. I only meant to say that if the AAAH don't have a pre
configured SA with the HA then it should be done as you state below.

>   such as determining if the FA-HA Key should be encrypted or not."

So how about this:

If the AAAH's local policy determines that the MN-HA Key and/or the MN-FA Key
must be encrypted and no pre-configured security association exists between the
AAAH and the home agent, the AAAH sends the HAR to the originating AAAF. In this
HAR the Destination-Host AVP is set to the value found in the AMR's
MIP-Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the
MIP-Candidate-Home-Agent-Host AVP found in the AMR are copied into the HAR.  If
necessary, the AAAH first sets up a DSA with the originating AAAF. If no
pre-configured security association exists between the AAAH and the home agent,
the AAAH should not attempt to set up a DSA with the home agent, since mobility
agents may not support CSM strong security.

If the AAAH's local policy determines that no keys need to be encrypted or the
keys need to be encrypted and a pre-configured security association exists
between the AAAH and the home agent, the HAR is sent by the AAAH back to the
foreign realm with the Destination-Host AVP set to the home agent's identity.
This HAR may not necessarily be received by the same AAAF which sent the AMR.
Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA AVP from the
AMR message to the HAR message.  In cases when another AAAF receives the HAR,
this new AAAF will use the  MIP-Originating-Foreign-AAA AVP for policy
decisions, such as determining if the FA-HA Key should be encrypted or not.

Does it make sense?

> your comment; can you flesh it out a bit more for me?

I'm sorry if I was unclear . I meant  the same as you state below without be to
detailed :). Thus, if AAAH is session-stateless it could either cache the SAs as
you describe below or the AAAH could use a "back-ended mechanism" like a
database. However, I believe this is implementation specific and I don't think
we have to specify a solution in the spec for this.

> set up a DSA with the FA, then the above paragraph should be slightly

So if my above changes is ok, how about this:

If, on the other hand, the home agent is to be allocated in the visited realm,
the AAAH transmits the HAR to the foreign home agent, where, prior to delivery
to the home agent, it is perused by the AAAF hosting the home agent. If the
session key needs to be encrypted the AAAH will encrypt the MIP-HA-to-MN Key AVP
and the MIP-FA-to-MN AVP in a CMS-Encrypted-Data AVP using the security
association with the home agent or with the AAAF associated with the home agent.
If no security association exists either between the AAAH and the home agent or
between the AAAH and the AAAF associated with the home agent, the AAAH will
check if a security association can be established, using DSA messages defined
in the CMS application [CMS], with the AAAF associated with the home agent and
if the DSA establishment is successful, the AAAH will encrypt the MIP-HA-to-MN
Key AVP and MIP-FA-to-MN AVP with the established security association. On the
other hand, if no security association exists and the DSA establishment fails,
the AAAH MUST return a Result-Code AVP with
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.

> Replace "September 2002" by "March 2002" (?).

Check.

> Replace "November 2001" by "April 2002" (?).

Check.

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 11 Apr 2002 11:34:57 -0400

Hi Tony,

> [...]

Yes, what you say makes sense.

The things that are still on my mind are:

1. Johan's comment (paraphrased as I understand it) that what is really
needed for issue#301 is for the AAAH to know the identity of the
destination AAAF hosting the foreign HA.  Although by requiring a fixed
AAAH over the life of a MN's session, the AAAH can (with some effort) come
up with the AAAF's identity, why not instead have the MN cache the
destination AAAF's identity instead of the AAAH's identity? This
eliminates the seemingly unnecessary restriction, and single point of
failure, of a fixed AAAH.  

On the other hand, a single AAAH does have some modest virtues:
[a] Once an SA is set up between the AAAH and the HA (or HA's AAAF), new
SAs needn't be set up due to an AAAH change; [b] Since the AAAH doesn't
change, the HA doesn't have to clear the session with the old AAAH when
a new AAAH comes on board; [c] does session/policy/resource management 
become easier with a fixed AAAH?

2. As a side issue to the problem of the AAAH wanting to set up an SA
with the destination AAAF but not knowing the AAAF's identity, this may
not be such a problem: I've just been told that a DSAR may be sent with
a Destination-Realm but without a Destination-Host, when the
Destination-Host isn't known.  When the DSAA comes back, the node that
sent the DSAR then learns the identity of the remote AAA server.

3. This is the first time there is text referring to the idea of a
"pre-configured" SA between the foreign HA and the AAAH.  I want to ask 
a couple questions about that, in a separate email.

4. The text makes references to CMS and DSAs.  With CMS being held back,
I don't know how Mobile IP security topics should be stated.

Bob K.

---

From: Tony Johansson <[email-masked]>
Date: Thu, 11 Apr 2002 12:07:05 -0700

Hi Bob,

> become easier with a fixed AAAH?

I definitely agree with what you state above and yes a believe that
session/policy/resource management
become easier with a fixed AAAH (especially since multiple AAAH's in the same
domain may not be synchronized).

> a couple questions about that, in a separate email.

Please forget the "pre-configured" stuff . I wasn't thinking when I sent out
the text yesterday :( Thank for the sanity check.

So how about the following text instead in section 1.4:

"If the AAAH's local policy determines that the MN-HA Key and/or the MN-FA Key
must be encrypted, the AAAH sends the HAR to the originating AAAF. In this HAR
the Destination-Host AVP is set to the value found in the AMR's
MIP-Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the
MIP-Candidate-Home-Agent-Host AVP found in the AMR are copied into the HAR.
If no security association exists between the AAAH and the originating AAAF,
the AAAH SHOULD make use of the CMS Strong Security Application [CMS] to
establish this association.

If the AAAH's local policy determines that no keys need to be encrypted, the
HAR is sent by the AAAH back to the foreign realm with the Destination-Host
AVP set to the home agent's identity. This HAR may not necessarily be received
by the same AAAF, which sent the AMR. Therefore the AAAH MUST always copy the
MIP-Originating-Foreign-AAA AVP from the AMR message to the HAR message.  In
cases when another AAAF receives the HAR, this new AAAF will use the
MIP-Originating-Foreign-AAA AVP for policy decisions, such as determining if
the FA-HA Key should be encrypted or not.

and in section 5.3:

"If, on the other hand, the home agent is to be allocated in the visited
realm, the AAAH transmits the HAR to the foreign home agent, where, prior to
delivery to the home agent, it is perused by the AAAF hosting the home agent.
If the session key needs to be encrypted the AAAH SHOULD encrypt the
MIP-HA-to-MN Key AVP and the MIP-FA-to-MN AVP in a CMS-Encrypted-Data AVP
using the security association with the AAAF associated with the home agent.
If no security association exists between the AAAH and the AAAF associated
with the home agent, the AAAH SHOULD check if a security association can be
established, using the CMS application [CMS]. On the other hand, if no
security association exists and cannot be created, the AAAH MUST return a
Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE."

> I don't know how Mobile IP security topics should be stated.

I hope text like the above with [CMS] referenced as informative will be good
enough. One of the conlusions from that meeting IESG security meeting
yesterday was that they will look at the possibilities to get one of the
security experts to help us to provide additional advice regarding this issue.

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 11 Apr 2002 16:25:24 -0400

Hi Tony,

Looks better all the time.  I don't think I have any more to add
right now, maybe something will come to me.

Your modified text looks fine.

Bob K.

> -----Original Message-----
> From: Tony Johansson [mailto:[email-masked]]
> Sent: Thursday, April 11, 2002 3:07 PM
> To: Bob Kopacz
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: updated text proposal to issue #299 and #301
>
> Hi Bob,
>
> Bob Kopacz wrote:
> >

---

From: Johan Johansson <[email-masked]>
Date: Mon, 15 Apr 2002 11:33:23 +0200

>failure, of a fixed AAAH.
Yes, this was my still unanswered question.

>become easier with a fixed AAAH?
I agree with all of the above but I strongly disagree that it is 
mandatory. They should all be perfectly allowable optimizations but 
mandating them is unnecessary, removes an interesting degree of freedom 
and most importantly forces external mechanisms to be used where none is 
needed.

j

---

From: "Bob Kopacz" <[email-masked]>
Date: Fri, 19 Apr 2002 14:39:29 -0400

Hi Johan,

> From: Johan Johansson [[email-masked]]
> Sent: Monday, April 15, 2002 5:33 AM
> To: Bob Kopacz
> Cc: Tony Johansson; [email-masked]

It seems to me that if the HA's AAAF's Identity was added as another
subtype for the AAA NAI extension, and if this information was returned
to the MN instead of (or in addition to) the AAAH's identity, then this
would meet the needs of issues #299 and #301.

Matter of fact, feeding the Destination-AAAF's identity to the MN might
be a good idea, anyway, as this would allow the session to continue if
the AAAH became unavailable.

> and most importantly forces external mechanisms to be used where none is 

I don't disagree with you here either.  It is a judgement call.

> j

Take care,
Bob K.

---

From: Tony Johansson <[email-masked]>
Date: Mon, 22 Apr 2002 15:12:25 -0700

Hi Bob and Johan,

> would meet the needs of issues #299 and #301.

So are you saying that we don't meet the needs for issue #299 and #301 without
the AAAF's Identity?!

> the AAAH became unavailable.

I really don't see why this would make it any easier?!.

Is it that bad for the MN to re- authenticate its self  if the AAAH becomes
unavailable? Thus,  the AAAF notice that the AAAH is unavailable (either directly
by itself or by a returned result code from an Diameter agent on the path), the
AAAF will return an error back to the MN via the FA and the MN will register
again without the AAAH NAI. How can this be better handled by always forwarding
the AMR to the same AAAF?!

Furthermore, what should a FA do when receiving a AAAF Identity from a foreign
network in AAA NAI from the MN? Thus, when the a MN moves from one network to a
new network the MN would have the AAAF stored from the previous network. So
should the FA issue the AMR to foreign AAAF ?!?!

> I don't disagree with you here either.  It is a judgement call

But nothing is really mandatory. Please, help me to understand where you see the
real problem here.

Regards,

/Tony

---

From: "Bob Kopacz" <[email-masked]>
Date: Mon, 22 Apr 2002 22:39:11 -0400

Hi Tony,

In responding to Johan, I seem to have created more confusion.

> From: "Tony Johansson" <[email-masked]>
> To: "Bob Kopacz" <[email-masked]>
> Cc: "Johan Johansson" <[email-masked]>; <[email-masked]>
> Date: Monday, April 22, 2002 6:16 PM
> 
> Hi Bob and Johan,
> 
> Bob Kopacz wrote:
> 
> > Hi Johan,
> >

No, not at all.  What I wasn't saying very well was that, it seems to
me, the needs of issues #299 and #301 can be met by having
the MN cache either:
[a] The HA's identity and the AAAH's identity, or
[b] The HA's identity and the destination AAAF's identity (i.e. the AAAF
hosting the HA).

We know option [a] above will work; that is what you sent out as proposed
text.  

It seems that option [b] would also work.  It satifies issue#299
(handoffs) because the HA's identity is provided, so whatever AAAH
handles the AMR, this AAAH can route the HAR to the HA.
It satisfies issue#301 (securing session keys) because, whatever AAAH
receives the AMR, this AAAH knows the identity of the AAAF hosting the 
HA, in case the AAAH wants to set up a DSA with the destination-AAAF
for the purpose of securing session keys.

> I really don't see why this would make it any easier?!.

I meant that, should the original AAAH become unavailable, a new AAAH
could know the identity of the Destination-AAAF upon receiving the
AMR, in case the new AAAH wanted to set up a DSA with the
Destination-AAAF for the purpose of security session keys.

> should the FA issue the AMR to foreign AAAF ?!?!

Goodness, no.

> But nothing is really mandatory. Please, help me to understand where you see the

I don't have a problem with your proposed text at all, Tony.  I was
saying that option [b] also appears to work.  Option [a] has some pros
and cons.  It seemed like Johan was saying that option [b] also works, 
and I was responding that it seems to me that is true.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 23 Apr 2002 08:32:33 +0200

All,

So if I have understood it correctly, the proposal is that if you receive
the AAAF identity in the AMR you can set up an end-to-end security
association with the AAAF in order to distribute keys?

So what if we add the AAAF identity to the aaa-nai draft and state that
every time it is received by the HA it has to be sent in the registration
reply if sent via the AAA infrastructure. Furthermore we say that when a MN
receives any of the AAA NAI subtypes it must include it in future
registration request where the AAA may be invoked.

We then make it a SHOULD for the FA to include the AAAH identity in the AMR
and a MUST to include the other subtypes.

Now it's up to the FA to decide if it would like to take the "optimised" way
and send the AMR to the same AAAH as before (and later do a failover if it's
down) or if it would like to just send it to the AAAH realm. Either way, the
AAAH can reach the HA and if it's a new AAAH it can still set up an
end-to-end security association with the AAAF that handles the HA if
allocated in another foreign network.

Have I understood everything correctly?

/Fredrik

>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Bob Kopacz
>Sent: den 23 april 2002 04:39
>To: Tony Johansson
>Cc: Johan Johansson; [email-masked]

---

From: Johan Johansson <[email-masked]>
Date: Tue, 23 Apr 2002 16:19:37 +0200

Hi everybody. Comments are embedded at random intervals.

>Have I understood everything correctly?

No. It is infeasible to have the foreign network decide things which 
concern the home network. If we however demand that the MN always echoes 
back whatever GNAIs that it receives and that the FA converts all that 
it receives to Diameter-speak the HA can then decide the policy by 
choosing which extensions that it includes in the MIP-Reg-Replys that it 
sends.

This seems to me to allow both ways of doing things while complicating 
neither. I am probably wrong though, so please point out my mistake.

>>>So are you saying that we don't meet the needs for issue #299
>>>
>>and #301 without
>>
>>>the AAAF's Identity?!
>>>

[a] however *requires* a cache of HA-to-AAAF mappings to be maintained 
on the AAAH and if the AAAH fails there is no way another AAAH can 
figure out which AAAF controls the HA. Diameter failover as specified in 
the base will *not* work in this case since the information is quite 
simply lost. Unless you maintain the cache in a manner that makes it 
available to all your AAAHs of course. I personally think this is 
unattractive when there is such a simple alternative, but the procedures 
outlined above would allow it.

>>>Is it that bad for the MN to re- authenticate its self  if the
>>>
>>AAAH becomes
>>
>>>unavailable? Thus,  the AAAF notice that the AAAH is unavailable
>>>
>>(either directly
>>
>>>by itself or by a returned result code from an Diameter agent on
>>>
>>the path), the
>>
>>>AAAF will return an error back to the MN via the FA and the MN
>>>
>>will register
>>
>>>again without the AAAH NAI. How can this be better handled by
>>>
>>always forwarding
>>

I think what Bob means is that unless you know the identity of the old 
AAAF you can not keep your HA and therefore it is game over for your 
session regardless of whether the MN reauthenticates itself or not. 
Please note that we are talking about the AAAF controlling the HA and 
not the one controlling the FA.

j

---

From: Tony Johansson <[email-masked]>
Date: Tue, 23 Apr 2002 13:41:37 -0700

Hi All,

Right now we have a proposal, based on the HA's NAI and the AAAH's NAI,  which
folks from both MIP-wg and AAA-wg seems to agree on. Sure,  the proposad solution
may be less optimal in some cases, however, the other proposal is also less
optimal in other cases. Regardless of which AAA NAI you decide to specify, if it
goes down you will have a problem. For example, adding the AAAF's NAI is also
possible, however this is an attempt to optimize scenarios that uses CMS
encryption - which may not even be used - and also what happens in the case the
AAAF in unavailable? Thus, the AAAH receives an AMR with an included AAAF NAI and
if the AAAF is down -  in what way would this then be better solved then in the
case that AAAH is down....

So, the point I'm trying to make here is that we have a solution (based on the
AAAH NAI and the HA NAI), which I believe is good enough and that we have
consensus for. If you really disagree with me here, please provide text to the
spec that really shows why the AAAF is necessary (and  not solely an
optimization)  and worth to delay the spec even more.

Regards,

/Tony

---

From: Johan Johansson <[email-masked]>
Date: Tue, 23 Apr 2002 23:59:06 +0200

I'll compose a fuller response tomorrow. For now I just want to answer 
one thing.

>case that AAAH is down....
In your suggestion the session ends if the AAAH *or* the AAAF goes down. 
My suggestion has one point of failure less.

j

---

From: "Fredrik Johansson" <[email-masked]>
Date: Wed, 24 Apr 2002 09:19:05 +0200

Johan,

>In your suggestion the session ends if the AAAH *or* the AAAF goes down.

NO, the failover mechanism in diameter-base still makes it possible to
change to another AAAH if the original one is down. The AMR still contains
the HA's identity so it can be reached, what it may not know is the identity
of the AAAF for a possible CVS transaction, but since we're not sure
what/how CMS will work, I would prefer that we go with a solution that we
know works, maybe not optimized in every sence, but it's at least simple.

Others?

/Fredrik

---

From: Johan Johansson <[email-masked]>
Date: Wed, 24 Apr 2002 09:56:55 +0200

>know works, maybe not optimized in every sence, but it's at least simple.
I don't know if I qualify as others, but...

The reason I am involving CMS is that it is what issue #301 is about. 
Since it's about securing AAAH-generated keys I don't really see how it 
is possible to ignore CMS. I also fail to see the complication in "if 
you get a GNAI extension return it/forward it" compared to "maintain a 
cache of HA-to-AAAF mappings". It's also hard for me to understand how 
it might not work at least as well since it includes the other suggested 
solution as a special case.

I have been arguing my case for several weeks now and only rarely 
received comments that discuss the technical nature of my proposal or 
that answer my critique of the other suggested solution. This is 
disappointing.

I will try to deliver an alternative text during the day so that it at 
least exists.

j

---

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 24 Apr 2002 12:56:41 -0400

Hi Johan and Fredrik and Tony,

I'm on vacation so haven't been keeping up on email very well.

> From: "Fredrik Johansson" <[email-masked]>
> To: "Johan Johansson" <[email-masked]>; 
>     "Tony Johansson" <[email-masked]>
> Cc: "Bob Kopacz" <[email-masked]>; <[email-masked]>
> Subject: RE: [AAA-WG]: updated text proposal to issue #299 and #301
> Date: Wednesday, April 24, 2002 3:19 AM
> 
> Johan,
> 
> >

I agree with this.  Here's my thinking:

With Tony's original proposal (where the MN caches HA-identity +
AAAH-identity), or with Johan's alternative (where the MN caches
HA-identity + Dest-AAAF-identity), I now don't think the session fails
if either the original AAAH goes down or the original destination-AAAF
goes down.

The problem of a (new) AAAH wanting to set up an SA with the
destination AAAF, but not knowing the AAAF's identity, may not be such
a problem: I've just been told that a DSAR may be sent with a
Destination-Realm but without a Destination-Host, when the
Destination-Host isn't known. When the DSAA comes back, the node that
sent the DSAR then learns the identity of the remote AAA server.

If this is true, then the Destination-AAAF's identity may be an
optimization more than a requirement.

Then, under Tony's original proposal, I think things would work like
this:

1. When session is first set up, HA returns HA-NAI and AAAH-NAI to MN,
in the Reg Reply.

2. MN caches this info.

3. When MN is handed off to new FA (possibly in new network), MN passes
HA-NAI and AAAH-NAI in Reg Req.

4. FA sends AMR to original AAAH.  Maybe has to fail over to new AAAH,
if original AAAH is down.

5. Whether original-AAAH or new-AAAH handles the AMR, this AAAH has
the HA's identity, so can successfully route the HAR.

6a. If new-AAAH needs to set up a DSA to secure HA-MN key, new-AAAH
can send DSAR without a Destination-Host.  Some AAAF in HA's network
will receive the DSAR, and new-AAAH will discover AAAF's identity
when the DSAA comes back.

6b. If original-AAAH wants to secure the HA-MN key, the original-AAAH
can do [6a] above.  Or, since the original-AAAH probably already has a
DSA with the destination-AAAF, the original-AAAH can retrieve the
destination-AAAF's identity from his cached DSA information.

7. One could add the Dest-AAAF-NAI as a new subtype to the AAA-NAI
extension, and the HA could pass this to the MN.  The Dest-AAAF's
identity can then be bandied about in the AMR.  This Dest-AAAF could
be treated like a "preferred" AAAF for a DSA by a new-AAAH.  But this
looks like an optimization.

8. I like the idea of *trying* to stick with one AAAH for a mobile
session, for reasons stated in previous emails: [a] Once an SA is set
up between the AAAH and the HA (or HA's AAAF), new SAs needn't be set
up due to an arbitrary AAAH change; [b] Since the AAAH doesn't change,
the HA doesn't have to clear the session with the old AAAH when a new
AAAH comes on board; [c] Session/policy/resource management is
easier with a fixed AAAH, since multiple AAAHs in the same domain may
not be synchronized.

Is this how others see Tony's original proposal working?

If so, then we have 
a. the virtues of a single AAAH without the requirement of a fixed
   AAAH, 
b. the AAAH doesn't become a single point of failure,
c. a new AAAH can still secure session keys without foreknowledge
of the destination-AAAF.

I have no resistance to adding a Dest-AAAF-NAI, if that is useful.

Bob K.