One document matched: draft-ng-nemo-aaa-use-00.txt
Internet Draft C. W. Ng
Document: draft-ng-nemo-aaa-use-00.txt Panasonic Singapore Labs
T. Tanaka
Matsushita Communications
Industrial
Expires: April 2003 October 2002
Usage Scenario and Requirements for AAA in Network Mobility Support
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 memo set out the basic Authentication, Authorization, and
Accounting (AAA) model for Network Mobility Support (NEMO), and
described various usage scenarios. From the scenarios, a set of AAA
requirements in NEMO is drawn.
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].
Ng, Tanaka Expires - April 2003 [Page 1]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
Table of Contents
1. Introduction...................................................2
1.1. Terms Used................................................3
1.2. Assumptions...............................................3
2. Overview of Operation..........................................4
2.1. Overview of Visiting Mobile Nodes Operation...............4
2.2. Resources Needed for NEMO Operation.......................4
2.3. Overview of AAA Operation.................................4
2.3.1. AAA Operation between MR and Access Router...........5
2.3.2. AAA Operation between VMN and MR.....................6
2.4. Home Resources vs Foreign Resources.......................7
3. Usage Scenario.................................................7
3.1. Scenario 1................................................8
3.1.1. Example..............................................8
3.1.2. AAA Operations.......................................9
3.2. Scenario 2................................................9
3.2.1. Examples............................................10
3.2.2. AAA Operations for MR...............................10
3.2.3. AAA Operations for MNNs.............................10
3.3. Scenario 3...............................................11
3.3.1. Examples............................................11
3.3.2. AAA Operations......................................12
3.4. Scenario 4...............................................12
3.4.1. Examples............................................12
3.4.2. AAA Operations......................................13
3.5. Scenario 5...............................................13
3.5.1. Examples............................................14
3.5.2. AAA Operations......................................14
4. AAA Requirements..............................................14
5. Security Considerations.......................................16
6. Acknowledgement...............................................17
References.......................................................17
Author's Addresses...............................................18
1. Introduction
The problem of Network Mobility Support (NEMO) is identified in
various previous works [3,4,5,6,7]. This document attempts to
explore the usage scenarios and requirements for Authentication,
Authorization, and Accounting (AAA) in the NEMO problem space. Since
NEMO entails various mobile devices accessing the Internet using
network resources that are in different administrative domains, AAA
is an important consideration for a NEMO solution.
In this document, we focus mainly on access control in NEMO. Since
NEMO infrastructure is by and large wireless in nature, access
control is a critical aspect for large-scale deployment of support
for NEMO. Such large-scale NEMO deployments are usually found in
Ng, Tanaka Expires - April 2003 [Page 2]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
commercial applications, where Internet Service Providers (ISP) erect
fixed and mobile access routers and allow subscribers to attach
devices to the access routers for Internet connection. Examples of
such commercial applications include providing Internet access in
trains, ships, and aircrafts.
Access control is needed in these networks in order to protect the
interest of the paying subscribers. If there is no access control,
significant portions of the network resources may be used by
unauthorized users, thereby affecting the quality of service provided
to other legitimate subscribers.
The need for access control exists in all networks that allow unknown
devices to connect to the network, and to identify itself to gain
access to services and resources provided in the network. Access
control function is usually provided by a gateway or router device,
generally known as a Network Access Server (NAS). Excellent work on
requirements for NAS can be found in [8]. It is not the objective of
this document to duplicate previous effort in defining NAS
requirements. Instead, this document explores specific requirements
that arise due to characteristics that are unique to a network in
motion. To this end, this document first presents the overview of
operations in a network in motion. Since a NEMO solution does not
exits (yet), this document assumes the operation to be based on a
reverse tunneling link between the mobile router in a mobile network
and the home agent in the home domain of the mobile router.
Following this, we describe possible usage scenarios of mobile
networks. From the usage scenarios, basic AAA requirements are drawn
out.
1.1. Terms Used
It is assumed that readers are familiar with the NEMO terminology
described in [9].
1.2. Assumptions
In this document, the following assumptions are made:
1. There exist an entity in the NEMO solution that resides in the
home domain of the mobile network node which provide
functionality similar to the home agent in the Mobile IP
specification.
2. This document assumes there is no need for local fixed nodes
(LFN) and local mobile nodes (LMN) to be authenticated by the
mobile router they attached to. This is because the LFNs and
LMNs belongs to the same administrative domain as their MR, and
are always attached to the same mobile network.
Ng, Tanaka Expires - April 2003 [Page 3]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
2. Overview of Operation
2.1. Overview of Visiting Mobile Nodes Operation
Access control of NEMO depends very much on the resources required
for NEMO solution. To identify the resources required, we have to
model the general sequence of operation. This model is applicable
whether the node is a mobile host or a mobile router. We will use
the term Visiting Mobile Node (VMN) to meant both host and router.
The sequence of operation is as follows:
(1) VMN starts up and performs auto-configuration to use a link-
local address.
(2) VMN obtains a global Care-of-Address (CoA) through router
solicitation, or Dynamic Host Configuration Protocol (DHCP)
[10].
(3) VMN discovers its Home Agent (HA) at its home domain.
(4) VMN sends the HA the appropriate binding updates.
2.2. Resources Needed for NEMO Operation
AAA is required in NEMO for two basic reasons:
(1) to control the access of and to account for the use of network
resources in the foreign domain, and
(2) to control the access of and to account for the use of network
resources in the home domain.
Network resources in the foreign domain that a VMN requires includes
a CoA, and the access to the wireless network channel. AAA for the
use of foreign resources is generally performed in a "link-local"
manner, utilizing access protocols such as IEEE 802.1x [11] to gain
access to the wireless network channel, and protocols such as DHCP
[10] to get a CoA. Since the link-layer and pool of IPv6 addresses
generally belongs to the same administrative domain, AAA for the
allocation of CoA is usually not required after granting access to
the link-layer network.
Network resources in the home domain that a VMN requires are the use
of HA, and the network bandwidth it consumes at the home domain for
the support of NEMO. Since the lowest layer where the VMN can
connect to the home network is at the IP layer, AAA operations for
the use network resources in the home domain must be carried out in
the IP layer.
2.3. Overview of AAA Operation
A plausible scenario for AAA operations is that two types of AAA
protocols will be used: a "link-local" AAA protocol, and a "global"
AAA protocol. The "link-local" AAA protocol is usually employed at
Ng, Tanaka Expires - April 2003 [Page 4]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
link-layer, and usually takes place over a single network hop.
Examples include IEEE 802.1x [11], PANA [12], or other EAP-variant
protocols [13]. The "global" AAA protocol is normally employed at
the IP layer, and usually takes place over multiple network hops.
Examples include Diameter [14], or RADIUS [15].
There are two main elements in AAA for NEMO. The first is the MR
performing AAA negotiations with the access router, and the second is
the MR handling AAA negotiations from a VMN. We will describe them
separately in the following sub-sections.
2.3.1. AAA Operation between MR and Access Router
Generally, a MR will initiate an access request by sending relevant
messages to the access router it attached to in the foreign domain
using a "link-local" AAA protocol. The access router can then
contact the AAA server in the same domain to check the credentials
provided by the MR. The AAA server in the foreign domain may or may
not have enough information to verify the credentials. If the AAA
server in the foreign network does not have sufficient information,
it can contact the AAA server in the home domain of the MR to
complete the verification process. Since the two AAA servers are
located in different domains, a "global" AAA protocol will have to be
used for the communications between them. This is depicted in Figure
1 below.
+------+
| |
| MR | <---------+ "link-local"
| | | AAA Protocol
+------+ |
+-----|---------------------+
| V | "global"
| +---------+ +---------+ | AAA Protocol
| | Access | | AAA |<--------------+
| | Router | | Server | | |
| +---------+ +---------+ | |
| Foreign Domain | |
+---------------------------+ |
| +-------|------+
/-------------\ | V |
/----| |---\ | +--------+ |
| | | | AAA | |
/---/ Internet |------| | Server | |
| | | +--------+ |
\--------| |----/ | Home Domain |
\------------/ +--------------+
Figure 1: AAA Operation between MR and Access Router.
Ng, Tanaka Expires - April 2003 [Page 5]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
2.3.2. AAA Operation between VMN and MR
When a MR allows a VMN to attach to its local mobile network based on
some access control policy, the MR is essentially behaving as a
Network Access Server, or NAS. As such, we basically model the
mobile router as NAS in this document, and draw heavily from work
done in IETF NASREQ Working Group [16].
The VMN will first initiate an access request by sending relevant
messages to the MR it attached to using a "link-local" AAA protocol.
The MR will normally not have enough information to verify the
credentials of the VMN. Thus it will have to contact an external AAA
server to perform the actual authentication and authorization. This
external AAA server can be located anywhere in the global Internet.
Hence, the communications carried out between the MR and the AAA
server will employ one of the "global" AAA protocol. This is
depicted in Figure 2 below.
+----------+ +---------+
| | | |
| VMN |<--------------->| MR |
| | "link-local" | |<------+
+----------+ AAA protocol +---------+ \
| \ "global"
| \ AAA protocol
/-------------\ \
/----| |---\ +-----|----------+
| | | V |
/---/ Internet | | +--------+ |
| |----| AAA | |
| | | | Server | |
\--------| |----/ | +--------+ |
\------------/ | ^ Home Domain |
| | | of MR |
| +--|-------------+
+----------|---------+ +
| V | / "global"
| +---------+ | / AAA Protocol
| | AAA |<-------+
| | Server | |
| +---------+ |
| Home Domain of VMN |
+--------------------+
Figure 2: AAA Operation between VMN and MR.
Ng, Tanaka Expires - April 2003 [Page 6]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
2.4. Home Resources vs Foreign Resources
The previous discussion only illustrates the access request for
foreign resources. To gain access to home resources, the MR/VMN will
typically has to discover its HA in the home domain, and send binding
updates to its HA. Access control on the use of home resources can
then be carried out by the HA after the reception of the binding
updates. This can be done with the HA consulting an AAA server.
Since the main operation of access control of home resources is not
carried out by the nodes in the mobile network, we will focus on the
access control of foreign resources in the remaining sections of this
document.
3. Usage Scenario
In this section, we describe several usage scenarios of NEMO. In our
descriptions, we will focus more on the AAA aspects of NEMO rather
than the routing solution. A total of five scenarios are presented,
classified according to the administrative domains of the access
routers (ARs), top-level mobile routers (TLMRs), nested visiting
mobile router (VMR), and mobile network nodes (MNNs), as shown in
Table 1 below. AD-1 and AD-2 are used to differentiate distinct
administration domains controlled by different Internet Service
Providers (ISP) or companies, and USER refers to the domain of
individual subscribers (or roaming subscribers) to AD-1.
Table 1: Administrative Domains (AD) in Different Scenarios
AR TLMR VMR MNN
---------- ---------- ---------- ----------
Scenario 1 AD-1 AD-1 None USER
Scenario 2 AD-2 AD-1 None USER
Scenario 3 AD-1 USER None USER
Scenario 4 AD-1 AD-1 USER USER
Scenario 5 AD-2 AD-1 USER USER
In scenarios 1 and 2, the subscribers are individual VMH attached to
MR in a foreign domain. The difference between scenarios 1 and 2 is
that in the first scenario, the MR and the AR it attached to belong
to the same administrative domain, while in scenario 2 they belong to
distinct administrative domains.
In scenarios 3, 4, and 5, the subscribers are moving networks
themselves. The difference between these scenarios is that in
scenario 3, the subscribers attach directly to fixed AR, while in
Ng, Tanaka Expires - April 2003 [Page 7]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
scenarios 4 and 5 the subscribers attach to a MR. For scenario 4,
the MR and the AR it attached to belong to the same administrative
domain, while in scenario 5 they belong to distinct administrative
domains.
Each scenario is described in greater details in the following sub-
sections. Examples of each scenario, and the AAA operations required
are also presented.
3.1. Scenario 1
In this scenario, subscribers are using their mobile devices to
connect to MRs that belongs to an Internet Service Provider (ISP).
The MRs have their points of attachment to the Internet via an AR
that belongs to the same ISP. Two distinct types of administrative
domains are present: one for the AR and MRs, and one for each mobile
network nodes (MNN). This is illustrated in Figure 3 below.
+-------------------------------+ +---------------+
| | | |
| +------+ +------+ | | +-------+ |
| | | | | | | | | |
Internet <-----| AR |---------| MR |----------| VMN | |
| | | | | | | | | |
| +------+ +------+ | | +-------+ |
| | | |
| Administrative Domain 1 | | USER |
+-------------------------------+ +---------------+
Figure 3: Scenario 1
3.1.1. Example
An example of such scenario will be the train network. A railway
company may collaborate with an ISP to provide each cabin of the
trains with a MR. Along the routes of the trains, the same ISP could
erect fixed ARs for the MRs of the train to connect to the Internet.
Passengers can then access the Internet via the MRs in the cabins.
Thus, each cabin (or possibly the entire train) can be treated as a
single mobile network.
In this case, the ISP/railway company owns both the ARs and the MRs.
The access devices of the subscribers (i.e. the passengers) are then
the MNNs.
Ng, Tanaka Expires - April 2003 [Page 8]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
3.1.2. AAA Operations
Since the MR for each mobile network belongs to the service provider
of the AR, the access authentication of the MR by the access routers
is straightforward. Each handover of the MR between the ARs may
require access authentication. No special consideration for NEMO is
necessary.
However, the MNNs (i.e. subscribers) will have to be authenticated by
the MR. Two different possibilities arise: (1) the MNN is a
subscriber with the service provider of the train network, and (2)
the MNN is a roaming subscriber with another ISP.
For the first case where the MNN is a subscriber of the local ISP,
the AAA process would typically be the following:
- The MNN makes a "link-local" access request to the MR.
- The MR consults the local AAA server to check the credentials
of the subscriber.
- The MR replies the request.
For the second case where the MNN is a roaming subscriber, the AAA
process would typically be the following:
- The MNN makes a "link-local" access request to the MR.
- The MR consults the local AAA server to check the credentials
of the subscriber.
- The local AAA server consults the home AAA server of the MNN to
check the credentials of the subscriber.
- Response is passed back from home AAA server, to local AAA
server, to MR back to the subscriber.
3.2. Scenario 2
This scenario is an extension of the previous one where the MRs may
not belong to the same administration domain as the ARs. In this
case, 3 distinct types of administrative domains are present: an
administrative domain for the ARs, an administrative domain for MRs,
an administrative domain for each MNNs. This illustrated in Figure 4
below.
Ng, Tanaka Expires - April 2003 [Page 9]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
+--------------+ +--------------+ +---------------+
| | | | | |
| +------+ | | +------+ | | +-------+ |
| | | | | | | | | | | |
Internet <------| AR |----------| MR |----------| VMN | |
| | | | | | | | | | | |
| +------+ | | +------+ | | +-------+ |
|Administrative| |Administrative| | |
| Domain 2 | | Domain 1 | | USER |
+--------------+ +--------------+ +---------------+
Figure 4: Scenario 2
3.2.1. Examples
An example of this scenario is again the train illustration. Here,
the train may travel along a route where the available ARs belong to
a different ISP. Other examples include ships and planes.
3.2.2. AAA Operations for MR
Since the AR and MR belong to different administrative domains, each
handover of MR between different ARs may require AAA request/response
negotiations. Such negotiations may employ standard mobile IP type
operations. A typical AAA negotiation will be:
- The MR makes a "link-local" access request to AR.
- The AR consults the local AAA server to check credentials of
MR.
- The local AAA server consults the home AAA server of the MR to
check credentials of MR.
- Response is passed back to the local AAA server, AR and MR in
that order.
3.2.3. AAA Operations for MNNs
For the MNN, there are again two possibilities: a subscribing MNN or
a roaming MNN. For both cases of MNN, it needs only be authenticated
by the MR once when the MNN first attaches to the MR.
For the first case where the MNN is a subscriber of the train
network, the AAA process would typically be the following:
- The MNN makes a "link-local" access request to the MR.
- The MR consults the local AAA server to check the credentials
of the subscriber.
- The MR replies the AAA request.
Ng, Tanaka Expires - April 2003 [Page 10]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
For the second case where the MNN is a roaming subscriber, the AAA
process would typically be the following:
- The MNN makes a "link-local" access request to the MR.
- The MR consults the local AAA server to check the credentials
of the subscriber.
- The local AAA server consults the home AAA server of the MNN to
check the credentials of the subscriber.
- Response is passed back from home AAA server, to local AAA
server, to MR back to the subscriber.
3.3. Scenario 3
This scenario is the case where the mobile network belongs to a
single administrative domain, but its access to the Internet via an
AR in a foreign domain. The mobile network does not allow VMNs to
attach to its mobile router. (In this document, we shall refer to
such mobile network as a private network). This is illustrated in
Figure 5 below.
+----------------+ +---------------------------------+
| | | |
| +------+ | | +------+ |
| | | | | | | |
Internet <-------| AR |------------| MR |---> private network |
| | | | | | | |
| +------+ | | +------+ |
| Administrative | | |
| Domain 1 | | USER |
+----------------+ +---------------------------------+
Figure 5: Scenario 3
3.3.1. Examples
One example of this scenario is the car network, where sensors,
laptops, and navigation systems are fixed nodes on the mobile car
network. The vehicle would have a MR to roam through the AR provided
by the ISP along major streets.
Another common example is the Wireless Personal Area Network (W-PAN).
The equipment used by a person formed a bluetooth-based mobile
network, with the 802.11b-enabled laptop/PDA, or a GPRS-enabled
handphone acting as the MR.
Ng, Tanaka Expires - April 2003 [Page 11]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
3.3.2. AAA Operations
For this scenario, there is no need for AAA between the MR and the
MNNs. The MR simply assumes that any node on the sub-net is an
authorized node of the network. (Here, we ignore the situation of a
nearby third-party node trying to sneak in an unauthorized access.)
The only requirements that are relevant are the AAA negotiations
between the AR and MR, and this will be similar to the previous
scenario (scenario 2).
A typical AAA negotiation will be:
- The MR makes a "link-local" access request to AR.
- The AR consults the local AAA server to check credentials of
MR.
- The local AAA server consults the home AAA server of the MR to
check credentials of MR.
- Response is passed back to the local AAA server, AR and MR in
that order.
3.4. Scenario 4
This scenario is the nested extension of Scenario 1 plus Scenario 3.
Here, a mobile network attaches itself to a higher level mobile
network (NEMO-1). The higher level MR (MR-1) and the AR belongs to a
single administrative domain, and the lower level mobile network
(NEMO-2) belongs to a single subscriber. This is illustrated in
Figure 6 below.
+-------------------------+ +------------------------+
| | | |
| +------+ +------+ | | +-------+ |
| | | | | | | | | |
Internet <----| AR |-----| MR |--------| VMR |---> private |
| | | | | | | | | network |
| +------+ +------+ | | +-------+ |
| | | |
| Administrative Domain 1 | | USER |
+-------------------------+ +------------------------+
Figure 6: Scenario 4
3.4.1. Examples
One example of this scenario is again the train. Here the MR-1 are
installed on the trains and the ARs belong to the same railway
Ng, Tanaka Expires - April 2003 [Page 12]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
company or ISP. The passenger, however, may bring in a W-PAN network
onto the train. Thus the W-PAN forms the NEMO-2, which attaches
itself to NEMO-1, the mobile network in the cabin of the train.
3.4.2. AAA Operations
In this scenario, there are two distinct administrative domains: one
encompassing the ARs and MR-1, and the other encompassing NEMO-2.
Since MR-1 for each NEMO-1 belongs to the service provider of the AR,
the access authentication of the MR by the AR is straightforward (as
in Scenario 1). Each handover of the MR between the AR may require
access authentication. In addition, there is no need for AAA
negotiations within NEMO-2, since this is usually a privately owned
network (eg. WPAN). Thus the only case we have to consider is the
AAA negotiations between MR-1 and MR-2.
A typical AAA negotiation will be:
- The MR-2 makes a "link-local" access request to MR-1.
- The MR-1 consults its home AAA server to check credentials of
MR-2.
- The home AAA server of MR-1 consults the home AAA server of MR-
2 to check credentials of MR-2.
- Response is passed back to the home AAA server of MR-1, MR-1
and MR-2 in that order.
3.5. Scenario 5
This scenario is the nested extension of Scenario 2 plus Scenario 3.
Here, a mobile network attaches itself to a higher level mobile
network (NEMO-1). The higher level mobile router (MR-1) and the AR
belongs to different administrative domains, and the lower level
mobile network (NEMO-2) belongs to a single subscriber. This is
illustrated in Figure 7 below.
+--------------+ +--------------+ +----------------------+
| | | | | |
| +------+ | | +------+ | | +-------+ |
| | | | | | | | | | | |
Internet <-----| AR |---------| MR |-------| VMR |--> private |
| | | | | | | | | | | network |
| +------+ | | +------+ | | +-------+ |
|Administrative| |Administrative| | |
| Domain 2 | | Domain 1 | | USER |
+--------------+ +--------------+ +----------------------+
Figure 7: Scenario 5
Ng, Tanaka Expires - April 2003 [Page 13]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
3.5.1. Examples
One example of this scenario is again the train. Here the MRs on the
trains and the access routers belong to different railway companies
or ISP. The passenger bring in a wireless PAN network onto the
train. Thus the W-PAN is the lower level mobile network (NEMO-2),
the cabin of the train is the higher level mobile network (NEMO-1).
3.5.2. AAA Operations
In this scenario, there are 3 different types of administrative
domains: one for the AR, one for NEMO-1, and one for each NEMO-2.
Again, no AAA negotiation is necessary within NEMO-2 as it is solely
owned by a single administrative agent.
AAA negotiations between AR and MR-1 is similar to those depicted in
Scenario 3. A typical AAA negotiation will be:
- The MR-1 makes a "link-local" access request to AR.
- The AR consults the local AAA server to check credentials of
MR-1.
- The local AAA server consults the home AAA server of MR-1 to
check credentials of MR-1.
- Response is passed back to the local AAA server, AR and MR-1 in
that order.
When MR-2 first enters the influence of NEMO-1, it will have to
perform AAA negotiation with MR-1. This is similar to scenario 4. A
typical AAA negotiation will be:
- The MR-2 makes a "link-local" access request to MR-1.
- The MR-1 consults its home AAA server to check credentials of
MR-2.
- The home AAA server of MR-1 consults the home AAA server of MR-
2 to check credentials of MR-2.
- Response is passed back to the home AAA server of MR-1, MR-1
and MR-2 in that order.
4. AAA Requirements
From the usage scenario, we can identify the set of requirements
described below. It must be noted that the requirements specified
are by no means exhaustive. Since a NEMO solution has yet to be
specified, these requirements are merely spelt out to generate
further discussion within the NEMO working group. When a NEMO
solution is eventually specified, AAA requirements by NEMO can be
rapidly generated by building on top of this document.
Ng, Tanaka Expires - April 2003 [Page 14]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
(1)The AAA servers MUST be able to share, or dynamically establish
security associations with external authorities that are able
to verify the credentials provided by the client.
This requirement is a direct induction from the need for AAA
servers of ARs/MRs to consult home AAA servers of mobile
network nodes for verifications of client's credentials. Since
these AAA servers usually belong to different administrative
domains, it is necessary for AAA operations to provide a
mechanism for AAA servers in two different domains to establish
a security relationship between each other.
(2)The VMN or MR MUST be able to provide complete, unforgeable
credentials without having to contact its home agent.
Since VMN or the MR would initiate network connectivity from a
foreign domain, it is necessary for it to be able to provide
credentials without having first granted access to NEMO
resources. Thus it has to be able to provide credentials
sufficient for verifications without the ability to contact any
other nodes in its home domain.
(3)Intermediate nodes MUST not be able to learn any information
which may enable them to reconstruct and reuse the credentials.
This requirement protects the AAA servers from replay attacks.
It is necessary for the ARs/MRs to be able to process the
credentials provided by the MRs/VMNs and yet unable to
reconstruct the credentials independently at a later time, so
that malicious AR/MR cannot use the credentials to launch a
replay attack against the home AAA server. It also serves to
protect the MRs/VMNs from the visited NEMO.
In addition, to the above requirements, the following security
requirements need to be considered.
(4)AAA request and response operations between the ARs/MRs and the
respective AAA servers MUST prevent eavesdropping.
Any AAA operations MUST prevent the confidential information
passed between the AR/MR and the corresponding AAA server from
being known by eavesdroppers in the network. This is
especially needed since NEMO typically operates in a wireless
environment.
(5)AAA request and response operations between the ARs/MRs and the
respective AAA servers MUST NOT be vulnerable to denial-of-
service attack.
Ng, Tanaka Expires - April 2003 [Page 15]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
Since AAA operations typically entail cryptographic
computations in the nodes involved, it is necessary to consider
denial of service attacks by consuming CPU and memory resources
to process illegitimate AAA requests, thereby preventing
authentication of a legitimate mobile network node.
(6)AAA request and response operations between the ARs/MRs and the
respective AAA servers MUST NOT be vulnerable to man-in-the-
middle attack.
Since AAA operations may involve more than two nodes and
operate over multiple hops, it MUST prevent communications
between two legitimate nodes from being spoofed by an attacker
in the middle.
The following are the set of requirements for NEMO in considerations
to AAA operations.
(7)MR that supports attachment of VMN on its internal link SHOULD
implement AAA client capability to be able to contact MR's home
AAA server to check on credentials provided by the visiting
nodes.
It is generally not expected for MR to implement a full AAA
server for scalability reasons. However, MR should be
configured to consult an AAA server (possibly an AAA server
from the MR's home domain) for verifications of credentials
from the VMN.
(8)MR that support attachment of VMN on its internal links SHOULD
NOT change its AAA policy for the said VMNs during a continuous
session, even when the MR has undergone a handover between AR
of different administrative domains.
It is expected for handover of MR should be transparent to VMNs
behind the MR. Thus, a change in administrative domain of the
AR should not be propagated to nodes behind the MR.
5. Security Considerations
This document illustrates the usage scenarios of NEMO AAA operations,
and specifies the NEMO AAA requirements. Because AAA is security
driven, security considerations are spelt out in the requirements.
Ng, Tanaka Expires - April 2003 [Page 16]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
6. Acknowledgement
The authors wish to express their sincere gratitude to Thierry Ernst
and Keisuke Uehara of the WIDE Project for their constructive
comments to the initial draft of this document.
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 Soliman, H., and Ernst, T., "NEMO (NEwork Mobility) Charter",
http://www.nal.motlabs.com/nemo/nemo-charter.txt.
4 Soliman, H., and Pettersson, M., "Mobile Networks (MONET) Problem
Statement and Scope", Internet Draft, draft-soliman-monet-
statement-00.txt, Feb 2002, Work In Progress.
5 Ernst, T., and Lach, H., "Network Mobility Support Requirements",
Internet Draft, draft-ernst-monet-requirements-00.txt, Feb 2002,
Work In Progress.
6 Lach, H. et. al., "Mobile Networks Scenarios, Scope and
Requirements", Internet Draft, draft-lach-monet-requirements-
00.txt, Feb 2002, Work In Progress.
7 Kniventon, T. J., and Yegin, A. E., "Problem Scope and
Requirements for Mobile Networks Working Group", Internet Draft,
draft-kniventon-monet-requiremetns-00.txt, Feb 2002, Work In
Progress.
8 Mitton, D., and Beadles, M., "Network Access Server Requirements
Next Genreration (NASREQNG) NAS Model", IETF RFC 2881, July 2000.
9 Ernst, T., and Lach, H., "Network Mobility Support Terminology",
Internet Draft, draft-ernst-monet-terminology-01.txt, Jul 2002,
Work In Progress.
10 Droms, R., et. al., "Dynamic Host Configuration Protocol for Ipv6
(DHCPv6)", Internet Draft, draft-ietf-dhc-dhcpv6-25.txt, Jun 2002,
Work In Progress.
Ng, Tanaka Expires - April 2003 [Page 17]
Internet-Draft Usage Scenario for AAA in NEMO October 2002
11 IEEE 802.1 Working Group, "Port-Based Network Access Control",
IEEE 802.1x Standard, June 2001.
12 Patil, B. et. al., "Charter of Protocol for Carrying
Authentication for Network Access", IETF PANA WG Charter, May
2002.
13 Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication
Protocol", IETF RFC 2284, March 1998.
14 Calhoun, P. R. et. al., "Diameter Base Protocol", Internet Draft,
draft-ietf-aaa-diameter-12.txt, July 2002, Work In Progress.
15 Rigney, C. et. al., "Remote Authentication Dial In User Service
(RADIUS)", IETF RFC 2865, June 2000.
16 IETF NASREQ WG, "Network Access Server Requirements Working Group
Charter", http://www.ietf.org/html.charters/nasreq-charter.html.
Author's Addresses
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #04-3530
Tai Seng Industrial Estate
Singapore 534415
Phone: (+65) 6554 5420
Email: cwng@psl.com.sg
Takeshi Tanaka
Wireless Solution Laboratories
Matsushita Communication Industrial Co Ltd
5-3, Hikarinooka, Yokoshuka-shi, Kanagawa
239-0847, Japan
Phone: +81-468-40-5494
Email: Takeshi.Tanaka@yrp.mci.mei.co.jp
Ng, Tanaka Expires - April 2003 [Page 18] | PAFTECH AB 2003-2026 | 2026-04-23 05:17:47 |