One document matched: draft-ietf-aaa-diameter-mobileip-17.txt
Differences from draft-ietf-aaa-diameter-mobileip-16.txt
AAA Working Group Pat R. Calhoun
Internet Draft Airespace
draft-ietf-aaa-diameter-mobileip-17.txt Tony Johansson
Category: Standards Track Bytemobile Inc
Charles E. Perkins
Nokia Research Center
Tom Hiller
(editor)
Lucent Technologies
April 2004
Diameter Mobile IPv4 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.
Abstract
This document specifies a Diameter application that allows a Diameter
server to authenticate, authorize and collect accounting information
for Mobile IPv4 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.
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 [2].
Calhoun et al Standards Track - November 2004 1
Diameter MIP April 2004
Table of Contents
1. Introduction.....................................................3
1.1. Entities and Relationships...................................4
2. Acronyms.........................................................6
3. Scenarios and Message Flows......................................6
3.1. Inter-Realm Mobile IPv4......................................6
3.2. Allocation of Home Agent in Foreign Network.................11
3.3. Co-located Mobile Node......................................15
3.4. Key Distribution Center (KDC)...............................17
4. Diameter Protocol Considerations................................19
4.1. Diameter Session Management.................................19
5. Command-Code Values.............................................21
5.1. AA-Mobile-Node-Request......................................21
5.2. AA-Mobile-Node-Answer.......................................23
5.3. Home-Agent-MIP-Request......................................24
5.4. Home-Agent-MIP-Answer.......................................25
6. Result-Code AVP Values..........................................26
6.1. Transient Failures..........................................26
6.2. Permanent Failures..........................................27
7. Mandatory AVPs..................................................27
7.1. MIP-Reg-Request AVP.........................................28
7.2. MIP-Reg-Reply AVP...........................................28
7.3. MIP-Mobile-Node-Address AVP.................................28
7.4. MIP-Home-Agent-Address AVP..................................29
7.5. MIP-Feature-Vector AVP......................................29
7.6. MIP-MN-AAA-Auth AVP.........................................30
7.7. MIP-FA-Challenge AVP........................................31
7.8. MIP-Filter-Rule AVP.........................................31
7.9. MIP-Candidate-Home-Agent-Host...............................31
7.10. MIP-Originating-Foreign-AAA AVP............................31
7.11. MIP-Home-Agent-Host AVP....................................32
8. Key Distribution Center.........................................32
8.1. Authorization Lifetime vs. MIP Key Lifetime.................33
8.2. Nonce vs. Session Key.......................................33
8.3. Distributing the Mobile-Home Session Key....................34
8.4. Distributing the Mobile-Foreign Session Key.................35
8.5. Distributing the Foreign-Home Session Key...................35
9. Key Distribution Center (KDC) AVPs..............................36
9.1. MIP-FA-to-MN-MSA AVP........................................37
9.2. MIP-FA-to-HA-MSA AVP........................................37
9.3. MIP-HA-to-FA-MSA AVP........................................38
9.4. MIP-HA-to-MN-MSA AVP........................................38
9.5. MIP-MN-to-FA-MSA AVP........................................38
9.6. MIP-MN-to-HA-MSA AVP........................................39
9.7. MIP-Session-Key AVP.........................................39
9.8. MIP-Algorithm-Type AVP......................................39
9.9. MIP-Replay-Mode AVP.........................................39
9.10. MIP-FA-to-MN-SPI AVP.......................................40
9.11. MIP-FA-to-HA-SPI AVP.......................................40
9.12. MIP-Nonce AVP..............................................40
9.13. MIP-MSA-Lifetime AVP.......................................40
9.14. MIP-HA-to-FA-SPI AVP.......................................40
Calhoun Standards Track - Expires November 2004 2
Diameter MIP April 2004
10. Accounting AVPs................................................41
10.1. Accounting-Input-Octets AVP................................41
10.2. Accounting-Output-Octets AVP...............................41
10.3. Acct-Session-Time AVP......................................41
10.4. Accounting-Input-Packets AVP...............................41
10.5. Accounting-Output-Packets AVP..............................41
10.6. Event-Timestamp AVP........................................42
11. AVP Occurrence Tables..........................................42
11.1. Mobile IP Command AVP Table................................43
11.2. Accounting AVP Table.......................................44
12. IANA Considerations............................................44
12.1. Command Codes..............................................44
12.2. AVP Codes..................................................44
12.3. Result-Code AVP Values.....................................44
12.4. MIP-Feature-Vector AVP Values..............................45
12.5. MIP-Algorithm-Type AVP Values..............................45
12.6. MIP-Replay-Mode AVP Values.................................45
12.7. Application Identifier.....................................45
13. Security Considerations........................................45
14. References.....................................................46
14.1. Normative..................................................46
14.2. Informative................................................47
15. Acknowledgements...............................................48
16. Authors' Addresses.............................................48
1. Introduction
Mobile IPv4 [MOBILEIP] allows a Mobile Node (MN) to change its point
of attachment to the Internet while maintaining its fixed home
address. Packets directed to the home address are intercepted by a
Home Agent (HA), encapsulated in a tunnel, and forwarded to the MN at
its current point of attachment. Optionally, a Foreign Agent (FA)
may be deployed at this point of attachment, which can serve as the
tunnel endpoint and may also provide access control for the visited
network link. In this role, the FA needs to authenticate each MN
that may attach to it, whether the MN is from the same or a different
administrative domain. The FA needs to verify that the MN is
authorized to attach and use resources in the foreign domain. Also,
the FA must provide information to the home administrative domain
about the resources used by the MN while it is attached in the
foreign domain.
The Authentication, Authorization, and Accounting requirements for
Mobile IPv4 are described in detail in other documents [MIPREQ,
CDMA2000]. This document specifies a Diameter application to meet
these requirements. This application is not applicable with the
Mobile IPv6 protocol.
Calhoun Standards Track - Expires November 2004 3
Diameter MIP April 2004
1.1. Entities and Relationships
The Diameter Mobile IPv4 Application supports the HA and FA in
providing Mobile IPv4 service to MNs. Both the HA and FA act as
Diameter clients. The MNs interact with the HA and FA using only
Mobile IPv4, and therefore do not implement Diameter.
The FA, when present, is always assumed to exist in the visited
administrative domain. The HA may be statically or dynamically
allocated to the MN in the home administrative domain, or may be
dynamically allocated to the MN in a visited administrative domain.
The home domain contains a home AAA server (AAAH) and the visited
domain contains a foreign AAA server (AAAF). When the MN is "at
home" (present on its home network), the AAAH and AAAF may be the
same.
The base Mobile IPv4 protocol [MOBILEIP] requires that an MN be pre-
configured with a home agent and a home address. This would include
a statically configured Mobility Security Association (MSA) between
the MN and HA. However, this document, together with extensions
[MIPNAI, MIPKEY, AAANAI] to the base Mobile IPv4 protocol, allows an
MN to be dynamically assigned a home address and/or home agent
(including the necessary mobility security association) when it
attaches to the Internet. This set of specifications also supports
the dynamic configuration of a mobility security association between
the MN and FA and between the FA and HA, which allows for secure
exchange of Mobile IPv4 control messages among these entities. The
dynamic configuration of these relationships is important to support
deployments where the MN can attach to a visited network without
having a pre-established relationship with it.
This application supports the distribution of MN-HA, MN-FA, and FA-HA
session keys. This allows the MN, FA, and HA to compute the required
integrity checks included within the subsequent Mobile IPv4
registration messages. Initially, the MN is assumed to have a long-
term AAA security association only with the AAAH, which is used to
bootstrap the MN-FA and MN-HA mobility security associations. The
AAAH creates the MN-FA and MN-HA session keys using a defined
algorithm that includes the long-term secret shared with the MN and a
locally created nonce for each session key. The nonces ensure that
the MN-HA and MN-FA session keys are fresh. Although the nonces are
only contributed by a single party (the AAAH), it is assumed that the
AAAH is a server with a substantial entropy pool, while the MN may be
an embedded device with only limited entropy. The AAAH distributes
these nonces to the HA, so that they can be included in a Mobile IPv4
Registration Reply that is sent to the mobile node. At the same
time, the AAAH distributes the session keys to the HA and FA. The
AAAH also distributes the FA-HA session key to both the FA and the
HA. The AAAH transports the keys as necessary via security
associations to the FA and HA.
Calhoun Standards Track - Expires November 2004 4
Diameter MIP April 2004
Note that each of the MN-HA, FA-HA and MN-FA session keys is just one
part of a mobility security association that includes Security
Parameter Index (SPI) and algorithm identifier values. The Diameter
Mobile IPv4 application also distributes the other security
association attributes along with the nonces and/or keys.
The AAAF and AAAH may establish a Diameter session directly with each
other, such as via a Diameter Redirect, or may pass messages via a
network of Diameter proxies. Where the AAAF and AAAH route messages
to each other through proxies, rather than a direct connection,
transitive trust is assumed. MNs can include their Network Access
Identifier (NAI) in a Mobile IPv4 Registration Request [MIPNAI],
which serves in place of the home address to identify the MN. The
NAI is used to route Diameter messages towards the correct AAAH.
This use of the NAI is consistent with the roaming model defined by
the ROAMOPS Working Group [EVALROAM, RFC2607].
In addition to supporting the derivation and transport of the MN-HA,
MN-FA and FA-HA session keys, this application also supports MIPv4
handoff. When an MN moves from one point of attachment to another,
the MN can continue the same Mobile IPv4 session using its existing
HA and home address.
The MN accomplishes this by sending a Mobile IPv4 Registration
Request from its new point of attachment. To enable a single set of
accounting records to be maintained for the entire session, including
handoffs, it is necessary to allow the AAAH to bind the new
registration to the pre-existing session. To enable the Mobile IPv4
Registration Request to be routed to the same AAAH, the MN SHOULD
include the AAAH NAI [AAANAI] in such re-registrations. Also, to
assist the AAAH in routing the messages to the MN's existing HA the
mobile node SHOULD include the HA NAI [AAANAI] in such re-
registrations. If the mobile node does not support the Mobile IPv4
AAA NAI extension [AAANAI], this functionality is not available.
The remainder of this document is structured as follows. Section
Section 2 provides acronym definitions. Section 3 provides some
examples and message flows illustrating both the Mobile IPv4 and
Diameter messages that occur when a mobile node attaches to the
Internet. Section 4 defines the relationship of this application to
the Diameter Base Protocol. Section 5 defines the new command codes
used by this application. Section 6 defines the new result codes
used by this application. Section 7 defines the set of mandatory
Attribute-Value-Pairs (AVPs) used by this application. Section 8
gives an overview of the key distribution capability, and Section 9
defines the key distribution AVPs used by this application. Section
10 defines the accounting AVPs, and Section 11 contains a listing of
all AVPs and their occurrence in Diameter commands. Finally,
Sections 12 and 13 give IANA and Security considerations,
respectively.
Calhoun Standards Track - Expires November 2004 5
Diameter MIP April 2004
2. Acronyms
AAAH Authentication, Authorization, and Accounting Home
AAAF Authentication, Authorization, and Accounting Home
AMR AA-Mobile-Node-Request
ASR Abort-Session-Request
AMA AA-Mobile-Node-Answer
AVP Attribute Value Pair
CoA Care-of-Address
FA Foreign Agent
FQDN Fully Qualified Distinguished Name
HA Home Agent
HAA Home-Agent-MIP-Answer
HAR Home-Agent-MIP-Request
KDC Key Distribution Center
MSA Mobility Security Association
MN Mobile Node
NAI Network Authentication Identity
RRQ Registration Request
SPI Security Parameter Index
STR Session-Termination-Request
3. Scenarios and Message Flows
This section presents four scenarios illustrating Diameter Mobile
IPv4 application, and describes the operation of key distribution.
In this document, the role of the "attendant" [MIPREQ] is performed
by either the FA (when present in a visited network) or the HA (for
co-located mobile nodes not registering via an FA), and these terms
will be used interchangeably in the following scenarios.
3.1. Inter-Realm Mobile IPv4
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 7.
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.
Calhoun Standards Track - Expires November 2004 6
Diameter MIP April 2004
Visited Realm Home Realm
+--------+ +--------+
|abc.com | AMR/AMA |xyz.com |
| AAAF |<------------------->| AAAH |
+->| server | server-server | server |
| +--------+ communication +--------+
| ^ ^
| AMR/AMA | client-server | HAR/HAA
| | communication |
v v v
+---------+ +---------+ +---------+
| Foreign | | Foreign | | Home |
| Agent | | Agent | | Agent |
+---------+ +---------+ +---------+
^
| Mobile IP
|
v
+--------+
| Mobile |
| Node | 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 5.2) from the AAAH.
Calhoun Standards Track - Expires November 2004 7
Diameter MIP April 2004
Mobile Node Foreign Agent AAAF AAAH Home
Agent
----------- ------------- ------------ ---------- -------
Advertisement &
<--------- Challenge
Reg-Req&MN-AAA ---->
AMR------------>
Session-Id = foo
AMR------------>
Session-Id = foo
HAR----------->
Session-Id = bar
<----------HAA
Session-Id = bar
<-----------AMA
Session-Id = foo
<------------AMA
Session-Id = foo
<-------Reg-Reply
Figure 2: Mobile IPv4/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 IPv4 registration process, as described in [MIPCHAL]. The
mobile node includes the Challenge and MN-AAA authentication
extension to enable authorization by the AAAH. If the authentication
data supplied in the MN-AAA extension is invalid, the 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. If this is a concern,
a more secure approach is to eliminate the AAAF and other Diameter
agents as in Figure 3:
Calhoun Standards Track - Expires November 2004 8
Diameter MIP April 2004
Redirect
FA AAAF Agent AAAH
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
In Figure 3, the FA sets up a TLS [TLS] or IPSec [IPSEC] based
security association with the AAAH directly and runs the AMR/AMA
exchange over it. This provides end-to-end security for secret keys
that may need to be distributed.
Figure 4 shows the interaction between the AAAH and HA with the help
of a redirect agent. When the AAAH and HA are in the same network, it
is likely that the AAAH knows the IP address of the HA, so the
redirect server would therefore not be needed; however, it is shown
anyway for completeness. The redirect server will most likely be
used in the case where the HA is allocated in a foreign network (see
Section 3.2 for more details of HA allocation in foreign networks).
Calhoun Standards Track - Expires November 2004 9
Diameter MIP April 2004
Redirect
HA Agent AAAH
HAR
<--------------------
HAA (Redirect)
-------------------->
Setup Security Association
<---------------------------------------->
HAR (MN-HA key)
<-----------------------------------------
HAA
----------------------------------------->
Figure 4: Use of a Redirect Server with HAR/HAA
As in Figure 2, the FA of Figure 3 would still provide the challenge
and the mobile sends the RRQ, etc.; however, these were eliminated
from Figure 3 to reduce 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. Note that the message flows in Figure 3
and Figure 4 apply only to the initial authentication and key
exchange. Accounting messages would still be sent via Diameter
agents, not the direct connection, unless network policies dictate
otherwise.
A mobile node that supports the AAA NAI extension [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 then
determines which Home Agent to use for the session. First, the AAAH
checks if an HA has been requested by the MN, by checking the MIP-
Home-Agent-Address AVP and the MIP-Home-Agent-Host AVP. The
administrative domain owning the HA may be determined from the realm
portion of the MIP-Home-Agent-Host AVP, or by checking the Home-
Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP and the
value of the MIP-Originating-Foreign-AAA AVP. If the requested HA
belongs to a permitted administrative domain, the AAAH SHOULD use the
Calhoun Standards Track - Expires November 2004 10
Diameter MIP April 2004
given HA for the session. Otherwise, the AAAH returns the response
(AMA) with the Result-Code AVP set to either
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE or
DIAMETER_ERROR_HA_NOT_AVAILABLE.
If the MN has not requested any particular HA, then an HA MUST be
dynamically allocated. In this case the MIP-Feature-Vector will have
the Home-Agent-Requested flag set. If the Home-Address-Allocatable-
Only-in-Home-Realm flag is not set, and if the Foreign-Home-Agent-
Available flag is set, then the AAAH SHOULD allow the foreign realm
to allocate the HA (see Section 3.2) but MAY allocate one itself in
the home realm if dictated by local policy. If the Home-Address-
Allocatable-Only-in-Home-Realm flag is set, then the AAAH MUST
allocate an HA in the home realm on behalf of the MN. Allocation of
the HA 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 a Home-Agent-MIP-Request (HAR), which contains
the Mobile IPv4 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 home address allocation.
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, as well as include the
address in both the Registration Reply and the MIP-Mobile-Node-
Address AVP.
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 Figure 4 for the use of the
redirect agent for the secure transport of the HAA and AMA messages.
See Section 4.1 for information on the management of sessions and
session identifiers by the Diameter Mobile IPv4 entities.
3.2. Allocation of Home Agent in Foreign Network
The Diameter Mobile IPv4 application allows a home agent to be
allocated in a foreign network, as required in [MIPREQ, CDMA2000].
Calhoun Standards Track - Expires November 2004 11
Diameter MIP April 2004
When a foreign agent detects that the mobile node has a home agent
address equal to 0.0.0.0 or 255.255.255.255 in the Registration
Request message, it MUST add a MIP-Feature-Vector AVP with the Home-
Agent-Requested flag set to one. If the home agent address is set to
255.255.255.255, the foreign agent 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 (i.e., a DiameterIdentity, which
is an FQDN) 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. The AAAF now sends the AMR to the AAAH. However, as
discussed above, the use of Diameter agents between the FA and AAAH
in this exchange would expose the MN-FA key. 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.
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 needs to be re-authenticated but
does not support the AAA NAI extension, it sends a registration
request without the AAA NAI and the HA NAI, even though it has been
previously authorized by the AAAH and requests to keep the assigned
home agent in the foreign network. 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.
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
Calhoun Standards Track - Expires November 2004 12
Diameter MIP April 2004
Foreign-Home-Agent-Available is set in the MIP-Feature-Vector AVP, or
the AMR indicates that the AAAF has offered a previously allocated
Home Agent for the mobile node, i.e. the Home-Agent-In-Foreign-
Network is set in the MIP-Feature-Vector AVP, then the AAAH must
decide whether its local policy would allow the user to have or keep
a home agent in the foreign network. Assuming the mobile node is
permitted to have or keep a home agent in the foreign network, the
AAAH determines the IP address of the HA based upon the FQDN of the
HA using DNS, or learns it via an MIP-Home-Agent-Address AVP in a
redirect response to an HAR (i.e., if the redirect server adds this
AVP to the HAA), and sends an 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 DNS is
used to determine the HA IP address, this specification makes the
assumption that the HA has a public address and it can be resolved by
DNS.
Security considerations may require that the HAR be sent directly
from the AAAH to the HA without the use of intermediary Diameter
agents. This requires that a security association between the AAAH
and HA be established, as in Figure 4. If 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.
Calhoun Standards Track - Expires November 2004 13
Diameter MIP April 2004
Visited Home
Realm Realm
+--------+ ------- AMR -------> +--------+
| AAAF | <------ HAR -------- | AAAH |
| | | |
+--->| server | ------- HAA -------> | server |
| +--------+ <------ AMA -------- +--------+
| ^ |
| | |
HAR/HAA | AMR | | AMA
v | v
+---------+ +---------+
| Home | | Foreign |
| Agent | | Agent |
+---------+ +---------+
^
+--------+ |
| Mobile |<----------+
| Node | Mobile IP
+--------+
Figure 5: Home Agent allocated in Visited Realm
Upon receipt of an 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.
If exposing keys to the Diameter Agents along the way represents an
unacceptable security risk, then the redirect approach depicted in
Figure 3 and Figure 4 MUST be used instead.
Calhoun Standards Track - Expires November 2004 14
Diameter MIP April 2004
Mobile Node Foreign Agent Home Agent AAAF AAAH
----------- ------------- ------------- ---------- ----------
<----Challenge----
Reg-Req (Response)->
------------AMR------------->
-----AMR---->
<----HAR-----
<-----HAR------
------HAA------>
-----HAA---->
<----AMA-----
<-------------AMA------------
<---Reg-Reply----
Figure 6: MIP/Diameter Exchange for HA is allocated in
Visited Realm
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.
3.3. 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.
Calhoun Standards Track - Expires November 2004 15
Diameter MIP April 2004
Home
Realm
+--------+
| AAAH |
| |
| server |
+--------+
^ |
| |
AMR | | AMA
| v
+--------+ +---------+
| Mobile | Registration | Home |
| Node |-------------->| Agent |
+--------+ Request +---------+
Figure 7: 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 8 shows the secure solution using redirect servers. In Figure
8, the Proxy AAA represents any AAA server or servers that the HA may
use. This applies to the visited or home network.
Local redirect
HA Proxy AAA Agent AAAH
AMR
--------------->
AMR (Redirect)
-------------------->
AMA (Redirect)
<---------------------
AMA (Redirect)
<----------------
Setup Security Association
<------------------------------------------------------>
AMR
------------------------------------------------------->
AMA (MN-HA key)
<-------------------------------------------------------
Figure 8: Use of Redirect Server for Co-located CoA and
AMR/AMA
Calhoun Standards Track - Expires November 2004 16
Diameter MIP April 2004
3.4. Key Distribution Center (KDC)
In order to allow the scaling of wireless data access across
administrative domains, it is necessary to minimize the specific
Mobility Security Associations (MSA) required. This means that each
Foreign Agent should not be required have a pre-configured shared
mobility security association with each Home Agent on the Internet,
nor should the mobile node be required to have a pre-configured
shared MSA with any specific home agent or any specific foreign
agent, as defined in [MOBILEIP].
The Diameter Mobile IPv4 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
session keys and nonces. Specifically, three session keys and two
nonces are generated:
- K1 - the MN-HA Session Key, which will serve as a MSA
between the Mobile Node and the Home Agent. An
associated nonce is generated that the Mobile Node uses
to derive the (identical) session key.
- K2 - the MN-FA Key, which will serve as the MSA
between the Mobile Node and the Foreign
Agent. An associated nonce is generated that the Mobile
Node uses to derive the (identical) session key.
- K3 - the FA-HA Key, which will serve as the MSA
between the Foreign Agent and the
Home Agent.
The same session key is used in both directions between two entities,
e.g., the Mobile Node and the Foreign Agent use the same session key
for the MN-FA and the FA-MN authentication extensions. However, the
SPIs may be different for the MN-FA and the FA-MN authentication
extensions.
All keys and nonces are generated by the AAAH, even if a Home Agent
dynamically allocated is in the foreign network.
Figure 9 depicts the MSAs used for Mobile-IPv4 message integrity
using the keys created by the DIAMETER server.
Calhoun Standards Track - Expires November 2004 17
Diameter MIP April 2004
+--------+ +--------+
|Foreign | K3 | Home |
|Agent |<-------------------->| Agent |
| | | |
+--------+ +--------+
^ ^
| K2 K1 |
| +--------+ |
| | Mobile | |
+------>| Node |<------+
| |
+--------+
Figure 9: Mobility Security Associations after Session
Key and Nonce Distribution
The keys destined for the foreign and home agent are propagated to
the mobility nodes via the Diameter protocol. If exposing keys to the
Diameter Agents along the way represents an unacceptable security
risk, then 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 IPv4 protocol and MUST therefore instead follow the mechanisms
described in [MIPKEYS]. In [MIPKEYS], the keys distributed to the
mobile node are instead sent as nonces, and the mobile node will use
the nonce and the long-term shared secret to create the keys (see
section 8).
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 and nonces.
Calhoun Standards Track - Expires November 2004 18
Diameter MIP April 2004
4. Diameter Protocol Considerations
This section details the relationship of the Diameter Mobile IPv4
application to the Diameter base protocol.
This document specifies Diameter Application-ID 4. 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].
Given the nature of Mobile IPv4, re-authentication can only be
initiated by a mobile node, which does not participate in the
Diameter message exchanges. Therefore, Diameter server initiated re-
auth does not apply to this application.
4.1. Diameter Session Management
The AAAH and AAAF MAY maintain session-state or MAY be session-
stateless. AAA redirect agents and AAA relay agents MUST NOT maintain
session-state. The AAAH, AAAF, proxies and relays agents MUST
maintain transaction state.
A mobile node's session is identified via its identity in the User-
Name AVP, 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. However, because the MN may interact with more
than one FA during the life of its session, it is important for the
Diameter Mobile IPv4 application to distinguish the two pieces of the
session (some state at the FA, some state at the HA) and to manage
them independently. The following sub-sections give further details.
4.1.1. Session Identifiers
During creation of the AMR, the FA will choose a session identifier.
During the creation of the HAR, the AAAH MUST use a different session
identifier than the one used in the AMR/AMA. If the AAAH is session-
stateful, it MUST send the same session identifier for all HARs
initiated on behalf of a given mobile node's session. Otherwise, if
the AAAH is session-stateless, it will manufacture a unique session-
id for every HAR.
When the HA is first allocated, it MUST create and include an Acct-
Multi-Session-Id AVP in the HAA returned to the AAAH. This
identifier will be kept constant for the life of the Mobile IPv4
session, as detailed in the next subsection.
4.1.2. Managing Sessions During Mobile IPv4 Handoffs
Given the nature of Mobile IPv4, a mobile node MAY receive service
from many foreign agents during a period of time. However, the home
Calhoun Standards Track - Expires November 2004 19
Diameter MIP April 2004
realm should not view these handoffs as different sessions, since
this could affect billing systems. Furthermore, foreign agents
usually do not communicate between each other, which implies AAA
information cannot be exchanged between these entities. Therefore, it
MUST be assumed that a foreign agent is not aware that a registration
request from a mobile node has been previously authorized.
A handoff registration request from a mobile node will cause the FA
to send an AMR to its AAAF. The AMR will include a new session
identifier, and MAY be sent to a new AAAF (i.e., a AAAF different
from the one used by the previous FA). However, assuming the MN
supports the AAA NAI, the AMR shall be received by the AAAH to which
the user is currently registered (possibly via the redirect mechanism
depicted in Figure 3).
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 10: Accounting messages w/ Mobile IPv4
Application
4.1.3. Diameter Session Termination
A foreign and home agent following this specification MAY expect
their respective Diameter servers to maintain session state
information for each mobile node in their networks. In order for the
Diameter Server to release any resources allocated to a specific
Calhoun Standards Track - Expires November 2004 20
Diameter MIP April 2004
mobile node, the mobility agents MUST send a Session-Termination-
Request (STR) to the Diameter server that authorized the service. The
mobility agents MUST issue the Session-Termination-Request (STR) if
the Authorization Lifetime has expired and no subsequent MIP
registration request has been received.
The AAAH SHOULD only deallocate all resources after the STR is
received from the home agent. This ensures that a mobile node that
moves from one foreign agent to another (hand-off) does not cause the
Home Diameter Server to free all resources for the mobile node.
Therefore, an STR from a foreign agent would free the session from
the foreign agent, but not the one towards the home agent (see Figure
11).
STR, Session-Id = foo STR, Session-Id = bar
---------------------> <--------------------
+----+ +------+ +------+ +----+
| FA | | AAAF | | AAAH | | HA |
+----+ +------+ +------+ +----+
<--------------------- --------------------->
STA, Session-Id = foo STA, Session-Id = bar
Figure 11: Session Termination and Session Identifiers
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.
5. Command-Code Values
This section defines Command-Code [DIAMBASE] values that MUST be
supported by all Diameter implementations conforming to this
specification. The following Command Codes are defined in this
specification:
Command-Name Abbreviation Code Section
-----------------------------------------------------------
AA-Mobile-Node-Request AMR 260 5.1
AA-Mobile-Node-Answer AMA 260 5.2
Home-Agent-MIP-Request HAR 262 5.3
Home-Agent-MIP-Answer HAA 262 5.4
5.1. AA-Mobile-Node-Request
Calhoun Standards Track - Expires November 2004 21
Diameter MIP April 2004
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 AAAH in order to
request the authentication and authorization of a mobile node. The
foreign agent (or home agent in the case of a co-located Mobile Node)
uses information found in the Registration Request to construct the
following AVPs that are to be included as part of the AMR:
Home Address (MIP-Mobile-Node-Address AVP)
Home Agent address (MIP-Home-Agent-Address AVP)
Mobile Node NAI (User-Name AVP [DIAMBASE])
MN-HA Key Request (MIP-Feature-Vector AVP)
MN-FA Key Request (MIP-Feature-Vector AVP)
MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP)
Foreign Agent Challenge Extension (MIP-FA-Challenge AVP)
Home Agent NAI (MIP-Home-Agent-Host AVP)
Home AAA server NAI (Destination-Host AVP [DIAMBASE])
Home Agent to Foreign Agent SPI (MIP-HA-to-FA-SPI AVP)
If the mobile node's home address is zero, the foreign or home agent
MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. If the
home agent address is zero or all ones, the MIP-Home-Agent-Address
AVP MUST NOT be present in the AMR.
If a home agent is used in a visited network, the AAAF MAY set the
Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in
the AMR message to indicate that it is willing to assign a Home Agent
in the visited realm.
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.
Calhoun Standards Track - Expires November 2004 22
Diameter MIP April 2004
Message Format
<AA-Mobile-Node-Request> ::= < Diameter Header: 260, REQ, PXY >
< Session-ID >
{ Auth-Application-Id }
{ User-Name }
{ Destination-Realm }
{ Origin-Host }
{ Origin-Realm }
{ MIP-Reg-Request }
{ MIP-MN-AAA-Auth }
[ Acct-Multi-Session-Id ]
[ Destination-Host ]
[ Origin-State-Id ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
[ MIP-Feature-Vector ]
[ MIP-Originating-Foreign-AAA ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ MIP-FA-Challenge ]
[ MIP-Candidate-Home-Agent-Host ]
[ MIP-Home-Agent-Host ]
[ MIP-HA-to-FA-SPI ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
5.2. AA-Mobile-Node-Answer
The AA-Mobile-Node-Answer (AMA), indicated by the Command-Code field
set to 260 and the 'R' bit cleared in the Command Flags field, is
sent by the AAAH in response to the AA-Mobile-Node-Request message.
The User-Name MAY be included in the AMA if present in the AMR. The
Result-Code AVP MAY contain one of the values defined in section 6,
in addition to the values defined in [DIAMBASE].
An AMA message with the Result-Code AVP set to DIAMETER_SUCCESS MUST
include the MIP-Home-Agent-Address AVP, MUST include the MIP-Mobile-
Node-Address AVP, and includes the MIP-Reg-Reply AVP if and only if
the Co-Located-Mobile-Node bit was not set in the MIP-Feature-Vector
AVP. The MIP-Home-Agent-Address AVP contains the Home Agent assigned
to the mobile node, while the MIP-Mobile-Node-Address AVP contains
the home address that was assigned. The AMA message MUST contain the
MIP-FA-to-HA-MSA, MIP-FA-to-MN-MSA if they were requested in the AMR,
and they were present in the HAR. The MIP-MN-to-HA-MSA and MIP-HA-to-
MN-MSA AVPs MUST be present if the session keys were requested in the
AMR, and the Co-Located-Mobile-Node bit was set in the MIP-Feature-
Vector AVP.
Calhoun Standards Track - Expires November 2004 23
Diameter MIP April 2004
Message Format
<AA-Mobile-Node-Answer> ::= < Diameter Header: 260, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Authorization-Lifetime ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Re-Auth-Request-Type ]
[ MIP-Feature-Vector ]
[ MIP-Reg-Reply ]
[ MIP-MN-to-FA-MSA ]
[ MIP-MN-to-HA-MSA ]
[ MIP-FA-to-MN-MSA ]
[ MIP-FA-to-HA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Type-Algorithm ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
5.3. Home-Agent-MIP-Request
The AAA sends the Home-Agent-MIP-Request (HAR), indicated by the
Command-Code field set to 262 and the 'R' bit set in the Command
Flags field, to the Home Agent. If the Home Agent is to be assigned
in a foreign network, the HAR is issued by the AAAH and forwarded by
the AAAF to the HA if no redirect servers are involved. If redirect
servers are involved the HAR is sent directly to the HA via a
security association. If the HAR message does not include a MIP-
Mobile-Node-Address AVP, 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, the AAAH
MUST create them and include them in the HAR message. When a FA-HA
session key is requested, it will be created and distributed by the
AAAH server.
Calhoun Standards Track - Expires November 2004 24
Diameter MIP April 2004
Message Format
<Home-Agent-MIP-Request> ::= < Diameter Header: 262, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Authorization-Lifetime }
{ Auth-Session-State }
{ MIP-Reg-Request }
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Destination-Realm }
{ MIP-Feature-Vector }
[ Destination-Host ]
[ MIP-MN-to-HA-MSA ]
[ MIP-MN-to-FA-MSA ]
[ MIP-HA-to-MN-MSA ]
[ MIP-HA-to-FA-MSA ]
[ MIP-MSA-Lifetime ]
[ MIP-Originating-Foreign-AAA ]
[ MIP-Mobile-Node-Address ]
[ MIP-Home-Agent-Address ]
[ MIP-Type-Algorithm ]
* [ MIP-Filter-Rule ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]
5.4. Home-Agent-MIP-Answer
The Home Agent sends the Home-Agent-MIP-Answer (HAA), indicated by
the Command-Code field set to 262 and the 'R' bit cleared in the
Command Flags field, to its local AAA server 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 6 instead of the values defined in [DIAMBASE].
Calhoun Standards Track - Expires November 2004 25
Diameter MIP April 2004
Message Format
<Home-Agent-MIP-Answer> ::= < Diameter Header: 262, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ Acct-Multi-Session-Id ]
[ User-Name ]
[ Error-Reporting-Host ]
[ Error-Message ]
[ MIP-Reg-Reply ]
[ MIP-Home-Agent-Address ]
[ MIP-Mobile-Node-Address ]
[ MIP-FA-to-HA-SPI ]
[ MIP-FA-to-MN-SPI ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ AVP ]
6. Result-Code AVP Values
This section defines new Result-Code [DIAMBASE] values that MUST be
supported by all Diameter implementations that conform to this
specification.
6.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 IPv4
Registration Reply to the mobile node with an appropriate
error code.
DIAMETER_ERROR_BAD_KEY 4007
This error code is used by the home agent to indicate to the
local Diameter server that the key generated is invalid.
Calhoun Standards Track - Expires November 2004 26
Diameter MIP April 2004
DIAMETER_ERROR_MIP_FILTER_NOT_SUPPORTED 4008
This error code is used by a mobility agent to indicate to
the home Diameter server that the requested packet filter
Rules cannot be supported.
6.2. Permanent Failures
Errors that fall within the permanent failures category are used to
inform the peer that the request failed, and SHOULD NOT be attempted
again.
DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE 5024
This error is used by the AAAF to inform the AAAH that
allocation of a home agent in the foreign domain is not
permitted at this time.
DIAMETER_ERROR_END_TO_END_MIP_KEY_ENCRYPTION 5025
This error is used by the AAAF / AAAH to inform the peer
that the requested Mobile IPv4 session keys could not be
delivered via a security association.
7. Mandatory AVPs
The following table describes the Diameter AVPs defined in the Mobile
IPv4 application, their AVP Code values, types, possible flag values
and whether the AVP MAY be encrypted.
Due to space constraints, the short form IPFiltrRule is used to
represent IPFilterRule and DiamIdent is used to represent
DiameterIdentity.
Calhoun Standards Track - Expires November 2004 27
Diameter MIP April 2004
+--------------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-Reg-Request 320 7.1 OctetString| M | P | | V | Y |
MIP-Reg-Reply 321 7.2 OctetString| M | P | | V | Y |
MIP-MN-AAA-Auth 322 7.6 Grouped | M | P | | V | Y |
MIP-Mobile-Node- 333 7.3 Address | M | P | | V | Y |
Address
MIP-Home-Agent- 334 7.4 Address | M | P | | V | Y |
Address
MIP-Candidate- 336 7.9 DiamIdent | M | P | | V | N |
Home-Agent-Host
MIP-Feature- 337 7.5 Unsigned32 | M | P | | V | Y |
Vector
MIP-Auth-Input- 338 7.6.2 Unsigned32 | M | P | | V | Y |
Data-Length
MIP- 339 7.6.3 Unsigned32 | M | P | | V | Y |
Authenticator-Length
MIP- 340 7.6.4 Unsigned32 | M | P | | V | Y |
Authenticator-Offset
MIP-MN-AAA-SPI 341 7.6.1 Unsigned32 | M | P | | V | Y |
MIP-Filter-Rule 342 7.8 IPFiltrRule| M | P | | V | Y |
MIP-FA-Challenge 344 7.7 OctetString| M | P | | V | Y |
MIP-Originating- 347 7.10 Grouped | M | P | | V | Y |
Foreign-AAA
MIP-Home-Agent- 348 7.9 DiamIdent | M | P | | V | N |
Host
7.1. MIP-Reg-Request AVP
The MIP-Reg-Request AVP (AVP Code 320) is of type OctetString and
contains the Mobile IPv4 Registration Request [MOBILEIP] sent by the
mobile node to the foreign agent.
7.2. MIP-Reg-Reply AVP
The MIP-Reg-Reply AVP (AVP Code 321) is of type OctetString and
contains the Mobile IPv4 Registration Reply [MOBILEIP] sent by the
home agent to the foreign agent.
7.3. MIP-Mobile-Node-Address AVP
The MIP-Mobile-Node-Address AVP (AVP Code 333) is of type Address and
contains the mobile node's home IP address.
Calhoun Standards Track - Expires November 2004 28
Diameter MIP April 2004
7.4. MIP-Home-Agent-Address AVP
The MIP-Home-Agent-Address AVP (AVP Code 334) is of type Address and
contains the mobile node's home agent IP address.
7.5. MIP-Feature-Vector AVP
The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and
is added with flag values set by the foreign agent or by the AAAF
owned by the same administrative domain as the foreign agent. The
foreign agent SHOULD include MIP-Feature-Vector AVP within the AMR
message it sends to the AAAF.
Flag values currently defined include:
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 sets the Mobile-Node-Home-Address-Requested flag in the MIP-
Feature-Vector AVP to zero.
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
set to one if the mobile node includes a "Generalized MN-HA Key Nonce
Generation Request" [MIPKEYS] extension, with the subtype set to AAA.
Calhoun Standards Track - Expires November 2004 29
Diameter MIP April 2004
If the mobile node includes a "Generalized MN-FA Key Nonce Generation
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 both to one.
When the AAAF receives the AMR message, it MUST first verify that the
sender was an authorized foreign agent. The AAAF then takes any
actions indicated by the settings of the MIP-Feature-Vector AVP
flags. The AAAF then MAY set additional flags. Only the AAAF may set
the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network
flags to one. This is done according to local administrative policy.
When the AAAF has finished setting additional flags according to its
local policy, then the AAAF transmits the AMR with the possibly
modified MIP-Feature-Vector AVP to the AAAH.
7.6. MIP-MN-AAA-Auth AVP
The MN-AAA-Auth AVP (AVP Code 322) is of type Grouped and contains
some ancillary data to simplify processing of the authentication data
in the Mobile IPv4 Registration Request [MOBILEIP, MIPCHAL] by the
target AAA server. Its value has the following ABNF grammar:
MIP-MN-AAA-Auth ::= < AVP Header: 322 >
{ MIP-MN-AAA-SPI }
{ MIP-Auth-Input-Data-Length }
{ MIP-Authenticator-Length }
{ MIP-Authenticator-Offset }
* [ AVP ]
7.6.1. MIP-MN-AAA-SPI AVP
The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and
indicates the MSA by which the targeted AAA server (AAAH) should
attempt to validate the Authenticator computed by the mobile node
over the Registration Request data.
Calhoun Standards Track - Expires November 2004 30
Diameter MIP April 2004
7.6.2. MIP-Auth-Input-Data-Length AVP
The MIP-Auth-Input-Data-Length AVP (AVP Code 338) is of type
Unsigned32 and contains the length, in bytes, of the Registration
Request data (data portion of MIP-Reg-Request AVP)that should be used
as input to the algorithm, as indicated by the MN-AAA-SPI AVP, used
to determine whether the Authenticator Data supplied by the mobile
node is valid.
7.6.3. MIP-Authenticator-Length AVP
The MIP-Authenticator-Length AVP (AVP Code 339) is of type Unsigned32
and contains the length of the authenticator to be validated by the
targeted AAA server (i.e., AAAH).
7.6.4. MIP-Authenticator-Offset AVP
The MIP-Authenticator-Offset AVP (AVP Code 340) is of type Unsigned32
and contains the offset into the Registration Request Data, of the
authenticator to be validated by the targeted AAA server (i.e.,
AAAH).
7.7. MIP-FA-Challenge AVP
The MIP-FA-Challenge AVP (AVP Code 344) is of type OctetString and
contains the challenge advertised by the foreign agent to the mobile
node. This AVP MUST be present in the AMR if the mobile node used the
RADIUS-style MN-AAA computation algorithm.
7.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.
7.9. MIP-Candidate-Home-Agent-Host
The MIP-Candidate-Home-Agent-Host AVP (AVP Code 336) is of type
DiameterIdentity and contains the identity of a home agent in the
foreign network that the AAAF proposes be dynamically assigned to the
mobile node.
7.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
in cases when the home agent is or may be allocated in a foreign
Calhoun Standards Track - Expires November 2004 31
Diameter MIP April 2004
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 ]
7.11. MIP-Home-Agent-Host AVP
The MIP-Home-Agent-Host AVP (AVP Code 348) is of type Grouped, and
contains the identity of the assigned Home Agent. If 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 ]
8. Key Distribution Center
The mobile node and mobility agents use session keys (i.e., the MN-
FA, FA-HA and MN-HA session keys) to compute authentication
extensions applied to MIP registration messages, as defined in
[MOBILEIP]. If session keys are requested the AAAH MUST return the
keys and nonces after the mobile node is successfully authenticated
and authorized.
The SPI values are used as key identifiers, each session key has its
own SPI value; nodes that share a key can have different SPIs. The
mobile node allocates SPIs for use in the mobility security
associations of the MN-FA and MN-HA authentication extensions, via
the Mobile IPv4 AAA Key Request extensions [MIPKEYS]. The home agent
allocates SPIs for the MN-HA and FA-HA mobility security association.
The foreign agent chooses a SPI for the MN-FA and HA-FA mobility
security association. In all cases, the entity that receives an
authentication extension (i.e., verifies the authentication
extension) is providing the entity that sends the authentication
extension (i.e., computes the authentication extension) the value of
the SPI to use for that key and extension. Note that the keys in
this regime are symmetric in the sense they are used in both
directions, even though the SPIs do not have to be symmetric.
Once the session keys and nonces have been distributed, subsequent
Mobile IPv4 registrations need not invoke the AAA infrastructure
until the keys expire. These registrations MUST include the MN-HA
authentication extension. In addition, subsequent registrations MUST
also include MN-FA authentication extension if the MN-FA session key
Calhoun Standards Track - Expires November 2004 32
Diameter MIP April 2004
was generated and distributed by AAA; similarly for subsequent use of
the FA-HA authentication extensions.
8.1. Authorization Lifetime vs. MIP Key Lifetime
The Diameter Mobile IPv4 application makes use of two timers - the
Authorization-Lifetime AVP [DIAMBASE] and the MIP-MSA-Lifetime AVP.
The Authorization-Lifetime contains the number of seconds before the
mobile node must issue a subsequent MIP registration request. The
content of the Authorization-Lifetime AVP corresponds to the Lifetime
field in the MIP header [MOBILEIP].
The MIP-MSA-Lifetime AVP contains the number of seconds before
session keys destined for the mobility agents and the mobile node
expire. A value of zero indicates infinity (no timeout). If not zero,
the value of the MIP-MSA-Lifetime AVP MUST is at least equal to the
value in the Authorization Lifetime AVP.
8.2. Nonce vs. Session Key
As described in section 3.4, the AAAH generates session keys and
transmits them to the home agent and foreign agent. The AAAH
generates nonces that correspond to the same keys and transmits them
to the mobile node. Where it is necessary to protect the session
keys and SPIs from un-trusted Diameter agents, end-to-end security
mechanisms such as TLS or IPSec are required to eliminate the all
Diameter Agents between the FA or HA and the AAAH, as outlined above.
In [MIPKEYS] the mobility security associations are established via
nonces transmitted to the mobile node via Mobile IPv4. To provide the
nonces, the AAAH must generate a random [RANDOM] value of at least
128 bits [MIPKEYS]. The mobile node then uses the nonce to derive the
MN-HA and MN-FA session keys.
More details of the MN-HA and the MN-FA session key creation
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 nonce.
The FA-HA and FA-HA session key is shared between the FA and HA.
The AAAH generates a random [RANDOM] value of at least 128 bits for
use as this session key.
See sections 9 for details about the format of the AVPs used to
transport the session keys.
Calhoun Standards Track - Expires November 2004 33
Diameter MIP April 2004
8.3. Distributing the Mobile-Home Session Key
If the mobile node does not have a MN-HA 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 MN-HA session key.
The distribution of the HA-MN (session) 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 AAAH only knows about Diameter
messages and AVPs, and the mobile node only knows about Mobile IPv4
messages and extensions [MOBILEIP]. For this purpose, AAAH includes
the MN-HA MIP-nonce AVP into a MIP-MN-to-HA-MSA AVP, which is added
to the HAR for FA COA style Mobile IPv4 or AMA for collocated COA
style Mobile IPv4 messages, and delivered either to a local home
agent or a home agent in the visited network. Recall the mobile node
will use the nonce to create the MN-HA session key using the MN-AAA
key it shares with the AAAH [MIPKEYS]. The AAAH has to rely on the
home agent (that also understands Diameter) to transfer the nonce
into a Mobile IPv4 "Generalized MN-HA Key Generation Nonce Reply"
extension [MIPKEYS] in the Registration Reply message. The HA
includes the SPIs proposed by the mobile node and the home agent in
the "Generalized MN-HA Key Generation Nonce Request" extension. The
home agent can format the Reply message and extensions correctly for
eventual delivery to the mobile node. The resulting Registration
Reply is added to the HAA's MIP-Reg-Reply AVP.
The AAAH parses the HAA message, transforms it into an AMA message
containing an MIP-Reg-Reply AVP, and sends the AMA message to the
foreign agent. The foreign agent then uses that AVP to recreate a
Registration Reply message containing the "Generalized MN-HA Key
Generation Nonce Reply" extension for delivery to the mobile node.
In summary, the AAAH generates the MN-HA nonce, which is added to the
MIP-MN-to-HA-MSA AVP, and a session key, which is added to the MIP-
HA-to-MN-MSA AVP. These AVPs are delivered to the home agent in HAR
or AMA messages. The home agent retains the session key for its own
use, and copies the nonce from the MIP-MN-to-HA-MSA AVP into a
"Generalized MN-HA Key Generation Nonce Reply" extension, which is
appended to the Mobile IPv4 Registration Reply message. This
Registration Reply message MUST also include the HA-MN authentication
extension, which is created using the newly allocated HA-MN session
key. The home agent then includes the Registration Reply message and
extensions into a MIP-Reg-Reply AVP as part of the HAA message to be
sent back to the AAA server.
Calhoun Standards Track - Expires November 2004 34
Diameter MIP April 2004
The key derived by the MN from the MN-HA session nonce is identical
to the HA-MN session key provided to the HA.
8.4. Distributing the Mobile-Foreign Session Key
The MN-FA session nonce is also generated by AAAH (upon request) and
is added to the MIP-MN-to-FA-MSA AVP, which is added to the HAR, and
copied by the home agent into a "Generalized MN-FA Key Generation
Nonce Reply" extension [MIPKEYS] to the Mobile IPv4 Registration
Reply message. The HA also includes the SPIs proposed by the mobile
node and foreign agent in the "MN-FA Key Generation Nonce Request"
extension. The AAAH includes the FA-MN session key in the MIP-FA-to-
MN-MSA AVP in the AMA, to be used by the foreign agent in the
computation of the FA-MN authentication extension.
The key derived by the MN from the MN-FA session nonce is identical
to the FA-MN session key provided to the FA.
8.5. Distributing the Foreign-Home Session Key
If the foreign agent requests an FA-HA session key, it also includes
a MIP-HA-to-FA-SPI AVP in the AMR to convey the SPI to be used by the
home agent for this purpose. The AAAH generates the FA-HA session
key, which is identical to the HA-FA session key, and distributes
that to both the HA and the FA over respective security associations
to each using the MIP-HA-to-FA-MSA and MIP-FA-to-HA-MSA AVPs. The HA
conveys the SPI the FA MUST use in the HAA; this is similar to the
way that the FA conveys the SPI the HA MUST use in the AMR. The AAAH
later includes these SPIs in the MIP-FA-HA-MSA and MIP-HA-FA-MSA
AVPs, respectively, along with the session key.
Refer to Figure 2, Figure 3, Figure 4 and Figure 6 for the messages
involved.
Note that if multiple MNs are registered on the same pair of FA and
HA, then multiple mobility security associations would be
distributed. However, only one is required to protect the Mobile IP
control traffic between FA and HA. This creates an unacceptable
level of state (i.e., to store the two SPIs and shared key for each
FA-HA mobility security association). To improve scalablity the FA
and HA may discard FA-HA mobility security associations prior to the
time they actually expire. However, if a proper discard policy is
not chosen, this could cause Mobile IP messages in transit or waiting
in queues for transmission to fail authentication.
The FA MUST always use the FA-HA security association with the latest
expiry time when computing authentication extensions on outgoing
messages. The FA MAY discard HA-FA mobility security associations 10
seconds after a new HA-FA mobility security association arrives with
a later expiry time.
Calhoun Standards Track - Expires November 2004 35
Diameter MIP April 2004
The HA SHOULD use the HA-FA mobility security association that has
the latest expiry time when computing authentication extensions in
outgoing messages. However, when the HA receives a new HA-FA
mobility security association with a later expiry time, the HA SHOULD
wait 4 seconds for the AMA to propagate to the FA before using the
new association. Note that the HA always uses the mobility security
association from the HAR when constructing the Mobile IP Registration
Reply in the corresponding HAA. The HA may discard an FA-HA mobility
security association once it receives a message authenticated by a
FA-HA mobility security association with a later expiry time.
9. Key Distribution Center (KDC) AVPs
The Mobile-IP protocol defines a set of mobility security
associations shared between the mobile node, foreign agent and home
agent. These three mobility security associations (MN-HA, MN-FA, and
FA-HA) are dynamically created by the AAAH, and has previously been
described in section 3.4 and section 8. 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
mobility security association. The first named entity in the AVP
name will use the mobility security association to create
authentication extensions using the given SPI and key. The second
named entity in the AVP name will use the mobility security
association to verify the authentication extensions of received
Mobile IP messages.
So for instance, the MIP-MN-to-HA-MSA AVP contains the MN-HA nonce,
which the mobile node will use to derive the MN-HA Key, and the MIP-
HA-to-MN-MSA AVP contains the MN-HA key for the home agent. Note that
mobility security associations are unidirectional, however, this
application delivers only one key that is shared between both
unidirectional security associations that exist between two peers.
The SPIs are however unique to each unidirectional security
association and are chosen by the peer that will receive the Mobile
IP messages authenticated with that security association.
The following table describes the Diameter AVPs defined in the Mobile
IP application, their AVP Code values, types, and possible flag
values.
Calhoun Standards Track - Expires November 2004 36
Diameter MIP April 2004
+--------------------------+
| AVP Flag Rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-FA-to-HA-SPI 318 9.11 Unsigned32 | M | P | | V | Y |
MIP-FA-to-MN-SPI 319 9.10 Unsigned32 | M | P | | V | Y |
MIP-HA-to-FA-SPI 323 9.14 Unsigned32 | M | P | | V | Y |
MIP-MN-to-FA-MSA 325 9.5 Grouped | M | P | | V | Y |
MIP-FA-to-MN-MSA 326 9.1 Grouped | M | P | | V | Y |
MIP-FA-to-HA-MSA 328 9.2 Grouped | M | P | | V | Y |
MIP-HA-to-FA-MSA 329 9.3 Grouped | M | P | | V | Y |
MIP-MN-to-HA-MSA 331 9.6 Grouped | M | P | | V | Y |
MIP-HA-to-MN-MSA 332 9.4 Grouped | M | P | | V | Y |
MIP-Nonce 335 9.12 OctetString| M | P | | V | Y |
MIP-Session-Key 343 9.7 OctetString| M | P | | V | Y |
MIP-Algorithm- 345 9.8 Enumerated | M | P | | V | Y |
Type
MIP-Replay-Mode 346 9.9 Enumerated | M | P | | V | Y |
MIP-MSA-Lifetime 367 9.13 Unsigned32 | M | P | | V | Y |
9.1. MIP-FA-to-MN-MSA AVP
The MIP-FA-to-MN-MSA AVP (AVP Code 326) is of type Grouped, and
contains the FA-MN session key. This AVP is conveyed to the FA in an
AMA message. The MN allocates the MIP-FA-to-MN-SPI. The FA creates
an FA-MN authentication extension using the session key and
algorithm, and the MN verifies that extension using the same session
key and algorithm. The data field of this AVP has the following ABNF
grammar:
MIP-FA-to-MN-MSA ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
9.2. MIP-FA-to-HA-MSA AVP
The MIP-FA-to-HA-MSA AVP (AVP Code 328) is of type Grouped, and
contains the FA-HA session key. This AVP is conveyed to the FA in an
AMA message. The HA allocates the MIP-FA-to-HA-SPI. The FA creates
the FA-HA authentication extension using the session key and
algorithm, and the HA verifies that extension using the same session
key and algorithm. The AVP's data field has the following ABNF
grammar:
Calhoun Standards Track - Expires November 2004 37
Diameter MIP April 2004
MIP-FA-to-HA-MSA ::= < AVP Header: 328 >
{ MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
9.3. MIP-HA-to-FA-MSA AVP
The MIP-HA-to-FA-MSA AVP (AVP Code 329) is of type Grouped, and
contains the Home Agent's session key, which it shares with the
foreign agent. This AVP is conveyed to the HA in an HAR message.
The FA allocates the MIP-HA-to-FA-SPI. The HA creates the HA-FA
authentication extension using the session key and algorithm, and the
FA verifies that extension using the same session key and algorithm.
The AVP's data field has the following ABNF grammar:
MIP-HA-to-FA-MSA ::= < AVP Header: 329 >
{ MIP-HA-to-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
9.4. MIP-HA-to-MN-MSA AVP
The MIP-HA-to-MN-MSA AVP (AVP Code 332) is of type Grouped, and
contains the HA-MN session key. This AVP is conveyed to the HA in an
HAR for the case of FA COA Mobile IPv4 and in an AMA for the case of
collocated COA Mobile IPv4. The MN allocates the MIP-HA-to-MN-SPI.
The HA creates the HA-MN authentication extension using the session
key and algorithm, and the MN verifies that extension using the same
session key and algorithm. The AVP's field has the following ABNF
grammar:
MIP-HA-to-MN-MSA ::= < AVP Header: 332 >
{ MIP-HA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]
9.5. MIP-MN-to-FA-MSA AVP
The MIP-MN-to-FA-MSA AVP (AVP Code 325) is of type Grouped, and
contains the MN-FA session nonce, which the mobile node uses to
derive the MN-FA session key. This AVP is conveyed to the HA in an
HAR message. The FA allocates the MIP-MN-to-FA-SPI. The MN creates
the MN-FA authentication extension using the session key and
algorithm, and the FA verifies that extension using the same session
key and algorithm.
Calhoun Standards Track - Expires November 2004 38
Diameter MIP April 2004
The home agent uses this AVP in the construction of the Mobile IP
"Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS].
MIP-MN-to-FA-MSA ::= < AVP Header: 325 >
{ MIP-MN-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-nonce }
* [ AVP ]
9.6. MIP-MN-to-HA-MSA AVP
The MIP-MN-to-HA-MSA AVP (AVP Code 331) is of type Grouped, and
contains the MN-HA session nonce, which the mobile node uses to
derive the MN-HA session key. This AVP is conveyed to the HA in an
HAR message for the case of FA COA Mobile IPv4 and in an AMR for the
case of collocated Mobile IPv4. The HA allocates the MIP-MN-to-HA-
SPI. The MN creates the MN-FA authentication extension using the
session key and algorithm, and the HA verifies that extension using
the same session key and algorithm.
The Home Agent uses this AVP in the construction of the Mobile IP
"Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS].
MIP-MN-to-HA-MSA ::= < AVP Header: 331 >
{ MIP-MN-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-nonce }
* [ AVP ]
9.7. MIP-Session-Key AVP
The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and
contains the Session Key for the associated Mobile IPv4
authentication extension. The HAAA selects the session key.
9.8. MIP-Algorithm-Type AVP
The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and
contains the Algorithm identifier for the associated Mobile IPv4
authentication extension. The HAAA selects the algorithm type. The
following values are currently defined:
2 HMAC-SHA-1 [HMAC]
9.9. MIP-Replay-Mode AVP
Calhoun Standards Track - Expires November 2004 39
Diameter MIP April 2004
The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and
contains the replay mode the Home Agent for authenticating the mobile
node. The HAAA selects the replay mode.
The following values are supported (see [MOBILEIP] for more
information):
1 None
2 Timestamps
3 Nonces
9.10. MIP-FA-to-MN-SPI AVP
The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and it
contains the Security Parameter Index the FA and MN use to refer to
the FA-MN session key. The MN allocates the SPI, and it MUST NOT
have a value between zero (0) and 255, which is the reserved
namespace defined in [MOBILEIP].
9.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 FA and HA use to refer to
the FA-HA session key. The HA allocates the SPI , and it MUST NOT
have a value between zero (0) and 255, which is the reserved
namespace defined in [MOBILEIP].
9.12. MIP-Nonce AVP
The MIP-Key-Material AVP (AVP Code 335) is of type OctetString and
contains the nonce sent to the mobile node for the associated
authentication extension. The mobile node follows the procedures in
[MIPKEYS] to generate the session key used to authenticate Mobile
IPv4 registration messages. The HAAA selects the nonce.
9.13. MIP-MSA-Lifetime AVP
The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and
represents the period of time (in seconds) for which the session key
or nonce is valid. The associated session key or nonce, as the case
may be, MUST NOT be used if the lifetime has expired; if the session
key or nonce lifetime expires while the session to which it applies
is still active, either the session key or nonce MUST be changed or
the association Mobile IPv4 session MUST be terminated.
9.14. MIP-HA-to-FA-SPI AVP
The MIP-HA-to-FA-SPI AVP (AVP Code 323) is of type Unsigned32, and
contains the Security Parameter Index the HA and FA use to refer to the
Calhoun Standards Track - Expires November 2004 40
Diameter MIP April 2004
HA-FA session key. The FA allocates the SPI, and it MUST NOT have a
value between zero (0) and 255, which is the reserved namespace defined
in [MOBILEIP].
10. Accounting AVPs
10.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.
10.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.
10.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.
10.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.
10.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.
Calhoun Standards Track - Expires November 2004 41
Diameter MIP April 2004
10.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.
11. AVP Occurrence Tables
The following tables presents the AVPs defined in this document and
their occurrences in Diameter messages. 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.
Calhoun Standards Track - Expires November 2004 42
Diameter MIP April 2004
11.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 |
MIP-FA-to-MN-MSA | 0 | 0-1 | 0 | 0 |
MIP-FA-to-HA-MSA | 0 | 0-1 | 0 | 0 |
MIP-HA-to-FA-MSA | 0 | 0 | 0-1 | 0 |
MIP-HA-to-MN-MSA | 0 | 0-1 | 0-1 | 0 |
MIP-MN-to-FA-MSA | 0 | 0 | 0-1 | 0 |
MIP-MN-to-HA-MSA | 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-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 |
MIP-MN-to-FA-SPI | 0 | 0 | 0 | 0-1 |
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-MSA-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 |
Calhoun Standards Track - Expires November 2004 43
Diameter MIP April 2004
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 |
------------------------------|-----+-----+-----+-----|
11.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 |
-------------------------------------|------+------+
12. 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.
12.1. Command Codes
This specification assigns the values 260 and 262 from the Command
Code namespace defined in [DIAMBASE]. See section 5 for the
assignment of the namespace in this specification.
12.2. AVP Codes
This specification assigns the values 318-348 and 363-366 from the
AVP Code namespace defined in [DIAMBASE]. See sections 7, 9, and 10
for the assignment of the namespace in this specification.
12.3. Result-Code AVP Values
Calhoun Standards Track - Expires November 2004 44
Diameter MIP April 2004
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 6 for the assignment of the namespace in
this specification.
12.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, as
listed in section 7.5. The remaining bits should only be assigned via
Standards Action [IANA].
12.5. MIP-Algorithm-Type AVP Values
As defined in Section 9.8, the MIP-Algorithm-Type AVP (AVP Code 345)
defines the value 2. All remaining values are available for
assignment via Designated Expert [IANA].
12.6. MIP-Replay-Mode AVP Values
As defined in Section 9.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].
12.7. Application Identifier
This specification assigns the value four (4) to the Application
Identifier namespace defined in [DIAMBASE]. See section 4 for more
information.
13. Security Considerations
This specification describes a Mobile IPv4 Diameter Application for
authenticating and authorizing a Mobile IPv4 mobile node. The
authentication algorithm used is dependent upon the transforms used
within the Mobile IPv4 protocol, and [MIPCHAL]. This specification,
in 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 IPv4
registration messages [MOBILEIP]. The key distribution is asymmetric
since communication with the mobile node occurs via the Mobile IPv4
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. The end-to-end security takes the form of TLS
or IPSec security associations between the AAAH and the FA, and the
AAAH and the HA. A DIAMETER redirect server may inform the FA of the
identity of the AAAH that serves the mobile. Similarly a redirect
server may inform the AAAH that it should establish a direct
connection with a security association to the HA. The AAAH and FA
and the AAAH and HA must mutually authenticate each other.
Calhoun Standards Track - Expires November 2004 45
Diameter MIP April 2004
Furthermore, the AAAH and HA MUST only accept TLS/IPSec connections
from known roaming partners. Alternately, if the AAAH acts as the
redirect server for an AMR message, then the AAAH may store the
Origin-Host AVP and subsequently accept a TLS/IPSec connection from
an FA that possesses the corresponding certificate. Similarly if the
HA acts as a redirect server for an HAR message then the HA may store
the Origin-Host AVP and subsequently accept a TLS/IPSec connection
from an AAAH that possesses the corresponding certificate.
Nonces are sent to the mobile node, which are used to generate the
session keys via the HMAC-SHA-1 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.
Note that the user of security associations does not strongly
authenticate the ownership of the FA's IP addresses (either the
endpoint of the TLS/IPSec connections used for AAA messages nor the
FA COA address). This could allow an FA that is part of a trusted
roaming consortium to obtain FA-HA mobility security associations
that belong to other domains, if the FA possesses copies of valid
Mobile IPv4 Registration Requests, e.g., that can pass replay
protection at the AAAH. To mitigate this threat, the AAAH may
compare the TLS/IPSec endpoint to the FA COA encoded in the Mobile
IPv4 Registration Request. This would prove the FA is routable at
the given FA COA, but suffers the drawback of forcing the FA to use
the same address for the tunnel and AAA client functionalities, which
may not be the case in all deployments.
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.
14. References
14.1. Normative
[DIAMBASE] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A.
Rubens,"Diameter Base Protocol", RFC 3588, September
Calhoun Standards Track - Expires November 2004 46
Diameter MIP April 2004
2003, December 2002.
[IANA] Narten, Alvestrand, "Guidelines for Writing an IANA C
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", Request For Comments 3021, December 2000.
[NAI] B. Aboba, M. Beadles "The Network Access Identifier."
Request For Comments 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-04.txt,
IETF work in progress, November 2003.
[AAANAI] F. Johansson, T. Johansson, "AAA NAI for Mobile IP
Extension", draft-mip4-aaa-nai-02.txt, IETF work
December 2003. (approved for publication)_
[IPSEC] S. Kent, Security Architecture for the Internet, RFC
2401, November 1998.
[TLS] Blake-Wilson, Transport Layer Security Extensions, RFC
3546, June 2003.
14.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.
Calhoun Standards Track - Expires November 2004 47
Diameter MIP April 2004
Radomness Recommendations for Security. RFC 1750,
Internet Engineering Task Force, December 1994.
15. Acknowledgements
The authors would like to thank Nenad Trifunovic, Haseeb Akhtar and
Pankaj Patel for their participation in the pre-IETF Document Reading
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. General redirect server text
due to Pasi Eronen was borrowed from Diameter-EAP. Pete McCann
improved the scalability of the HA-FA mobility security associations
and assisted in the review.
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.
16. Authors' Addresses
Questions about this memo can be directed to:
Pat Calhoun Tony Johansson
Airespace Bytemobile, Inc.
110 Nortech Parkway 2029 Stierlin Court
San Jose, CA 95154 Mountain View, CA 94043
USA USA
Phone: +1 408-635-2023 Phone: +1 650-641-7817
Email: pcalhoun@airespace.com Fax: +1 650-641-7701
Email: tony.johansson@bytemobile.com
Charles E. Perkins Tom Hiller
Nokia Research Center Lucent Technologies
313 Fairchild Drive 1960 Lucent Lane
Mountain View, CA 94043 Naperville, IL 60566
USA USA
Phone: +1 650-625-2986 Phone: +1 630-979-7673
Fax: +1 650-625-2502 E-mail: tomhiller@lucent.com
Email: charliep@iprg.nokia.com
Calhoun Standards Track - Expires November 2004 48
Diameter MIP April 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 Secretariat.
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 practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 implementation 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 languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Calhoun Standards Track - Expires November 2004 49 | PAFTECH AB 2003-2026 | 2026-04-21 19:10:28 |