Subject: Re: [MOBILE-IP] AAA functionality

From: Patrice Calhoun <[email-masked]>
Date: Tue, 18 Jan 2000 14:22:21 -0800

>Hi,
>
>
>Patrice Calhoun wrote:
>>
>> The problem I see with the proposal below is that it assumes that the
>mobility
>> 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.

The AAAH MUST somehow be contacted, in order to get some reassurances that
the AAAH is willing to pay for the services rendered. The AAAF will expect
to get this before it provides services.

>
>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?

hmmm... I would state that shared secrets in an inter-domain mobility network
would be the rule, not the exception. It seems as if you are targetting
lan mobility, and the cellular carriers that I've talked to need roaming.

>
>
>> In the "unnecessary and
>> inneffient" (as you call it) proposal, the AAAH generates the keying
>> 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.

It wasn't taken as an insult, but it was simply your viewpoint, not the WGs.

>
>> 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?
>
>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.

I still haven't heard back from many carriers that state that they would provide
free services. In fact, all I've heard are comments from carriers against
the grace period.

>Any counter arguments?

Well, expecting all devices to have a pre-configured shared secret doesn't
scale. What other argument do we need? Perhaps I am missing something fundamental
here, but I don't see the problem. In our proposals, we aren't requiring that
the AAA infrastructure process, or parse, the Registration Requests, they are
considered blobs. So, how is a single internet round trip ineffient? Your
proposal requires additional latency (two round trips), free services,
unmanageable security relationships, and cannot support dynamic home agents.

>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.

and if this isn't the case, then free service is a problem.

>- 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.

How did you select the home agent. How do you know if the home agent
needs to be allocated in the local, or the foreign domain? This information
would come from the AAAH.

>- In situations where AAAH is not needed, the sequential mode and the
>parallel mode reduce to one and the same.

so how do you support dynamic home agent (local or foreign) when using
a parallel approach? Perhaps I missed it, but I don't see it.

PatC
>
>
>Regards,
>        Tom
>
>
>>
>> >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]
>
>--
>       Tom Weckström           [email-masked]

---

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

> to get this before it provides services.

This is the point. You say the AAAF needs the info before, and some
others say it should be a policy issue whether the AAA authentication
reply should come from the AAAH before the access is granted.

Let's vote. What do other people think about this grace period issue? We
already have some opinions, but I'd like to see some more.

> lan mobility, and the cellular carriers that I've talked to need roaming.

I did not target to any specific mobility scheme. It may be that the
cellular carriers need the dynamic HA allocation more to get rid of
configuration tasks.

o If we have a shared secret between HA and MN and we use a static HA,
then the parallel mode works well, right? This might be the situation
for corporate roaming workforce.

o If we have a dynamic HA allocation, then we'd have to get the decision
from the AAAH first, as you said. I did not take into account that also
the Home Network might want to assign the HA dynamically.

> free services. In fact, all I've heard are comments from carriers against

Hmm. Visit Finland some time. Telia just starts providing Internet
access for free, and there has been a smaller operator called NIC that
has done that for a longer time. :-)
Also professor Arto Karila from HUT stated last summer that it will be
most probable that there will be much more free access providers by the
end of the year here in Finland.
The story is available in Finnish at:
http://www.wow.fi/WOW/17332438005461012486069354?path=tietotekniikka/juttu&document_id=125418

> scale.

All the devices meaning all the Mobile Nodes and their HAs. Well, that
can be a one time issue like the similar actions for a cellular phone.
Also the phones have their HLR and it does not bring too much
scalability problems, does it? ;)

> What other argument do we need? Perhaps I am missing something fundamental

The problem is the AAA processing time and the most probably longer
round trip time through the path of AAA servers, proxies, brokers, ets.
than through plain Internet (direct FA <--> HA).

I admit that the sequential proposal has less messages. The overhead the
parallel mode would bring is the couple of octets in the additional
headers plus some processing time in the routers. Then again, the
sequential mode packets might get fragmented due to their possibly large
size thus ending up to almost the same amount of transferred data and
used router processor time...

The key question is: "How we measure efficiency"
with:
        - Number of messages
        - Latency for the session initialization
        - Handoff latency
        - Administratvie burden
        - Accuracy of billing
        - Amount of sent data

I can see there some contradictory elements. That is why I am for a
definition that allows both modes.

> and if this isn't the case, then free service is a problem.

If the free service really IS a problem. And additional countermeasures
may be started in a case of misuse. Of course, this would need some
elaborate software which would make the solution slightly more complex.
But what wouldn't one do for a faster access. ;)

Regards,
         Tom