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

From: Tony Johansson <[email-masked]>
Date: Tue, 02 Apr 2002 19:23:35 -0800

All,

Here are some clarifications/changes to some editorial mistakes in the
proposed text that I sent out yesterday regarding issue#299 and #301.
Please find the clarifications/changes made embedded...

/Tony

Tony Johansson wrote:

> I'm sorry if you receive this twice....
>
> /Tony
>
> -------- Original Message --------
> Subject: Issue #299 and #301
     Date: Mon, 01 Apr 2002 11:53:07 -0800
     From: Tony Johansson <[email-masked]>
       To: [email-masked]
>
> All,
>
> I have worked on new  proposed text for issue 299 and 301, see below,
> based on the solution we agree upon at the IETF 53. Part of this
> solution is also the draft-johansson-mip-aaa-nai-00.txt, which defines
> the needed AAAH NAI and the HA NAI, please see
> http://www.ietf.org/internet-drafts/draft-johansson-mip-aaa-nai-00.txt.
> The draft have been submitted to the mobileip wg and will go to wg
> final call if no major comments/issues are found on the mobileip wg
> list.
>
> I hope this solves the issue 299 and 301, however I need help to
> understand how I should deal the newly submitted issue #321 regarding
> CMS. Is it good enough to just move the CMS ref to informative?
>
> Comments please.
>
> /Tony
>
>
>
>
>
> Added to to section 1.0:
>
> "1.0  Introduction
>
>  ...
>
>    Furthermore, the nature of mobile IP also means that the mobile
> node
>    will do handoffs between different foreign agents and to guarantee
>    that a registered user always ends up in the same initial AAAH the
>    Mobile Node MUST always include the home NAI and the AAAH NAI
>    [AAANAI].

change to:

   Furthermore, the nature of mobile IP also means that the mobile node
   will do handoffs between different foreign agents and to guarantee
   that a registered user always ends up in the same initial AAAH the
   Mobile Node MUST always include the AAAH NAI [AAANAI]. Finally, to
   assist the AAAH in routing the messages to a mobile node's home agent

   the mobile node MUST always include the HA NAI [AAANAI].

>
>
>  ... "
>
> I've made changes here and there in section 1.2, 1.3 and 1.4, so here
> is the whole text...
>
> " 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. 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
> andauthorized,
>    MUST always include the assigned home agent in the HA-NAI
>    and the authorizing Home AAA server in the AAAH-NAI in the
>    registration request message [AAANAI] sent to the FA, every time
> the
>    Mobile Node needs to re-authenticating. So, in the event that the
> AMR
>    generated by the FA is for a session that has 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 the identity of the assigned HA found in the HA-NAI.

change to:
   A mobile node, which has been previously authenticated and
   authorized, MUST always include the assigned home agent in the HA-NAI

   and the authorizing Home AAA server in the AAAH-NAI in the
   registration request message [AAANAI] sent to the FA, every time the
   Mobile Node needs to be re-authenticated. So, in the event that the
   AMR generated by the FA is for a session that has 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 the identity 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 the
> MIP-
>    Home-Agent-Host AVP, the MIP-Originating-Foreign-AAA AVP and the
>    Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP.
> If
>    home agent is located in the foreign realm, then 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
>
>    Originating-Host AVP and Originating-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.
>
>    The AAAF is responsible for ensuring that the AMA message is
> properly
>    forwarded to the correct foreign agent.
>
>
> 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.
>
>    The first registration request from a mobile node will therefore
>    cause an AMR to be sent to its AAAF. The AMR will include a new
>    session identifier, and MAY even be sent to a different AAAF in the
>
>    visited network.

change to:
   The first registration request from a mobile node will therefore
   cause an AMR to be sent to its AAAF. The AMR will include a new
   session identifier, and MAY even be sent to a different AAAF in the
   visited network. 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 in 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
> byincluding
>    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 agents 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 interact with two AAAFs.

Change to:
   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. "
>
> Added to section 2.1  AA-Mobile-Node-Request:
>
> "2.1  AA-Mobile-Node-Request
>
>    The AA-Mobile-Node-Request (AMR), indicated by the Command-Code
> field
>    set to 260 and the 'R' bit set in the Command Flags field, is sent
> by
>    an attendant, acting as a Diameter client, to a server in order to
>    request the authentication and authorization of a Mobile Node.  The
>
>    Foreign Agent (or Home Agent in the case of a co-located Mobile
> Node)
>    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.
>
>   ..."
>
> Added to section 4.0:
>
> "
>    MIP-Home-Agent  348  4.12     Grouped    | M  |  P  |    |  V  | Y
> |
>    Host                                     |    |     |    |     |
> | "
>
>
>
> Added a new grouped AVP:
>
> "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: 348 >
>                                { Destination-Realm }
>                                { Destination-Host }
>                              * [ AVP ] "
>
> Added new text to section 5.3 :
>
> " 5.3  Distributing the Mobile-Home Session Key
>
>   ...
>
>    If the home agent is in the home realm, then AAAH can directly
> encode
>    the Mobile-Home session key into a MIP-HA-to-MN-Key AVP and include
>
>    that AVP in the HAR message for delivery to the home agent.
>
>    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.
>
>   ... "
>
>
>
>
>
>

---

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 3 Apr 2002 12:16:33 -0500

Hi Tony,

I'm looking over your proposed solution to issues #299 and #301.

Issue#301 has to do with how to distribute AAAH-generated session keys
securely, and up to now this has relied on CMS.  As does the resolved
issue#266, on securely distributing an AAAF-generated FA-HA-Key, when
there is a foreign HA.

But I'm confused about CMS.  That is, my understanding is that CMS is
being held back, and that the Mobile IPv4 draft, and others, will move
ahead without CMS.

Here's some questions, so I can give you better feedback:

Q1: Is it true that terms like "CMS" and "DSA" and "end-to-end security"
shouldn't be part of the current Mobile IPv4 draft?

Q2: If so, then is issue#301 being shelved for the time being?  And the
Mobile IPv4 draft will say something like "the only currently-available
security for session keys is TLS".

Q3: When CMS does come out, is the game plan to then update and release
a new Mobile IPv4 RFC, with CMS security for session keys, and solutions
for issues#266 and #301?  Or is the plan that the CMS RFC will include
information about how Mobile IPv4 can use CMS to hide session keys, so
that the Mobile IPv4 RFC won't require updating?

Thanks,
Bob K.

---

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 3 Apr 2002 13:48:10 -0500

Hi Tony,

I'm confused on a few points, so I hope you'll bear with me.

Most of my comments are focused on issue#299: handling handoffs.

I'll send separate comments more focused on issue#301: securing
session keys.

I've tagged my specific suggestions with "-->".

Bob K.

> The draft have been submitted to the mobileip wg and will go to wg final
> call if no major comments/issues are found on the mobileip wg list.
> 

--> How about changing the tail of the first sentence to "the Mobile
Node, upon changing his point of attachment for a given session, MUST
include the home NAI and the AAAH NAI [AAANAI]".  Just to make it clear
that the AAAH NAI information isn't required in the initial Registration
Request of a session.

--> How about changing the second sentence to: "Finally, to assist the
AAAH in routing the messages to a mobile node's home agent the mobile
node MUST include the HA NAI [AAANAI], if including an HA IP address
other than 0.0.0.0 or 255.255.255.255"

--> The plan, then, is that exactly one AAAH will be employed for the
life of a MN's session.  And if that AAAH becomes unavailable, it is
"game over" for the MN's session, even if other AAAHs are available?  If
this is true, should this be explicitly stated?

>  ... "
> 
> I've made changes here and there in section 1.2, 1.3 and 1.4, so here is
> the whole text...
> 
> Mobile-Node-Request (AMR) message, which includes the AVPs defined in
> section 2.1.  The Home Address, Home Agent, Mobile Node NAI and other
> forwarded to the local Diameter server, known as the AAA-Foreign, or
> AAAF.
> 
>                Visited Realm                    Home Realm
>                  +--------+                     +--------+
> [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
> authorization from the AAAH expires. 

The last sentence, beginning "Note that...", either needs more
clarification, or maybe should be striken.  

For example, how (what is the algorithm by which) does the FA determine
whether or not to invoke AAA services?

Also, for example, doesn't this sentence conflict with the last sentence
of the first paragraph of section 1.3, which says that "Therefore, it
MUST be assumed that a foreign agent is not aware that a registration
request from a mobile node has been previously authorized."

Also, wouldn't there be other reasons for the FA to invoke AAA services,
beyond "*only* when the prior authorization from the AAAH expires".
E.g, the authorization might not have expired, but maybe the new FA
needs an FA-xx key.  Or the key lifetime is approaching expiration.

--> I would suggest either striking the "Note that..." sentence
altogether, or trimming it to "It is not required that the foreign agent
invoke AAA services every time a Registration Request is received from
the mobile".

>                                      The expiration time of the
> authorization is communicated through the Authorization-Lifetime AVP
> 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
> 
> extension to enable authorization by AAAH. If the authentication data
> A mobile node, which has been previously authenticated andauthorized,
> Mobile Node needs to re-authenticating. So, in the event that the AMR

--> Replace the above paragraph (due to various typos) with:

  "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."

--> How about appending the following sentence to the above paragraph:

  "Furthermore, if the Registration Request contains an AAAH-NAI,
  then the FA sets the AMR's Destination-Realm based on the AAAH's NAI.
  Otherwise the FA sets the AMR's Destination-Realm based on the MN's
  NAI.

--> And how about adding the following paragraph:

  "Whenever the mobile node specifies a home agent IP address with a value
  other than 0.0.0.0 or 255.255.255.255 in a Registration Request, the
  mobile node MUST also include an HA-NAI which conveys the home agent's
  identity and realm."

The above paragraph makes it clear that, if the MN knows who his HA is,
whether generating an initial Reg Req or a handoff Reg Req, the MN must
also specify the HA's identity.

> If the mobile node was successfully authenticated, the AAAH checks if
> the Home Agent was located in the foreign realm, by checking the MIP-

--> Exactly what is the check that the AAAH does with the values of the
MIP-Home-Agent-Host AVP, the MIP-Originating-Foreign-AAA AVP, and the
Home-Agent-In-Foreign-Network flag?  I think too many AVPs are probably being
inspected here.  Isn't the Home-Agent-In-Foreign-Network flag alone
sufficient to make the "HA is in foreign network" determination?

--> Do we need the Home-Agent-In-Foreign-Network flag anymore?  It seems
to be at best redundant, and at worst conflicting.  Here's what I mean:

As I understand it, the Home-Agent-In-Foreign-Network flag would be set
by an AAAF if and only if:
(a) the FA's AMR contained a MIP-HA-Host AVP, and
(b) the HA's realm (from the MIP-HA-Host AVP) is different from the
MN's home realm (from the AMR's Destination-Realm AVP).

But the AAAH, when processing an AMR which contains a MIP-HA-Host AVP,
could just as easily check the HA's realm against his own, as to inspect
the Home-Agent-In-Foreign-Network flag (and the other two AVPs mentioned
above).  And wouldn't have to worry about conflicting information.

> If home agent is located in the foreign realm, then AAAH sends an HAR
    ^                                                 ^
  If the home agent is located in the foreign realm, then the AAAH ...

> 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,
> AAAH MAY allocate a home address for the mobile node, while the Home
> Address AVP within the HAR.  The absence of this AVP informs the Home
> During the creation of the HAR, the AAAH MUST use a different session
> 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,
> the session from the foreign agent, but not the one towards the home
> agent (see figure 3).
> 
> Upon receipt of the HAR, the home agent first processes the Diameter
> message. The home agent processes the MIP-Reg-Request AVP and creates
> Originating-Host AVP and Originating-Realm AVP of the HAR. If a home
  ^^^^^^^^^^^              ^^^^^^^^^^^^^^^^^
  Origin-Host AVP and Origin-Realm AVP of the HAR. If a home
> the address in both the Registration Reply and within the MIP-Mobile-
> Node-Address AVP.
> 

Since this is a RADIUS attribute, it'd be a good idea to retain
the RADIUS name, i.e. "Acct-Multi-Session-Id".

> present in the HAA, and the MIP-Home-Agent-Address, MIP-Mobile-Node-
> The AAAF is responsible for ensuring that the AMA message is properly

Since Answers always take the reverse path of Requests, I don't think
the previous paragraph is necessary.

> 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
> 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

I don't like the first sentence of the above paragraph because it talks
about the "first registration request" and "a different AAAF".  That is,
how can there be a different AAAF yet involved if this is only the first
registration request?  Maybe it would be clearer to rephrase this
sentence as follows:

  "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."

> of an existing session. If the HA receives an HAR for a mobile node,
> This Accounting-Multi-Session-Id AVP will be returned to the foreign
>    Accounting-Multi-Session-Id = a   Accounting-Multi-Session-Id = a
> 
> 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
> 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-
> 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
> doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP
              
--> How about renaming this AVP from MIP-Originating-Foreign-AAA to
MIP-Origin-Foreign-AAA?  This is consistent with the names of the
existing "Origin-Host" and "Origin-Realm" AVPs, and we won't have to
worry about mixing up "Originating" and "Origin".

--> I also like the idea of the the originating AAAF *always* including
his identity in an AMR, whether including a Candidate-MIP-HA or not.
This has two virtues:

1. The AAAH and HA always have a fixed place to look for the FA's
identity.

2. The AAAH can be assured that the AMR has actually passed through an
AAAF on the way, and thus that the foreign network had its opportunity
to apply its policy.  What I mean is this: When the FA sends an AMR, it
is routed by Destination-Realm.  Suppose the FA has a Relay between
itself and the local AAAF.  The FA sends the AMR to the Relay.  If the
Relay's routing is misconfigured, the Relay may just route the AMR
directly to the AAAH, bypassing the AAAF.  The AAAH wouldn't necessary
know that the AAAF was bypassed.  But if the MIP-Originating-Foreign-AAA
AVP was required but not present, this would tip off the AAAH that
something was amiss.

> Agent-Host AVP contains the identity of the home agent that would be
> the assigned home agent in the foreign network, the mobile node MUST
                                    ^^
  the FA. Upon receipt, the FA will create the AMR including 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

--> This is a good place to add a paragraph that defines the exact test
that the AAAF does to make the "HA-is-in-Foreign-Network" determination.

If keeping the Home-Agent-In-Foreign-Network flag, then add the
paragraph:

  "The Home-Agent-In-Foreign-Network flag is set by the AAAF if:
  (a) the FA's AMR contains a MIP-HA-Host AVP, and
  (b) the HA's realm (from the MIP-HA-Host AVP) is different from the
  MN's home realm (from the AMR's Destination-Realm AVP)."

Or, if eliminating the Home-Agent-In-Foreign-Network flag (my
preference), but wanting to specify how an AAA server would make the
"HA-is-in-Foreign-Network" determination, add the following paragraph:

  "An AAA server concludes that the HA is in a foreign network if:
  (a) the FA's AMR contains a MIP-HA-Host AVP, and
  (b) the HA's realm (from the MIP-HA-Host AVP) is different from the
  MN's home realm (from the AMR's Destination-Realm AVP)."

--> Question: Because of subrealms, is it sufficient that the HA's realm
be merely *different* from the MN's home realm, or does the test need to
instead specify matching of trailing substrings?  That is, could the
MN's NAI be "[email-masked]" while the AAAH's NAI is "[email-masked]"?

> to authorize the mobile node.  If the AMR indicates that the AAAF has
> Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or
> 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 byincluding
                                                              ^
  AMR message, the AAAH sends the HAR message to Home Agent by including

> AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if
> Foreign-AAA AVP for policy decisions, such as determining if the FA-
> 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

Does "...no security association is known to the home agent" mean that
the AAAH has no pre-existing SA with the specified HA?

> the MIP-Candidate-Home-Agent-Host AVP found in the AMR.

Probably my fault, but I'm confused.  

1. It looks like sometimes the HAR is sent with a Destination-Host set
to the HA's identity, and other times with the Destination-Host set to
an AAAF's identity.  

2. I also get confused trying to understand the context under
discussion in some of these paragraphs, i.e. if this is the initial AMR
for a session with a candidate foreign-HA, or if this is a handoff for a
session with an established foreign-HA in the same visited network, or
if this is a handoff into a new network for a session with an
established foreign-HA in a previously-visited network

But what I will do is to re-read this stuff, and send a separate email
with more specific questions and suggestions.

> AAAF forwards the HAA to the AAAH in the home realm. The AMA is then
> Result-Code indicates success, the HAA and AMA MUST include the MIP-
> -----------   -------------  -------------   ----------    ----------
> 
>   <----Challenge----
> Reg-Req (Response)->
> 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
> realm. If this is the case, the AAAH must check whether the mobile is
> 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 and no security association is known to the home agent, the
> Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send
> 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
> Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile
> request that a new Home Agent and Address be allocated. When the AAAH
> The AA-Mobile-Node-Request (AMR), indicated by the Command-Code field
> set to 260 and the 'R' bit set in the Command Flags field, is sent by
> Foreign Agent (or Home Agent in the case of a co-located Mobile Node)
> MIP-Home-Agent  348  4.12     Grouped    | M  |  P  |    |  V  | Y  |
> Host                                     |    |     |    |     |    |
> "
> 
> 
> 
> Added a new grouped AVP:
> 

It is a little odd to be using "Destination-Realm" and "Destination-Host"
as the member AVPs of this MIP-Home-Agent-Host grouped AVP.

--> I like the idea of creating three generic AVPs, called
"Host-Identity" and "Host-Realm" and "Host-IP-Address".  These
AVPs would be members of a grouped AVP which can carry 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.

I may fire this off as a separate issue and see how it flies.

> If the home agent is in the home realm, then AAAH can directly encode
> 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
> can be established using DSA messages defined in the CMS application
> [CMS] with the originating host found in the MIP-Originating-Foreign-
> association. On the other hand, if no security association exists and

---

From: Tony Johansson <[email-masked]>
Date: Wed, 03 Apr 2002 13:18:35 -0800

Hi Bob,

There will be a conference call next week with IESG regarding normative
dependencies on CMS within the Diameter
Base, NASREQ, and MIP documents. So, we have to wait and see the outcome
from that meeting..

/Tony

---

From: Tony Johansson <[email-masked]>
Date: Wed, 03 Apr 2002 18:18:50 -0800

Hi Bob,

Thanks for your veeery loooong mail ;-)

Please, find my comments inline...

/Tony

> that the AAAH NAI information isn't required in the initial Registration

This is explicitly stated in [AAANAI], so I don't see why we need to repeat that
in this draft.

> other than 0.0.0.0 or 255.255.255.255"

See comment above, will be stated in -01.

> "game over" for the MN's session, even if other AAAHs are available?

The protocol doesn't mention this, since this capability may be provided by an
implementation outside the scope of this protocol.

> whether or not to invoke AAA services?

The details are specified in RFC3012.

> needs an FA-xx key.  Or the key lifetime is approaching expiration.

Again, you will find some of the details in RFC3012. In brief, if the MN has no
SA to the FA the MN must include the MN-AAA auth ext. This could e.g. happen if
MN does a handoff to a new FA where no session keys are known or if the session
keys have expired.. Also, section 5.5.1 Authorization Lifetime vs. MIP Key
Lifetime in in Diameter mipv4 appl explains the two timers used in mip, which my
trigger this behavior.

>   realm of the assigned HA found in the HA-NAI."

Ok.

>   mobile node MUST also include an HA-NAI which conveys the home agent's

This is specified in [AAANAI].

> sufficient to make the "HA is in foreign network" determination?

No - checking this flag alone does not provide the capability of determining that
there may be more than one foreign network involved.

>   If the home agent is located in the foreign realm, then the AAAH ...

check.

> >        STR, Session-Id = foo       STR, Session-Id = bar

check.

> the RADIUS name, i.e. "Acct-Multi-Session-Id".

Good catch. Please make a new issue to the BASE.

> the previous paragraph is necessary.

Ok.

>   received the previous AMR."

Ok.

> his identity in an AMR, whether including a Candidate-MIP-HA or not.

Ok. I'll change the text to always include the originating AAAF.

>   the FA. Upon receipt, the FA will create the AMR including the

check.

> that the AAAF does to make the "HA-is-in-Foreign-Network" determination.

The protocol provides all the necessary info. It's an implementation specific
detail as to how this exact test is performed.

>   AMR message, the AAAH sends the HAR message to Home Agent by including

check.

> the AAAH has no pre-existing SA with the specified HA?

Yes.

---

From: Johan Johansson <[email-masked]>
Date: Thu, 04 Apr 2002 11:59:18 +0200

>this is true, should this be explicitly stated?

How about not breaking what was not previously broken instead? I will 
consider anything that requires that the same AAAH be used throughout 
the mobile node's session a showstopper bug. If you for some reason 
*prefer* that an MN use the same AAAH throughout the session then by all 
means introduce this redundant functionality as a MAY.

>clarification, or maybe should be striken.  
Agreed. There should probably be something regarding Mobile IP tunnel 
renewal.

>request from a mobile node has been previously authorized."
But section 1.3 is with regard to FA handover. If the FA has a session 
(Diameter or MobileIP for that matter) for a particular MN then 
obviously it knows that there was a previous authorization. The intent 
of section 1.3 is to explain why the AAAFs and AAAHs can't assume that 
there isn't already a session just because there is no Destination-Host 
in the AMR.

>beyond "*only* when the prior authorization from the AAAH expires"
>--> I would suggest either striking the "Note that..." sentence altogether, or trimming it to "It is not required that the foreign agent
First of all, I agree that there could be other reasons for the FA to 
invoke AAA services. Then again the sentence is more ambigous than in 
error really. It just states that the only time that the FA is required 
to invoke AAA services is when the previous authorization expires, which 
is true. Remember that the key lifetime *IS* the authorization lifetime 
while Authorization-Lifetime is used as the MobileIP tunnel renewal 
interval. See issue #306.

>>in the AA-Mobile-Node-Answer (AMA, see section 2.2) from the AAAH.
....which of course means that this sentence is wildly misleading.

>  realm of the assigned HA found in the HA-NAI."
I don't understand why you have chosen to make this fundamental 
restriction in the protocol? The only think that must remain constant 
during a session is the home agent and the HA-NAI part is then of course 
needed to make the protocol work, but why introduce the AAAH NAI just to 
make the protocol less capable?

>  Otherwise the FA sets the AMR's Destination-Realm based on the MN's
If the MN NAI works why use something else? Why not simply state that 
the MN's NAI MUST be used to deduce the realm?

>also specify the HA's identity.
Seems reasonable to me.

>above).  And wouldn't have to worry about conflicting information.
I certainly don't understand why it would need to inspect the 
MIP-Originating-Foreign-AAA AVP. The Home-Agent-In-Foreign-Network flag 
might need to be retained to make this visible in the accounting which 
contains the feature vector, but the AAAH doesn't seem to need it to 
determine if the HA is in the foreign realm or not.

 From Tony's answer:

>checking this flag alone does not provide the capability of determining that
While this is true, it makes me wonder what we do differently if more 
than one foreign network *is* involved. The only place it seems to make 
a difference to me is in the accounting and billing and it's not obvious 
to me that it can be determined (easily) from the accounting messages. 
Potentially, the session ids could be used I guess, but it seems 
laborious. If the server is stateless or the request is handled by a 
different AAAH, wouldn't additional information be needed beyond those 
avps mentioned be needed to detect a handover between different foreign 
networks anyway?

>>this application.
I don't like this paragraph for many reasons. For one there has been 
many many changes to the statemachine after it was written and I guess 
someone should check if it is still true. Another is that it is 
virtually impossible to implement the Diameter Mobile IP application 
sessions with an "unmodified" base session state machine.

>1. The AAAH and HA always have a fixed place to look for the FA's
I suppose you mean the AAAF's identity?

>AVP was required but not present, this would tip off the AAAH that
If we agree to say that a AAAF must add it's identity upon processing a 
message then I have no objections. But if you are saying that a network 
MUST have a AAAF I disagree. Consequently the AAAH can't know if 
something is amiss or not.

>detail as to how this exact test is performed.
   1. How can you be so sure about that until you have a "peer-reviewed"
      algorithm for it?
   2. Since the network topology of the home network comes into play
      here, how does the AAAF implementation know how to perform the
      test? Let's say [email-masked] visits the alien
      department and gets an HA in the alien.space.com realm, which is
      foreign to elvis even if only slightly. Next he goes outside and
      switches to the wlan.isp.com realm. Please explain how
      aaaf.wlan.isp.com knows that the HA is in a foreign realm. We
      don't have to put the algorithm in the draft, but I would like to
      see one that works.

>to the HA's identity, and other times with the Destination-Host set to
I'm curious about the SHOULD. What should it do otherwise? Is the above 
a recommendation to send it to the AAAF but it's ok to send it to the HA 
too? Or MUST it always send it to the AAAF (if the HA is in the foreign 
net) but it may potentially use other sources of information to deduce 
it's identity?

j

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 4 Apr 2002 10:32:12 -0500

Hi Tony,

> Good catch. Please make a new issue to the BASE.

Already done.  This was part of Issue#314: Minor 
clarifications/corrections to Base-09.

Bob K.

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 4 Apr 2002 11:27:21 -0500

Hi Johan and Tony,

Here's some partial feedback on the specific subissue of using
a single AAAH over the life of a MN session.

> .................................................
> 

You are right, this does introduce a new single point of failure.

More complete comments at next break point.

> .................................................
> 

I think (but am not sure) the reason the proposed text states that a
single AAAH be used over the life of a MN session is this: In earlier
discussions of issue#299, the AMR carried only the HA's IP address and
not the HA's identity.  After a handoff to a new foreign domain where
the MN wanted to retain the foreign HA in the first-visited foreign
domain, the AAAH had to somehow map the HA's IP address into an HA
identity+realm, so that the AAAH could route the HAR to the HA.  This
presented a problem for the AAAH.  But if the AAAH is session-stateful,
and the same AAAH is used over the life of the MN session, then the AAAH
could just retreive the HA's identity+realm from his internal state
information.  Problem solved.  But a new AAAH without this cached state
information would still have the "mapping HA IP Address to
Identity+Realm" problem.

However, now that the handoff AMR contains the HA's identity+realm, a
new AAAH doesn't have this problem.  So it seems that the need to employ
a single AAAH over the life of a session is gone, at least in terms of
the "mapping HA IP Address to Identity+Realm" snag.

One thing that a new AAAH doesn't have, however, is the identity+realm 
of the destination AAAF hosting the foreign HA.  A single
session-stateful AAAH employed over the life of a MN's session would
have this destination-AAAF-identity information as part of his session
state.  If the AAAH needs to know the destination-AAAF's identity for
the purpose of securing session keys, then this presents a problem for a
new AAAH.

> 
> .................................................
> 

Yes.  I thought "AAAF" but typed "FA".  Same letters involved :)

> something is amiss or not.

Are you saying that a visited foreign network could have FAs but no AAAFs?  
I didn't know that.  My understanding of the "real world" scenarios is
frequently more limited than I'd like.

> .................................................

---

From: Tony Johansson <[email-masked]>
Date: Thu, 04 Apr 2002 13:41:27 -0800

Bob and Johan,

To really try to clarify this. We are in worst case talking about  a single point
of failure for a MN's session. However, this is a limitation already imposed
today in the MIP application, which stated -    "In the event that the AMR
generated by the FA is for a session that has was previously authorized by the
AAAH, it MUST include the Destination-Host AVP". So, to be very explicit, we are
not introducing any new limitations with this new functionality design to handle
both issue#299 and #301. Regardless, this perceived limitation (single point of
failure for a MN's session) can be overcome by utilizing the fail over mechanisms
described in Base.

IMHO, since the  failover mechanisms are described in the Base there is no need
to discuss them in the MIP application.

To support the failover mechanisms in Base, the following clarification should be
added in [AAANAI]:

" 5. AAAH Identity subtype

 ....

A mobile node MUST always save the AAAH Identity received in the registration
reply message and MUST provide the AAAH Identity in every registration request
sent when re-authenticating.

 .... "

Any comments / objections to this.

/Tony

---

From: Johan Johansson <[email-masked]>
Date: Fri, 05 Apr 2002 01:05:10 +0200

>the "mapping HA IP Address to Identity+Realm" snag.
Yes. I agree that it in some cases might make things a bit smoother, but 
I think this should be optional since the protocol does seem to work 
well without it.

>the purpose of securing session keys, then this presents a problem for a
Here you and Tony have dug in way more deeply than I. If all you need is 
the identity of the AAAF you should direct your HAR to, wouldn't the 
Mip-Originating-Foreign-AAA AVP suffice if you require the AAAF to add 
it if a AAAF is present (otherwise the problem obviously doesn't exist)?

>frequently more limited than I'd like.
Well... "real world" scenarios are so far pretty scarce. But there is 
nothing that I know of that requires a AAAF to exist unless you want to 
allow allocation of HAs for visitors. This shouldn't be interpreted as 
if I don't like AAAFs, but I think that for a significant subset of 
 deployments the foreign network doesn't have to have one.

And, as you know I've been lobbying, if not on the wg list, for some 
"real world" networks to be built before the standard goes to an RFC but 
I guess it wasn't to be.

j

---

From: "Bob Kopacz" <[email-masked]>
Date: Thu, 4 Apr 2002 18:41:46 -0500

Hi Johan and Tony,

# From: Johan Johansson [[email-masked]]
# Sent: Thursday, April 04, 2002 6:05 PM
# To: Bob Kopacz
# Cc: Tony Johansson; David Spence; aaa-wg
# Subject: Re: [AAA-WG]: Re: [Fwd: Issue #299 and #301]
# 
# Bob Kopacz wrote:
# 
# >However, now that the handoff AMR contains the HA's identity+realm, a
# >new AAAH doesn't have this problem.  So it seems that the need to employ
# >a single AAAH over the life of a session is gone, at least in terms of
# >the "mapping HA IP Address to Identity+Realm" snag.
# >
# Yes. I agree that it in some cases might make things a bit smoother, but 
# I think this should be optional since the protocol does seem to work 
# well without it.
# 
# >One thing that a new AAAH doesn't have, however, is the identity+realm 
# >of the destination AAAF hosting the foreign HA.  A single
# >session-stateful AAAH employed over the life of a MN's session would
# >have this destination-AAAF-identity information as part of his session
# >state.  If the AAAH needs to know the destination-AAAF's identity for
# >the purpose of securing session keys, then this presents a problem for a
# >new AAAH.
# >
# Here you and Tony have dug in way more deeply than I. If all you need is 
# the identity of the AAAF you should direct your HAR to, wouldn't the 
# Mip-Originating-Foreign-AAA AVP suffice if you require the AAAF to add 
# it if a AAAF is present (otherwise the problem obviously doesn't exist)?

No.  I didn't describe the context fully enough earlier, sorry.

In the case I was thinking about, there are two foreign realms involved.
The MN first visited realm X, was allocated HA(X), and HA(X) is hosted by
AAAF(X). Then the MN migrated to realm Y, and attached to FA(Y), and FA(Y)
is hosted by AAAF(Y).  The AMR's MIP-Originating-AAAF is AAAF(Y) in the new
realm.  And the AAAH (maybe) wants to set up some sort of SA with AAAF(X)
in the old realm, and the AAAH doesn't know who AAAF(X) is.

Question for Tony: Since the AMR now contains the HA's identity, it seems
there is less need to require a single AAAH over the life of a MN session,
since a new AAAH can contact the HA as easily as a previous AAAH could. So
what is the reason for wanting to require a single AAAH over the life of a
MN session?  Is it to help resolve the above-mentioned
securing-session-key problem, where a new AAAH wouldn't know who AAAF(X)
is, but an old session-stateful AAAH would?  Does that mean that
session-statefulness is now also required?  Sorry I'm so thick.

# >>>2. The AAAH can be assured that the AMR has actually passed through an
# >>>AAAF on the way, and thus that the foreign network had its opportunity
# >>>to apply its policy.  What I mean is this: When the FA sends an AMR, it
# >>>is routed by Destination-Realm.  Suppose the FA has a Relay between
# >>>itself and the local AAAF.  The FA sends the AMR to the Relay.  If the
# >>>Relay's routing is misconfigured, the Relay may just route the AMR
# >>>directly to the AAAH, bypassing the AAAF.  The AAAH wouldn't necessary
# >>>know that the AAAF was bypassed.  But if the MIP-Originating-Foreign-AAA
# >>>AVP was required but not present, this would tip off the AAAH that
# >>>something was amiss.
# >> 
# >>If we agree to say that a AAAF must add it's identity upon processing a 
# >>message then I have no objections. But if you are saying that a network 
# >>MUST have a AAAF I disagree. Consequently the AAAH can't know if 
# >>something is amiss or not.
# >
# >Are you saying that a visited foreign network could have FAs but no AAAFs?  
# >I didn't know that.  My understanding of the "real world" scenarios is
# >frequently more limited than I'd like.
# >
# Well... "real world" scenarios are so far pretty scarce. But there is 
# nothing that I know of that requires a AAAF to exist unless you want to 
# allow allocation of HAs for visitors. This shouldn't be interpreted as 
# if I don't like AAAFs, but I think that for a significant subset of 
#  deployments the foreign network doesn't have to have one.
# 
# And, as you know I've been lobbying, if not on the wg list, for some 
# "real world" networks to be built before the standard goes to an RFC but 
# I guess it wasn't to be.

I guess what I was trying to say was: In the Diameter Mobile IPv4 draft,
whenever an FA is involved, there is ALWAYS a local AAAF server in the
diagrams and the text.  There is no mention of the possibility that there
may not be a local AAAF for the FA to pass the AMR through, so I was 
surprised by your comment.  If this sort of thing is ok, then maybe the 
draft should add a sentence or two saying so.

# j
#

---

From: Tony Johansson <[email-masked]>
Date: Thu, 04 Apr 2002 17:01:57 -0800

Bob Kopacz wrote:

> is, but an old session-stateful AAAH would?

Correct.

> Does that mean that
> session-statefulness is now also required?

No, the AAAH  can be session stateless using some back-ended mechanism, which is
beyond the scope of this protocol, to retrieve necessary info.

/Tony

---

From: Johan Johansson <[email-masked]>
Date: Sun, 07 Apr 2002 12:57:40 +0000

>beyond the scope of this protocol, to retrieve necessary info.
If you mean that it would keep track through mentioned back-ended 
mechanism what AAAF the mobile node just used for the indicated session 
then the AAAH is still stateful. Otherwise we might as well write the 
entire session state to some back-ended mechanism and call the entire 
protocol stateless.

It seems to me that it would make more sense to have the mobile node 
carry the information that we are really after, i.e. the identity of the 
AAAF, than to make it carry the identity of a server that it doesn't 
care about that may be able to hold the information we want.

j

---

From: Johan Johansson <[email-masked]>
Date: Sun, 07 Apr 2002 14:46:26 +0000

>to discuss them in the MIP application.
It is not entirely true that the limitation is quite as rigid already, 
but instead of splitting hairs, I assume that the failover mechanism you 
are referring to is section 8.18 and the Session-Server-Failover AVP set 
to the value TRY_AGAIN? It seems to fit the bill quite nicely in any case.

My main objection however is that this is unneccessary for issue 299 
since this has already been independently solved and misses the target 
for issue 301 unless you also force the AAAH to keep state. What you 
really are after is the identity of the AAAF used in the previous 
authentication so make the mobile node store that instead. As long as 
you don't demand that the AAAH keep state there is really very little 
you can gain by hitting the same AAAH.

Speaking of keeping state, I can't locate any place where we explicitly 
disallow stateless clients, but section 1.2 states that

In the event that the AMR generated by the FA is for a session that
   has was previously authorized by the AAAH, it MUST include the
   Destination-Host AVP, with the identity of the AAAH. The AAAH's
   identity can be retrieved from the Origin-Host AVP in the last AMA
   received for the session.

which seems to require Diameter session state. Section 1.0 discusses 
statefulness of all other entities so why not clients?

j