Subject: Re: [MOBILE-IP] AAA functionality

From: Patrik Flykt <[email-masked]>
Date: Wed, 5 Jan 2000 10:39:59 +0200

Hi,

>Perhaps I am missing something, but I *really* don't see how the AAA
>and Mobile-IP requests can be done in parallel. If a requirement is
>that it must be possible to separate the two, then I would prefer to
>see that both requests are done sequentially, first AAA then Mobile-IP.
>This would remove many strange interactions, and would be a much cleaner
>approach.

I suppose there is a requirement that AAA and MIP messages can be separated
(be it parallell or serial message sending). When you pay for access with
your credit card the authorization/accounting goes to the credit card
company's AAA server, while the Mobile IP messages go to your home agent.

The sequential approach is extremely useful if the only case of using AAA
with MIP is to ensure that the provider of the foreign agent is able to
account for every second of foreign agent usage. However, the provider could
also be interested in allowing a short grace period to ensure that the
real-time applications used in the mobile node would experience the shortest
possible service disruption. I suppose the AAA processing will take at least
a couple of seconds and even longer when there are several brokers between
the visited and home domains. The grace period enables of course a
possibility of fraud, which the provider has to take into account.
Minimizing fraud could be done for example by allowing the grace period only
to those who have visited the same provider's network earlier and have been
given a session key, as described in the "Minimal Latency Secure Hand-off"
draft. There is also a third possibility when the provider is providing free
access for everyone without any accounting but with authorization. The
provider wants to be sure that the home AAA domain authorizes the mobile
node, i.e. it is not stolen, in the (for some reason) wrong domain, etc.

Regards,

        Patrik

---

From: Tom Weckström <[email-masked]>
Date: Mon, 10 Jan 2000 01:42:02 +0200

Hi,

My comments about the Parallel vs Sequential AAA&MIP processing:

If we can find a way to support a parallel processing of MIP and AAA
signaling, I really support that. I think mixing MIP and AAA too much
with each other is not a a good solution. Also, encapsulation the
other's messages entirely inside other's messages seems both unnecessary
and inefficient.

Could we define the requirements for the interfaces between the AAA
protocol and the MIP protocol to support parallel processing of these
protocols?
I think it would be possible.

The picture I have in mind has two messaging flows, the original MIP and
the AAA. AAA flow would happen at a smaller range (inside the core)
 (i.e. FA <-> AAAF <-> Broker / HA <-> AAAH <-> Broker)
while the MIP would cover all the way from MN to HA.

Here is my proposal:
(message flows in a successfull registration)

1. The reg.request with enough information for Autorization and
Authentication originates from the MN.

2. The reg.req. is processed by the FA.

3. An AAA message is send by the FA (either to AAAF or to a broker)
   The FA uses the information from the MIP reg.req. to build the AAA
message.
   At the same time the MIP reg.req. is forwarded to the HA.

4. The MIP reg.req. is processed by the HA.

5. HA answers to MN with a MIP reg.reply.
(E.g. according to MN authentication, but the user remains
unauthenticated at the moment.)

6. Reg.reply reaches FA and MN, and MN starts using the network.
   (Alternatively we might stop the reply at FA to wait for the AAA
approval, but the MN could try to access the network even without the
received reply.)

7. An AAA message exchange happens between HA, AAAH, the Broker / AAAF,
and other AAA elements. The user is authenticated and authorized,
Acocunting begins. Finally, the FA gets the AAA approval/denial.

8. FA sends a new reg.reply or the postponed original reg.reply or a
reg.reply with a correct denial code to the MN.

The interface we would need here would contain:
- FAs ability to fomulate AAA messages to AAAF (AAA module)
- HAs ----------------- " --------------- AAAH  ---- " ----
- FAs and HAs ability to understand the AAA messages and to generate
replies according to them.

I would claim this approach beats the sequential approach in efficiency
by far.
Your comments about possible weaknesses of this rapidly hacked
parallelism example are most welcome!

Best regards,
                Tom

--
        Tom Weckström           [email-masked]
        Otakaari 20 B 39        Helsinki University of Technology
        02150 Espoo             Department of Computer Science