Subject: Re: [MOBILE-IP] AAA functionality

From: Patrice Calhoun <[email-masked]>
Date: Tue, 18 Jan 2000 15:53:27 -0800

>Patrice Calhoun wrote:
>
>> >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.
>
>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.

ok. I assume you already know what my vote would sound like? :)

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

I would assume that most corporate networks would be reluctant to provide
access to a mobile without prior authentication. I know that my company's
MIS (IT) is quite strict about security. Perhaps some networks are more
lax in their security requirements.

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

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

Perhaps finland is a special case. I wish that we had free access here in the
US :)

>
>
>> >Any counter arguments?
>>
>> Well, expecting all devices to have a pre-configured shared secret doesn't
>> 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? ;)

well, we aren't designing the system around HLR and VLRs, right? Since we
KNOW that this will be run over the Internet, some security is required
between the FA (VLR) and the HA (HLR). Further, some security is required
between the MN (MS) and the FA. The scalability problem doesn't come from
the MN-HA, but rather from the MN-FA and the FA-HA. This is especially
problematic in an inter-domain network.

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

Well, given that this typically ONLY occurs when then MS is turned on, I fail
to see the problem. One could easily argue that the processing power on the
AAA servers could be such that the Internet bandwidth becomes the issue, and
here more traversals over the 'net would be a problem.

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

I think this is a red herring. The number of registration requests that
will result in a check with the AAA infrastructure is so low that I have a
hard time accepting that as a counter-argument. To date, I have never
seen a registration request exceed 800 bytes, even with all of the fluff
that we've been adding to Mobile IP recently.

Furthermore, the more messages there are on the internet, the higher the
possiblity for packet drops, and the need for retransmission.

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

I won't argue in supporting both, but I am not sure how popular the
parallel method will be. Also, the more we support, the more code I need
to write, and some people may have issues with that.

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

Just to re-iterate (and make sure that we agree), the AAA involvement is
ONLY performed when the MN is started. The AAA infrastructure is also
checked when keys expire, but this can be done sufficiently in advance as
to not affect access.

PatC
>
>
>Regards,
>        Tom
>
>--
>       Tom Weckström           [email-masked]

---

From: Gerald Maguire <[email-masked]>
Date: Wed, 19 Jan 2000 07:46:53 +0100

I think access providers are finding that with bandwidth costing less
and less, with increasing numbers of hot spots (which are paid for by
the users regularily in these sites -- generally for a contracted
price), ... that doing the accounting/billing/... to squeeze every
last $/SEK/FIM/... out of users is not good economics.

  a. Consider that the transit systems in a number of cities don't
     have turnstiles -- but rather have patrols which spot check that the
     riders have paid. The operator saves all the capital costs of the
     turnstiles, the maintenance personnel required to keep them working,
     the lost revenue when they don't work properly, ... -- and trades this
     off for some lost revenue due to people riding who did not pay.

  b. Consider that most major credit card companies have a certain
     fraction of fraudulant transactions. They have learned that it is
     not economical to decrease this below a certain rate (as the costs
     to do so is greater than the loss of not doing so).

In the case of cellular, Telia offers large customers the ability to
have a site specific GSM service for which the customer pays a flat
price per user. Thus there is no per call billing for all calls from
these users in this specific area. The operator can easily calculated
what the contract price for an N year period should be to provide this
service for Y users. The customer periodically tells the operator who
these Y users are to be. The result is wireless voice access for less
cost (for the N years) that putting up a campus based cordless phone
system.

As Tom righly points out: the penalty for not allowing the grace period
is a reduction in performance of the handover -- even for those who
are paying!

Chip