Subject: [MOBILE-IP] AAA functionality

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 4 Jan 2000 09:10:52 -0800

Hello,

There has been some discussion about how to let AAA authorize
a mobile node's connectivity separately from the process of
Mobile IP registration.  The idea would be to give a mobile
node a little unauthorized time while the AAA process
goes to completion.  It is expected that a Mobile IP registration
will be faster than authentication/authorization by AAA.

Suppose that the Mobile IP registration succeeds, and the AAA
authentication fails.  Then, one might expect that the Mobile IP
registration should be terminated immediately without waiting for
the registration lifetime to expire.  Mobile IP does not currently
have any mechanism to do this.  I think the mobile node has to
be notified that something went wrong.  Thus, we need a way to
send the notification to the mobile node.

This could be a new Mobile IP message, or ICMP, or ... ?
Any such message would have to be authenticated in some
way that is credible to the mobile node.

The alternative would be just to cut off service to the mobile
node without notification, which seems rather draconian.

Can anyone offer a good solution to enable this sort of
parallel processing for mobile node registrations?

Regards,
Charlie P.

---

From: Yingchun Xu <[email-masked]>
Date: Tue, 4 Jan 2000 15:25:29 -0600

Another way of doing this will be to merge AAA and Mobile-IP request procedures.

+===========================================+
|          AAA Infrastructure             |
+===========================================+
   /|\      |                     |       /|\
RRQ    RRP                    RRQ    RRP
    |            \|/                       \|/            |
+=======+                +=======+
|       FA     |     <-----Tunneling Data------->     |      HA      |
|            |                |                  |
+=======+                +=======+

Here RRQ and RRP will be the Mobile IP Registration Request and Reply Messages.
The data tunneling will be between FA and HA.

For repeat registration caused by lifetime expiration, the registration can
optionally go directly from FA to HA.

--Yingchun.

Xinhua Zhao <[email-masked]> on 01/04/2000 02:19:13 PM

Please respond to Xinhua Zhao <[email-masked]>

Sent by:  Xinhua Zhao <[email-masked]>

To:   [email-masked]
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  Re: [MOBILE-IP] AAA functionality

> 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 agree that it would be a cleaner approach to do them sequentially.
Although doing them in parallel won't work without devising some new
mechanism, the idea of letting a mobile host to obtain connectivity
as soon as possible (potentially translating into faster handoff)
without having to wait for AAA (presumably takes longer) to complete
is worth some consideration.

So, in case we want to do them in parallel, there is another
possibility in addition to the two mentioned by Charlie. See below.

> PatC

Another possibility would be for the mobile host to treat the
registration reply as temporary (with a certain timeout value),
indicated through an extension. Short of subsequent AAA
authorization messages, the mobile host must terminate the
registration at the end of the temporary usage period. The
advantage of this approach is that it does not introduce any
new messages.

Regards,

Xinhua

MosquitoNet Project on Mobile and Wireless Computing
Stanford University
http://MosquitoNet.Stanford.EDU

---

From: Woo-June Kim <[email-masked]>
Date: Wed, 5 Jan 2000 19:04:53 +0900

Hi,

The discussion upto now basically brings up two conflicting requirements.

When the user is registering for the first time with a FA, AAA authentication/authorization should it seems be done before MIP registration. (This could also be done by embedding the MIP msgs inside the AAA msg as suggested earlier, but this would also result in a sequential check - presumably if the AAA authentication/authorization fails, the MIP registration is never carried out.)

Another requirement seems to be the wish for allowing previously connected registered users a fast registration method when registering with a new FA near the old FA. i.e minimization of service disruption. This requirement becoming more severe when Real-Time services are used in the future. 

Allowing grace periods seems fraught with problems of fraud etc. As suggested by Patrik in the e-mail below some sort of localized caching behaviour (my generic term for the use of session_id as envisioned below) may help solve this problem. Another may be to enable the AAAs to not only act as proxies, but also exhibit a caching behaviour so as to allow previously connected users to get quicket authentication/authorization. (I am not sure if this is in the AAA requirements document generated by this group.)

Note that there has also been a fair amount of discussion within this group regarding methods for "speeding up" MIP registration or carrying out faster handoffs for the same reasons as above. C. Perkins "Regionalized Tunnel Management" being one example. ("Cellular IP" also being another, though relying on slightly different methods.)

As Charles has previously said, there may or may not be a need for such methods. Correct setting of parameters etc. may be enough. (Correct me if I am incorrect in my understanding or recollection of Charles' comments. I think they were in reply to a thread on Cellular IP ..) But if we must develop a solution, one based on localized caching methods seems to be the simplest way out. Maybe not optimal, but one that is fairly robust. Optimality would have to be provided by correct dimensioning, capacity allocation, placement of caches etc. by the operators - a good way for such operators to differentiate themselves from other service providers. 

Comments ?

bye

Woojune Kim,
Senior Engineer
Samsung Electronics Ltd. 
tel : +82-342-779-8526
hp : +82-11-368-7480
e-mail : [email-masked]

>        Hi,
>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: Patrik Flykt <[email-masked]>
Date: Wed, 5 Jan 2000 17:29:10 +0200

Hello,

>This could be a new Mobile IP message, or ICMP, or ... ?

This is not only a problem of a parallell execution of both AAA and MIP, it
seems to be more general than that. What if some AAA event occurs which
forces the mobility binding to be terminated at the foreign agent ?

It seems rather draconian just to cut off service since the mobile node may
still hear the agent advertisements from the foreign agent and do nothing
since it isn't aware of the termination. Is there any chance of defining a
new Mobile IP message or to send a new binding reply denying the
registration ?

Regards,

        Patrik Flykt

---

From: Patrice Calhoun <[email-masked]>
Date: Wed, 5 Jan 2000 07:35:21 -0800

>possibility of fraud, which the provider has to take into account.

The ISDN world comes to mind when I read this. If you recall, people figured
out how to send messages in-band in the D channel, and this was enough for
them to get the message across. The result, no need to actually establish a
call, just initiate a call and send the message in the request.

This seems very similar. An MS could get connected with a bogus user-name and
get access long enough to send an instant message to his/her home network.
No fee necessary. I would be quite interested in hearing from the carriers
on whether this is acceptable or not.

>draft.

In the case of the Minimal Latency Security Handoff scheme, a visit to the
AAA wouldn't even be necessary since the keying information is provided. This
draft allows the MS to maintain the session keys for the FA, and the keys have
an explicit life-time. So, if the MS calls within the expiration period, no
visit to the AAA is necessary.

There is also a third possibility when the provider is providing free
>node, i.e. it is not stolen, in the (for some reason) wrong domain, etc.

This is done in the PPP world. No authentication, but accounting messages
are maintained. Therefore, the AAA is never reached when access is requested.

PatC

---

From: Steven Glass - Solaris Software <[email-masked]>
Date: Wed, 5 Jan 2000 11:38:49 -0500

>Xinhua,

    So - no news is bad news?  If the MN doesn't hear it's OK to continue within
X seconds of getting the [first] registration reply, it MUST assume it's not OK
to continue.  What if that reply is delayed (we don't know how long they're
"supposed to take", but the rule is likely to be 2x or 3x that long for the
timeout), or what if the reply is lost [UDP], or the [TCP] reply needs to be
retransmitted (which may mean renegotiated)?  The MN will have to assume it's
dead, but it wont know why, so it wont know how to correct the action.

    I see the need for different MIP and AAA path processing, but I don't think
the MN should get an answer until it gets one it can live with for the duration
of the registration lifetime.  In this event, that means the FA passes the
regreq [inside a AAA packet] to the Foreign AAA server, then that server passes
AAA messages to the credit card company while the mip packets [still inside AAA
packets] go to the home domain (to set up FA/MN keys, etc).  The foreign AAA
server waits until all AAA replies are received, then merges them into one
response to the FA which relays it to the MN (or it can likely wait until the
first 'no' comes back).

>A mechanism to explicitly terminate a binding can potentially be useful
>in the scenario when an FA needs to be turned down and allow another FA
>in the same subnet to take over. Waiting for the mobile node to figure
>this out by its own through the loss of FA "beacons" can take too long.
>Is this what is in your mind for such a mechanism?

    Sure, though this case could be solved by 'resetting' the FA so it sends one
becon with the busy bit set.   That broadcasts to all MNs that it's been reset,
but isn't servicing any more bindings.  It would be useful, however, if an HA
was going down...

                                  Cheers,
                                  Steve

---

From: "Munson, Mark A." <[email-masked]>
Date: Thu, 6 Jan 2000 10:05:37 -0500

>Pat Calhoun wrote:

>on whether this is acceptable or not.

This is something that we have discussed within TR-45.6 and have concluded
(at least the carriers have) that this it is not an acceptable design to
return a successful RR to the MS until both the AAA and MIP registrations
have completed successfully.  The fraud risks and state complexities are too
much for a fee based system.  It would appear that tightly tying the AAA and
MIP registration message flows together provides the cleanest solution in
this case.

Regards,
Mark

---

From: Scott Guthery <[email-masked]>
Date: Fri, 7 Jan 2000 07:46:33 -0800

On E2E grounds the IP pipe should go all the way to the
SIM/WIM/USIM; i.e. MIP for smart cards.  Some initial
work has been done: www.scdk.com/websim.pdf.

Comments are solicited and greatly appreciated.

Cheers, Scott

-----Original Message-----
From: Phil Karn <[email-masked]>
To: [email-masked]
<[email-masked]>
Date: Friday, January 07, 2000 12:48 AM
Subject: Re: [MOBILE-IP] AAA functionality

>It is also an issue for the carrier that wants to be more then a simple
>"pipe" to transport data over.  I do agree that you are entitled to your

Ah, here we reach the crux of the issue. Speaking as a potential user
of your service, an IP "pipe" is all I want from you, and it's all I'm
willing to pay for.

And it's not just me. I know I speak for many prospective users (the
ones who understand the issues, anyway) and for those who conceived
the Internet architecture. Go read the classic paper by Saltzer, Reed
& Clark, "End-to-End Arguments in System Design"
(http://people.qualcomm.com/karn/library.html).

This one paper is so fundamental that I've often thought prospective
IETFers (especially those affiliated with telcos) should be required
to read it and pass a test before they can participate in any IETF
working group. :-)

Unfortunately, many carriers (not just Sprint) see no glamor in being
pipe providers, even though they can make plenty of money if they do
it well and at reasonable cost. It's a widespread problem that also
afflicts cable modem networks, for example. Fortunately, my own cable
modem provider is proving themselves so incompetent at operating all
these superfluous network functions that they're being forced to
eliminate them just to keep the packets flowing.

Phil

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 7 Jan 2000 15:57:25 -0800

Allright, I'll bite.

What *is* the access method in question? Are you talking about PPP?
If so, the simple act of re-establishing PPP is quite high when a
hand-off occurs.

In our scenario, we are proposing that the carriers are delivering
IP services (directly), and the service is requested through Mobile IP.
Mobile IP will make use of AAA, in much the same way PPP does today.

PatC
>>telematics are two big ones).  If we allow users a grace period they could
>>potentially run their business without getting properly authorized.  While
>>there are possibly other ways to block this usage AAA is the best solution.
>
>Why is this an issue for you? In a properly layered network, Mobile IP
>would be outside the scope of the wireless carrier. It would exist as
>a co-located FA on the mobile user's computer and as a HA on the
>user's home network, e.g., at his residence or business. That's if it
>even existed at all, since MIP would be a user choice, and most mobile
>users given the choice wouldn't need it in the first place.
>
>You would just charge for the user's generic internet access service,
>and the behavior of MIP (or even its existence) wouldn't matter to
>you.  It would all just be billable user data to you.
>
>Phil

---

From: "Lipford, Mark" <[email-masked]>
Date: Sat, 8 Jan 2000 15:28:48 -0600

I would disagree with your statement that we see no value in being just a
"pipe"  I believe that being a pipe is a service we should and will provide.
I also believe there are users that want more then a pipe.  We need to be
prepared to be that as well.  Per a different thread I have indicated that
some of your current comments are not accurate, therefore I will not bore
this group with the details again.

Regards

                -----Original Message-----
                From:   Phil Karn [mailto:[email-masked]]
                Sent:   Friday, January 07, 2000 2:47 AM
                To:     [email-masked]
                Cc:     [email-masked];
[email-masked]
                Subject:        Re: [MOBILE-IP] AAA functionality

                >"pipe" to transport data over.  I do agree that you are
entitled to your

                Ah, here we reach the crux of the issue. Speaking as a
potential user
                of your service, an IP "pipe" is all I want from you, and
it's all I'm
                willing to pay for.

                And it's not just me. I know I speak for many prospective
users (the
                ones who understand the issues, anyway) and for those who
conceived
                the Internet architecture. Go read the classic paper by
Saltzer, Reed
                & Clark, "End-to-End Arguments in System Design"
                (http://people.qualcomm.com/karn/library.html).

                This one paper is so fundamental that I've often thought
prospective
                IETFers (especially those affiliated with telcos) should be
required
                to read it and pass a test before they can participate in
any IETF
                working group. :-)

                Unfortunately, many carriers (not just Sprint) see no glamor
in being
                pipe providers, even though they can make plenty of money if
they do
                it well and at reasonable cost. It's a widespread problem
that also
                afflicts cable modem networks, for example. Fortunately, my
own cable
                modem provider is proving themselves so incompetent at
operating all
                these superfluous network functions that they're being
forced to
                eliminate them just to keep the packets flowing.

                Phil

---

From: "Martin Johnsson (ERA)" <[email-masked]>
Date: Mon, 10 Jan 2000 10:52:40 +0100

OK, I'm happy with your response. My main issue is really that AAA and IP mobility are separate topics and should be kept separated (and out from current discussion, most people seems to agree on  that).

But just to make one comparision. The ISSLL WG of IETF is the one group who is responsible for mapping the work of the Intserv WG to different link layer technologies. Mapping of AAA to different technologies/services would also be needed, and coordination an issue wherever there is a possible interaction, e.g. Mobile IP and PPP. Who will take care of that?

Cheers,
   /Martin

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: den 7 januari 2000 09:18
To: 'Martin Johnsson (ERA)'; [email-masked]
Subject: RE: [MOBILE-IP] AAA functionality

>AAA may come up with different solutions for different technologies, e.g.
one for MIP and >another one for PPP (if they can be separated)

The charter of the AAA WG is to define requirements for a AAA protocol based
on inputs from the WGs that would use that protocol. It is explicitly *not*
in the AAA WG charter to define how Mobile IP will use AAA. That is the job
of the Mobile IP WG, which is best qualified for that task. Among other
things, this ensures that issues of Mobile IP architecture are discussed
within the WG that best understands Mobile IP.

Bernard Aboba
Co-Chair, AAA WG

---

From: Steven Glass - Solaris Software <[email-masked]>
Date: Mon, 10 Jan 2000 11:48:21 -0500

I'd also like to point out that not having a shared secret between the MN 
and HA can also be viewed as a policy issue, but Mobile IP requires it, as so 
many adamantly pointed out in DC!

    Despite this thread subject, this is a Mobile IP issue, not a AAA issue as 
it's up to the FA as the policy enforcement point.  If a grace period is 
allowed, it'll also be an implementation issue.  Another issue will be if the FA 
decides to revoke the registration request (after the HA has approved it) does 
it need to inform the home domain.  This certainly is a AAA issue.

                                  Cheers,
                                      Steve

>MIME-Version: 1.0
>Content-Transfer-Encoding: 8bit
>From: Tom Weckström <[email-masked]>
>I bring in my vote for the grace period...
>
>
>N. Asokan wrote:
>>
>> I think whether to allow free time or not is ultimately a policy issue.
>> Seems to me that we shouldn't devise a mechanism that precludes that
>> policy.
>
>
>I agree with Asokan, Patrik and others, that allowing the grace period
>is a policy issue. Furthermore, we should not forbid such liberal
>policies with our protocol design!
>Telcos may not like the possibility of using their network even for
>short periods of time. However, telcos are certainly not the only ones
>providing wireless services in the future. As someone pointed out
>earlier, the pure Ip accessibility may even not be the ultimate source
>for cash flows. I hope every university lab or airport lobby bar will be
>able to set up its own wireless AP and start providing access to the
>Internet. As the number of access provider increases, the number of
>"inter-domain" handoffs may significantly increase. I really do not want
>to mandate _everyone_ to disable the grace period and thus end up in
>rediculous latencies and unbearable glitches in the connections.
>
>
>Best regards,
>                Tom
>
>
>--
>        Tom Weckström           [email-masked]
>        Otakaari 20 B 39        Helsinki University of Technology
>        02150 Espoo             Department of Computer Science

---

From: Patrik Flykt <[email-masked]>
Date: Fri, 21 Jan 2000 09:32:28 +0200

Hello,

>so how do you support dynamic home agent (local or foreign) when using
>a parallel approach?

Being able to support a parallel approach means that the address of the home
agent is known to the mobile node, or the mobile node is doing an dynamic
home agent discovery, otherwise there wouldn't be anywhere to send the
registration request to. Yes, then we need pre-shared secrets with our home
agent. Why not allow pre-shared authenticators, since one has to configure
the home agent's address anyway ?

With the sequential approach dynamic home agent allocation becomes possible,
this is a desired feature in many networks. Unfortunately, with the
sequential approach it becomes impossible to split the MIP registration and
the access authorization. With the parallel approach one could pay for or
authorize the access by some means, e.g. a credit card (/whatever) company,
and acquire connectivity through the MIP protocol. The authorizing company
need necessarily not be interested in which protocol you are using when
accessing the IP network.

It is important to support both the serial and the parallel approach since
this gives MIP a lot of flexibility, one can allocate a home address and a
home agent dynamically and split up the authorization from the acces
protocol when needed.

Regards,

        Patrik