AAA Working Group                                        Pat R. Calhoun 
Internet Draft                                                Airespace 
draft-ietf-aaa-diameter-mobileip-15.txt                  Tony Johansson 
Category: Standards Track                                Bytemobile Inc 
                                                     Charles E. Perkins 
                                                  Nokia Research Center 
                                                             Tom Hiller 
                                                               (editor) 
                                                    Lucent Technologies 
                                                          November 2003 
 
 
                     Diameter Mobile IP Application 
 
 
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
      all provisions of Section 10 of RFC2026 [1].  
 
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of 
   six months and may be updated, replaced, or obsoleted by other 
   documents at any time. It is inappropriate to use Internet- Drafts 
   as reference material or to cite them other than as "work in 
   progress."  
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt  
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
1. Abstract 
    
   This document specifies a Diameter application that allows a Diameter 
   server to authenticate, authorize and collect accounting information 
   for Mobile IP services rendered to a mobile node.  Combined with the 
   Inter-Realm capability of the base protocol, this application allows 
   mobile nodes to receive service from foreign service providers. 
   Diameter Accounting messages will be used by the foreign and home 
   agents to transfer usage information to the Diameter servers. 
    
    
2. Conventions used in this document 
    
   <Add any conventions that you use in your document here.  Common 
   conventions are listed below.> 
    
   In examples, "C:" and "S:" indicate lines sent by the client and 
   server respectively. 
    
  
Calhoun et al        Standards Track - March 2004                    1 
                             Diameter MIP                November 2003 
 
 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in RFC-2119 [2]. 
    
    
3. Introduction 
    
   Mobile IP, as defined in [MOBILEIP], defines a method that allows a 
   mobile node to change its point of attachment to the Internet with 
   minimal service disruption. Mobile IP does not provide any specific 
   support for mobility across disparate administrative domains, and 
   therefore does not specify how usage can be accounted for, which has 
   limited the applicability of Mobile IP in a IPv4 commercial 
   deployment.  The Mobile IP specification as defined in [MOBILEIP] 
   recommends mobile nodes to have a static home address and a home 
   agent. However this may not be always possible in certain deployment 
   scenarios. Recent developments in areas that impact IP mobility in 
   the IETF allow Mobile IP [MOBILEIP] to work just as well when mobile 
   nodes do not have a static home agent and home address. In addition, 
   another specification [MIPNAI] allows a mobile node to use its NAI 
   instead of its home address, which better accommodates current 
   administrative practice. 
    
   This document specifies Application-ID 4 to the Diameter base 
   protocol [DIAMBASE] that allows a Diameter server to authenticate, 
   authorize and collect accounting information for Mobile IP services 
   rendered to a mobile node. This application MUST NOT be used in 
   conjunction with the Mobile IPv6 protocol. 
    
   Combined with the Inter-Realm capability of the Diameter base 
   protocol, this application allows mobile nodes to receive service 
   from foreign service providers. The Diameter Accounting messages will 
   be used by the foreign and home agents to transfer usage information 
   to the Diameter servers. 
    
   The Mobile IP protocol [MOBILEIP] specifies a security model that 
   requires that mobile nodes and home agents share a pre-existing 
   security association, which leads to scaling and configuration 
   issues. This specification defines Diameter functions that allow the 
   AAA server to act as a Key Distribution Center (KDC), whereby dynamic 
   session keys are created and distributed to the mobility entities for 
   the purposes of securing Mobile IP Registration messages. Strong 
   authentication and confidentiality of session keys is required, and 
   is to be provided via mutually authenticated TLS or IPsec. 
    
   As with the Diameter base protocol, AAA servers implementing the 
   Mobile IP application can process users' identities supplied in a 
   Network Access Identifier (NAI) format [NAI], which is used for 
   Diameter message routing purposes.  Mobile nodes include their NAI in 
   Registration messages, as defined in [MIPNAI]. The use of the NAI is 
   consistent with the roaming model defined by the ROAMOPS Working 
   Group [EVALROAM]. 
    
  
Calhoun              Standards Track - March 2003                    2 
                             Diameter MIP                November 2003 
 
 
   A home AAA server (AAAH) and foreign AAA server (AAAF), which support 
   the Mobile-IP authentication application 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. 
    
   Given the nature of Mobile IP, a 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. 
    
   Furthermore, the nature of Mobile IP also means that the mobile node 
   will do handoffs between different foreign agents. To guarantee that 
   a registered user always ends up in the same initial AAAH, the mobile 
   node SHOULD 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 SHOULD always include the HA NAI [AAANAI]. If the mobile 
   node does not support the Mobile IP AAA NAI extension [AAANAI], this 
   MAY limit the functionality that can be offered to such a mobile 
   node.  
    
   The Diameter Mobile-IP Application meets the requirements specified 
   in [MIPREQ, CDMA2000]. Later subsections in this introductory section 
   provide some examples and message flows of the Mobile IP and Diameter 
   messages that occur when a mobile node requests service in a foreign 
   network. In this document, the role of the "attendant" [MIPREQ] is 
   performed by either the home agents (for co-located mobile nodes) or 
   foreign agents for the Mobile-IP Application, and these terms will be 
   used interchangeably. 
    
3.2  Inter-Realm Mobile IP 
    
   When a mobile 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 
                        +--------+                     +--------+ 
  
Calhoun              Standards Track - March 2003                    3 
                             Diameter MIP                November 2003 
 
 
                        |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   | mn@xyz.com 
                              +--------+ 
                         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 
   (mn@xyz.com) 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 
  
Calhoun              Standards Track - March 2003                    4 
                             Diameter MIP                November 2003 
 
 
      -----------   -------------   ------------   ----------   ------- 
                    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. 
    
   The above scenario causes the MN-FA and MN-HA keys to be exposed to 
   Diameter agents all along the Diameter route.  A more proper approach 
   is to eliminate the AAAF and other Diameter agents as follows:   
    
    
    
    
    
    
    
    
    
    
    
    
    
  
Calhoun              Standards Track - March 2003                    5 
                             Diameter MIP                November 2003 
 
 
                                       
                                       Local redirect        Home 
        FA                AAAF             Agent           Server                     
               AMR                                                           
          ---------------->                                                  
                              AMA (Redirect)                              
                            ---------------->                      
                              AMA (Redirect)                                
                            <----------------                      
            AMA (Redirect)                                                
          <----------------                                     
                                                   
                         Setup Security Association                                 
          <-------------------------------------------------->                
                                                                   
                                  AMR                                       
           -------------------------------------------------->   
                             AMA (MN-FA key)                        
          <---------------------------------------------------   
    
             Figure 3: Use of a Redirect Server with AMR/AMA 
    
    
   Figure 4 shows the HA and the AAAH are in the same network so it is 
   likely that the HAAA knows the IP address of the HA, and the redirect 
   server would therefore not be needed, but are shown for completeness.  
    
   The FA still provides the challenge and the mobile sends the RRQ, 
   etc., as in the previous figure, however these were eliminated from 
   Figure 3 and 4 to reduce figure clutter.  The redirect server 
   eliminates the AAAF and any other Diameter agents from seeing the 
   keys as they are transported to the FA and HA. 
    
                       Local Redirect            Home 
        HA                  Agent               Server 
                                       HAR            
                              <--------------------   
                                   HAA (Redirect)        
                              -------------------->               
                  Setup Security Association          
         <---------------------------------------->      
                        HAR (MN-HA key)      
         <-----------------------------------------   
                              HAA                               
         ----------------------------------------->   
     
             Figure 4: Use of a Redirect Server with HAR/HAA 
    
        
    
   Accounting messages are sent via Diameter agents, not the direct 
   connection, unless network policies dictate otherwise.  
    
  
Calhoun              Standards Track - March 2003                    6 
                             Diameter MIP                November 2003 
 
 
   A mobile node with AAA NAI extension support [AAANAI], 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, when re-authenticating. So, in the 
   event that the AMR generated by the FA is for a session that was 
   previously authorized, it MUST include the Destination-Host AVP, with 
   the identity of the AAAH found in the AAAH-NAI, and the MIP-Home- 
   Agent-Host AVP with the identity and realm of the assigned HA found 
   in the HA-NAI. If on the other hand the mobile node does not support 
   the AAA NAI extension, the FA may not have the identity of the AAAH 
   and the identity and realm of the assigned HA. This means that 
   without support of the AAA NAI extension, the FA may not be able to 
   guarantee, that the AMR will be destined to the same AAAH, which 
   previously authenticated and authorized the mobile node, since the FA 
   may not know the identity of the AAAH. 
    
   If the mobile node was successfully authenticated, the AAAH checks if 
   the home agent was located in the foreign realm, by checking Home-
   Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. Other 
   AVP's like the MIP-Home-Agent-Host AVP and the MIP-Originating- 
   Foreign-AAA AVP may also be used to verify the location of the home 
   agent. If the home agent is located in the home realm, then the AAAH 
   sends an HAR message to the home agent, which contains a MIP-Reg-
   Request AVP.   
    
   However, as in the case of the AMA and the MN-FA key, using Diameter 
   agents exposes the MN-HA key to Diameter agents along the way.  
   Figure 4 shows the use of a redirect server to avoid this problem.    
    
   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.  Refer 
   to Figure 4 if the HA does not have a direct path to the HA.  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. 
  
Calhoun              Standards Track - March 2003                    7 
                             Diameter MIP                November 2003 
 
 
    
   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 5). 
    
              STR, Session-Id = foo       STR, Session-Id = bar 
              --------------------->      <-------------------- 
         +----+      +------+      +------+                    +----+ 
         | FA |      | AAAF |      | AAAH |                    | HA | 
         +----+      +------+      +------+                    +----+ 
              <---------------------      ---------------------> 
              STA, Session-Id = foo       STA, Session-Id = bar 
                
             Figure 5: Session Termination and Session Identifiers 
    
   Upon receipt of the HAR, the home agent first processes the Diameter 
   message. The home agent processes the MIP-Reg-Request AVP and creates 
   the Registration Reply, encapsulating it within the MIP-Reg-Reply 
   AVP. In the creation of the Registration Reply the Home Agent must 
   include the HA NAI and the AAAH NAI, which will be created from the 
   Origin-Host AVP and Origin-Realm AVP of the HAR. If a home address is 
   needed, the home agent MUST also assign one and include the address 
   in both the Registration Reply and within the MIP-Mobile-Node-Address 
   AVP. 
    
   The HA MUST include an Acct-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 Acct-Multi-Session-Id 
   that was present in the HAA, and the MIP-Home-Agent-Address, MIP-
   Mobile-Node-Address AVPs in the AMA message. See Figure 3 and 4 for 
   the use of the redirect agent for the secure transport of the HAA and 
   AMA messages.   
    
3.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 

  
Calhoun              Standards Track - March 2003                    8 
                             Diameter MIP                November 2003 
 
 
   a foreign agent is not aware that a registration request from a 
   mobile node has been previously authorized. 
    
   A handoff registration request from a mobile node will cause an AMR 
   to be sent to its AAAF. The AMR will include a new session 
   identifier, and MAY be sent to an AAAF in the visited network other 
   than the AAAF, which received the previous AMR. However, with the 
   usage of the AAA NAI, this AMR is guaranteed to be received by the 
   AAAH to which the user is currently registered.   
    
   As discussed above, it may be undesirable for keys, such as the MN-FA 
   keys, to be exposed to any Diameter Agents.  In this case the FA 
   should establish a security association with the AAAH directly, using 
   redirects as described above.  This completely eliminates the AAAF 
   from the transaction.  
    
   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 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. 
    
              ACR, Session-Id = foo         ACR, Session-Id = bar 
              Acct-Multi-Session-Id = a     Acct-Multi-Session-Id = a 
              --------------------->      <-------------------- 
         +----+      +------+      +------+                    +----+ 
         | FA |      | AAAF |      | AAAH |                    | HA | 
         +----+      +------+      +------+                    +----+ 
              <---------------------      ---------------------> 
              ACA, Session-Id = foo       ACA, Session-Id = bar 
    
               Figure 6: Accounting messages w/ Mobile IP Application 
    
    
3.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-
  
Calhoun              Standards Track - March 2003                    9 
                             Diameter MIP                November 2003 
 
 
   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 with AAA NAI extension support 
   [AAANAI] has been previously authorized by the AAAH and now needs to 
   be re-authenticated, and requests to keep the assigned home agent in 
   the foreign network, the mobile node MUST include the HA NAI and the 
   AAAH NAI in the registration request to the FA. Upon receipt, the FA 
   will create the AMR including the MIP-Home-Agent-Address AVP, the 
   Destination-Host AVP based on the AAAH NAI and 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. 
     
   In the event that the mobile node that does not support the AAA NAI 
   extension 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 sends a registration request 
   without the AAA NAI and the HA NAI. Upon receipt, the FA will create 
   the AMR including the MIP-Home-Agent-Address AVP. If the AAAF 
   authorizes the use of the requested home agent, and if it has 
   knowledge that the requested home agent is in its own domain, the 
   AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-
   Feature-Vector AVP. 
    
   As above, the use of Diameter servers in this exchange will expose 
   keys.  If this is deemed undesirable, a redirect server approach 
   should be utilized to communicate the AMR to the AAAH.  This causes 
   the FA to communicate the AMR directly to the AAAH via a security 
   association.  
    
   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-
  
Calhoun              Standards Track - March 2003                   10 
                             Diameter MIP                November 2003 
 
 
   Network is set in the MIP-Feature-Vector AVP, then the AAAH must 
   decide whether its local policy would allow the user to have a Home 
   Agent in the foreign network or to keep the Home Agent in the foreign 
   network. If so, and after checking authorization from the data in the 
   AMR message, the AAAH sends the HAR message to Home Agent by 
   including the Destination-Host AVP set to the value found in the 
   AMR's MIP-Candidate-Home-Agent-Host AVP or MIP-Home-Agent-Host AVP if 
   the HA has been previously allocated and authorized by the AAAH. If 
   the HA has not been previously allocated by the foreign domain, the 
   HAR sent by the AAAH does not contain the MIP-Home-Agent-Address. 
    
   If the AAAH does not have the IP address of the HA and if there isn't 
   a security association, then a redirect server approach of Figure Y 
   should be utilized to communicate the HAR to the HA.  This requires a 
   security association between the AAAH and HA be established. If the 
   redirect server cannot resolve the HA, or no security association can 
   be established, the AAAH MUST return an AMA with the Result-Code AVP 
   set to DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION. 
    
   If Diameter agents are being used (i.e., there is no redirect server, 
   etc.) the AAAH sends the HAR to the originating AAAF. In this HAR the 
   Destination-Host AVP is set to the value found in the AMR's MIP-
   Originating-Foreign-AAA AVP, and the MIP-Home-Agent-Host AVP or the 
   MIP-Candidate-Home-Agent-Host AVP found in the AMR are copied into 
   the HAR. 
    
   Therefore, the AAAH MUST always copy the MIP-Originating-Foreign-AAA 
   AVP from the AMR message to the HAR message.  In cases when another 
   AAAF receives the HAR, this new AAAF will send the HAR to the HA. 
    
                              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 7: Home Agent allocated in Visited Realm 
    
  
Calhoun              Standards Track - March 2003                   11 
                             Diameter MIP                November 2003 

 
 
   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 8: Mobile IP/Diameter Message Exchange when HA is allocated in 
                                  Visited Realm 
    
    
   Figures 9 and 10 shows the secure approach involving redirect agents.  
    
    
                                      Local Redirect          Home 
       FA               FAAA              Agent              Server 
         
              AMR                                                     
         --------------->                                              
                                 AMR  
                          (Redirect, f-HA)                   
                         -------------------->                  
                                 AMA  
                         (Redirect, f-HA))                  
                         <--------------------                  
               AMA  
          (Redirect, f-HA)                                            
         <---------------                                                             
                                 AMR (f-HA)                  
         ------------------------------------------------------>   
                              AMA (MN-FA key)     
         <------------------------------------------------------   
    
                     Figure 9: Use of Redirect Server for AMR/AMA 
    
    
    
  
Calhoun              Standards Track - March 2003                   12 
                             Diameter MIP                November 2003 
 
 
    
    
    
    
    
                       Local Redirect             Home 
       HA                  Agent                 Server   
                                    HAR      
                             <----------------------   
                                   HAA (Redirect)                
                             ---------------------->   
                         HAR (MN-HA key)     
         <------------------------------------------   
                             HAA        
         ------------------------------------------>   
    
               Figure 10: Use of Redirect Server for HAR/HAA 
    
   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 AAAH will have to 
   provide services for both visited networks, e.g., key refresh, per 
   Figures 9 and 10. 
    
    
3.5  Co-located Mobile Node 
    
   In the event that a mobile node registers with the Home Agent as a 
   co-located mobile node, there is no foreign agent involved.  
   Therefore, when the Home Agent receives the Registration Request, an 
   AMR message is sent to the local AAAH server, with the Co-Located-
   Mobile-Node bit set in the MIP-Feature-Vector AVP. The Home Agent 
   also includes the Acct-Multi-Session-Id AVP in the AMR sent to the 
   AAAH, as the AAAH may find this a useful piece of session-state or 
   log entry information. 
    
                                             Home 
                                            Realm 
                                          +--------+ 
                                          |  AAAH  | 
                                          |        | 
                                          | server | 
                                          +--------+ 
                                            ^  | 
                                            |  | 
                                        AMR |  | AMA 
                                            |  v 
                +--------+               +---------+ 
                | Mobile | Registration  |  Home   | 
                | Node   |-------------->|  Agent  | 
                +--------+    Request    +---------+ 
                         
  
Calhoun              Standards Track - March 2003                   13 
                             Diameter MIP                November 2003 
 
 
                      Figure 11: Co-located Mobile Node 
    
   If the MN-HA-Key-Requested bit was set in the AMR message from the 
   Home Agent, the home agent and mobile node's session keys would be 
   present in the AMA message. 
    
   Figure 12 shows the secure solution using redirect servers.  In 
   Figure 12, the Proxy AAA represents any AAA server or servers that 
   the HA may use.  This applies to the visited or home network.   
    
    
    
                                       Local redirect          Home  
       HA           Proxy AAA              Agent              Server 
                                                                          
         AMR                                                               
         --------------->                                              
                             AMR (Redirect)                             
                         -------------------->                
                             AMA (Redirect)                             
                        <---------------------                
         AMA (Redirect)                                            
         <----------------           
                       Setup Security Association 
         <------------------------------------------------------>                
                                      AMR            
         ------------------------------------------------------->   
                              AMA (MN-HA key)    
         <-------------------------------------------------------   
    
     Figure 12: Use of Redirect Server for Co-located CoA and AMR/AMA 
    
3.6  Key Distribution Center (KDC) 
    
   In order to allow the scaling of wireless data access across 
   administrative domains, it is necessary to minimize the specific 
   security associations required. This means that each Foreign Agent 
   should not be required have a pre-configured shared security 
   association with each Home Agent on the Internet, nor should the 
   mobile node be required to have a pre-configured shared security 
   association with any specific home agent or any specific foreign 
   agent, as defined in [MOBILEIP]. 
    
   Diameter Mobile IP application solves this by including a key 
   distribution center (KDC), which means that after a Mobile Node is 
   authenticated, the authorization phase includes the generation of 
   sessions keys.  Specifically, three keys are generated and are 
   required by [MOBILEIP]: 
    
     - K1 - the MN-HA Key, which will work as security association 
   between 
             the Mobile Node and the Home Agent. 
     - K2 - the MN-FA Key, which will work as the security association 
  
Calhoun              Standards Track - March 2003                   14 
                             Diameter MIP                November 2003 
 
 
             between the Mobile Node and the Foreign Agent 
     - K3 - the FA-HA Key, which will work as the security association 
             between the Foreign Agent and the Home Agent 
    
   Figure 13 depicts the new security associations used for Mobile-IP 
   message integrity using the keys derived by the DIAMETER server. 
    
                      +--------+                      +--------+ 
                      |Foreign |          K3          | Home   | 
                      |Agent   |<-------------------->| Agent  | 
                      |        |                      |        | 
                      +--------+                      +--------+ 
                              ^                        ^ 
                              | K2                  K1 | 
                              |       +--------+       | 
                              |       | Mobile |       | 
                              +------>| Node   |<------+ 
                                      |        | 
                                      +--------+ 
             Figure 13 - Security Association after Key Distribution 
    
   If the home agent is assigned in the home network, each key is 
   generated and encrypted by the home Diameter server. If instead the 
   home agent is assigned in the foreign network the K3 key is generated 
   and encrypted by the foreign network's local Diameter server, while 
   the K1 and K2 is still generated and encrypted by the home Diameter 
   server. 
    
   The keys destined for the foreign and home agent are propagated to 
   the mobility nodes via the Diameter protocol, and the keys must be 
   protected either by IPSec or TLS security associations that exist 
   directly between the HA and AAAH or the FA and AAAF, as explained 
   above.   
    
   The keys destined for the mobile node must also be propagated via the 
   Mobile IP protocol and must therefore instead follow the mechanisms 
   described in [aaa-keys].  In [MIPKEYS], the keys distributed to the 
   mobile node are instead sent as a nonce, and the mobile node and the 
   home Diameter will use the nonce and the long-term shared secret to 
   create the keys (see section 5.2). 
    
   Once the session keys have been established and propagated, the 
   mobility devices can exchange registration information directly as 
   defined in [MOBILEIP] without the need of the Diameter 
   infrastructure.  However the session keys have a lifetime, after 
   which the Diameter infrastructure must be invoked again to acquire 
   new session keys. 
    
3.7  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. In order for the 
  
Calhoun              Standards Track - March 2003                   15 
                             Diameter MIP                November 2003 
 
 
   Diameter Server to release any resources allocated to a specific 
   mobile node, the mobility agents MUST send a Session-Termination-
   Request (STR) to the Diameter server that authorized the service. The 
   Session-Termination-Request (STR) MUST be issued by the mobility 
   agents if the Authorization Lifetime has expired and no subsequent 
   MIP registration request have been received. 
    
   The home Diameter server 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 (hand-off) does not 
   cause the Home Diameter Server to free all resources for the mobile 
   node. 
    
   When deallocating all of the mobile node's resources the home 
   Diameter server (and the foreign Diameter server in case of 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. 
    
3.8  Advertising application support 
    
   Diameter nodes conforming to this specification MAY advertise support 
   by including the value of four (4) in the Auth-Application-Id or the 
   Acct-Application-Id AVP of the Capabilities-Exchange-Request and 
   Capabilities-Exchange-Answer command [DIAMBASE]. 
    
4.0  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-Answer        AMA         260          2.2 
         AA-Mobile-Node-Request       AMR         260          2.1 
         Home-Agent-MIP-Answer        HAA         262          2.4 
         Home-Agent-MIP-Request       HAR         262          2.3 
 
4.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: 
    
  
Calhoun              Standards Track - March 2003                   16 
                             Diameter MIP                November 2003 
 
 
    
             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]) 
    
   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. 
    
   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 ] 
  
Calhoun              Standards Track - March 2003                   17 
                             Diameter MIP                November 2003 
 
 
                                    * [ Route-Record ] 
                                    * [ AVP ] 
    
    
4.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 present in the AMR. The 
   Result-Code AVP MAY contain one of the values defined in section 3.0, 
   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-Key, MIP-FA-to-MN-Key if they were requested in the AMR, 
   and they were present in the HAR. The MIP-MN-to-HA-Key and MIP-HA-to-
   MN-Key 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. 
    
   An AMA message with the Result-Code AVP set to 
   DIAMETER_LIMITED_SUCCESS MAY include the MIP-Home-Agent-Address AVP 
   if a dynamically assigned home agent was requested by the mobile 
   node. Upon receipt of this result code, the foreign agent MUST issue 
   the Registration Request to the Home Agent in the manner described in 
   [MOBILEIP]. 
    
   An AMA message with the Result-Code set to DIAMETER_MULTI_ROUND_AUTH 
   MAY include mobile node session key AVPs (see Section 6.1) such as 
   the MIP-MN-to-FA-Key AVP and the MIP-MN-to-HA-Key AVP. If such an AVP 
   is present in the AMA message, the foreign agent MUST include the 
   corresponding Mobile IP key distribution extension in the 
   Registration Reply it sends to the mobile node. This is to support 
   multi-roundtrip authentication mechanisms. 
    
    
      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 ] 
  
Calhoun              Standards Track - March 2003                   18 
                             Diameter MIP                November 2003 
 
 
                                     [ Auth-Session-State ] 
                                     [ Error-Message ] 
                                     [ Error-Reporting-Host ] 
                                     [ Re-Auth-Request-Type ] 
                                     [ MIP-Feature-Vector ] 
                                     [ MIP-Reg-Reply ] 
                                     [ MIP-MN-to-FA-Key ] 
                                     [ MIP-MN-to-HA-Key ] 
                                     [ MIP-FA-to-MN-Key ] 
                                     [ MIP-FA-to-HA-Key ] 
                                     [ MIP-HA-to-MN-Key ] 
                                     [ MIP-Key-Lifetime ] 
                                     [ MIP-Type-Algorithm ] 
                                     [ MIP-Home-Agent-Address ] 
                                     [ MIP-Mobile-Node-Address ] 
                                   * [ MIP-Filter-Rule ] 
                                     [ Origin-State-Id ] 
                                   * [ Proxy-Info ] 
                                   * [ AVP ] 
    
    
4.3  Home-Agent-MIP-Request 
    
   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, is sent by 
   the AAA 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. If the HAR message does not include a MIP-Mobile-Node-Address 
   AVP, and 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 an MIP-Mobile-Node-
   Address AVP. 
    
   When session keys are requested for use by the mobile node (see 
   section 5.0), the AAAH MUST create them and include them in the HAR 
   message.  When a Foreign-Home session key is requested, it will be 
   created and distributed by the AAA server in the same realm as the 
   home agent. 
    
      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 } 
  
Calhoun              Standards Track - March 2003                   19 
                             Diameter MIP                November 2003 
 
 
                                      { MIP-Feature-Vector } 
                                      [ Destination-Host ] 
                                      [ MIP-MN-to-HA-Key ] 
                                      [ MIP-MN-to-FA-Key ] 
                                      [ MIP-HA-to-MN-Key ] 
                                      [ MIP-HA-to-FA-Key ] 
                                      [ MIP-HA-to-FA-SPI ] 
                                      [ MIP-Key-Lifetime ] 
                                      [ MIP-Originating-Foreign-AAA ] 
                                      [ MIP-Mobile-Node-Address ] 
                                      [ MIP-Home-Agent-Address ] 
                                      [ MIP-Type-Algorithm ] 
                                    * [ MIP-Filter-Rule ] 
                                      [ Origin-State-Id ] 
                                    * [ Proxy-Info ] 
                                    * [ Route-Record ] 
                                    * [ AVP ] 
    
    
4.4  Home-Agent-MIP-Answer 
    
   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, is 
   sent by the Home Agent to its local AAA server in response to a Home-
   Agent-MIP-Request. The User-Name MAY be included in the HAA if 
   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 3.0 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 ] 
    
    
5.0  Result-Code AVP Values 
  
Calhoun              Standards Track - March 2003                   20 
                             Diameter MIP                November 2003 
 
 
    
   This section defines new Result-Code [DIAMBASE] values that MUST be 
   supported by all Diameter implementations that conform to this 
   specification. 
 
5.1  Transient Failures 
    
   Errors that fall within the transient failures category are used to 
   inform a peer that the request could not be satisfied at the time it 
   was received, but 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 IP 
            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. 
             
5.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 that the 
            requested Mobile IP session keys could not be encrypted with 
            the CMS strong security application and therefore failed. 
 
5.0  Mandatory AVPs 
    
   The following table describes the Diameter AVPs defined in the Mobile 
   IP application, their AVP Code values, types, possible flag values 
   and whether the AVP MAY be encrypted. 
  
Calhoun              Standards Track - March 2003                   21 
                             Diameter MIP                November 2003 
 
 
    
   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-Filter-Rule  342  5.8     IPFiltrRule| M  |  P  |    |  V  | Y  | 
   MIP-Auth-Input-  338  5.6.2   Unsigned32 | M  |  P  |    |  V  | Y  | 
     Data-Length                            |    |     |    |     |    | 
   MIP-             339  5.6.3   Unsigned32 | M  |  P  |    |  V  | Y  | 
     Authenticator-Length                   |    |     |    |     |    | 
   MIP-             340  5.6.4   Unsigned32 | M  |  P  |    |  V  | Y  | 
     Authenticator-Offset                   |    |     |    |     |    | 
   MIP-Candidate-   336  5.9     DiamIdent  | M  |  P  |    |  V  | N  | 
     Home-Agent-Host                        |    |     |    |     |    | 
   MIP-Home-Agent-  348  5.11    DiamIdent  | M  |  P  |    |  V  | N  | 
     Host                                   |    |     |    |     |    | 
   MIP-FA-Challenge 344  5.7     OctetString| M  |  P  |    |  V  | Y  | 
   MIP-Feature-     337  5.5     Unsigned32 | M  |  P  |    |  V  | Y  | 
     Vector                                 |    |     |    |     |    | 
   MIP-Home-Agent-  334  5.4     Address    | M  |  P  |    |  V  | Y  | 
     Address                                |    |     |    |     |    | 
   MIP-MN-AAA-Auth  322  5.6     Grouped    | M  |  P  |    |  V  | Y  | 
   MIP-MN-AAA-SPI   341  5.6.1   Unsigned32 | M  |  P  |    |  V  | Y  | 
   MIP-Mobile-Node- 333  5.3     Address    | M  |  P  |    |  V  | Y  | 
     Address                                |    |     |    |     |    | 
   MIP-Reg-Request  320  5.1     OctetString| M  |  P  |    |  V  | Y  | 
   MIP-Reg-Reply    321  5.2     OctetString| M  |  P  |    |  V  | Y  | 
   MIP-Originating- 347  5.10    Grouped    | M  |  P  |    |  V  | Y  | 
   Foreign-AAA                              |    |     |    |     |    |          
    
    
5.1  MIP-Reg-Request AVP 
    
   The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and 
   contains the Mobile IP Registration Request [MOBILEIP] sent by the 
   mobile node to the foreign agent. 
    
    
5.2  MIP-Reg-Reply AVP 
    
   The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and 
   contains the Mobile IP Registration Reply [MOBILEIP] sent by the home 
   agent to the foreign agent. 
    
5.3  MIP-Mobile-Node-Address AVP 
  
Calhoun              Standards Track - March 2003                   22 
                             Diameter MIP                November 2003 
 
 
    
   The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and 
   contains the mobile node's home IP address. 
    
   5.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. 
    
5.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: 
            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., not equal to 
   0.0.0.0 or 255.255.255.255) in its Registration Request, the foreign 
   agent zeroes the Mobile-Node-Home-Address-Requested flag in the MIP-
   Feature-Vector AVP. 
    
   If the mobile node sets the home address field equal to 0.0.0.0 in 
   its Registration Request, the foreign agent sets the Mobile-Node-
   Home-Address-Requested flag to one. 
    
   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. 
    
   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 

  
Calhoun              Standards Track - March 2003                   23 
                             Diameter MIP                November 2003 
 
 
   set to one if the mobile node includes a Generalized MN-HA Key 
   Request [MIPKEYS] extension, with the subtype set to AAA. 
    
   If the mobile node includes a Generalized MN-FA Key Request [MIPKEYS] 
   extension with the AAA subtype 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 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 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. 
    
5.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 IP 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 ] 
    
5.6.1  MIP-MN-AAA-SPI AVP 
       
   The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and 
   indicates the algorithm by which the targeted AAA server (AAAH) 
  
Calhoun              Standards Track - March 2003                   24 
                             Diameter MIP                November 2003 
 
 
   should attempt to validate the Authenticator computed by the mobile 
   node over the Registration Request data. 
    
5.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 (indicated by the MN-AAA-SPI AVP) used 
   to determine whether the Authenticator Data supplied by the mobile 
   node is valid. 
    
5.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). 
    
5.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). 
    
5.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. 
    
5.8  MIP-Filter-Rule AVP 
    
   The MIP-Filter-Rule AVP (AVP Code 342) is of type IPFilterRule, and 
   provides filter rules that need 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. 
    
5.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 be dynamically assigned to the 
   mobile node. 
    
5.10 MIP-Originating-Foreign-AAA AVP 
    
   The MIP-Originating-Foreign-AAA AVP (AVP Code 347) if 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 
  
Calhoun              Standards Track - March 2003                   25 
                             Diameter MIP                November 2003 
 
 
   in cases when the home agent is or may be allocated in a foreign 
   domain. If present in the AMR, the AAAH MUST copy the MIP-
   Originating-Foreign-AAA AVP into the HAR. 
    
         MIP-Originating-Foreign-AAA ::= < AVP Header: 347 > 
                                          { Origin-Realm } 
                                          { Origin-Host } 
                                        * [ AVP ] 
    
5.11 MIP-Home-Agent-Host AVP 
    
      The MIP-Home-Agent-Host AVP (AVP Code 348) 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 ] 
    
6.0  Key Distribution Center 
    
   The mobile node and mobility agents use session keys to compute 
   authentication extensions applied to registration messages, as 
   defined in [MOBILEIP]: Mobile-Foreign, Foreign-Home and Mobile-Home. 
   If session keys are requested the AAA server(s) MUST return the key 
   material after the mobile node is successfully authenticated and 
   authorized. 
    
   The SPI values are used as key identifiers, meaning that each session 
   key has its own SPI value; nodes that share a key also share an SPI. 
   The mobile node proposes SPIs for use in computing the Mobile-Foreign 
   and Mobile-Home authentication extensions, via the Mobile IP AAA Key 
   Request extensions [MIPKEYS], while the home agent allocates the 
   Mobile-Foreign, Mobile-Home and Foreign-Home SPIs. 
    
   Once the session keys have been distributed, subsequent Mobile IP 
   registrations need not invoke the AAA infrastructure until the keys 
   expire.  These registrations MUST include the Mobile-Home 
   authentication extension.  In addition, subsequent registrations MUST 
   also include Mobile-Foreign authentication extension if the Mobile-
   Foreign key was generated and distributed by AAA; similarly for 
   subsequent use of the Foreign-Home authentication extensions. 
    
6.1 Authorization Lifetime vs. MIP Key Lifetime 
    
   The Diameter Mobile IP application makes use of two timers - the 
   Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. 
    
   The Authorization-Lifetime contains the number of seconds before the 
   mobile node must issue a subsequent MIP registration request. The 

  
Calhoun              Standards Track - March 2003                   26 
                             Diameter MIP                November 2003 
 
 
   content of the Authorization-Lifetime AVP corresponds to the Lifetime 
   field in the MIP header [MOBILEIP]. 
    
   The MIP-Key-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 zero, 
   the value of the MIP-Key-Lifetime AVP MUST be at least equal to the 
   value in the Authorization Lifetime AVP. 
    
6.2 Key Material vs. Session Key 
    
   As described in section 1.6, session keys and nonces are generated by 
   the AAAH and are transmitted to the home agent, foreign agent and 
   mobile node. Security associations destined for the home and foreign 
   agents are established via transmission of session keys and SPIs, 
   protected by transmission-level security as defined in [DIAMBASE]. 
   Where it is necessary to protect the nonces, session keys, and SPIs 
   from untrusted Diameter agents, end-to-end security mechanisms are 
   required to eliminate the all Diameter Agents between the FA or HA 
   and the AAAH, as outlined above. 
    
   In [MIPKEYS] the mobile node security associations are established 
   via nonces transmitted to the mobile node via Mobile IP. 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 
   procedure are found in [MIPKEYS].  
    
   It is important that the hashing algorithm used by the mobile node to 
   construct the session key is the same as the one used by the AAAH in 
   the session key generation procedure. The AAAH therefore indicates 
   the algorithm used along with the key material. 
    
   The Foreign-Home session key is shared between two mobility agents: 
   the FA and HA. Since this key is not destined for the mobile node, 
   there is no need to follow the session key generation procedures 
   detailed above. Instead, the AAAH generates a random [RANDOM] value 
   of at least 128 bits for use as the Foreign-Home session key. 
    
   See sections 7.0 for details about the format of the AVPs used to 
   transport the session keys. 
    
6.3  Distributing the Mobile-Home Session Key 
    
   If the mobile node does not have a Mobile-Home session key, then the 
   AAAH is likely to be the only entity trusted that is available to the 
   mobile node.  Thus, the AAAH has to generate the Mobile-Home session 
   key, and encode it for eventual consumption by the mobile node and 
   home agent. 
    

  
Calhoun              Standards Track - March 2003                   27 
                             Diameter MIP                November 2003 
 
 
   The distribution of the MN-HA key to the HA has been specified above.  
   The HA and AAAH establish a security association (IPSec or TLS) and 
   transport the key over that security association.  
    
   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.  
    
   The AAAH also has to arrange for the key to be delivered to the 
   mobile node. Unfortunately, the AAA server only knows about Diameter 
   messages and AVPs, and the mobile node only knows about Mobile IP 
   messages and extensions [MOBILEIP].  For this purpose, AAAH includes 
   the Mobile-Home session Key Material AVP into a MIP-MN-to-HA-Key AVP, 
   which is added to the HAR message, and delivered either to a local 
   home agent or a home agent in the visited network. The AAAH has to 
   rely on the home agent (that also understands Diameter) to transfer 
   the keying material (nonce) into a Mobile IP Generalized MN-HA Key 
   Reply extension [MIPKEYS] in the Registration Reply message, using 
   the SPI proposed by the Mobile Node in the MN-HA Key Request From AAA 
   Subtype 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 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 Reply extension for 
   delivery to the mobile node. 
    
   In summary, the AAAH generates the Mobile-Home key material, which is 
   added to the MIP-MN-to-HA-Key AVP, and a session key, which is added 
   to the MIP-HA-to-MN-Key AVP. These AVPs are delivered to the home 
   agent in an HAR message. The home agent retains the session key for 
   its own use, and copies the key material (nonce) from the MIP-MN-to-
   HA-Key AVP into a Generalized MN-HA Key Reply extension, which is 
   appended to the Mobile IP Registration Reply message. This 
   Registration Reply message MUST also include the Mobile-Home 
   authentication extension, created using the newly allocated Mobile-
   Home 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. 
    
6.4  Distributing the Mobile-Foreign Session Key 
    
   The Mobile-Foreign session key material (nonce) is also generated by 
   AAAH (upon request) and is added to the MIP-MN-to-FA-Key Material 
   AVP, which is added to the HAR, and copied by the home agent into a 
   Generalized MN-FA Key Reply Extension [MIPKEYS] to the Mobile IP 
   Registration Reply message, using the SPI proposed by the mobile node 
   in the MN-FA Key Material From AAA Request Subtype extension. The 
   AAAH includes the session key in the MIP-FA-to-MN-Key AVP in the AMA, 

  
Calhoun              Standards Track - March 2003                   28 
                             Diameter MIP                November 2003 
 
 
   to be used by the foreign agent in the computation of the Mobile-
   Foreign authentication extension. 
    
6.5  Distributing the Foreign-Home Session Key 
    
   If the foreign agent requests a foreign home 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 Foreign-Home 
   session key and distributes it to both the HA and the FA over 
   respective security associations to each using the MIP-HA-to-FA and 
   MIP-FA-to-HA-Key AVPs.  The HA conveys the SPI the FA should use in 
   the HAA; the AAAH later includes that in the MIP-FA-HA-Key AVP, along 
   with the session key.  
    
   Refer to Figures 3, 4, 9, and 10 for the messages involved.  
 
7.0  Key Distribution Center (KDC) AVPs 
 
   The Mobile-IP protocol defines a set of security associations shared 
   between the mobile node, foreign agent and home agent. These three 
   security associations (Mobile-Home, Mobile-Foreign, and Foreign-Home) 
   can be dynamically created by the AAAH, and has previously been 
   described in section 1.6 and 5.2. AAA servers supporting the Diameter 
   Mobile IP Application MUST implement the KDC AVPs defined in this 
   document. 
    
   The names of the KDC AVPs indicate the two entities sharing the 
   security association defined by the key or the key material; the 
   intended receiver of the AVP is the first named entity. So, for 
   instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key 
   material (nonce), which the mobile node will use to derive the 
   Mobile-Home Key, and the MIP-HA-to-MN-Key AVP contains the Mobile-
   Home key for the home agent. 
    
   The following table describes the Diameter AVPs defined in the Mobile 
   IP application, their AVP Code values, types, possible flag values 
   and whether the AVP MAY be encrypted. 
    
   [Editor note: The following table has errors.] 
    
    
                                            +--------------------------+ 
                                            |       AVP Flag Rules     | 
                                            |----+-----+----+-----|----+ 
                   AVP  Section             |    |     |SHLD| MUST|MAY | 
   Attribute Name  Code Defined  Value Type |MUST| MAY | NOT|  NOT|Encr| 
   -----------------------------------------|----+-----+----+-----|----| 
   MIP-Algorithm-   345  7.8     Enumerated | M  |  P  |    |  V  | Y  | 
     Type                                   |    |     |    |     |    | 
   MIP-FA-to-HA-Key 328  7.2     Grouped    | M  |  P  |    |  V  | Y  | 
   MIP-FA-to-HA-SPI 318  7.11    Unsigned32 | M  |  P  |    |  V  | Y  | 
   MIP-HA-to-FA-SPI 3**  7.14    Unsigned32 | M  |  P  |    |  V  | Y  | 
   MIP-FA-to-MN-Key 326  7.1     Grouped    | M  |  P  |    |  V  | Y  | 
  
Calhoun              Standards Track - March 2003                   29 
                             Diameter MIP                November 2003 
 
 
   MIP-FA-to-MN-SPI 319  7.10    Unsigned32 | M  |  P  |    |  V  | Y  | 
   MIP-HA-to-FA-Key 329  7.3     Grouped    | M  |  P  |    |  V  | Y  | 
   MIP-HA-to-MN-Key 332  7.4     Grouped    | M  |  P  |    |  V  | Y  | 
   MIP-Key-Lifetime 367  7.13    Unsigned32 | M  |  P  |    |  V  | Y  | 
   MIP-Key-Material 335  7.12    OctetString| M  |  P  |    |  V  | Y  | 
   MIP-MN-to-FA-Key 325  7.5     Grouped    | M  |  P  |    |  V  | Y  | 
   MIP-MN-to-HA-Key 331  7.6     Grouped    | M  |  P  |    |  V  | Y  | 
   MIP-Replay-Mode  346  7.9     Enumerated | M  |  P  |    |  V  | Y  | 
   MIP-Session-Key  343  7.7     OctetString| M  |  P  |    |  V  | Y  | 
 
    
7.1  MIP-FA-to-MN-Key AVP 
    
   The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and 
   contains the foreign agent's session key, which it shares with the 
   mobile node. Its Data field has the following ABNF grammar: 
    
         MIP-FA-to-MN-Key ::= < AVP Header: 326 > 
                              { MIP-FA-to-MN-SPI } 
                              { MIP-Algorithm-Type } 
                              { MIP-Session-Key } 
                            * [ AVP ] 
    
7.2  MIP-FA-to-HA-Key AVP 
    
   The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and 
   contains the foreign agent's session key, which it shares with the 
   home agent. Its Data field has the following ABNF grammar: 
    
         MIP-FA-to-HA-Key ::= < AVP Header: 328 > 
                              { MIP-FA-to-HA-SPI } 
                              { MIP-Algorithm-Type } 
                              { MIP-Session-Key } 
                            * [ AVP ] 
    
    
7.3  MIP-HA-to-FA-Key AVP 
    
   The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and 
   contains the Home Agent's session key, which it shares with the 
   foreign agent. Its Data field has the following ABNF grammar: 
    
         MIP-HA-to-FA-Key ::= < AVP Header: 329 > 
                              { MIP-Algorithm-Type } 
                              { MIP-Session-Key } 
                            * [ AVP ] 
    
7.4  MIP-HA-to-MN-Key AVP 
    
   The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and 
   contains the Home Agent's session key, which it shares with the 
   mobile node. Its Data field has the following ABNF grammar: 
    
  
Calhoun              Standards Track - March 2003                   30 
                             Diameter MIP                November 2003 
 
 
         MIP-HA-to-MN-Key ::= < AVP Header: 332 > 
                              { MIP-Algorithm-Type } 
                              { MIP-Replay-Mode } 
                              { MIP-Session-Key } 
                            * [ AVP ] 
 
7.5  MIP-MN-to-FA-Key AVP 
    
   The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and 
   contains the mobile node's key material (a nonce), which it uses to 
   derive the session key it shares with the foreign agent. The home 
   agent uses this AVP in the construction of the Mobile IP "Unsolicted 
   MN-FA Key from AAA Subtype" extension [MIPKEYS]. The SPI in the 
   extension's FA SPI field is allocated by the home agent, but it 
   SHOULD take into consideration the SPI requested by the mobile node 
   in the "MN-FA Key Request From AAA Subtype" extension. 
    
         MIP-MN-to-FA-Key ::= < AVP Header: 325 > 
                              { MIP-Algorithm-Type } 
                              { MIP-Key-Material } 
                              { MIP-MN-AAA-SPI } 
                            * [ AVP ] 
 
7.6  MIP-MN-to-HA-Key AVP 
    
   The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and 
   contains the mobile node's  key material, which it uses to derive the 
   session key it shares with the Home Agent. The Home Agent uses this 
   AVP in the construction of the Mobile IP "Unsolicted MN-HA Key from 
   AAA Subtype" extension [MIPKEYS]. The SPI in the extension's HA SPI 
   field is allocated by the Home Agent, but it SHOULD take into 
   consideration the SPI requested by the mobile node in the "MN-HA Key 
   Request From AAA Subtype" extension. 
    
         MIP-MN-to-HA-Key ::= < AVP Header: 331 > 
                              { MIP-Algorithm-Type } 
                              { MIP-Replay-Mode } 
                              { MIP-Key-Material } 
                              { MIP-MN-AAA-SPI } 
                            * [ AVP ] 
 
7.7  MIP-Session-Key AVP 
    
   The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and 
   contains the Session Key to be used between two Mobile IP entities. 
    
7.8  MIP-Algorithm-Type AVP 
    
      The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, 
   and 
      contains the Algorithm identifier used to generate the associated 
      Mobile IP authentication extension. The following values are 
      currently defined: 
  
Calhoun              Standards Track - March 2003                   31 
                             Diameter MIP                November 2003 
 
 
    
         1   HMAC-MD5 [HMAC] 
         2   HMAC-SHA-1 [HMAC] 
    
7.9  MIP-Replay-Mode AVP 
    
   The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and 
   contains the replay mode the Home Agent should use when 
   authenticating the mobile node. 
     
   The following values are supported (see [MOBILEIP] for more 
   information): 
    
         1   None 
         2   Timestamps 
         3   Nonces 
 
7.10  MIP-FA-to-MN-SPI AVP 
    
   The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and 
   contains the Security Parameter Index the foreign agent is to use to 
   refer to the session key it shares with the mobile node. The SPI 
   created MUST NOT be a value between zero (0) and 255, which is the 
   reserved namespace defined in [MOBILEIP]. This AVP MAY be added in 
   the HAA message by the home agent for the AAAH's use in MIP-FA-to-MN-
   SPI AVP of the MIP-FA-to-MN-Key AVP. 
    
 
7.11  MIP-FA-to-HA-SPI AVP 
    
   The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and 
   contains the Security Parameter Index the foreign agent is to use to 
   refer to the session key it shares with the home agent. The SPI 
   created MUST NOT be a value between zero (0) and 255, which is the 
   reserved namespace defined in [MOBILEIP]. If FA-HA keys are being 
   generated, this AVP MUST be added in the HAA message by the Home 
   Agent for the AAAH's (or AAAF's) use in providing the value of the 
   MIP-FA-to-HA-SPI member of the grouped MIP-FA-to-HA-Key AVP. 
 
    
7.12  MIP-Key-Material AVP 
    
   The MIP-Key-Material AVP (AVP Code 335) is of type OctetString and 
   contains the key material sent to the mobile node. The mobile node 
   follows the procedures in [MIPKEYS] to generate the session key used 
   to authenticate Mobile IP registration messages. 
    
7.13  MIP-Key-Lifetime AVP 
    
   The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 and 
   represents the period of time (in seconds) for which the session key 
   is valid.  The session key MUST NOT be used if the lifetime has 
   expired; if the key lifetime expires while the session to which it 
  
Calhoun              Standards Track - March 2003                   32 
                             Diameter MIP                November 2003 
 
 
   applies is still active, either the session key MUST be changed or 
   the or the session MUST be terminated. 
    
    
7.14  MIP-HA-to-FA-SPI AVP 
    
   The MIP-HA-to-FA-SPI AVP (AVP Code 3**) is of type Unsigned32, and 
   contains the Security Parameter Index the home agent is to use to 
   refer to the session key it shares with the foreign agent. The SPI 
   created MUST NOT be a value between zero (0) and 255, which is the 
   reserved namespace defined in [MOBILEIP]. If FA-HA keys are being 
   generated, this AVP MUST be added in the HAA message by the Home 
   Agent for the AAAH's (or AAAF's) use in providing the value of the 
   MIP-HA-to-FA-SPI member of the grouped MIP-HA-to-FA-Key AVP. 
    
   The FA should provide this to the AAAH in the AMR, as it should 
   control the assignment of this SPI. 
    
8.0  Accounting AVPs 
 
   [Editor note: Will anyone use the AVPs of this section?  Deployments 
   using MIP, e.g., 3GPP2 have VSAs for this purpose.] 
    
8.1  Accounting-Input-Octets AVP 
 
   The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, 
   and contains the number of octets in IP packets received from the 
   user. This AVP MUST be included in all Accounting-Request messages 
   and MAY be present in the corresponding Accounting-Answer messages as 
   well. 
    
8.2  Accounting-Output-Octets AVP 
    
   The Accounting-Output-Octets AVP (AVP Code 364) is of type 
   Unsigned64, and contains the number of octets in IP packets sent to 
   the user. This AVP MUST be included in all Accounting-Request 
   messages and MAY be present in the corresponding Accounting-Answer 
   messages as well. 
    
8.3  Acct-Session-Time AVP 
    
   The Acct-Time AVP (AVP Code 46) is of type Unsigned32, and indicates 
   the length of the current session in seconds. This AVP MUST be 
   included in all Accounting-Request messages and MAY be present in the 
   corresponding Accounting-Answer messages as well. 
     
8.4  Accounting-Input-Packets AVP 
    
   The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64, 
   and contains the number of IP packets received from the user. This 
   AVP MUST be included in all Accounting-Request messages and MAY be 
   present in the corresponding Accounting-Answer messages as well. 
    
  
Calhoun              Standards Track - March 2003                   33 
                             Diameter MIP                November 2003 
 
 
8.5  Accounting-Output-Packets AVP 
    
   The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64, 
   and contains the number of IP packets sent to the user. This AVP MUST 
   be included in all Accounting-Request messages and MAY be present in 
   the corresponding Accounting-Answer messages as well. 
    
8.6  Event-Timestamp AVP 
    
   The Event-Timestamp (AVP Code 55) is of type Time, and MAY be 
   included in an Accounting-Request message to record the time that 
   this event occurred on the mobility agent, in seconds since January 
   1, 1970 00:00 UTC. 
    
    
9.0  AVP Occurrence Tables 
    
   The following tables presents the AVPs defined in this document, and 
   specifies in which Diameter messages they MAY, or MAY NOT be present. 
   Note that AVPs that can only be present within a Grouped AVP are not 
   represented in this table. 
    
   The table uses the following symbols: 
         0      The AVP MUST NOT be present in the message. 
         0+     Zero or more instances of the AVP MAY be present in the 
               message. 
         0-1    Zero or one instance of the AVP MAY be present in the 
               message. 
         1     One instance of the AVP MUST be present in the message. 
    
    
9.1  Mobile IP Command AVP Table 
    
   The table in this section is limited to the Command Codes defined in 
   this specification. 
    
                                    +-----------------------+ 
                                    |      Command-Code     | 
                                    |-----+-----+-----+-----+ 
      Attribute Name                | AMR | AMA | HAR | HAA | 
      ------------------------------|-----+-----+-----+-----+ 
      Authorization-Lifetime        | 0-1 | 0-1 | 1   | 0   | 
      Auth-Application-Id           | 1   | 1   | 1   | 1   | 
      Auth-Session-State            | 0-1 | 0-1 | 1   | 0   | 
      Acct-Multi-Session-Id         | 0-1 | 0-1 | 0   | 0-1 | 
      Destination-Host              | 0-1 | 0   | 0-1 | 0   | 
      Destination-Realm             | 1   | 0   | 1   | 0   | 
      Error-Message                 | 0   | 0-1 | 0   | 0-1 | 
      Error-Reporting-Host          | 0   | 0-1 | 0   | 0-1 | 
      MIP-Candidate-Home-Agent-Host | 0-1 | 0   | 0-1 | 0   | 
      MIP-Home-Agent-Host           | 0-1 | 0   | 0-1 | 0   | 
      MIP-Originating-Foreign-AAA   | 0-1 | 0   | 0-1 | 0   | 
      MIP-FA-Challenge              | 0-1 | 0   | 0   | 0   | 
  
Calhoun              Standards Track - March 2003                   34 
                             Diameter MIP                November 2003 
 
 
      MIP-FA-to-HA-Key              | 0   | 0-1 | 0-1 | 0   | 
      MIP-FA-to-HA-SPI              | 0   | 0   | 0   | 0-1 | 
      MIP-HA-to-FA-SPI              | 0   | 0   | 0   | 0-1 | 
      MIP-MN-to-FA-Key              | 0   | 0-1 | 0   | 0   | 
      MIP-FA-to-MN-SPI              | 0   | 0   | 0   | 0-1 | 
      MIP-MN-to-FA-SPI              | 0   | 0   | 0   | 0-1 | 
      MIP-MN-to-HA-Key              | 0   | 0-1 | 0   | 0   | 
      MIP-HA-to-MN-SPI              | 0   | 0   | 0   | 0-1 | 
      MIP-MN-to-HA-SPI              | 0   | 0   | 0   | 0-1 | 
      MIP-Feature-Vector            | 0-1 | 0-1 | 1   | 0   | 
      MIP-Filter-Rule               | 0   | 0+  | 0+  | 0   | 
      MIP-Home-Agent-Address        | 0-1 | 0-1 | 0-1 | 0-1 | 
      MIP-Key-Lifetime              | 0   | 0-1 | 0-1 | 0   | 
      MIP-MN-AAA-Auth               | 1   | 0   | 0   | 0   | 
      MIP-Mobile-Node-Address       | 0-1 | 0-1 | 0-1 | 0-1 | 
      MIP-Reg-Reply                 | 0   | 0-1 | 0   | 0-1 | 
      MIP-Reg-Request               | 1   | 0   | 1   | 0   | 
      Origin-Host                   | 1   | 1   | 1   | 1   | 
      Origin-Realm                  | 1   | 1   | 1   | 1   | 
      Origin-State-Id               | 0-1 | 0-1 | 0-1 | 0-1 | 
      Proxy-Info                    | 0+  | 0+  | 0+  | 0+  | 
      Redirect-Host                 | 0   | 0+  | 0   | 0+  | 
      Redirect-Host-Usage           | 0   | 0-1 | 0   | 0-1 | 
      Redirect-Max-Cache-Time       | 0   | 0-1 | 0   | 0-1 | 
      Result-Code                   | 0   | 1   | 0   | 1   | 
      Re-Auth-Request-Type          | 0   | 0-1 | 0   | 0   | 
      Route-Record                  | 0+  | 0   | 0+  | 0   | 
      Session-Id                    | 1   | 1   | 1   | 1   | 
      User-Name                     | 1   | 0-1 | 1   | 0-1 | 
      ------------------------------|-----+-----+-----+-----| 
    
    
9.2  Accounting AVP Table 
   The table in this section is used to represent which AVPs defined in 
   this document are to be present in the Accounting messages, defined 
   in [DIAMBASE]. 
    
                                           +-------------+ 
                                           | Command-Code| 
                                           |------+------+ 
      Attribute Name                       |  ACR |  ACA | 
      -------------------------------------|------+------+ 
      Accounting-Input-Octets              |  1   |  0-1 | 
      Accounting-Input-Packets             |  1   |  0-1 | 
      Accounting-Output-Octets             |  1   |  0-1 | 
      Accounting-Output-Packets            |  1   |  0-1 | 
      Acct-Multi-Session-Id                |  1   |  0-1 | 
      Acct-Session-Time                    |  1   |  0-1 | 
      MIP-Feature-Vector                   |  1   |  0-1 | 
      MIP-Home-Agent-Address               |  1   |  0-1 | 
      MIP-Mobile-Node-Address              |  1   |  0-1 | 
      Event-Timestamp                      | 0-1  |   0  | 
      -------------------------------------|------+------+ 
  
Calhoun              Standards Track - March 2003                   35 
                             Diameter MIP                November 2003 
 
 
 
    
10.0  IANA Considerations 
    
    
   This section contains the namespaces that have either been created in 
   this specification, or the values assigned to existing namespaces 
   managed by IANA. 
    
    
10.1  Command Codes 
    
   This specification assigns the values 260 and 262 from the Command 
   Code namespace defined in [DIAMBASE]. See section 2.0 for the 
   assignment of the namespace in this specification. 
    
    
10.2  AVP Codes 
    
   This specification assigns the values 318-348 and 363-367 from the 
   AVP Code namespace defined in [DIAMBASE]. See sections 4.0 and 6.0 
   for the assignment of the namespace in this specification. 
    
    
10.3  Result-Code AVP Values 
    
   This specification assigns the values 4005-4008, and 5024-5025 from 
   the Result-Code AVP (AVP Code 268) value namespace defined in 
   [DIAMBASE].  See section 3.0 for the assignment of the namespace in 
   this specification. 
    
10.4  MIP-Feature-Vector AVP Values 
    
   There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that 
   are available for assignment. This document assigns bits 1-9, 
   aslisted in section 4.5. The remaining bits should only be assigned 
   via Standards Action [IANA]. 
    
10.5  MIP-Algorithm-Type AVP Values 
    
   As defined in Section 6.8, the MIP-Algorithm-Type AVP (AVP Code 345) 
   defines the values 1-3. All remaining values are available for 
   assignment via Designated Expert [IANA]. 
    
10.6  MIP-Replay-Mode AVP Values 
    
   As defined in Section 6.9, the MIP-Replay-Mode AVP (AVP Code 346) 
   defines the values 1-3. All remaining values, except zero, are 
   available for assignment via Designated Expert [IANA]. 
    
10.7  Application Identifier 
    

  
Calhoun              Standards Track - March 2003                   36 
                             Diameter MIP                November 2003 
 
 
   This specification assigns the value four (4) to the Application 
   Identifier namespace defined in [DIAMBASE]. See section 1.8 for more 
   information. 
 
11.0  Security Considerations 
    
   This specification describes a Mobile IP Diameter Application for 
   authenticating and authorizing a Mobile IP mobile node. The 
   authentication algorithm used is dependent upon the transforms used 
   within the Mobile IP protocol, and [MIPCHAL]. This specification, 
   conjunction with [MIPKEYS] also defines a method by which the home 
   Diameter server can create and distribute session keys and nonces for 
   use in authenticating and integrity-protecting Mobile IP registration 
   messages [MOBILEIP]. The key distribution is asymmetric since 
   communication with the mobile node occurs via the Mobile IP protocol 
   [AAAKEY, MOBILEIP], while communication to the Home Agent and Foreign 
   Agent occurs via the Diameter protocol.  Where untrusted Diameter 
   agents are present, end-to-end security MUST be used Between the AAAH 
   and the HA/FA. 
    
   Nonces are sent to the mobile node, which are used to generate the 
   session keys via the HMAC-MD5 one-way function. If the nonces are 
   compromised, then the pre-shared key between the mobile node and the 
   home Diameter server would be vulnerable to an offline dictionary 
   attack. To prevent this, the pre-shared key between the mobile node 
   and the home Diameter server SHOULD be a randomly chosen quantity of 
   at least 96 bits.   
    
   Since the session key is determined by the long-term secret and the 
   nonce, the nonce SHOULD be temporally and globally unique; if the 
   nonce were to repeat, then so would the session key. To prevent this, 
   a nonce is strongly recommended to be random [RANDOM] value of at 
   least 128 bits. The long-term secret between the MN and HA MUST be 
   periodically refreshed, to guard against recovery of the long-term 
   secret due to nonce reuse or other factors. This is accomplished 
   using out-of-band mechanisms, which are not specified in this 
   document. 
    
   It should also be noted that it is not recommended to set the MIP-
   Session-Key AVP value equal to zero, since keeping session keys for a 
   long time (no refresh) increases the level of vulnerability. 
    
    
12.0 References 
    
12.1 Normative 
    
   [DIAMBASE]     P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. 
                  Rubens, 
                  "Diameter Base Protocol", draft-ietf-aaa-diameter- 
                  17.txt (editor queue status), December 2002. 
    
   [IANA]         Narten, Alvestrand, "Guidelines for Writing an IANA C 
  
Calhoun              Standards Track - March 2003                   37 
                             Diameter MIP                November 2003 
 
 
                  Considerations Section in RFCs", BCP 26, RFC 2434, 
                  October 1998 
    
   [MOBILEIP]     C. Perkins, Editor. IP Mobility Support. RFC 3344, 
                  August 2002. 
    
   [MIPCHAL]      C. Perkins, P. Calhoun, "Mobile IP Challenge/Response 
                  Extensions", draft-ietf-mip4-rfc3012bis-00.txt. 
                  November 2003. 
    
   [NAI]          B. Aboba, M. Beadles "The Network Access Identifier."  
                  RFC 2486.  January 1999. 
    
   [HMAC]         H. Krawczyk, M. Bellare, and R. Cannetti.  HMAC: 
                  Keyed Hashing for Message Authentication.  RFC 2104, 
                  February 1997. 
    
   [MIPKEYS]      C. Perkins, P. Calhoun, "AAA Registration Keys for 
                  Mobile IP", draft-ietf-mipv4-aaa-key-00.txt,  
                  IETF work in progress, November 2003. 
    
   [AAANAI]       F. Johansson, T.Johansson, "AAA NAI for Mobile IP  
                  Extension", draft-mobileip-aaa-nai-05.txt, IETF work 
                  In progress, March 2003. 
    
   12.2 Informative 
    
   [MIPREQ]       S. Glass, S. Jacobs, C. Perkins, "Mobile IP  
                  Authentication, Authorization, and Accounting 
                  Requirements". RFC 2977. October 2000. 
                  
   [CDMA2000]     T. Hiller and al, "CDMA2000 Wireless Data Requirements 
                  for AAA", RFC 3141, June 2001. 
    
   [KEYWORDS]     S. Bradner, "Key words for use in RFCs to Indicate 
                  Requirement Levels", BCP 14, RFC 2119, March 1997. 
    
   [EVALROAM]     B. Aboba, G. Zorn, "Criteria for Evaluating Roaming 
                  Protocols", RFC 2477, January 1999. 
    
   [MIPNAI]       P. Calhoun, C. Perkins, "Mobile IP Network Address 
                  Identifier Extension", RFC 2794, March 2000. 
 
   [RANDOM]       D. Eastlake, 3rd, S. Crocker, and J. Schiller. 
                  Radomness Recommendations for Security. RFC 1750,  
                  Internet Engineering Task Force, December 1994. 
                   
    
    
   13.0  Acknowledgements 
    
   The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and 
   Pankaj Patel for their participation in the pre-IETF Document Reading 
  
Calhoun              Standards Track - March 2003                   38 
                             Diameter MIP                November 2003 
 
 
   Party, to Erik Guttman for his very useful proposed text, and to 
   Fredrik Johansson, Martin Julien and Bob Kopacz for their very useful 
   contributed text.  
    
   The authors would also like to thank the participants of 3GPP2's TSG-
   X working group for their valuable feedback and also the following 
   people for their contribution in the development of the protocol: 
    
   Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael 
   Chen, Henry Haverinen, Johan Johansson.  In addition, general text 
   for use with the redirect server were borrowed from Diameter-EAP text 
   by Pasi Eronen.  
    
   Pat Calhoun would like to thank Sun Microsystems since most of the 
   effort put into this document was done while he was in their employ.  
    
    
   14.0  Authors' Addresses 
    
      Questions about this memo can be directed to: 
    
         Pat Calhoun 
         Airespace 
         110 Nortech Parkway 
         San Jose, CA 95154 
         USA 
    
         Phone: +1 408-635-2023 
         Email: pcalhoun@airespace.com 
    
         Tony Johansson 
         Bytemobile, Inc 
         2029 Stierlin Court 
         Mountain View, California 94043 
         USA 
    
         Phone:  +1 650-641-7817 
           Fax:  +1 650-641-7701 
         E-Mail: tony.johansson@bytemobile.com 
    
         Charles E. Perkins 
         Nokia Research Center 
         313 Fairchild Drive 
         Mountain View, California 94043 
         USA 
    
         Phone:  +1 650-625-2986 
           Fax:  +1 650-625-2502 
         E-Mail: charliep@iprg.nokia.com 
 
         Tom Hiller 
         Lucent Technologies 
         1960 Lucent Lane  
  
Calhoun              Standards Track - March 2003                   39 
                             Diameter MIP                November 2003 
 
 
         Naperville, IL 60566 
         USA 
         Phone: +1 630-979-7673 
         E-mail: tomhiller@lucent.com 
    
    















































  
Calhoun              Standards Track - March 2003                   40 
                             Diameter MIP                November 2003 
 
 
    
Full Copyright Statement 
 
   "Copyright (C) The Internet Society (date). All Rights Reserved. 
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implmentation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into 
    
    
 
   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP 
      9, RFC 2026, October 1996. 
    
   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997 
    




























  
Calhoun              Standards Track - March 2003                   41