tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4004

 
 
 

Diameter Mobile IPv4 Application

Part 2 of 3, p. 20 to 38
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 20 
4.  Diameter Protocol Considerations

   This section details the relationship of the Diameter Mobile IPv4
   application to the Diameter base protocol.

   This document specifies Diameter Application-ID 2.  Diameter nodes
   conforming to this specification MAY advertise support by including
   the value of two (2) in the Auth-Application-Id or the Acct-
   Application-Id AVP of the Capabilities-Exchange-Request and
   Capabilities-Exchange-Answer commands [DIAMBASE].  The value of two
   (2) MUST be used as the Application-Id in all AMR/AMA and HAR/HAA
   commands.  The value of two (2) MUST be used as the Application-Id in
   all ACR/ACA commands, as this application defines new, mandatory AVPs
   for accounting.  The value of zero (0) SHOULD be used as the
   Application-Id in all STR/STA and ASR/ASA commands, as these are
   defined in the Diameter base protocol and no additional mandatory
   AVPs for those commands are defined in this document.

   Given the nature of Mobile IPv4, re-authentication can only be
   initiated by a mobile node, which does not participate in the
   Diameter message exchanges.  Therefore, Diameter server initiated
   re-auth does not apply to this application, and RAR/RAA commands MUST
   NOT be sent for Diameter Mobile IPv4 sessions.

4.1.  Diameter Session Management

   The AAAH and AAAF MAY maintain session-state or MAY be session-
   stateless.  AAA redirect agents and AAA relay agents MUST NOT
   maintain session-state.  The AAAH, AAAF, proxies and relays agents
   MUST maintain transaction state.

   A mobile node's session is identified via its identity in the User-
   Name AVP and the MIP-Mobile-Node-Address, and the MIP-Home-Agent-
   Address AVPs.  This is necessary in order to allow the session state

Top      Up      ToC       Page 21 
   machine, defined in the base protocol [DIAMBASE], to be used without
   modification for this application.  However, as the MN may interact
   with more than one FA during the life of its session, it is important
   for the Diameter Mobile IPv4 application to distinguish the two
   pieces of the session (some state at the FA, some state at the HA)
   and to manage them independently.  The following sub-sections give
   further details.

4.1.1.  Session Identifiers

   During creation of the AMR, the FA will choose a session identifier.
   During the creation of the HAR, the AAAH MUST use a different session
   identifier than that used in the AMR/AMA.  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.

   When the HA is first allocated, it MUST create and include an Acct-
   Multi-Session-Id AVP in the HAA returned to the AAAH.  This
   identifier will be kept constant for the life of the Mobile IPv4
   session, as detailed in the next subsection.

4.1.2.  Managing Sessions during Mobile IPv4 Handoffs

   Given the nature of Mobile IPv4, 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, as this
   could affect billing systems.  Furthermore, foreign agents usually do
   not communicate between each other, which implies that AAA
   information cannot be exchanged between these entities.

   A handoff registration request from a mobile node will cause the FA
   to send an AMR to its AAAF.  The AMR will include a new session
   identifier and MAY be sent to a new AAAF (i.e., a AAAF different from
   that used by the previous FA).  However, the AMR shall be received by
   the AAAH to which the user is currently registered (possibly via the
   redirect mechanism depicted in Figure 3).

   As 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 an existing service, then the HA MUST be able to
   modify its internal session state information to reflect the new
   session identifier.

Top      Up      ToC       Page 22 
   For correlation to occur, accounting records must have some
   commonality across handoffs.  Therefore, the home agent MUST send the
   same Acct-Multi-Session-Id AVP value in all HAAs for the mobile's
   session.  That is, the HA generates a unique Acct-Multi-Session-Id
   when receiving an HAR for a new session and returns this same value
   in every HAA for the session.  This Acct-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 Acct-Multi-Session-Id in the
   accounting messages, as depicted in Figure 10.

4.1.3.  Diameter Session Termination

   A foreign and home agent following this specification MAY expect
   their respective Diameter servers to maintain session state
   information for each mobile node in their networks.  For a Diameter
   Server to release any resources allocated to a specific mobile node,
   that server has to receive a Session-Termination-Request (STR) from a
   mobility agent.  The mobility agents MUST issue the Session-
   Termination-Request (STR) if the Authorization Lifetime has expired
   and no subsequent MIP registration request has been received.

   The AAAH SHOULD only deallocate all resources after the STR is
   received from the home agent.  This ensures that a mobile node that
   moves from one foreign agent to another (for example, as a result of
   a handover) does not cause the Home Diameter Server to free all
   resources for the mobile node.  Therefore, an STR from a foreign
   agent would free the session from the foreign agent, but not the
   session state associated with the home agent (see Figure 10).

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

            Figure 10.  Session Termination and Session Identifiers

   When deallocating all of the mobile node's resources, the home
   Diameter server (and the foreign Diameter server in the case of an HA
   allocated in foreign network) MUST destroy all session keys that may
   still be valid.

   In the event that the AAAF wishes to terminate a session, its Abort-
   Session-Request (ASR) [DIAMBASE] message SHOULD be sent to the FA.
   Similarly, the AAAH SHOULD send its message to the Home Agent.

Top      Up      ToC       Page 23 
5.  Command-Code Values

   This section defines Command-Code [DIAMBASE] values that MUST be
   supported by all Diameter implementations conforming to this
   specification.  The following Command Codes are defined in this
   specification:

         Command-Name             Abbreviation    Code       Section
         -----------------------------------------------------------
         AA-Mobile-Node-Request       AMR         260          5.1
         AA-Mobile-Node-Answer        AMA         260          5.2
         Home-Agent-MIP-Request       HAR         262          5.3
         Home-Agent-MIP-Answer        HAA         262          5.4


5.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 (i.e., the Foreign Agent), acting as a Diameter client,
   to an AAAF 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, to be included as part of
   the AMR:

             Home Address (MIP-Mobile-Node-Address AVP)
             Home Agent Address (MIP-Home-Agent-Address AVP)
             Mobile Node NAI (User-Name AVP [DIAMBASE])
             MN-HA Key Request (MIP-Feature-Vector AVP)
             MN-FA Key Request (MIP-Feature-Vector AVP)
             MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP)
             Foreign Agent Challenge Extension (MIP-FA-Challenge AVP)
             Home Agent NAI (MIP-Home-Agent-Host AVP)
             Home AAA server NAI (Destination-Host AVP [DIAMBASE])
             Home Agent to Foreign Agent SPI (MIP-HA-to-FA-SPI AVP)

   If the mobile node's home address is zero, the foreign or home agent
   MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR.  If the
   home agent address is zero or all ones, the MIP-Home-Agent-Address
   AVP MUST NOT be present in the AMR.

   If a home agent is used in a visited network, the AAAF MAY set the
   Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in
   the AMR message to indicate that it is willing to assign a Home Agent
   in the visited realm.

Top      Up      ToC       Page 24 
   If the mobile node's home address is all ones, the foreign or home
   agent MUST include a MIP-Mobile-Node-Address AVP, set to all ones.

   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 }
                                      [ Acct-Multi-Session-Id ]
                                      [ Destination-Host ]
                                      [ Origin-State-Id ]
                                      [ MIP-Mobile-Node-Address ]
                                      [ MIP-Home-Agent-Address ]
                                      [ MIP-Feature-Vector ]
                                      [ MIP-Originating-Foreign-AAA ]
                                      [ Authorization-Lifetime ]
                                      [ Auth-Session-State ]
                                      [ MIP-FA-Challenge ]
                                      [ MIP-Candidate-Home-Agent-Host ]
                                      [ MIP-Home-Agent-Host ]
                                      [ MIP-HA-to-FA-SPI ]
                                    * [ Proxy-Info ]
                                    * [ Route-Record ]
                                    * [ AVP ]

Top      Up      ToC       Page 25 
5.2.  AA-Mobile-Node-Answer

   The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field
   set to 260 and the 'R' bit cleared in the Command Flags field, is
   sent by the AAAH in response to the AA-Mobile-Node-Request message.
   The User-Name MAY be included in the AMA if it is present in the AMR.
   The Result-Code AVP MAY contain one of the values defined in section
   6, in addition to the values defined in [DIAMBASE].

   An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST
   include the MIP-Home-Agent-Address AVP, MUST include the MIP-Mobile-
   Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if
   the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector
   AVP.  The MIP-Home-Agent-Address AVP contains the Home Agent assigned
   to the mobile node, while the MIP-Mobile-Node-Address AVP contains
   the home address that was assigned.  The AMA message MUST contain the
   MIP-FA-to-HA-MSA and MIP-FA-to-MN-MSA if they were requested in the
   AMR and were present in the HAR.  The MIP-MN-to-HA-MSA and MIP-HA-
   to-MN-MSA AVPs MUST be present if the session keys were requested in
   the AMR and the Co-Located-Mobile-Node bit was set in the MIP-
   Feature-Vector AVP.

      Message Format

         <AA-Mobile-Node-Answer> ::= < Diameter Header: 260, PXY >
                                     < Session-Id >
                                     { Auth-Application-Id }
                                     { Result-Code }
                                     { Origin-Host }
                                     { Origin-Realm }
                                     [ Acct-Multi-Session-Id ]
                                     [ User-Name ]
                                     [ Authorization-Lifetime ]
                                     [ Auth-Session-State ]
                                     [ Error-Message ]
                                     [ Error-Reporting-Host ]
                                     [ Re-Auth-Request-Type ]
                                     [ MIP-Feature-Vector ]
                                     [ MIP-Reg-Reply ]
                                     [ MIP-MN-to-FA-MSA ]
                                     [ MIP-MN-to-HA-MSA ]
                                     [ MIP-FA-to-MN-MSA ]
                                     [ MIP-FA-to-HA-MSA ]
                                     [ MIP-HA-to-MN-MSA ]
                                     [ MIP-MSA-Lifetime ]
                                     [ MIP-Home-Agent-Address ]
                                     [ MIP-Mobile-Node-Address ]
                                   * [ MIP-Filter-Rule ]

Top      Up      ToC       Page 26 
                                     [ Origin-State-Id ]
                                   * [ Proxy-Info ]
                                   * [ AVP ]

5.3.  Home-Agent-MIP-Request

   The AAA sends the Home-Agent-MIP-Request (HAR), indicated by the
   Command-Code field set to 262 and the 'R' bit set in the Command
   Flags field, to the Home Agent.  If the Home Agent is to be assigned
   in a foreign network, the HAR is issued by the AAAH and forwarded by
   the AAAF to the HA if no redirect servers are involved.  If any are,
   the HAR is sent directly to the HA via a security association.  If
   the HAR message does not include a MIP-Mobile-Node-Address AVP, the
   Registration Request has 0.0.0.0 for the home address, and the HAR is
   successfully processed, the Home Agent MUST allocate the mobile nodes
   address.  If, on the other hand, the home agent's local AAA server
   allocates the mobile node's home address, the local AAA server MUST
   include the assigned address in a MIP-Mobile-Node-Address AVP.

   When session keys are requested for use by the mobile node, the AAAH
   MUST create them and include them in the HAR message.  When a FA-HA
   session key is requested, it will be created and distributed by the
   AAAH server.

      Message Format

         <Home-Agent-MIP-Request> ::= < Diameter Header: 262, REQ, PXY >
                                      < Session-Id >
                                      { Auth-Application-Id }
                                      { Authorization-Lifetime }
                                      { Auth-Session-State }
                                      { MIP-Reg-Request }
                                      { Origin-Host }
                                      { Origin-Realm }
                                      { User-Name }
                                      { Destination-Realm }
                                      { MIP-Feature-Vector }
                                      [ Destination-Host ]
                                      [ MIP-MN-to-HA-MSA ]
                                      [ MIP-MN-to-FA-MSA ]
                                      [ MIP-HA-to-MN-MSA ]
                                      [ MIP-HA-to-FA-MSA ]
                                      [ MIP-MSA-Lifetime ]
                                      [ MIP-Originating-Foreign-AAA ]
                                      [ MIP-Mobile-Node-Address ]
                                      [ MIP-Home-Agent-Address ]
                                    * [ MIP-Filter-Rule ]
                                      [ Origin-State-Id ]

Top      Up      ToC       Page 27 
                                    * [ Proxy-Info ]
                                    * [ Route-Record ]
                                    * [ AVP ]

5.4.  Home-Agent-MIP-Answer

   In response to a Home-Agent-MIP-Request, the Home Agent sends the
   Home-Agent-MIP-Answer (HAA), indicated by the Command-Code field set
   to 262 and the 'R' bit cleared in the Command Flags field, to its
   local AAA server.  The User-Name MAY be included in the HAA if it is
   present in the HAR.  If the home agent allocated a home address for
   the mobile node, the address MUST be included in the MIP-Mobile-
   Node-Address AVP.  The Result-Code AVP MAY contain one of the values
   defined in section 6 instead of the values defined in [DIAMBASE].

      Message Format

         <Home-Agent-MIP-Answer> ::= < Diameter Header: 262, PXY >
                                     < Session-Id >
                                     { Auth-Application-Id }
                                     { Result-Code }
                                     { Origin-Host }
                                     { Origin-Realm }
                                     [ Acct-Multi-Session-Id ]
                                     [ User-Name ]
                                     [ Error-Reporting-Host ]
                                     [ Error-Message ]
                                     [ MIP-Reg-Reply ]
                                     [ MIP-Home-Agent-Address ]
                                     [ MIP-Mobile-Node-Address ]
                                     [ MIP-FA-to-HA-SPI ]
                                     [ MIP-FA-to-MN-SPI ]
                                     [ Origin-State-Id ]
                                   * [ Proxy-Info ]
                                   * [ AVP ]

6.  Result-Code AVP Values

   This section defines new Result-Code [DIAMBASE] values that MUST be
   supported by all Diameter implementations that conform to this
   specification.

Top      Up      ToC       Page 28 
6.1.  Transient Failures

   Errors in the transient failures category are used to inform a peer
   that the request could not be satisfied at the time it was received,
   but that it may be able to satisfy the request in the future.

         DIAMETER_ERROR_MIP_REPLY_FAILURE    4005
            This error code is used by the home agent when processing of
            the Registration Request has failed.

         DIAMETER_ERROR_HA_NOT_AVAILABLE     4006
            This error code is used to inform the foreign agent that the
            requested Home Agent cannot be assigned to the mobile node
            at this time.  The foreign agent MUST return a Mobile IPv4
            Registration Reply to the mobile node with an appropriate
            error code.

         DIAMETER_ERROR_BAD_KEY              4007
            This error code is used by the home agent to indicate to the
            local Diameter server that the key generated is invalid.

         DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED   4008
            This error code is used by a mobility agent to indicate to
            the home Diameter server that the requested packet filter
            Rules cannot be supported.

6.2.  Permanent Failures

   Errors that fall within the permanent failures category are used to
   inform the peer that the request failed and SHOULD NOT be attempted
   again.

         DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024
            This error is used by the AAAF to inform the AAAH that
            allocation of a home agent in the foreign domain is not
            permitted at this time.

         DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025
            This error is used by the AAAF/AAAH to inform the peer that
            the requested Mobile IPv4 session keys could not be
            delivered via a security association.

7.  Mandatory AVPs

   The following table describes the Diameter AVPs defined in the Mobile
   IPv4 application; their AVP Code values, types, and possible flag
   values; and whether the AVP MAY be encrypted.

Top      Up      ToC       Page 29 
   Due to space constraints, the short form IPFiltrRule is used to
   represent IPFilterRule, and DiamIdent is used to represent
   DiameterIdentity.

                                            +--------------------------+
                                            |    AVP Flag rules        |
                                            |----+-----+----+-----|----+
                   AVP  Section             |    |     |SHLD| MUST|MAY |
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   MIP-Reg-Request  320  7.1     OctetString| M  |  P  |    |  V  | Y  |
   MIP-Reg-Reply    321  7.2     OctetString| M  |  P  |    |  V  | Y  |
   MIP-MN-AAA-Auth  322  7.6     Grouped    | M  |  P  |    |  V  | Y  |
   MIP-Mobile-Node- 333  7.3     Address    | M  |  P  |    |  V  | Y  |
     Address
   MIP-Home-Agent-  334  7.4     Address    | M  |  P  |    |  V  | Y  |
     Address
   MIP-Candidate-   336  7.9     DiamIdent  | M  |  P  |    |  V  | N  |
     Home-Agent-Host
   MIP-Feature-     337  7.5     Unsigned32 | M  |  P  |    |  V  | Y  |
     Vector
   MIP-Auth-Input-  338  7.6.2   Unsigned32 | M  |  P  |    |  V  | Y  |
     Data-Length
   MIP-             339  7.6.3   Unsigned32 | M  |  P  |    |  V  | Y  |
     Authenticator-Length
   MIP-             340  7.6.4   Unsigned32 | M  |  P  |    |  V  | Y  |
     Authenticator-Offset
   MIP-MN-AAA-SPI   341  7.6.1   Unsigned32 | M  |  P  |    |  V  | Y  |
   MIP-Filter-Rule  342  7.8     IPFiltrRule| M  |  P  |    |  V  | Y  |
   MIP-FA-Challenge 344  7.7     OctetString| M  |  P  |    |  V  | Y  |

   MIP-Originating- 347  7.10    Grouped    | M  |  P  |    |  V  | Y  |
   Foreign-AAA
   MIP-Home-Agent-  348  7.11    DiamIdent  | M  |  P  |    |  V  | N  |
     Host

7.1.  MIP-Reg-Request AVP

   The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and
   contains the Mobile IPv4 Registration Request [MOBILEIP] sent by the
   mobile node to the foreign agent.

7.2.  MIP-Reg-Reply AVP

   The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and
   contains the Mobile IPv4 Registration Reply [MOBILEIP] sent by the
   home agent to the foreign agent.

Top      Up      ToC       Page 30 
7.3.  MIP-Mobile-Node-Address AVP

   The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and
   contains the mobile node's home IP address.

7.4.  MIP-Home-Agent-Address AVP

   The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and
   contains the mobile node's home agent IP address.

7.5.  MIP-Feature-Vector AVP

   The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and
   is added with flag values set by the foreign agent or by the AAAF
   owned by the same administrative domain as the foreign agent.  The
   foreign agent SHOULD include MIP-Feature-Vector AVP within the AMR
   message it sends to the AAAF.

      Flag values currently defined include the following:

            1   Mobile-Node-Home-Address-Requested
            2   Home-Address-Allocatable-Only-in-Home-Realm
            4   Home-Agent-Requested
            8   Foreign-Home-Agent-Available
            16  MN-HA-Key-Request
            32  MN-FA-Key-Request
            64  FA-HA-Key-Request
            128 Home-Agent-In-Foreign-Network
            256 Co-Located-Mobile-Node

   The flags are set according to the following rules.

   If the mobile node includes a valid home address (i.e., one not equal
   to 0.0.0.0 or 255.255.255.255) in its Registration Request, the
   foreign agent sets the Mobile-Node-Home-Address-Requested flag in the
   MIP-Feature-Vector AVP to zero.

   If the mobile node sets the home agent field equal to 255.255.255.255
   in its Registration Request, the foreign agent sets both the Home-
   Agent-Requested flag and the Home-Address-Allocatable-Only-in-Home-
   Realm flag to one in the MIP-Feature-Vector AVP.

Top      Up      ToC       Page 31 
   If the mobile node sets the home agent field equal to 0.0.0.0 in its
   Registration Request, the foreign agent sets the Home-Agent-Requested
   flag to one and zeroes the Home-Address-Allocatable-Only-in-Home-
   Realm flag in the MIP-Feature-Vector AVP.

   Whenever the foreign agent sets either the
   Mobile-Node-Home-Address-Requested flag or the Home-Agent-Requested
   flag to one, it MUST set the MN-HA-Key-Request flag to one.  The MN-
   HA-Key-Request flag is also set to one if the mobile node includes a
   "Generalized MN-HA Key Generation Nonce Request" [MIPKEYS] extension,
   with the subtype set to AAA.

   If the mobile node includes a "Generalized MN-FA Key Generation Nonce
   Request" [MIPKEYS] extension with the AAA subtype (1) in its
   Registration Request, the foreign agent sets the MN-FA-Key-Request
   flag to one in the MIP-Feature-Vector AVP.

   If the mobile node requests a home agent in the foreign network
   either by setting the home address field to all ones, or by
   specifying a home agent in the foreign network, and the AAAF
   authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign-
   Network bit to one.

   If the AAAF is willing and able to assign a home agent in the foreign
   network, the AAAF sets the Foreign-Home-Agent-Available flag to one.

   If the Home Agent receives a Registration Request from the mobile
   node indicating that the MN is acting as a co-located mobile node,
   the home agent sets the Co-Located-Mobile-Node bit to one.

   If the foreign agent's local policy allows it to receive AAA session
   keys and it does not have any existing FA-HA key with the home agent,
   the foreign agent MAY set the FA-HA-Key-Request flag.

   The foreign agent MUST NOT set the Foreign-Home-Agent-Available and
   Home-Agent-In-Foreign-Network flag both to one.

   When the AAAF receives the AMR message, it MUST first verify that the
   sender was an authorized foreign agent.  The AAAF then takes any
   actions indicated by the settings of the MIP-Feature-Vector AVP
   flags.  The AAAF then MAY set additional flags.  Only the AAAF may
   set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-
   Network flags to one.  This is done according to local administrative
   policy.  When the AAAF has finished setting additional flags
   according to its local policy, then the AAAF transmits the AMR with
   the possibly modified MIP-Feature-Vector AVP to the AAAH.

Top      Up      ToC       Page 32 
7.6.  MIP-MN-AAA-Auth AVP

   The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains
   some ancillary data to simplify processing of the authentication data
   in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the
   target AAA server.  Its value has the following ABNF grammar:

         MIP-MN-AAA-Auth ::= < AVP Header: 322 >
                             { MIP-MN-AAA-SPI }
                             { MIP-Auth-Input-Data-Length }
                             { MIP-Authenticator-Length }
                             { MIP-Authenticator-Offset }
                           * [ AVP ]

7.6.1.  MIP-MN-AAA-SPI AVP

   The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and
   indicates the MSA by which the targeted AAA server (AAAH) should
   attempt to validate the Authenticator computed by the mobile node
   over the Registration Request data.

7.6.2.  MIP-Auth-Input-Data-Length AVP

   The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type
   Unsigned32 and contains the length, in bytes, of the Registration
   Request data (data portion of MIP-Reg-Request AVP) that should be
   used as input to the algorithm, as indicated by the MN-AAA-SPI AVP,
   used to determine whether the Authenticator Data supplied by the
   mobile node is valid.

7.6.3.  MIP-Authenticator-Length AVP

   The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32
   and contains the length of the authenticator to be validated by the
   targeted AAA server (i.e., AAAH).

7.6.4.  MIP-Authenticator-Offset AVP

   The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32
   and contains the offset into the Registration Request Data, of the
   authenticator to be validated by the targeted AAA server (i.e.,
   AAAH).

Top      Up      ToC       Page 33 
7.7.  MIP-FA-Challenge AVP

   The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and
   contains the challenge advertised by the foreign agent to the mobile
   node.  This AVP MUST be present in the AMR if the mobile node used
   the RADIUS-style MN-AAA computation algorithm [MIPCHAL].

7.8.  MIP-Filter-Rule AVP

   The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule and
   provides filter rules that have to be configured on the foreign or
   home agent for the user.  The packet filtering rules are set by the
   AAAH by adding one or more MIP-Filter-Rule AVPs in the HAR if
   destined for the home agent and/or in the AMA if destined for the
   foreign agent.

7.9.  MIP-Candidate-Home-Agent-Host

   The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type
   DiameterIdentity and contains the identity of a home agent in the
   foreign network that the AAAF proposes to be dynamically assigned to
   the mobile node.

7.10.  MIP-Originating-Foreign-AAA AVP

   The MIP-Originating-Foreign-AAA AVP (AVP Code 347) is of type Grouped
   and contains the identity of the AAAF, which issues the AMR to the
   AAAH.  The MIP-Originating-Foreign-AAA AVP MUST only be used in cases
   when the home agent is or may be allocated in a foreign domain.  If
   the MIP-Originating-Foreign-AAA AVP is present in the AMR, the AAAH
   MUST copy it into the HAR.

         MIP-Originating-Foreign-AAA ::= < AVP Header: 347 >
                                          { Origin-Realm }
                                          { Origin-Host }
                                        * [ AVP ]

7.11.  MIP-Home-Agent-Host AVP

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

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

Top      Up      ToC       Page 34 
8.  Key Distribution

   The mobile node and mobility agents use session keys (i.e.,
   the MN-FA, FA-HA, and MN-HA session keys) to compute authentication
   extensions applied to MIP registration messages, as defined in
   [MOBILEIP].  If session keys are requested, the AAAH MUST return the
   keys and nonces after the mobile node is successfully authenticated
   and authorized.

   The SPI values are used as key identifiers, and each session key has
   its own SPI value; nodes that share a key can have multiple different
   SPIs all referring to the same key.  In all cases, the entity that
   receives an authentication extension (i.e., that verifies the
   authentication extension) is providing the entity that sends the
   authentication extension (i.e., that computes the authentication
   extension) the value of the SPI to use for that computation.  Note
   that the keys in this model are symmetric in that they are used in
   both directions, even though the SPIs do not have to be symmetric.

   The mobile node allocates SPIs for use in the FA-MN and HA-MN
   mobility security associations, via the Mobile IPv4 AAA Key Request
   extensions [MIPKEYS].  The home agent allocates SPIs for the MN-HA
   and FA-HA mobility security association.  The foreign agent chooses
   SPIs for the MN-FA and HA-FA mobility security associations.

   Once the session keys and nonces have been distributed, subsequent
   Mobile IPv4 registrations need not invoke the AAA infrastructure
   until the keys expire.  As mandated by Mobile IPv4, these
   registrations MUST include the MN-HA authentication extension.
   Likewise, subsequent registrations MUST also include MN-FA
   authentication extension if the MN-FA session key was generated and
   distributed by AAA.  The same hold true for subsequent use of the
   FA-HA authentication extensions.

8.1.  Authorization Lifetime vs. MIP Key Lifetime

   The Diameter Mobile IPv4 application makes use of two timers: the
   Authorization-Lifetime AVP [DIAMBASE] and the MIP-MSA-Lifetime AVP.

   The Authorization-Lifetime contains the number of seconds before the
   mobile node must issue a subsequent MIP registration request.  The
   content of the Authorization-Lifetime AVP corresponds to the Lifetime
   field in the MIP header [MOBILEIP].

   The MIP-MSA-Lifetime AVP contains the number of seconds before
   session keys destined for the mobility agents and the mobile node
   expire.  A value of zero indicates infinity (no timeout).  If not

Top      Up      ToC       Page 35 
   zero, the value of the MIP-MSA-Lifetime AVP MUST be at least equal to
   the value in the Authorization Lifetime AVP.

8.2.  Nonce vs. Session Key

   As described in section 3.4, the AAAH generates session keys and
   transmits them to the home agent and foreign agent.  The AAAH
   generates nonces that correspond to the same keys and transmits them
   to the mobile node.  When it is necessary to protect the session keys
   and SPIs from un-trusted Diameter agents, end-to-end security
   mechanisms such as TLS or IPSec are required to eliminate all
   Diameter Agents between the FA or HA and the AAAH, as outlined above.

   In [MIPKEYS], the mobility security associations are established via
   nonces transmitted to the mobile node via Mobile IPv4.  To provide
   the nonces, the AAAH must generate a random [RANDOM] value of at
   least 128 bits [MIPKEYS].  The mobile node then uses the nonce to
   derive the MN-HA and MN-FA session keys.

   More details of the MN-HA and the MN-FA session key creation
   procedures are found in [MIPKEYS].

   The hashing algorithm used by the mobile node to construct the
   session key has to be the same as that used by the AAAH in the
   session key generation procedure.  The AAAH therefore indicates the
   algorithm used along with the nonce.

   The FA-HA and HA-FA session key is shared between the FA and HA.  The
   AAAH generates a random [RANDOM] value of at least 128 bits for use
   as this session key.

   See sections 9 for details about the format of the AVPs used to
   transport the session keys.

8.3.  Distributing the Mobile-Home Session Key

   If the mobile node does not have an MN-HA session key, then the AAAH
   is likely to be the only trusted entity that is available to the
   mobile node.  Thus, the AAAH has to generate the MN-HA session key.

   The distribution of the HA-MN (session) key to the HA is specified in
   sections 1.2 and 3.4.  The HA and AAAH establish a security
   association (IPSec or TLS) and transport the key over it.  If no
   security association exists between the AAAH and the home agent and a
   security association cannot be established, the AAAH MUST return a
   Result-Code AVP with DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION.

Top      Up      ToC       Page 36 
   The AAAH also has to arrange for the key to be delivered to the
   mobile node.  Unfortunately, the AAAH only knows about Diameter
   messages and AVPs, and the mobile node only knows about Mobile IPv4
   messages and extensions [MOBILEIP].  For this purpose, AAAH includes
   the MN-HA MIP-nonce AVP into a MIP-MN-to-HA-MSA AVP, which is added
   to the HAR (for FA COA style Mobile IPv4) or to the AMA (for
   collocated COA-style Mobile IPv4 messages) and delivered either to a
   local home agent or a home agent in the visited network.  Note that
   the mobile node will use the nonce to create the MN-HA session key by
   using the MN-AAA key it shares with the AAAH [MIPKEYS].  The AAAH has
   to rely on the home agent (which also understands Diameter) to
   transfer the nonce into a Mobile IPv4 "Generalized MN-HA Key
   Generation Nonce Reply" extension [MIPKEYS] in the Registration Reply
   message.  The HA includes the SPIs proposed by the mobile node and
   the home agent in the "Generalized MN-HA Key Generation Nonce
   Request" extension.  The home agent can format the Reply message and
   extensions correctly for eventual delivery to the mobile node.  The
   resulting Registration Reply is added to the HAA's MIP-Reg-Reply AVP.

   The AAAH parses the HAA message, transforms it into an AMA message
   containing an MIP-Reg-Reply AVP, and sends the AMA message to the
   foreign agent.  The foreign agent then uses that AVP to recreate a
   Registration Reply message containing the "Generalized MN-HA Key
   Generation Nonce Reply" extension for delivery to the mobile node.

   In summary, the AAAH generates the MN-HA nonce, which is added to the
   MIP-MN-to-HA-MSA AVP, and a session key, which is added to the
   MIP-HA-to-MN-MSA AVP.  These AVPs are delivered to the home agent in
   HAR or AMA messages.  The home agent retains the session key for its
   own use and copies the nonce from the MIP-MN-to-HA-MSA AVP into a
   "Generalized MN-HA Key Generation Nonce Reply" extension, which is
   appended to the Mobile IPv4 Registration Reply message.  This
   Registration Reply message MUST also include the HA-MN authentication
   extension, which is created by using the newly allocated HA-MN
   session key.  The home agent then includes the Registration Reply
   message and extensions into a MIP-Reg-Reply AVP as part of the HAA
   message to be sent back to the AAA server.

   The key derived by the MN from the MN-HA session nonce is identical
   to the HA-MN session key provided to the HA.

8.4.  Distributing the Mobile-Foreign Session Key

   The MN-FA session nonce is also generated by AAAH (upon request) and
   added to the MIP-MN-to-FA-MSA AVP, which is added to the HAR and
   copied by the home agent into a "Generalized MN-FA Key Generation
   Nonce Reply" extension [MIPKEYS] of the Mobile IPv4 Registration
   Reply message.  The HA also includes the SPIs proposed by the mobile

Top      Up      ToC       Page 37 
   node and foreign agent in the "Generalized MN-FA Key Generation Nonce
   Request" extension.  The AAAH includes the FA-MN session key in the
   MIP-FA-to-MN-MSA AVP in the AMA, to be used by the foreign agent in
   the computation of the FA-MN authentication extension.

   The key derived by the MN from the MN-FA session nonce is identical
   to the FA-MN session key provided to the FA.

8.5.  Distributing the Foreign-Home Session Key

   If the foreign agent requests an FA-HA session key, it also includes
   a MIP-HA-to-FA-SPI AVP in the AMR to convey the SPI to be used by the
   home agent for this purpose.  The AAAH generates the FA-HA session
   key, which is identical to the HA-FA session key, and distributes
   that to both the HA and the FA over respective security associations
   by using the MIP-HA-to-FA-MSA and MIP-FA-to-HA-MSA AVPs.  The HA
   conveys the SPI that the FA MUST use in the HAA; this is similar to
   the way in which the FA conveys that the SPI that the HA MUST use in
   the AMR.  The AAAH later includes these SPIs in the MIP-FA-HA-MSA and
   MIP-HA-FA-MSA AVPs, respectively, along with the session key.

   Refer to Figures 2, 3, 4, and 6 for the messages involved.

   Note that if multiple MNs are registered on the same FA and HA pair,
   then multiple mobility security associations would be distributed.
   However, only one is required to protect the Mobile IP control
   traffic between FA and HA.  This creates an unacceptable level of
   state (i.e., to store the two SPIs and shared key for each FA-HA
   mobility security association).  To improve scalability, the FA and
   HA may discard FA-HA mobility security associations prior to the time
   when they actually expire.  However, if a proper discard policy is
   not chosen, this could cause Mobile IP messages in transit or waiting
   in queues for transmission to fail authentication.

   The FA MUST always use the FA-HA security association with the latest
   expiry time when computing authentication extensions on outgoing
   messages.  The FA MAY discard HA-FA mobility security associations 10
   seconds after a new HA-FA mobility security association arrives with
   a later expiry time.

   The HA SHOULD use the HA-FA mobility security association that has
   the latest expiry time when computing authentication extensions in
   outgoing messages.  However, when the HA receives a new HA-FA
   mobility security association with a later expiry time, the HA SHOULD
   wait 4 seconds for the AMA to propagate to the FA before using the
   new association.  Note that the HA always uses the mobility security
   association from the HAR when constructing the Mobile IP Registration
   Reply in the corresponding HAA.  The HA MAY discard an FA-HA mobility

Top      Up      ToC       Page 38 
   security association once it receives a message authenticated by a
   FA-HA mobility security association with a later expiry time.



(page 38 continued on part 3)

Next RFC Part