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]