Subject: [MOBILE-IP] Comments on AAA Requirements

From: Basavaraj Patil <[email-masked]>
Date: Thu, 18 Nov 1999 14:24:03 -0600

Mobile IP WG members,

Please provide comments and feedback to the Mobile IP AAA Requirements
I-D (draft-ietf-mobileip-aaa-reqs-00.txt). We as a WG need to arrive at a
consensus
on the base set of AAA requirements that Mobile IP needs from a AAA
protocol.
The current set of requirements in the document may need to be scaled down.
Let's not get carried away in specifying requirements to do things that are
not
essential at the present time or immediate future. Providing a clear set of
the very
minmum requirements to the AAA WG would probably be in the best interest
of Mobile IP and will probably let the AAA WG be in a better position in
providing a
protocol solution.

-Basavaraj

---

From: Patrik Flykt <[email-masked]>
Date: Mon, 29 Nov 1999 13:28:29 +0200

Hi all,

I notice that I have written a very long mail with comments on the MIP AAA
requirements. Not all of the mail needs to be read, in 1. and 2. it is
enough to just read the comments.

Thanks to Asokan for his valuable comments !

Best regards,

        Patrik Flykt <[email-masked]>

Since there has been indications that it SHOULD be possible to separate
MIPv4
and AAA messages, here is an attempt to sketch how such a separation could
be
achieved. If you are familiar with the DIAMETER Mobile IP extensions draft
[1],
you can skip both 1. and 2. except for some of the comments.

1. Bundling MIP and AAA messages.
=================================

Bundling the MIPv4 and AAA messages is almost identical to the scenario
presented in the DIAMETER Mobile IP extensions draft [1]:

                             c.
                  +------+ --------> +------+
                  | FAAA |           | HAAA |
                  +------+ <-------- +------+
                     ^ |          f.    ^ |
                     | |g.              | |d.
                     | |                | |
                   b.| |              e.| |
             a.      | V                | V
     +----+ -----> +----+             +----+
     | MN |     h. | FA |             | HA |
     +----+ <----- +----+             +----+

a. The MN sends a registration request containing the MN's NAI to the FA.
b. The FA sends the registration request to the FAAA.
c. The FAAA sends the registration request in an AAA message to the domain
   specified by the MN's NAI. The AAA message will possibly traverse a vast
AAA
   network.
d. The HAAA receives the AAA message and verifies the MN. The registration
   request is forwarded to a HA.
e. The HA processes the registration request and creates a registration
reply,
   which is sent to the HAAA.
f. The HAAA sends the registration reply in an AAA message to the FAAA.
g. The FAAA forwards the registration reply to the FA.
h. The FA sends the registration request to the MN.

Comments:

If the FAAA treats the registration request as opaque data, the result of
the
registration request processing, e.g. authorized/not authorized, should be
attached in an AAA-readable format so that the FAAA can learn the outcome of
the AAA verification. Optionally also the HAAA could rely on an HA doing the
authentication verification if the HAAA treats the registration request as
opaque data. In this case the HAAA is merely the connection point of the
home
network to the AAA network. These are probably implementation-specific
issues
separate for both networks.

If the MN sends "0.0.0.0" as its home address, either the HAAA or the HA can
choose a home address for the MN, preferably the HA so that the HAAA can
focus
on doing AAA and not to act as an address selection utility, especially if
the
address of the HA is present in the registration request. The MN could of
course also be doing dynamic HA allocation according to RFC 2002. In this
case
the MN needs to send a new registration request after the first one.

2. Allocation of a HA in a foreign domain
=========================================

This scenario is also almost identical to the one described in [1]:

               e.            c.
     +----+ <---- +------+ --------> +------+
     | HA |  f.   | FAAA |           | HAAA |
     +----+ ----> +------+ <-------- +------+
                     ^ |          d.
                     | |g.
                     | |
                   b.| |
             a.      | V
     +----+ -----> +----+
     | MN |     h. | FA |
     +----+ <----- +----+

a. The MN sends a registration request containing the MN's NAI to the FA.
b. The FA sends the registration request to the FAAA.
c. The FAAA sends the registration request to the domain specified by the
MN's
   NAI and indicates wheter it is able to assign a HA to the MN.  The AAA
   message will possibly traverse a vast AAA network. The HAAA receives the
AAA
   message and verifies the MN. The HAAA notices that the FAAA has indicated
   wheter it can provide a HA for the MN.
d. If the local policy prohibits foreign HA allocation, proceed as in steps
1d.
   to 1h. in the previous example. Otherwise the HAAA will tell the FAAA
that
   it accepted the registration and wants the FAAA to assign an HA for the
   visiting MN.
e. The FAAA sends the registration request to a selected HA, if the HAAA
agreed
   upon using a foreign HA.
f. The HA returns an registration reply to the FAAA.
g. The FAAA sends the registration reply to the FA.
h. The FA sends the registration reply to the MN

Comments:

If the MN sends "0.0.0.0" as the address of its HA, then either the HAAA or
the
FAAA selects a HA for the MN.

As above in 1.

3. Separation of MIP and AAA messages
=====================================

When not bundling the MIPv4 and AAA messages, we end up in a scenario like
this:

                             c.
                  +------+ --------> +------+
                  | FAAA |       d.  | HAAA |
                  +------+ <-------- +------+
                     ^ |
                     | |e.
                     | |
                   b.| |
             a.      | V    f.
     +----+ -----> +----+ ----------> +----+
     | MN |     h. | FA |         g.  | HA |
     +----+ <----- +----+ <---------- +----+

a. The MN sends a registration request containing the MN's NAI and a
   authenticator token to the FA.
b. The FA sends the authenticator token to the FAAA.
c. The FAAA sends the authenticator token to the domain specified by the
MN's
   NAI. The AAA message will possibly traverse a vast AAA network.
d. The HAAA verifies the authenticator token, and tells the outcome of the
   verification to the FAAA.
e. The FAAA tells the FA if the MN is authorized to use the services
provided
   by the FA.
f. - h. Based on e. above, the FA will either immediately deny (h.) the
   registration request or forward (f.) the registration request to the HA.
A
   normal MIPv4 registration reply will be issued by the HA (g.) and
forwarded
   by the FA to the MN (h.).

Comments:

The size of the authenticator token sent in a MIPv4 registration request
will
probably be greater than 255 octets, maybe a non-skippable "jumbo extension"
should be specified according to the MIER [2] framework ?

The authenticator token SHOULD be allowed to be quite arbitrary and
different
from a registration request since it is not sure wheter the home AAA domain
at
all cares or knows about MIP registration requests. The requirements of the
authenticator token are probably different from those specified by the MIP
protocol, e.g. non-repudiation, etc.

The FAAA may or may not know the true identity of the MN depending on the
MN's
NAI, but at least it will know if the HAAA accepted the authenticator in d.

Note that steps b. to e. and f. to h. could be executed in parallel. The FA
will immediately accept the MIP registration attempt, but if the FAAA later
detects an authorization failure, the FA can stop the MN from using its
services by e.g. turning on a packet filter for the MN. In this scenario the
address of the HA has to be known to the MN.

If the MN sends "0.0.0.0" as its home address, the HA has to choose a home
address for the MN.

Note also that when separating MIP and AAA messages, the local policy at the
FA
may require the FA to query its HAAA to see if it is allowed to provide
service
to the MN. The HAAA of the FA may or may not be the same as the HAAA
specified
in the domain part of the MN's NAI.

4. Mixing MIP registration requests and authenticator tokens
============================================================

When the MN has specified itself and/or its HA to have the address "0.0.0.0"
and has included an authenticator token in the registration request, it is
not
totally obvious how the FAAA knows if the HAAA is able to or wants to assign
IP addresses for the MN and HA. One solution could be that if an
authenticator
token is present and the address of the HA and the MN is "0.0.0.0", then the
FAAA will assign an HA. On the other hand, maybe this is too restrictive ?
The
other extreme is that we always require the MN to send an authenticator
token
and have the FA announce that AAA authenticators are required - this is not
a
good solution either.

One solution is that the FAAA will forward both the authenticator token and
the
registration request to the HAAA. If the HAAA sends an registration request
and
indicates successfull registration, then proceed as in scenario 1. If the
HAAA
indicates that the authenticator token was accepted without replying with an
registration request, then the FAAA has to proceed according to scenario 2.
Instead of checking the validity of the registration request in scenario 2.,
the HAAA will check the authenticator token instead and discard the
registration request.

When the address of the HA is known to the FA, the FA can send the
registration
request either in parallell with the AAA message or after the outcome of the
AAA authorization. The FAAA can also return a registration reply. All this
depends on the local policy and the address of the HA.

With these things in mind, we have four options:

    HA     |  MN home  | separate  | assigner of  | Maps to
  address  |  address  | MIP/AAA   |   address    | scenario
-----------+-----------+-----------+--------------+----------
  present  |  present  | possible/ |    N/A       | 1, 3, 4
           |           |  policy   |              |
-----------+-----------+-----------+--------------+----------
  present  | "0.0.0.0" | possible/ | HA (any home | 1, 3, 4
           |           | policy    | address)     |
-----------+-----------+-----------+--------------+----------
 "0.0.0.0" |  present  |     no    | specific HA  | 2, 4
           |           |           | selected by  |
           |           |           | HAAA         |
-----------+-----------+-----------+--------------+----------
 "0.0.0.0" | "0.0.0.0" |     no    | HA and home  | 2, 4
           |           |           | address      |
           |           |           | selected by  |
           |           |           | HAAA or FAAA |

In every scenario the HAAA can attach any number of extensions to the AAA
messages. These extension could contain keys for the foreign domain, billing
information, etc. The HA shouldn't deal with NAIs but only IP addresses, the
HAAA should deal with NAIs.

The HAAA authorization could be more than just MIP authentication. The HAAA
may
have black lists, credit records, etc. to consult before it decides to
accept
or reject a registration request. Even if the authentication is perfectly
valid, the HAAA may reject a request because your current balance is low or
something like that.

[1] P. Calhoun, C. Perkins; DIAMETER Mobile IP extensions;
    draft-calhoun-diameter-mobileip-03.txt (work in progress)

[2] M. Khalil R. Narayanan, E. Qaddoura, H Akhtar; Mobile IP Extensions
    Rationalization (MIER); draft-mkhalil-mobileip-mier-00.txt