One document matched: draft-ietf-aaa-mobile-ip-req-00.txt
INTERNET DRAFT G. Dommety
Category: Informational Cisco Systems
Title: draft-ietf-aaa-mobile-ip-req-00.txt S. Glass
April 1999 Nokia Telecommunications
T.Hiller
Lucent
S. Jacobs
GTE Laboratories
B. Patil
Nortelnetworks
C. Perkins
Sun Microsystems
Mobile IP Authentication, Authorization, and Accounting Requirements
draft-ietf-aaa-mobile-ip-req-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 document is a submission by the AAA Working Group of the
Internet Engineering Task Force (IETF). Comments should be
submitted to the aaa-wg@merit.edu mailing list.
Distribution of this memo is unlimited.
Abstract
The AAA Working Group is currently looking at defining the
requirements for Authentication and Authorization. This document
contains the requirements which would have to be supported within
AAA to aid in providing Mobile IP services.
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 1]
Internet Draft Mobile IP AAA Requirements 25 June 1999
Contents
Abstract.......................................................... 1
1.0 Introduction ............................................. 2
1.1 Background ............................................... 2
1.2 Terminology .............................................. x
2.0 Mobile IP Utilization of AAA...............................x
2.1 Brokerage with apriori contract arrangements ............. x
2.2 Opportunistic with dynamic/on-the-fly contracting ........ x
2.3 Third party (i.e. pre-paid and/or Credit Service) ........ x
3.0 Mobile IP AAA Requirements ............................... x
3.1 Authentication Requirements .............................. x
3.2 Authorization Requirements ............................... x
3.3 Accounting Requirements .................................. x
4.0 Future Considerations ("in the spirit of Mobile IP").......x
5.0 Security Considerations................................... x
A.0 Mobile IP Deployment Types and Overview................... x
A.1 Mobile IPv4................................................x
A.2 Mobile IPv6................................................x
References........................................................ x
Authors' Address.................................................. x
1. Introduction
1.1 Background
Customers obtain internet services by being provided a point of
attachment to a "home domain", generally from an ISP, or other
organization from which service requests are made, and fulfilled.
With the increasing popularity of mobile devices, a need has been
generated to allow users to attach to any domain convenient to their
current location. In this way, a customer needs access to resources
being provided by an administrative domain different than their home
domain (called a "foreign domain"). In no specific order, the need
for service from a foreign domain requires, in many models,
accounting, which leads directly to authorization, and of course
authentication. (Note: there is some argument which of these leads
to, and is derived from the others, but there is common agreement
that all are needed, and in general simultaneously).
An agent in a foreign domain, being called on to provide access
to a resource by a mobile user (a.k.a. the customer), is likely to
request, if not require, the customer provide credentials which can
be authenticated before access to resources are permitted. These
resources may be as simple as a conduit back to the customer's home
domain, or may be as complex as access to specific private resources
within the foreign domain. These credentials can be exchanged in
many different ways, all of which are beyond the scope of this
document, however the need for this transaction is recognized, and
the ability for the foreign domain to authenticate the mobile user
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 2]
Internet Draft Mobile IP AAA Requirements 25 June 1999
is necessary in order for the user to be allowed access. Once the
mobile user is authenticated, services within the foreign domain it
is authorized to access, as well as an account of the actual
resources used can be assembled.
Mobile IP is a technology that allows a network node ("host
computer") to migrate from its "home" network to other networks,
either within the same administrative domain, or to other
administrative domains. This document will identify, describe, and
discuss the functional and performance requirements for Mobile IP
in the areas of Authentication, Authorization, and Accounting.
The formal description of Mobile IP can be found in [RFC2002], and
its supporting documents [RFC2003], [RFC2004], [RFC2005], [RFC2006],
and [RFC2290]. A very basic overview of the extent of the Mobile IP
protocol is given in appendix A, and is provided for motivation
only.
1.2. Terminology
This document frequently uses the following terms:
Accounting
The act of collecting information on resource usage for
the purpose of trend analysis, auditing, billing, or
cost allocation.
Agent Advertisement
An advertisement message constructed by attaching a
special "mobility extension" to the standard RFC1256
router advertisement message.
Authentication
The act of verifying the identity of an entity (subject).
Authorization
The act of determining whether a requesting entity
(subject) will be allowed access to a resource (object).
Billing
The act of preparing an invoice.
Care-of Address
The termination point of a tunnel toward a mobile node,
for datagrams forwarded to the mobile node while it is
away from home. The protocol can use two different types
of care-of address: A "foreign agent care-of address" is
an address of a foreign agent with which the mobile node
is registered, and a "co-located care-of address" is an
externally obtained local address which the mobile node
has associated with one of its own network interfaces.
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 3]
Internet Draft Mobile IP AAA Requirements 25 June 1999
Correspondent Node
A peer with which a mobile node is communicating. A
correspondent node may be either mobile or stationary.
Foreign Agent
A router on a mobile node's visited network which
provides routing services to the mobile node while
registered. The foreign agent detunnels and delivers
datagrams to the mobile node that were tunneled by the
mobile node's home agent. For datagrams sent by a mobile
node, the foreign agent may serve as a default router for
registered mobile nodes.
Foreign Network
Any network other than the mobile node's Home Network.
Home Address
An IP address that is assigned for an extended period of
time to a mobile node. It remains unchanged regardless
of where the node is attached to the Internet.
Home Agent
A router on a mobile node's home network which, when the
mobile node is away from home, receives traffic for the
mobile node, tunnels these datagrams for delivery to the
mobile node, and maintains current location information
for the mobile node.
Home Network
A network having a network prefix matching that of a
mobile node's home address. Note that standard IP
routing mechanisms will deliver datagrams destined to
a mobile node's Home Address to the mobile node's
Home Network.
Inter-domain Accounting
Inter-domain accounting is the collection of
information on resource usage of an entity with an
administrative domain, for use within another
administrative domain. In inter-domain accounting,
accounting packets and session records will typically
cross administrative boundaries.
Intra-domain Accounting
Intra-domain accounting is the collection of information
on resource within an administrative domain, for use
within that domain. In intra-domain accounting,
accounting packets and session records typically do not
cross administrative boundaries.
Link A facility or medium over which nodes can communicate at
the link layer. A link underlies the network layer.
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 4]
Internet Draft Mobile IP AAA Requirements 25 June 1999
Link-Layer Address
The address used to identify an endpoint of some
communication over a physical link. Typically, the
Link-Layer address is an interface's Media Access Control
(MAC) address.
Mobile Node
A host that changes its point of attachment from one
network or subnetwork to another. A mobile node
may change its location without changing its IP address;
it may continue to communicate with other Internet nodes
at any location using its home IP address, assuming
link-layer connectivity to a point of attachment is
available, and either foreign agent, or colocation
authorization is available.
Mobility Agent
Either a Home Agent or a Foreign Agent.
Mobility Binding
The association of a home address with a care-of address,
along with the remaining lifetime of that association.
Node A host or a router.
Real-time Accounting
Real-time accounting involves the processing of
information on resource usage within a defined time
window. Time constraints are typically imposed in order
to limit financial risk.
Session record
A session record represents a summary of the resource
consumption of a user over the entire session. Accounting
gateways creating the session record may do so by
processing interim accounting events.
Tunnel The path followed by a datagram while it is encapsulated.
The model is that, while it is encapsulated, a datagram
is routed to a knowledgeable decapsulating node, which
decapsulates the datagram and then correctly delivers it
to its ultimate destination.
Visited Network
A network other than a mobile node's Home Network, to
which the mobile node is currently connected.
1.3. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [RFC2119].
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 5]
Internet Draft Mobile IP AAA Requirements 25 June 1999
2.0 Mobile IP Utilization of AAA
Mobile IP is dependent on authentication between the mobile node,
and its home agent. Moreover, there are modes for authentication
between mobile-node and foreign domain, as well as authentication
between home domain and foreign domain. There are no authentication
modes specific to Mobile IP between mobile node and correspondent
node as, to the correspondent, the mobile node is on its home
network (this does not preclude the use of any other security type
as an enhancement to Mobile IP, such as IPSec, however). In the
most general sense, the latter two Mobile IP authentication modes
place a demand on the ability for a node in one domain to
authenticate a node from another domain for a specific service,
perhaps attaching (agreed-on) fee(s) for specific service(s). This
can be accomplished in (essentially) two ways: with a pre-existing
service agreement between two administrative domains, or by
negotiating a service agreement "on-the-fly", possibly with a
trusted third party (a.k.a "brokerage"). Each of these topologies
is described below.
2.1. Pre-existing Contract Arrangements (Home-Foreign agreement)
In some circumstances, there may be an agreement in place before
the mobile node joins the foreign domain. This may be in the form
of either "bill-before-service", or "service-before-bill" agreement.
Note that services and rates are agreed on before hand in both
cases, but in the former case the general model is payment is made
after service is provided (e.g. home phone service model), and in
the later case payment is made before service (e.g. pre-paid phone
card model).
2.1.1 Existing 2-party handshake
In many circumstances, the mobile user (aka customer) will know
which services they need, or are likely to need, from a specific
administrative domain before actually visiting it. In this
circumstance a service agreement between the two administrative
domains may be put in place before the mobile node joins the foreign
domain. In this way perhaps the mobile node's credentials, or some
way to authenticate them, are at the foreign domain before the
mobile node arrives. Similarly, the mobile node may bring with it
the foreign domain's credentials, or some way to authenticate them.
Services the mobile node requires, has access to, and whatever the
billing requirements are for (each) such service may have also been
worked out in advanced. In addition, it is likely home and foreign
domains have already been authenticated to one another, but a
confirmation when service begins MUST be made.
2.1.2 Third party (i.e. pre-paid and/or Credit Service) Contract
This category can be broken into a few smaller ones. There's
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 6]
Internet Draft Mobile IP AAA Requirements 25 June 1999
the dial-in notion where you plug-in somewhere either directly, or
connect via PPP and get Mobile IP service. There's an additional
concept of going in to a cyber cafe (or a 7-11) and getting a
"pre-paid network card" which you insert into your laptop. At this
time Mobile IP registration takes place; perhaps the card shares an
authentication to the visited domain (which is the card's home
domain) to make sure it's not pirated. The mobile node
authenticates itself to its home domain as usual, and if needed, any
authentication between the home and foreign domains is resolved as
well.
2.1.3 Ramifications for Requirements
From the above scenarios we can identify the following requirements:
- There MUST be a way for the foreign domain to authenticate the
credentials of the mobile node. Either it has the ability to
authenticate the credentials itself, or it has the ability to
securely contact an authentication authority and have the
credentials verified on its behalf. How the local authentication
authority does this is beyond the scope of this document, however
there MUST NOT be a requirement that the mobile node be in contact
with its home domain prior to authenticating itself to the foreign
domain (as in a requirement that the mobile node boot at home
prior to roaming).
- There MUST be a way for the mobile node to authenticate the
credentials of the foreign domain. This need not necessarily be
before the foreign domain verifies its credentials, and so may be
done in cooperation with its home domain. There is an implication
in the registration process of Mobile IP that the mobile node
verifies itself to the foreign domain before the foreign domain is
verified by the mobile node. Whatever the AAA solution, there
MUST NOT be a "chicken and egg" problem.
- There MUST be a way for the home domain and the foreign domain
to mutually authenticate each other. There is an implication in
the registration process of Mobile IP that the foreign domain
verifies itself to the home domain before the home domain replies,
and verifies itself to the foreign domain. Whatever the AAA
solution, there MUST NOT be a "chicken and egg" problem.
- There must be a way for the foreign domain to be notified of
new credentials, either before a mobile node connects to the
foreign domain, or while it is connected and receiving service.
Depending on the new credentials this may or may-not require a
challenge-request from the foreign domain to the registered mobile
node. Such speculation is beyond the scope of this document,
though any AAA protocol should not preclude this requirement.
- If the foreign agents and foreign-domain authentication
authorities are different machines then they MUST share a security
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 7]
Internet Draft Mobile IP AAA Requirements 25 June 1999
relationship.
- There MUST be a way for the foreign agent to "keep state" for
pending credential requests while the authentication authority is
examining the mobile node's credentials.
- The authentication solution must be scalable. Essentially an
unlimited number of mobile nodes may be registering with the same
foreign agent simultaneously.
- Since the mobile node is not likely to get service until its
credentials are checked, it MUST be able to provide complete, yet
unforgeable credentials without the need to interact with its home
domain.
- Since the credentials must remain unforgeable, any intervening
node MUST NOT be able to learn any (secret) information which may
enable it to reconstruct the credentials.
- There MUST be a mechanism in the authentication process to
guard against replay attacks.
2.2. Dynamic/on-the-fly contracting, the Broker model
2.2.1 Negotiation Topology
While the scenarios described above work for a limited number of
administrative domains providing service for, or receiving service
from, a limited number of administrative domains, it is likely to
not be possible for every administrative domain to have service
contracts with every other administrative domain. Ideally, then,
there needs to be a mechanism in place for "on the fly"
negotiations. This document recognizes the fact that there are
non-negotiable items related to authentication which are based on
site policies, and are likely to be inflexible. Accounting, and
authorization, on the other hand, may provide some areas where
negotiation between home and foreign administrative domains can take
place.
As an example, in the single-negotiation scenario, a mobile node,
who's home is DOMAIN-A connects to DOMAIN-B with which DOMAIN-A does
not already have a service agreement. There may be overlap between
the two ISPs authorization and accounting requirements allowing for
a service connection. For example, DOMAIN-B may wish to charge the
mobile node $20.00 for the connection. If DOMAIN-A (or the MN user)
is willing to pay it, then the MN can be granted the authority to
use at least the minimal set of Mobile IP services. If DOMAIN-B is
willing, other services may also be authorized, such as reverse
tunneling, and such a negotiation may also be performed.
It's important to note that, if there needs to be a negotiation for
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 08]
Internet Draft Mobile IP AAA Requirements 25 June 1999
authorization to certain services, those parameters which are
required by all parties for Mobile IP functionality on the visited
network SHOULD be negotiated first. That is, in the above example,
if reverse tunneling is considered a requirement by the mobile node,
then reverse tunnelling MUST be agreed to before billing begins.
The same is true if the foreign domain is requiring reverse
tunnelling, but the home domain is unwilling to use it. If one party
has explicitly demanded a parameter as a requirement, but the other
party is unable to provide/accept it, then there is no mid-ground,
and (this instance of) on-the-fly contracting has failed.
Motivated by this, we propose the ability for a foreign agent to
inform a AAA server what services are going to need to be authorized
for a specific mobile node, so an authorization decision can be made
before registrations are forwarded to the home network. If a AAA
server deems the requested combination is not possible, a foreign
agent SHOULD return error 65, "administratively prohibited", to the
mobile node and await another (modified) registration request. The
foreign agent may alter its agent advertisements to the network
however it sees fit. We believe it's likely a foreign agent will be
advertising in accordance with the policies configured on its AAA
server, but the resolution of services these beacons are advertising
is likely a superset of all services offered (as per [2002], but NOT
necessarily what every mobile node will be authorized to use.
2.2.2 Ramifications for Requirements
From the above scenarios we can identify the following
requirements in addition to those identified in section 2.1.3 above.
- Allowing negotiation of service terms by way of a brokerage
model SHOULD be allowed.
- AAA MUST recognize that each administrative domain will provide
different capabilities (likely a subset of choice of manufacturer,
and local policy), and hence service parameters will vary from
administrative domain to administrative domain. There MUST be a
way for the domains to negotiate a minimal set of service
requirements they deem necessary for service. There need not be
any guarantee all identified services, or access to them, is
available, however. In analogy, there MUST be a way for the home
domain to inform the foreign domain which services it deems
necessary for communication with the mobile node.
- There MUST be a way for the foreign domain and home domains to
verify message integrity even though the messages have passed
through an intermediate negotiator. Note: the negotiator may be a
trusted third-party, or exist in part within multiple domains
(such as between brokers in the home and foreign domains). When
such negotiations include the mobile node, it MUST be able to
verify the integrity of the messages as well.
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 9]
Internet Draft Mobile IP AAA Requirements 25 June 1999
3.0 Mobile IP requirements on AAA
Based on the above scenarios, and the topology of Mobile IP itself,
the following breakdown of requirement for AAA from Mobile IP can be
ascertained. We repeat, and add to, all the requirements stated in
section 2 above, unionizing when necessary, for completeness.
Since Mobile IP provides no distinction between these categories,
if AAA requires a policy demanding only one set of services, a
restriction on Mobile IP functionality may result. Some
administrative policies may demand some restrictions on their
networks, but the AAA protocol MUST NOT explicitly make any
restrictions.
3.1 Authentication
- There MUST be a way for the foreign domain to authenticate the
credentials of the mobile node. Either it has the ability to
authenticate the credentials itself, or it has the ability to
securely contact an authentication authority and have the
credentials verified on its behalf. How the local authentication
authority does this is beyond the scope of this document.
- There MUST be a way for the mobile node to authenticate the
credentials of the foreign domain. This need not necessarily be
before the foreign domain verifies its credentials, and so may be
done in cooperation with its home domain. There is an implication
in the registration process of Mobile IP that the mobile node
verifies itself to the foreign domain before the foreign domain is
verified by the mobile node. Whatever the AAA solution, there
MUST NOT be a "chicken and egg" problem.
- There MUST be a way for the home domain and the foreign domain
to mutually authenticate each other. There is an implication in
the registration process of Mobile IP that the foreign domain
verifies itself to the home domain before the home domain replies,
and verifies itself to the foreign domain. Whatever the AAA
solution, there MUST NOT be a "chicken and egg" problem.
- AAA authentication support for Mobile IP MUST either be able to be
supported by the mobility agents, or the Mobility Agents MUST have
a way of obtaining the information they require from a AAA server
in a timely fashion. Based on requirements from [2002], this is
on the order of less-than 1 sec between request and final
response.
- Challenge authentications MUST also be supported, though are not
as time-critical, and are likely to need to be performed within
the resolution of the billing, specifically hourly, 1/2 hourly,
1/4 hourly, every 6 minutes (1/10 of an hour), or maybe as often
as once per minute.
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 10]
Internet Draft Mobile IP AAA Requirements 25 June 1999
- There must be a way for the foreign agent to "keep state" for
pending credential requests while the authentication authority is
examining the mobile node's credentials.
- The authentication solution must be scalable. The AAA protocol
MUST be able to handle unlimited number of authentications as the
number of mobile nodes registering with the same foreign agent can
be unbounded, as can the number of simultaneous registration
attempts. The AAA protocol MUST be able to handle mobility agents
providing Mobile IP services to an unlimited number of mobile
nodes.
- Since the mobile node is not likely to get service until its
credentials are checked, it MUST be able to provide complete, yet
unforgeable credentials without the need to interact with its home
domain.
- Since the mobile node's credentials must remain unforgeable, any
intervening node must not be able to learn any (secret)
information which may enable it to reconstruct the credentials.
- There MUST be a mechanism in the authentication process to guard
against replay attacks. This mechanism need not be hidden from a
snooper, but it must prevent the snooper from successful replay.
- There MUST be a way for the foreign domain and home domains to
verify message integrity when the messages have passed through an
intermediate negotiator. Note: the negotiator may be a trusted
third-party, or exist in part within multiple domains (such as
negotiation between brokers in the home and foreign domains).
When such negotiations include the mobile node, it MUST be able to
verify the integrity of the messages as well (as part of the home
domain).
- AAA MUST NOT place additional constraints on the re-registration
of a mobile node with its current home agent.
- AAA MUST NOT place the constraint that a mobile node be required
to re-register with the same home agent.
3.2 Authorization
Mobile IP considers several different resource categories available
to the mobile node, but does not differentiate between them. Since
Mobile IP provides no distinction between these categories, if AAA
were to require a policy demanding only a subset of these resources,
a restriction on Mobile IP functionality may result. Some
administration domain policies may prohibit authorization to a
selection of these, but the AAA protocol itself MUST NOT make any
restrictions.
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 11]
Internet Draft Mobile IP AAA Requirements 25 June 1999
AAA MUST provide an authorization mechanism for the mobile node to
any of the following services for which it is controlling access:
- link access to the visited network
- router advertisement messages, possibly received in response to
solicitations (to either the all subnet broadcast address
255.255.255.255, or the all mobile-agent address 224.0.0.11),
or by "snooping" network traffic sent to either the all subnet
broadcast address, 255.255.255.255, or the all host IGMP multicast
address 224.0.0.1
- potential access to a topologically routable address for the
visited subnet (such as that obtained via DHCP, PPP, etc.).
AAA MUST provide an authorization mechanism for the foreign agent
to provide these services for a visiting mobile node:
- foreign agent care-of address service
- The ability for the foreign agent to receive tunneled datagrams
for the mobile node
- The ability for the foreign agent to act as a first-hop router for
the mobile node
- foreign agent packet decapsulation service
- IP-in-IP decapsulation is a required service.
- Minimal Encapsulation decapsulation MAY be provided.
- GRE decapsulation MAY be provided
- foreign agent packet encapsulation (reverse tunnelling)
- IP-in-IP encapsulation is required
- Minimal Encapsulation encapsulation may be provided
- GRE encapsulation may be provided
AAA MUST provide an authorization mechanism for the home agent to
provide these services for a mobile node visiting another subnet:
- the ability to gratuitous ARP, thereby updating the ARP
caches of the machines normally one-hop away from the
mobile node, and claiming its IP address on the home link.
- home agent encapsulation service MUST be provided
IP-in-IP encapsulation is required.
Minimal Encapsulation encapsulation MAY be provided.
GRE encapsulation MAY be provided.
- home agent packet decapsulation (reverse tunnelling)
- IP-in-IP decapsulation is required
- Minimal Encapsulation decapsulation may be provided
- GRE decapsulation may be provided.
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 12]
Internet Draft Mobile IP AAA Requirements 25 June 1999
The ability for the home agent to then forward the decapsulated
datagrams to the network.
AAA MUST recognize that each administrative domain will provide
different capabilities (likely a subset of choice of manufacturer,
and local policy), and hence service parameters will vary from
administrative domain to administrative domain. There MUST be a way
for the domains to negotiate a minimal set of service requirements
they deem necessary for service. There need not be any guarantee
all identified services, or access to them, is available, however.
In analogy, there MUST be a way for the home domain to inform the
foreign domain which services it deems necessary for communication
with the mobile node.
If any part of the registration process (such as replay protection)
is going to involve the AAA servers, access to a real-time clock
MUST be authorized. Note that Mobile IP by itself does not require
a mobile node and home agent clocks be accurate (just
synchronized).
3.3 Accounting
There are few accounting considerations within Mobile IP itself.
This is primarily due to the fact that Mobile IP considers
machine-roaming, and not user-roaming. In any event, we recognize
the need for accounting reliability. Accounting information should
be authenticatable (to aid in reconciliation). Regardless of the
authentication and authorization mechanisms, accounting information
SHOULD be available to the domains before registration is finalized.
Moreover their SHOULD be a way for any entity running accounting
software (mobile nodes and mobility agents) to get a usage summary
accurate to within the billing break-down (e.g. hour, 1/2 hour,
1/4 hour, 1/10 hour, minute, etc). The accounting break-down should
be itemized to the resolution of the individual service being
charged for. For example, basic care-of address, and reverse-
-tunnelling services as separate items. Moreover, accounting MUST
be able to be broken down to individual authorizations for
individual mobile nodes. The local administrative domain may not
require such granularity, but AAA MUST NOT prohibit it.
It was thought as [RFC2002] was growing that perhaps administrators
on foreign domains may want to charge mobile nodes for the service
of receiving its data on their subnet. It is possible, where
foreign agents have mandated the registration request pass through
them, (and/or potentially when no co-location is possible), to
tabulate bandwidth on a per-packet, or byte-sum basis, the data
being delivered to the mobile node. While this was the "spirit" at
the time, no Mobile IP mechanisms were specified to this regard in
any of the Mobile IP documents. It is therefore beyond the scope of
this document to place any requirements on AAA to do so, but it is
believed to be entirely within the scope of AAA to do so.
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 13]
Internet Draft Mobile IP AAA Requirements 25 June 1999
3.4 General Requirements
- Allowing negotiation of service terms by way of a brokerage model
SHOULD be allowed.
4.0 Future Considerations ("in the spirit of Mobile IP")
### I thought this would be something to put the finishing touches on
### the philosophical MIP approach to AAA. Anyone?
5.0 Security Considerations
This is a requirements draft for AAA based on Mobile IP. As AAA is
security driven, most of this document addresses the security
considerations AAA MUST make on behalf of Mobile IP. It is beyond
the scope of this document to make any conjectures on the usefulness,
or problems which may result from using AAA with Mobile IP. It is,
however, entirely within the scope of the AAA protocol to do so.
Appendix A - Mobile IP Deployment Types and Overview
A.1 Mobile IP - service basics
As a first effort to capture the AAA requirements regarding Mobile
IP, this document initially considers Mobile IP for IP version 4.
In the future Mobile IP for IP version 6 will be incorporated.
To understand the requirements Mobile IP places on AAA, a quick
presentation of the Mobile IP topology may be helpful.
AAA MUST support all possible Mobile IP implementations so as not
to reduce the functional support of the Mobile IP protocol. This
is not an extensive exploration of the Mobile IP core, and related
protocols. The reader is advised to be familiar with the Mobile IP
protocols. This section is included for motivation only.
A.1.2 The Mobile Node
Mobile IP requires a way for the mobile node to establish a link-
connection to the foreign subnet. Once this has been achieved,
there MUST be a way for the mobile node to passively detect it has
moved. This is generally achieved by listening for agent
advertisements beaconed by mobility agents. Alternatively, a
mobile node may send router solicitations on any of it's links in
order to receive the advertisements. When a mobile node receives
an advertisement, it determines if this link has changed its point
of attachment based on configuration elements such as home subnet
prefix, and subnet information contained in the beacons.
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 14]
Internet Draft Mobile IP AAA Requirements 25 June 1999
If the mobile node has changed its point of attachment, and it is
not on its home subnet, it MUST get a care-of address to use on the
visited subnet. While foreign agents in general provide a local
care-of address, and decapsulation services for mobile nodes, there
is no requirement that a foreign agent MUST be the care-of address
for a visiting mobile node, and therefore there is no requirement
that a foreign agent MUST provide decapsulation services to a
mobile node. A mobile node MAY get a locally routeable address via
any dynamic address assignment protocol (such as DHCP, PPP, etc) to
use as a care-of address. Regardless of where the local care-of
address is physically located, the MN formulates a registration
request which MUST always include replay protection, and an
extension authenticatable by a home agent on the mobile node's home
link. This authenticatable registration request is either directed
at the home subnet of the mobile node (if the mobile node has
obtained a local care-of address), or at the link address of one of
the beaconing foreign agents for forwarding to the mobile node's
home subnet. In addition, a beconning foreign agent MAY require
the mobile node always pass registration requests through it. If
the mobile node is passing the registration request through a
foreign agent, the mobile node MAY also make the registration
request authenticatable to the foreign agent via a separate
extension in the registration request.
Note: the mobile node need NOT have an assigned home agent. There
is a mechanism in [2002] which describes a home-agent discovery.
Also, the mobile node also need NOT have an assigned home address.
There are mechanisms being devised to provide a mobile node an
assigned home address dynamically from the home subnet at the time
of registration. AAA MUST NOT rely on the mobile node having a
valid IP address at any time before registration is complete.
An authenticatable registration reply from a home agent, sent via
the care-of address the mobile node is using, should return
shortly. If not, the mobile node is only allowed to attempt to
register at most once-per-second. The reply from a home agent will
either indicate acceptance, or denial with a suitable error code.
The mobile node may then adapt its next registration request
accordingly, and reregister.
Each registration request and reply is either timestamped, or
identified by a unique (to each MN-HA "registration-session") nonce
so as to protect against replay attacks. It is the responsibility
of the mobile node to reregister in a timely enough fashion as to
avoid any lapse in service.
While away from its home subnet, a mobile node MUST use its care-of
address as its first hop. If the care-of address the mobile node
is using belongs to a foreign agent, the foreign agent becomes its
first hop router for delivery of all datagrams. If the mobile node
is using a colocated care-of address, all datagrams must emanate
from the care-of address as if being routed by it, that is the
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 15]
Internet Draft Mobile IP AAA Requirements 25 June 1999
care-of address MUST NOT be the source address of the datagram. In
this case the mobile node continues to use its home address as the
care-of address.
If, upon receiving an agent advertisement, the mobile node
determines it has changed its point of attachment, and it is now on
its home subnet, a special form of the registration request is
sent, namely a deregistration request. This notifies the home
agent that the mobile node has returned to the home subnet. A
gratuitous ARP then needs to be sent by the mobile node to update
the ARP-caches of nodes on the home subnet.
A.1.3 The Mobility Agent
Mobility agents MUST advertise their presence on a link. This is
done by appending a "mobility extension" on to an RFC1256 router
advertisement. It is common practice for a mobility agent to also
append subnet information as well onto the same enhanced router
advertisement to aid the mobile node in move detection. These
beacons are not allowed to be sent at a rate of more than
once-per-second, and must also be sent to either the all-subnet
broadcast address, 255.255.255.255, or the all-host IGMP multicast
address, 224.0.0.1. The mobility agent must also respond to
router solicitation messages sent to either the all-subnet
broadcast address, or the all-mobility-agents multicast address
224.0.0.14, by unicasting the same mobility-extension enhanced
router advertisement to the requesting node.
A.1.3.1 The Foreign agent
In addition to the above, foreign agents provide local care-of
addresses, and decapsulation services for mobile nodes. There is
no requirement that a foreign agent be the care-of address for a
visiting mobile node, however, and therefore there is no
requirement that a foreign agent provide decapsulation services for
a mobile node. As described above, in this case the mobile node
must either find another foreign agent willing to decapsulate
packets for it, or must find a suitable address to co-locate with.
In general practice, however, all foreign agents have the
capability to decapsulate packets for visiting mobile nodes, though
may be busy due to resources allocated for visiting mobile nodes
already registered with them.
If the mobile node wishes a foreign agent to serve as the tunnel
decapsulation point for it, the foreign agent will receive a
registration packet from the mobile node with information destined
for the mobile node's home subnet. The registration request MAY
also contain a extension authenticating the mobile node to the
foreign agent. If the registration request is acceptable, the
foreign agent must enter the mobile node's link-layer address in
its ARP cache, and the mobile node's home address and requested
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 16]
Internet Draft Mobile IP AAA Requirements 25 June 1999
binding lifetime into its visitor's list. The foreign agent should
also remember the mobile node's Home Agent address at this time, if
supplied. The registration request is then sent verbatim (less
any FA authenticator consumed by the foreign agent) to the home
subnet identified in the registration request. An extension
authenticating the foreign agent to the home agent MAY be attached.
If a registration reply does not arrive, the foreign agent is not
responsible for retransmitting the registration request.
When the foreign agent receives a registration reply, it may
contain an extension authenticating the home agent to the foreign
agent. The foreign agent should verify the mobile node's home
address in the reply exists in its visitor's list, and forward it
to the mobile nodes link-layer address contained in its ARP-cache.
It must also take note of whether the registration was denied, in
which case it may clean up the resources it dedicated to this
mobile node, or whether the registration was approved, and if so
for how long (and not longer than the FA originally granted). The
foreign agent MUST provide the decapsulating service it promised
for at least this period. It is the responsibility of the
visiting mobile node to renew this registration if it wishes to
continues using this foreign agent beyond the granted lifetime.
A.1.3.2 The Home Agent
Home agents advertise their presence in exactly the same fashion as
foreign agents. This is done so a mobile node will know when it
has returned home without any special "home-detection" mechanism.
Home agents will also receive authenticatable registration requests
from "their" mobile nodes which are visiting foreign subnets. The
Home Agent must analyze these registration requests, and respond
accordingly with an authenticatable registration reply in a
reasonable amount of time. In case of denial, a corresponding
error code must be returned. In case of approval, it must also
include the lifetime which it is willing to act on behalf of the
mobile node, not greater than that in the registration request. In
addition, the home agent must send a gratuitous ARP on the mobile
node's home link identifying the mobile node's home IP address, and
its own link-layer address on this interface in order to update the
ARP-table entries of nodes on this subnet. In either case an
authenticatable registration reply must be sent by the home agent
to the care-of address identified in the registration request sent
by the mobile node. This registration reply MAY include
authentication for the foreign agent servicing the mobile node.
When the home agent is acting on behalf of the mobile node, it will
receive datagrams on the interface located on the mobile node's
home link sent to the mobile node's home IP address, but to its own
link-layer address. When this happens, the home agent will
encapsulate the datagram using it's address as the source address,
and the mobile node's care-of address as the destination, and send
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 17]
Internet Draft Mobile IP AAA Requirements 25 June 1999
them to the mobile node's care-of address. Encapsulation can be
done in any one of several ways. If the mobile node has requested
broadcast and multicast forwarding, the home agent multiply
encapsulates these datagrams, first with the mobile node's home
address, then with the care-of address being used by the mobile
node.
The home agent must act on behalf of the mobile node for at least
the lifetime it approved in the last registration reply it sent to
the care-of address of the mobile node. It is the responsibility
of the mobile node to reregister if it will be away from the home
network beyond this time.
A.2 Mobile IPv6
<tbd>
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 18]
Internet Draft Mobile IP AAA Requirements 25 June 1999
References
[RFC1256] Deering, S., editor, "ICMP Router Discovery Messages",
September 1991.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", April 1992.
[RFC1541] Droms, R., editor, "Dynamic Host Configuration Protocol",
October 1993.
[RFC1701] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic
Routing Encapsulation (GRE)", October 1994.
[RFC2002] Perkins, C., editor, "IP mobility support", October 1996.
[RFC2003] Perkins, C., "IP Encapsulation within IP", October 1996.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP" October 1996.
[RFC2005] Solomon, J., "Applicability Statement for IP Mobility
Support", October 1996
[RFC2006] D. Cong, D., Hamlen, M., editors, "The Definitions of
Managed Objects for IP Mobility Support using SMIv2",
October 1996.
[RFC2119] Bradner, S., editor, "Key words for use in RFCs to Indicate
Requirement Levels.", March, 1997.
[RFC2290] Solomon, J., Glass, S., "Mobile-IPv4 Configuration Option
for PPP IPCP", February 1998.
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 19]
Internet Draft Mobile IP AAA Requirements 25 June 1999
Authors' Addresses
Gopal Dommety
IOS Network Protocols
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706, USA
Phone: 408-525-1404
Fax: 408-526-4952
Email: gdommety@cisco.com
Steven M. Glass
Nokia Telecommunications
3 Burlington Woods Drive
Suite 250
Burlington, MA. 01803 USA
Phone: 781-359-5125
Fax: 781-359-5050
Email: steve.glass@ntc.nokia.com
Tom Hiller
Wireless Data Standards & Architectures
Lucent Technologies
263 Shuman Drive
Room 1HP2F-218
Naperville, IL 60563, USA
Phone: 630-976-7673
Email:tom.hiller@lucent.com
Stuart Jacobs
Secure Systems Department
GTE Laboratories,
40 Sylvan Road,
Waltham, MA 02451-1128, USA.
Phone: 781-466-3076
Fax: 781-466-2838
Email: sjacobs@gte.com
Basavaraj Patil
Wireless Technology Labs
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082-4399, USA
Phone: 972-684-1489
Fax: 972-685-3207
Email: bpatil@nortelnetworks.com
Charles Perkins
Sun Microsystems Laboratories
901 San Antonio Road, MS MPK15-214
Palo Alto, CA 94303-4900, USA
Phone: 650-786-6464
Fax: 650-786-6445
Email: cperkins@eng.sun.com
Dommety,Glass,Hiller,Jacobs,Patil,Perkins Expires Dec.25,1999 [page 20]
| PAFTECH AB 2003-2026 | 2026-04-21 19:04:04 |