DIME Working Group A. Muhanna
Internet-Draft M. Khalil
Intended status: Informational Nortel
Expires: January 15, 2009 A. Lior
Bridgewater Systems
July 14, 2008
MIPv4 Authentication Using a New Diameter MIPv4 Application
draft-muhanna-diameter-mip4-performance-02.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 January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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.
Muhanna, et al. Expires January 15, 2009 [Page 1]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
However, these SDos use a link layer access authentication mechanism,
e.g., using an EAP application, to derive the related MIP4 shared
keys and security association. This document an overview of these
respected architectures and their handling to MIP4 security
association and keys derivation and distribution. It presents an
analysis of the performance and impact of Diameter MIPv4 Application
and RADIUS based solutions on the time the 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3
2.1. Conventions used in this document . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . 17
Muhanna, et al. Expires January 15, 2009 [Page 2]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
1. 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. However, these SDOs use a link layer access
authentication mechanism, e.g., using an EAP application, to derive
the related MIP4 shared keys and security associations. This
document provide an overview of these architectures and their
handling to MIP4 security association and keys derivation and
distribution. It also 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 presented under section 8.
2. Conventions & Terminology
2.1. Conventions used in this document
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 [RFC-2119].
Muhanna, et al. Expires January 15, 2009 [Page 3]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
2.2. Terminology
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].
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, et al. Expires January 15, 2009 [Page 4]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
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, et al. Expires January 15, 2009 [Page 5]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
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 RFC4004 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, et al. Expires January 15, 2009 [Page 6]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
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, et al. Expires January 15, 2009 [Page 7]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
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, et al. Expires January 15, 2009 [Page 8]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
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, et al. Expires January 15, 2009 [Page 9]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
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, et al. Expires January 15, 2009 [Page 10]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
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 RFC4004 Diameter MIPv4 application model, both
scenarios No. 2 and 3 mean one single scenario since the FA does not
Muhanna, et al. Expires January 15, 2009 [Page 11]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
communicate the 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 RFC4004 Diameter MIPv4 Application
Muhanna, et al. Expires January 15, 2009 [Page 12]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
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, RFC4004 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 Mobile 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
protocol. However, current Mobile IPv4 deployments prefer a Diameter
MIPv4 Application that fits in the current AAA architecture. Hence a
Diameter MIPv4 Application which uses a model similar to the concept
of RADIUS based mechanism is preferred. In such application, both
advantages of Diameter protocol and RADIUS based mechanism could be
achieved with the best possible performance.
Muhanna, et al. Expires January 15, 2009 [Page 13]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
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. The authors
would like to thank Alper Yegin and Kuntal Chowdhury for their
comments and support of this effort.
Muhanna, et al. Expires January 15, 2009 [Page 14]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
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
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Phone: +1 (972) 685-1416
Email: amuhanna@nortel.com
Mohamed Khalil
2221 Lakeside Blvd.
Richardson, TX 75082
USA
Phone: +1 (972) 685-0564
Email: mkhalil@nortel.com
Muhanna, et al. Expires January 15, 2009 [Page 15]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
Avi Lior
Bridgewater Systems Corporation
303 Terry Fox Drive
Suite 100
Ottawa, Ontario K2K 3J1
Canada
Phone: +1 (613) 591-6655
Email: avi@bridgewatersystems.com
Muhanna, et al. Expires January 15, 2009 [Page 16]
Internet-Draft MIP4 AAA Performance: New DIME MIP4 Appl July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, et al. Expires January 15, 2009 [Page 17]