Seamoby Working Group Dan Forsberg
INTERNET DRAFT Rajeev Koodli
22 Feb 2002 Charles E. Perkins
Communication Systems Laboratory
Nokia Research Center
Context Relocation of AAA Parameters in IP Networks
draft-forsberg-seamoby-aaa-relocate-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
This memo provides information for the Internet community. This
memo does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.
Abstract
Network access authentication and authorization is used for
providing unabused access to users and for billing and accounting
purposes. AAA has been proposed as an infrastructure that could
provide such support. With AAA, an access router can be configured
with packet filtering rules to allow controlled access. However, in
a wireless network, a user's Mobile Node may change its access router
multiple times due to user mobility. Thus, packet filtering state
needs to be re-established at every access router the MN visits. An
efficient way to re-establish the access network policy enforcement
in the access routers is needed to reduce the AAA signaling in the
network and in the access link. This document provides a mechanism
based on context transfer to accomplish this ``seamless'' network
access during handovers.
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page i]
Internet Draft AAA Context relocate 22 Feb 2002
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Terminology 2
3. AAA Network Access Control State 3
4. Protocol Overview 4
5. AAA Context Transfer with Handover signaling 4
6. Message Formats 5
6.1. AAA Context Transfer Request ICMP Option . . . . . . . . 6
7. AAA Context Transfer Reply ICMP Option 6
7.1. AAA Context Transfer Request CTIN Suboption . . . . . . . 8
7.2. AAA Context Transfer CTIN-Ack Suboption . . . . . . . . . 8
7.3. AAA Acknowledgment Code Format . . . . . . . . . . . . . 8
8. Configurable Parameters 9
9. Security Considerations 9
10. IANA Considerations 9
11. Acknowledgments 9
Addresses 11
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 1]
Internet Draft AAA Context relocate 22 Feb 2002
1. Introduction
Wireless access network providers need a way to authenticate
and authorize users for billing and accounting purposes. The AAA
infrastructure provides this kind of service for the provider in the
core network. For example, packet filtering can be used to block
access to the local network from unauthorized users. An access
network usually contains multiple access routers that route IP
packets to and from a user's Mobile Node (MN). During handover from
one access router to another, this packet filtering state needs to be
re-established in the new access router.
The AAA infrastructure is used to authenticate and authorize the
user for IP session(s), typically for a certain duration, called
session lifetime. The session controls packet filtering and thus a
user's access to the network. A user's mobile node may change the
access router many times during a single session. Thus, there needs
to be an efficient way to re-establish the packet filtering state in
the new access router without the need for elaborate signaling over
the AAA infrastructure. One possible way to avoid this signaling
is to use context transfers between the access routers to transfer
the required network access control state from the old router to the
new router and thus rebuild the packet filtering rules in the new
router for the user. Other possibility could be to consult the local
AAA agent about the user's AAA status. This requires additional
signaling compared to the context transfer and could slow down the
handover process.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and
"silently ignore" in this document are to be interpreted as described
in RFC 2119 [3].
We define the following terms for use in this document.
HAck Message The ICMP Handover Acknowledgment message, sent from
the New Router to the Previous Router, and defined
in [6].
HI Message The ICMP Handover Initiate message, sent from the
Previous Router to the New Router, and defined in [6].
New Router (Nrtr) The router to which the MN attaches after
handover
Previous Router (Prtr) The MN's default router prior to handover
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 2]
Internet Draft AAA Context relocate 22 Feb 2002
New access address (Naddr) The access IP address of the Mobile
Node (MN) when attached to the link served by the New
Router
Previous access address (Paddr) The access IP Address of the
Mobile Node (MN) when attached to the link served by the
Previous Router
CTIN-Ack Message Any IPv6 message received by the mobile node
containing the CTIN-Ack Destination Option defined
in [8].
CTIN Message Any IPv6 message sent by the mobile node containing
the CTIN Destination Option defined in [8].
CT-Rep Message The Context Transfer Reply message, sent between
access routers, and defined in [8].
CT-Req Message The Context Transfer Request message, sent between
access routers, and defined in [8].
Network Access Identifier (NAI) The Network Access Identifier,
or NAI [1], is used in the Diameter protocol to extract
a user's identity and realm. The identity is used
to identify the user during authentication and/or
authorization, while the realm is used for message
routing purposes.
3. AAA Network Access Control State
In AAA infrastructure, the NAI is used as the user's identity
for network access. Sessions are identified with Session-Ids,
which are bound to the NAI and thus for a specific user. Each
session has a certain lifetime and state that depends on the result
code that the AAA infrastructure provides. In the first phase,
when the user requests network access, the state is STATE_PENDING.
STATE_OPEN is reached when the AAA infrastructure has successfully
authenticated and authorized the user's NAI. In STATE_OPEN the
access network uses a mechanism to identify packets to and from the
user's mobile terminal and filters out unauthorized packets. A
binding and identification between IP packets and the user's AAA
session is required for proper network access control. One possible
way to do this is to bind the session to the mobile terminal's
IP address(es) in the access network and use packet filtering
based on the(se) address(es). This document doesn't address the
issues with address spoofing. When a session is closed, the AAA
state becomes STATE_DISCON and packet filtering rules are updated.
Re-authentication can be used to increase the session lifetime.
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 3]
Internet Draft AAA Context relocate 22 Feb 2002
In the rest of this document we simply call the state necessary
for network access ``AAA context'' or ``AAA state''.
4. Protocol Overview
When a suitable trigger arrives, the MN's previous access router
transfers the AAA access control state to the MN's new access router.
The examples of suitable triggers include an explicit message from
the MN, a message from a trusted network entity controlling handover,
a link layer indication about the MN's movement etc. The Prtr uses
the Context Transfer Reply (CT-Rep) message to include the AAA state
and send it to the new access router. The Nrtr, upon verifying the
security association with the sender (i.e., Prtr), installs the
received AAA context and allows the MN's packets to pass through.
The new access router SHOULD send a CT-Rep-Ack message back to the
previous access router containing the status of AAA context transfer.
When the MN attaches to the Nrtr, it does not engage in additional
AAA protocol exchanges. However, there might be a need to update
AAA entities in the backbone about the MN's current location. For
instance, the AAA agent in the MN's home domain (AAAH) may need to
be informed if the MN changes the local domain AAA agent (AAAL). For
this, there are two options, both of which are beyond the scope of
this document. First, the MN re-authenticates itself after handover.
Second, the Nrtr informs AAAL about the MN's new location. In
either case, it is imperative that the access router belonging to a
different AAA agent ensure the MN is properly authenticated. In any
case, a protocol such as Candidate Access Router discovery [9] may
be useful in such inter-domain handovers.
5. AAA Context Transfer with Handover signaling
In this section, we provide an illustration of how the AAA state
can be transferred along-with handover signaling between the access
routers. The AAA state contains variables that together form the
transferred context. There are two handover scenarios; first, the
Prtr transfers AAA context prior to the MN's attachment to the
Nrtr, and second, the transfer takes place subsequent to the MN's
attachment to Nrtr.
In the ``fast handover'' scenario, the previous router,
in response to either the network-initiated handover or the
mobile-initiated handover, includes the AAA context in a Predictive
Context Transfer (PCT) message. The trigger to the Prtr is sent in
the form of a Context Transfer Initiate (CTIN) message. A PCT is a
general-purpose message for transferring contexts and can itself be
sent using any appropriate handover message, such as a HI message.
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 4]
Internet Draft AAA Context relocate 22 Feb 2002
The Nrtr follows the rules specified in [8] in processing the PCT
message, and then installs the AAA context. A successfull activation
of the AAA context allows the MN to continue sending its packets. In
response to the PCT message, the Nrtr SHOULD send a Context Transfer
Reply Acknowledgment (CT-Rep-Ack) message back to the Prtr. When
there is an error, the new access router sends a notification message
(CTIN-AcK) to the MN in which it includes the reason for unsuccessful
AAA context activation. In the event of an error, the MN SHOULD
re-initiate AAA signaling.
When predictive context transfer is either unavailable or fails,
the Nrtr fetches context subsequent to the MN's attachment to it.
In this ``basic handover'' scenario, the MN sends a CTIN message
containing its Previous IP address and Previous Router address to
the New Router as part of Neighbor Discovery or as an option in the
network access authentication message [2]. In response to the CTIN
message, recognizing that the required state is not available, the
Nrtr transmits a Context Transfer Request (CT-Req) message with AAA
sub option. And, the Prtr responds back with a Context Transfer
Reply (CT-Rep) message containing the actual AAA context information.
See [8] for the details.
Observe that always including the CTIN message with the AAA
suboption makes the operation robust. When the AAA context is
already present, the Nrtr would immediately allow the MN to send its
packets. When it is not available, for instance due to fast handover
protocol failure or simply due to unfavorable physical conditions,
the CTIN message with AAA suboption serves as a trigger to initiate
context transfer.
6. Message Formats
AAA options and suboptions are defined for use in several
different protocol message types:
1. as an option or a sub option to a HI, HAck, CT-Req, or CT-Rep
ICMPv6 messages.
2. as a suboption of an IPv6 destination option.
3. as an extension to a Mobile IPv4 registration request to be
processed by a Foreign Agent.
4. as an extension to some other seamless handover message to be
defined in the future for mobile nodes using IPv4.
The general format for the options is the same in all cases, as
shown in Figure 1.
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 5]
Internet Draft AAA Context relocate 22 Feb 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAAOpt Type | AAAOpt Len | AAAOpt Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: AAA Options, Suboptions and Extension Format
6.1. AAA Context Transfer Request ICMP Option
The AAAReq suboption is sent by Nrtr to Previous Router in the
CT-Req message to obtain AAA context on behalf of the mobile node.
1. Suboption Type: AAAReq-ICMP
2. Suboption Length: 0
Source address The IP address of the New Router
Destination Address The IP address of the Previous
Router
7. AAA Context Transfer Reply ICMP Option
The AAA Context Transfer Reply suboption (AAARep) is defined for
Prtr to transfer state to Nrtr in the HI or CT-Rep ICMP messages.
The AAARep suboption includes the necessary state for Nrtr to
seamlessly carry-over authentication and authorization state.
Ctxt Type An integer set to indicate AAA context
Ctxt Length Length of AAA context in 8 octets
AAA Context Profile Type
An IANA object that uniquely identifies the
type of AAA context present
Lifetime Remaining authorization lifetime in seconds
of the AAA session if in STATE_OPEN.
Remaining disconnect timeout in seconds if in
STATE_DISCON. Remaining authorization pending
lifetime in seconds if in STATE_PENDING.
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 6]
Internet Draft AAA Context relocate 22 Feb 2002
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ctxt Type | Ctxt Length | AAA Context Profile Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| State | NAI len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Id len | NAI data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Id data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: AAA Reply Data Element
State State of the session: STATE_OPEN (1),
STATE_DISCON (2), STATE_PENDING (3),
STATE_IDLE (0).
STATE_OPEN denotes that the session is
authenticated. STATE_PENDING means that
the authentication process is pending. In
STATE_DISCON state the session is about to
expire.
NAI len NAI length in bytes.
Session-Id len
Session-Id length in bytes.
NAI data Network Access Identifier (NAI) [1].
Session-Id data
Session-Id has the same format as the
Session-Id AVP data [4].
If the Lifetime is zero, it indicates that Prtr cannot supply the
required client AAA context to Nrtr.
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 7]
Internet Draft AAA Context relocate 22 Feb 2002
7.1. AAA Context Transfer Request CTIN Suboption
When the mobile node wishes to continue the same AAA session at
Nrtr, it sends the AAA Context Transfer Request (AAAReq) suboption in
a message addressed to Nrtr containing a CTIN Destination Option.
1. Suboption Type: AAAReq-CTIN
2. Suboption Length: 0
7.2. AAA Context Transfer CTIN-Ack Suboption
The AAA Context Transfer Acknowledge suboption (AAAAck) is defined
for inclusion in the CTIN-Ack IPv6 Destination Option, and is used
by Nrtr to respond to the mobile node. Note that CTIN-Ack is an
optional message. The MN SHOULD be prepared to accept packets
treated with feature contexts even when it does not receive a
CTIN-Ack message.
1. Suboption Type: AAAAck-CTIN-Ack
2. Suboption Length: 1
The AAAAck-CTIN-Ack message has a AAAAck Response Code. The
format is shown in Figure below.
7.3. AAA Acknowledgment Code Format
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| AAAAck Code |
+-+-+-+-+-+-+-+-+
Figure 3: AAA Context Transfer CTIN-Ack
Suboption (AAAAck) format
In this section, we define the various result codes sent back to
the MN in response to its request for AAA context transfer.
1. Code: 00 (AAA_CT_SUCCESSFUL)
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 8]
Internet Draft AAA Context relocate 22 Feb 2002
This reply code denotes successful AAA context transfer and AAA
session state construction.
1. Code: 02 (AAA_CT_ERROR)
This reply code denotes AAA context transfer failure and/or
AAA session state construction error. In this case the MN SHOULD
reinitiate AAA signaling for network access.
8. Configurable Parameters
Every access router supporting the mobility extensions defined
in this document SHOULD be able to configure each parameter in
the following table. Each table entry contains the name of the
parameter, the default value, and the section of the document in
which the parameter first appears.
Parameter Name Default Value
------------------- ----------------------
AAA_CONTEXT_SAVE_TIME2 * CT-Req_REXMIT_TIME
AAA_CONTEXT_PURGE_TIME5 * CT-Req_REXMIT_TIME
CTIN_WAIT_TIME 1000 milliseconds
9. Security Considerations
All context transfer for AAA MUST be secured by use of the
Authentication suboption [7], or the IPv6 Authentication Header [5].
Thus, no additional vulnerability has been introduced.
10. IANA Considerations
The AAA Profile Type described in this document needs IANA type
number assignment.
11. Acknowledgments
Stefano Faccin provided valuable feedback and input to this
document.
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 9]
Internet Draft AAA Context relocate 22 Feb 2002
References
[1] B. Aboba and M. Beadles. The Network Access Identifier (work
in progress). Internet Draft, Internet Engineering Task Force,
November 1998.
[2] N. Asokan, P. Flykt, C. Perkins, and T. Eklund. AAA for IPv6
Network Access (work in progress). Internet draft, Internet
Engineering Task Force, 2001.
[3] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[4] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER
Base Protocol (work in progress). Internet Draft, Internet
Engineering Task Force.
draft-calhoun-diameter-12.txt, December 1999.
[5] S. Kent and R. Atkinson. IP Authentication Header. Request for
Comments (Proposed Standard) 2402, Internet Engineering Task
Force, November 1998.
[6] R. Koodli and C. Perkins. Fast Handovers in Mobile IPv6 (work in
progress). Internet Draft, Internet Engineering Task Force.
draft-koodli-mobileip-fastv6-01.txt, October 2000.
[7] R. Koodli and C. Perkins. A Framework for Smooth Handovers
with Mobile IPv6 (work in progress). Internet Draft, Internet
Engineering Task Force.
draft-koodli-mobileip-smoothv6-01.txt, November 2000.
[8] R. Koodli and C. Perkins. A Context Transfer Framework for
Seamless Mobility (work in progress). Internet Draft, Internet
Engineering Task Force.
draft-koodli-seamoby-ct-03.txt, July 2001.
[9] D. Trossen and et al. Issues in candidate access router
discovery for seamless IP-level handoffs (work in progress).
Internet Draft, Internet Engineering Task Force, January 2002.
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 10]
Internet Draft AAA Context relocate 22 Feb 2002
Addresses
Questions about this memo can also be directed to the authors:
Dan Forsberg
Communications Systems Lab
Nokia Research Center
Itamerenkatu 11-13
00180 HELSINKI
Finland
Phone: +358-50 483-9470
Fax: +358 718-036-227
Rajeev Koodli
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2359
EMail: rajeev.koodli@nokia.com
Fax: +1 650 625-2502
Charles Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502
Forsberg, Koodli, Perkins Expires 22 July 2002 [Page 11]