MIP4 Working Group A. Muhanna Internet-Draft M. Khalil Intended status: Informational Nortel Networks Expires: December 30, 2007 June 28, 2007 MIPv4 Authentication Performance Using RADIUS and Diameter MIPv4 draft-muhanna-diameter-mip4-performance-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on December 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Current Mobile IPv4 deployments use RADIUS based MIPv4 user authentication and authorization. Diameter Mobile IPv4 Application [RFC4004] offers another method for MIPv4 authentication, authorization, and dynamic mobility security association allocation, e.g. MN-HA SA allocation. Some SDOs are considering the use of Diameter Mobile IPv4 Application to replace RADIUS based mechanism. This document presents an analysis of the performance and impact of Diameter MIPv4 Application and RADIUS based solutions on the time the Muhanna & Khalil Expires December 30, 2007 [Page 1] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 mobile node uses during the initial session setup. Some common MIPv4 scenarios which require the mobile node to retransmit its initial RRQ message have been identified and used. The set of assumptions and requirements used for this study has been clearly documented under section 5. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mobile IPv4 Authentication and Authorization Models . . . . . 4 4. Authentication and Authorization Model and MIPv4 RRQ Retransmission . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Performance Requirements and Assumptions . . . . . . . . . . . 7 6. RADIUS Based Model Performance . . . . . . . . . . . . . . . . 8 6.1. RADIUS Based Model Handling of Scenario No. 1 . . . . . . 9 6.2. RADIUS Based Model Handling of Scenario No. 2 . . . . . . 9 6.3. RADIUS Based Model Handling of Scenario No. 3 . . . . . . 9 6.4. RADIUS Based Model Handling of Scenario No. 4 . . . . . . 10 7. Diameter MIPv4 Application Based Model Performance . . . . . . 11 7.1. Diameter MIPv4 Model Handling of Scenario No. 1 . . . . . 11 7.2. Diameter MIPv4 Model Handling of Scenarios 2 and 3 . . . . 11 7.3. Diameter MIPv4 Model Handling of Scenario No. 4 . . . . . 13 8. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Muhanna & Khalil Expires December 30, 2007 [Page 2] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 1. Conventions used in this document The keywords "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 [4]. All the general mobility and AAA related terminologies and abbreviations are to be interpreted as defined in IPv4 Mobility Support specification [RFC-3344], Diameter Mobile IPv4 Application specification [RFC-4004], and RADIUS related AAA protocol specifications [e.g. RFC2865]. 2. Introduction RADIUS based MIPv4 user authentication and authorization and to some extent MN-HA SA allocation model is widely used in current Mobile IPv4 deployments. On the other hand, Diameter Mobile IPv4 Application [RFC4004] offers another model for MIPv4 authentication, authorization, and dynamic mobility security association allocation, e.g. MN-HA SA allocation. Some SDOs are currently evaluating and considering the use of Diameter Mobile IPv4 Application to replace RADIUS based mechanism. This document presents an analysis of the expected performance and impact of Diameter MIPv4 Application model in comparison to RADIUS based solutions on the amount of time the mobile node uses during the initial session setup. During mobile IPv4 session setup, in many occasions and due to several network conditions, the MN is required to retransmit the initial RRQ to successfully register its point of attachment with its Home agent. In section 4, some of the common MIPv4 scenarios, which require the mobile node to retransmit its initial RRQ message have been identified and used as a base for this analysis. Moreover, the set of assumptions and requirements used for this analysis has clearly been documented under section 5. After this Introduction, a brief summary and background of the Mobile IPv4 Authentication and Authorization models are introduced under section 3. Section 4 present how mobile IPv4 initial registration request message is retransmitted during initial session setup and its handling in the different authentication and authorization models. Common scenarios which require the mobile node to retransmit initial RRQ are also presented. In section 5, all the requirements and assumptions used in the analysis of this study are captured. Sections 6 and 7 present the behavior of RADIUS and Diameter Mobile IPv4 Application models, respectively. The summary and conclusion of this study is presenetd under section 8. Muhanna & Khalil Expires December 30, 2007 [Page 3] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 3. Mobile IPv4 Authentication and Authorization Models Currently, there are several Mobile IPv4 deployments which use standard RADIUS AAA protocol (e.g. RFC2865) to authenticate and authorize mobile IPv4, MIPv4, users. In these deployments, Foreign Agent, FA, for example, uses RADIUS protocol to communicate with the home AAA server to authenticate MIPv4 users using MN-AAA Authentication extension in a CHAP-like mechanism [RFC3012]. Although, there is not a standardized defined interface between the Home Agent and the home AAA server, yet, these deployments use RADIUS to authenticate, authorize, and sometimes to download a dynamic MN-HA security association parameters, for example, MN-HA secret key. In the RADIUS based MIPv4 model, the access network, FA, uses one round trip to authenticate the MIPv4 user by validating the MIPv4 RRQ using the MN-AAA authentication extension via the Home AAA, H-AAA. As soon as the FA receive a successful authentication indication it relays the Mobile IPv4 Registration Request message, RRQ, to the HA to do its validation and authorization of the user. If the HA does not have the proper security parameters available after receiving the user initial RRQ, the HA uses RADIUS protocol to download the MN-HA SA parameters, e.g. MN-HA secret key, from the home AAA server. Figure 1 presents an example of the call flow of a MIPv4 session establishment using RADIUS based AAA protocol for MIPv4 user authentication and authorization. Alternatively, Diameter Mobile IPv4 Application [RFC4004] introduces a new mechanism for MIPv4 user authentication and authorization using Diameter as AAA protocol. In this application, initial mobile IPv4 registration (RRQ and RRP messages) between the FA and HA is completely transported via the Diameter AAA infrastructure using Diameter AMR and AMA messages to carry the MIPv4 RRQ and RRP messages in addition to other authentication, authorization, and dynamic SA attributes. Figure 2 presents an example of the call flow of a MIPv4 session setup using Diameter MIPv4 Application as AAA protocol for MIPv4 user authenticating and authorization. Muhanna & Khalil Expires December 30, 2007 [Page 4] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 MN FA HA H-AAA | | | | | | | | |RRQ(MN-AAA AE) | | |------------>| RADIUS Access Rqst [MN-AAA Auth] | | |------------------------------------------->| | | | | | | RADIUS Access Accept [Auth. + Authorized] | | |<-------------------------------------------| | | | | | | RRQ | | | |------------------------>| | | | NO MN-HA SA | | | + | | | Auth. Needed | | | | | | | | Access Request | | | |----------------->| | | | | | | | Access Accept | | | |<-----------------| | | | | | | Validate RRQ | | | Cache MN-HA SA | | | RRP | | | |<------------------------| | |RRP(Success) | | | |<------------| | | | | | | Figure 1: MIPv4 Session Establishment Using RADIUS Based Model Muhanna & Khalil Expires December 30, 2007 [Page 5] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 MN FA HA H-AAA | | | | | | | | |RRQ(MN-AAA AE) | | |------------>| Diameter AMR [MN-AAA Auth, RRQ, etc.] | | |------------------------------------------->| | | | | | | | HAR [MN-HA SA] | | | |<-----------------| | | | | | | | HAA [RRP] | | | |----------------->| | | | | | | Diameter AMA [Auth. + Authorized, RRP] | | |<-------------------------------------------| | RRP(Success)| | | |<------------| | | | | | | Figure 2: MIPv4 Session Establishment Using Diameter MIPv4 Application Model 4. Authentication and Authorization Model and MIPv4 RRQ Retransmission Mobile IPv4 protocol [RFC3344] uses UDP transport for MIPv4 control messages, registration request and registration reply. Since UDP transport does not guarantee delivery of its packets, MIPv4 protocol offers its own retransmission mechanism to guarantee delivery of MIPv4 control messages as in section 3.6.3. [RFC3344]. According to RFC3344, if the mobile node does not receive a registration replay within a period of time, the mobile node MUST NOT retransmit the registration request within less than 1 second from the time it sent the initial RRQ. RFC3344 also requires that the mobile node SHOULD at least wait twice the previous period before the next retransmission. In wireless network, air link resources is very expensive and getting the mobile node to register with the HA as quickly as possible is a high priority. In order to achieve this objective, the mobile node, in many deployments, retransmits its initial registration request after only 1 second of its initial RRQ. When FA receives the initial RRQ, FA contacts its local AAA server in order to facilitate the MIPv4 user authentication and authorization Muhanna & Khalil Expires December 30, 2007 [Page 6] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 by contacting the home AAA server of the MIPv4 user. While the FA is trying to authenticate and authorize the MIPv4 user credential using information from the initial RRQ, the following scenarios present the main possible MIPv4 registration request retransmissions: 1. FA receives a retransmitted RRQ from the MN before receiving a response from the home AAA server via its local AAA server. 2. FA receives a retransmitted RRQ after the FA has already received a successful response from the home AAA server but the FA has not yet relayed the initial RRQ to the HA. 3. FA receives a retransmitted RRQ after the FA has already received a successful response from the home AAA server and after the FA has already relayed the initial RRQ to the HA and waiting for the RRP. 4. FA receives a retransmitted RRQ after the FA already has received a MIPv4 registration reply from the HA but has not yet relayed the reply to the mobile node. The first three scenarios capture the most common scenarios of the retransmission of the initial MIPv4 RRQ while the FA is trying to authenticate and authorize the MIPv4 user. The fourth scenario does not happen while the FA is waiting for the MIPv4 authentication and authorization, however, it is very relevant to the performance comparison addressed in this draft and based on that it was considered. Other more complicated scenarios may happen which involve the retransmission of the AAA message between the FA and its local/home AAA server in addition to the MIPv4 registration request retransmission. However, these other scenarios are either common to both MIPv4 AAA models or their impacts are already covered by the above scenarios. 5. Performance Requirements and Assumptions The following bullets capture the base general assumptions and requirements for this performance comparison and analysis. o The scenarios listed under section 3 of this document will be used as a base for this performance comparison. o FA-AAA Round Trip: Is defined as the round trip between the FA and the home AAA server using a RADIUS or Diameter MIPv4 Application based AAA protocol. Muhanna & Khalil Expires December 30, 2007 [Page 7] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 o HA-AAA-RADIUS Round Trip: Is defined as the round trip between the HA and the home AAA server using a RADIUS based AAA protocol. o AAA-HA-DIAMETER Round Trip: Is defined as the round trip between the home AAA server and the HA using Diameter MIPv4 Application based AAA protocol. o The cost of a RADIUS based FA-AAA-RADIUS round trip is equal to the Diameter MIPv4 Application based FA-AAA-DIAMETER round trip. o The cost of a RADIUS HA-AAA round trip is equal to a Diameter MIPv4 Application AAA-HA round trip. o Only successful authentication and authorization scenarios are considered. However, due to some network condition, a delay causes the MN not to receive the initial MIPv4 RRP message on time which forces the MN to retransmit the initial RRQ message. o All network setup and geographical location of the different MIP agents/ entities and AAA infrastructure are exactly the same in both cases. o In the case of HA-AAA RADIUS interface, if the HA receives a retransmitted RRQ while waiting for home AAA server response or after receiving a home AAA server response, the HA is able to cache the MN-HA SA parameters and MIPv4 user service authorization based on the home AAA server response in connection with the initial RRQ. In this case, the HA is not required to contact the home AAA again for the retransmitted RRQ. 6. RADIUS Based Model Performance In the RADIUS model, FA uses RADIUS AAA protocol to build an access request message, using related information from the MIPv4 initial RRQ, and by contacting the local AAA server to facilitate the authentication and authorization of the MIPv4 user through the user home AAA server. This process involves a single round trip RADIUS messages, access request and access accept or access reject in the case of failure, between the FA and the AAA server (local/home). In this model, home AAA server is not required to communicate with the HA while the FA is waiting for the AAA server response. On the other hand, the HA MAY communicate with the home AAA server only after the MIPv4 user is successfully authenticated and authorized by the home AAA and consequently the FA has relayed the initial RRQ and the HA has received it. In the case when the HA does Muhanna & Khalil Expires December 30, 2007 [Page 8] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 not have the MN-HA security association parameters available, e.g. MN-HA secret key, or MIPv4 service authorization requires the home AAA server approval, the HA builds and sends a RADIUS access request based on the MIPv4 user identity and the RRQ information to the home AAA. This RADIUS access request is used to request the MN-HA SA parameters and the user MIPv4 service authorization in order to enable the HA to validate the MIPv4 RRQ and offer the MIPv4 mobility service. The cost of such process is one HA-AAA round trip. In general, after the user is authenticated and authorized at the FA by the home AAA server and the FA is waiting for a response from the user HA, the FA MAY relay any retransmitted RRQ directly to the HA without the need to contact the home AAA server. In this case, the FA depends on the HA to authenticate and authorize the retransmitted RRQ. 6.1. RADIUS Based Model Handling of Scenario No. 1 In this scenario and since the FA is in the waiting state to home AAA response, FA contacts the home AAA server similar to the initial RRQ. The FA builds a RADIUS access accept message and send it to the local AAA server exactly similar to its handling of the initial RRQ. This scenario adds a cost of an extra FA-AAA round trip to initial the call setup. 6.2. RADIUS Based Model Handling of Scenario No. 2 In this scenario and since the FA has received the successful home AAA server response, the FA , based on local policy, relays the retransmitted RRQ after the initial RRQ without contacting the home AAA server for retransmitted RRQ authentication and authorization. This scenario adds a cost of ZERO FA-AAA round trip to the initial call setup. Figure 3 shows an example of how RADIUS based AAA model handles a retransmitted initial MIPv4 RRQ. 6.3. RADIUS Based Model Handling of Scenario No. 3 This scenario is similar to scenario No. 2 and the FA, based on local policy, relays the retransmitted RRQ to the HA without contacting the home AAA server to authenticate and authorize the user based on the MIPv4 retransmitted RRQ. This scenario adds a cost of ZERO FA-AAA round trip to the initial call setup. Muhanna & Khalil Expires December 30, 2007 [Page 9] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 MN FA HA H-AAA | | | | | | | | | RRQ(i) | | | | [MN-AAA AE] | | | |------------>| RADIUS Access Rqst [MN-AAA CHAP Auth] | | |------------------------------------------->| | | | | | | RADIUS Access Accept [Auth. + Authorized] | | |<-------------------------------------------| | | RRQ(i) | | | |------------------------>| | | FA Waiting NO MN-HA SA | | for RRP(i) + | | RRQ(r) | Auth. Needed | |------------>| | Access Request | | User Has Been |----------------->| | Authenticated | Access Accept | | Relay RRQ(r) |<-----------------| | | RRQ(r) Validate RRQ(i) | | |-------------------> Queue RRQ(r) | | | RRP(i) Cache MN-HA SA | | RRP(i) |<------------------------| | |<------------| RRP(r) Validate RRQ(r) | | RRP(r) |<------------------------| | |<------------| | | | | | | Figure 3: Handling of MIPv4 Retransmitted RRQ during Session Establishment Based on RADIUS AAA Model 6.4. RADIUS Based Model Handling of Scenario No. 4 In this scenario and since the FA has received the successful home AAA server response and a successful RRP from the HA, the FA relays the retransmitted RRQ to the HA without contacting the home AAA server to authenticate and authorize the user based on the retransmitted RRQ. This scenario adds a cost of ZERO FA-AAA round trip to the initial call setup. Muhanna & Khalil Expires December 30, 2007 [Page 10] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 7. Diameter MIPv4 Application Based Model Performance In the Diameter MIPv4 Application AAA protocol model, FA uses Diameter MIPv4 application AAA protocol to build an AMR message, using related information from the MIPv4 initial RRQ, and by contacting the local AAA server to facilitate the authentication and authorization of the MIPv4 user through the user home AAA server. After the home AAA server receives the AMR message, home AAA server allocate the proper HA, statically or dynamically, and after authenticating the MIPv4 RRQ based on MN-AAA authentication extension, home AAA server builds HAR and sends it to the HA. The HAR includes necessary MN-HA SA parameters, e.g. MN-HA secret key, and possibly the HA-FA SA parameters, e.g. FA-HA secret key and FA-HA SPI. After the HA receives the HAR, it extracts the MN-HA SA parameters to build the MN-HA AE and then build a MIPv4 RRP that is then mapped to the proper attributes of the HAA. HA sends the HAA back to the home AAA server for the home AAA server to build a AMA and communicate back to the FA through the local AAA server. This process always involves a single FA-AAA-DIAMETER round trip and AAA-HA-DIAMETER round trip. In this model, home AAA server is always required to communicate with the HA while the FA is waiting for the home AAA server response which is dependent on the HA to successfully process the HAR and build the RRP and send the HAA back to the home AAA server. In general, after the user is authenticated and authorized at the FA by the home AAA server and the FA receives a retransmitted RRQ, the FA has no other choice other than contacting the home AAA server via the local AAA server. In this case, contacting the home AAA server always add one FA-AAA-DIAMETER and one AAA-HA-DIAMETER round trips. 7.1. Diameter MIPv4 Model Handling of Scenario No. 1 In this scenario and since the FA is in the waiting state for the home AAA response, FA contacts the home AAA server similar to the initial RRQ. The FA builds an AMR message and send it to the local AAA server exactly similar to its handling of the initial RRQ. This scenario adds a cost of one FA-AAA-DIAMETER and one AAA-HA- DIAMETER round trips to the initial call setup. 7.2. Diameter MIPv4 Model Handling of Scenarios 2 and 3 In the case of Diameter MIPv4 application model, both scenarios No. 2 and 3 mean one single scenario since the FA does not communicate the Muhanna & Khalil Expires December 30, 2007 [Page 11] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 initial RRQ nor the retransmitted one directly to the HA. In both of these scenarios, the FA is required to contact the home AAA server similar to the initial RRQ. The FA builds an AMR message and send it to the local AAA server exactly similar to its handling of the initial RRQ. In each of these two scenarios, Diameter MIPv4 application model adds a cost of one FA-AAA-DIAMETER and one AAA-HA-DIAMETER round trips to the initial call setup. MN FA HA H-AAA | | | | | | | | | RRQ(i) | | | | [MN-AAA AE] | | | |------------>| Diameter AMR [MN-AAA, RRQ(i), etc.] | | |------------------------------------------->| | FA Waiting | HAR [MN-HA SA] | | for RRP(i) |<-----------------| | | | HAA [RRP(i)] | | | |----------------->| | | Diameter AMA [Auth. + Authorized, RRP(i)] | | |<-------------------------------------------| | User Has Been | | | Authenticated | | | Build RRP(i) | | | RRQ(r) | | | |------------>| | | | RRP(i) | | | |<------------| | | | Relay RRQ(r) | | | | Diameter AMR [MN-AAA, RRQ(r), etc.] | | |------------------------------------------->| | FA Waiting | HAR [MN-HA SA] | | for RRP(r) |<-----------------| | | | HAA [RRP(r)] | | | |----------------->| | | Diameter AMA [Auth. + Authorized, RRP(r)] | | RRP(r) |<-------------------------------------------| |<------------| | | | | | | Figure 4: Handling of MIPv4 Retransmitted RRQ during Session Establishment Based on Diameter MIPv4 Application Muhanna & Khalil Expires December 30, 2007 [Page 12] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 7.3. Diameter MIPv4 Model Handling of Scenario No. 4 In this scenario and since the FA has received the successful home AAA server response which includes a successful RRP from the HA, the FA is still required to contact the home AAA server similar to the initial RRQ. The FA builds an AMR message and send it to the local AAA server exactly similar to its handling of the initial RRQ. In this scenario, the Diameter MIPv4 application model adds a cost of one FA-AAA-DIAMETER and one AAA-HA-DIAMETER round trips to the initial call setup. 8. Summary and Conclusions In summary, the Diameter Mobile IPv4 Application model uses the AAA infrastructure exclusively for the mobile IPv4 initial session setup. This means that initial RRQ and RRP are always transmitted via Diameter Mobile IPv4 Application attributes and messages, e.g. AMR, AMA, HAR, and HAA. In the case when the mobile node is required to retransmit the initial RRQ, Diameter Mmobile IPv4 application [RFC4004] model requires repeating all of the initial registration process over the AAA infrastructure one more time. This mechanism is very expensive and causes a heavy burden on the AAA infrastructure. According to this study, the Diameter mobile IPv4 application model adds one FA-AAA-DIAMETER and one AAA-HA-DIAMETER round trips in all of the examined four scenarios. However, RADIUS based model adds only one FA-AAA-RADIUS round trip for scenario No. 1 and none in all of the other examined scenarios. Table 1 captures the summary of the findings of this study with respect to Diameter and RADIUS based models performance. In conclusion, since RADIUS protocol has some limitation in comparison to Diameter, it is highly recommended to have an Authentication and Authorization AAA application based on Diameter using a model similar to the concept of RADIUS based mechanism. In such application, both advantages of Diameter protocol and RADIUS based mechanism could be achieved with the best possible performance. Muhanna & Khalil Expires December 30, 2007 [Page 13] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 Table 1. Mobile IPv4 Authentication and Authorization Cost Using Diameter MIPv4 Application vs. RADIUS +----------------+--------------+----------------+----------------+ | Scenario | RADIUS Based | Diameter MIPv4 | Comments | | Type | Model | Model | | +----------------+--------------+----------------+----------------- | Scenario No. 1 | 1 FA-AAA rt | 1 FA-AAA rt | | | | | + | | | | | 1 AAA-HA rt | | +----------------+--------------+----------------+----------------+ | Scenario No. 2 | | 1 FA-AAA rt | | | | zero rt | + | | | | | 1 AAA-HA rt | | +----------------+--------------+----------------+----------------+ | Scenario No. 3 | | 1 FA-AAA rt | | | | zero rt | + | | | | | 1 AAA-HA rt | | +----------------+--------------+----------------+----------------+ | Scenario No. 4 | | 1 FA-AAA rt | | | | zero rt | + | | | | | 1 AAA-HA rt | | +----------------+--------------+----------------+----------------+ 9. IANA Considerations This document does not require any IANA interaction. 10. Security Considerations This document does not present any new security requirement. It only present a comparison of the performance of RADIUS based and Diameter Mobile IPv4 Application based when used for MIPv4 user Authentication and authorization. 11. Acknowledgements The authors would like to thank Sri Gundavelli for his review, discussion and encouragement for writing this document. Muhanna & Khalil Expires December 30, 2007 [Page 14] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 12. References 12.1. Normative References [RFC-3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC-4004] Calhoun, P., Johansson T., Perkins C., Hiller T., and McCann, P., "Diameter Mobile IPv4 Application", RFC 4004, August 2005. [RFC-2865] Rigney, C., Willens, S., Rubens, A., and Simpson, W., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC-3012] Perkins, C. and Calahoun, P. "Mobile IPv4 Challenge/ Response Extensions", RFC 3012, November 2000. Authors' Addresses Ahmad Muhanna Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: amuhanna@nortel.com Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: mkhalil@nortel.com Muhanna & Khalil Expires December 30, 2007 [Page 15] Internet-Draft MIP4 AAA Performance: RADIUS vs. Diameter June 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Muhanna & Khalil Expires December 30, 2007 [Page 16]