Subject: Re: [MOBILE-IP] AAA functionality

From: Patrice Calhoun <[email-masked]>
Date: Tue, 18 Jan 2000 09:44:00 -0800

The problem I see with the proposal below is that it assumes that the mobility
entities have a pre-configured security association. In the "unnecessary and
inneffient" (as you call it) proposal, the AAAH generates the keying
information. If we decide to split, which MUST be optional, the process,
and allow the procedures to occur serially, then the AAAH can STILL create
the keying information, but it would require additional round trips over
the 'net.

If the we opt for parallel, then either ALL of the mobility entities have a
pre-configured security association, which would rule out dynamic home agent
allocation (which is a requirement), or require some third party security
mechanism, such as IP security (which requires MANY round trips over the 'net).

So, how is your proposal more efficient?

PatC

>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
>
>
>
>Patrik Flykt wrote:
>>
>>         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
>
>--
>        Tom Weckström           [email-masked]
>        Otakaari 20 B 39        Helsinki University of Technology
>        02150 Espoo             Department of Computer Science

---

From: Tom Weckström <[email-masked]>
Date: Wed, 19 Jan 2000 00:16:14 +0200

Hi,

Patrice Calhoun wrote:
> entities have a pre-configured security association.

Yes, you are right.
We could also make the signaling go through the HA up to the AAAH, but
this would then slow down the process.

What about setting this to optional, and if there was no shared secret
(e.g. in dynamic HA allocation), we'd act according to the (possibly)
slower mode?

> In the "unnecessary and
> information.

Sorry, I did not mean to insult. I meant it seems inefficient to me. I
may be wrong, but I'd like to have good justifications for why the
sequential model is more efficient. If it is not, then it would be
unnecessary at least for those who have a shared secret, but possibly
useful for those without it.

> If we decide to split, which MUST be optional, the process,

> So, how is your proposal more efficient?

It is more efficient at least for those who have a SA with their HA,
because it allows the MN to start using the 'net while the AAA process
is still unfinished.
Any counter arguments?
It might be more efficient even for those who need a dynamics HA
allocation, since also that could be separated from the registration, as
follows:

- Allocation of a HA in a foreign domain

The idea is from Patrik Flykt.
I modified the message sequencies a little bit.
Letters I changed appear with asterisks:

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

Explanation:

- (*.d*) Is a request to the allocated HA BEFORE an ack is coming from
the HAAA.
Speeds up, but adds signals, if the reply from the HAAA (*e.*) is a
DENIAL.

- As soons as (*e.*) arrives, send it to FA in (g.). Speeds up, too.

- The new (i.) Is only needed if (*e.*) was a DENIAL.

- The (*h.*) is sent to the MN before the (i.) to speed up latency of
the handoff handling.

My observations:
- The message order is radical.
- The scheme is based on the assumption that HAAA normally accepts the
MN.
- I assume the core network and HA are fast, and sending/processing a
couple of extra messages is allowed in DENIAL cases.
- This should speed up the process in situations where the MN ia
correctly authorized, since the HA would be dynamically allocated
already when the (*e.*) arrives.
- In situations where AAAH is not needed, the sequential mode and the
parallel mode reduce to one and the same.

Regards,
         Tom