Subject: Re: [MOBILE-IP] AAA functionality

From: "Lipford, Mark" <[email-masked]>
Date: Fri, 7 Jan 2000 00:02:16 -0600

Karl,

Don't want to spend a lot of time discussing this, I do agree that
co-located FA is one implementation that will work.  But only supporting a
single implementation is short-sighted from a service providers perspective.
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
thoughts and opinions on what a carrier needs to offer, but as a carrier
that is listening to many potential data customers we need to larger view.

Regards

                -----Original Message-----
                From:   Phil Karn [mailto:[email-masked]]
                Sent:   Wednesday, January 05, 2000 7:28 PM
                To:     [email-masked]
                Cc:     [email-masked];
[email-masked]
                Subject:        Re: [MOBILE-IP] AAA functionality

                >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: Phil Karn <[email-masked]>
Date: Fri, 7 Jan 2000 00:46:49 -0800

>"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: Pete McCann <[email-masked]>
Date: Fri, 7 Jan 2000 16:10:14 -0600

Hi, Phil,

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

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

That's fine, and a Simple IP service will be available for customers
like you.  But carriers have also decided to provide a foreign agent
service (with FA-located COA) for these networks, and I would argue
that this does add value.  I think we need to take into account
current and future applications that need IP addresses to persist
longer than the connectivity to a single base station or radio access
network.  The market will decide which one of us is right.

Given that Mobile IP will be used, the advantages of FA-located COA
include (in increasing order of importance, IMHO):

1) Reduced overhead on the air interface.

Perhaps this is a red herring after mechanisms such as RFC2507 have
been deployed, but I'm not sure how long that's going to take.

2) Reduced consumption of address space.

Yes, we would like to provide a VPN service to mobile nodes where they
don't even get a public address.  This can be accomplished by
concatenating the link-layer demux pipe with a Mobile IP pipe that
originates at the FA.

Both of the above are related to:

3) Simplified design of mobile nodes.

Arguably, mobile nodes are made simpler if they only have to deal with
one IP interface + a signaling protocol, rather than two IP interfaces,
one with a Mobile IP encapsulation on it.  This will ease the task of
writing clients for existing operating systems (yes, I'm talking about
Windows).

Also, it would be nice to access a private network without having to
implement IPSec on a handset.  In this case hop-by-hop protection of
traffic (using link-layer encryption) is good enough for a lot of
people.

4) Future techniques for fast handoff.

To support very low-latency handoff, some kind of forwarding mechanism
needs to be in place at the old point of attachment.  This service is
one that cannot be provided end-to-end because the mobile node is no
longer there at the time it is needed!  It requires MIP signaling
(using the Previous FA extension) and coordination with the network.
All of the proposals for non-transparent micromobility (HAWAII,
Cellular IP) require that the mobile node send MIP control messages to
some entity in the network.

5) The "attendant" function.

If you believe Chip's note about using true packet interfaces as
opposed to circuit interfaces, which itself makes the end-to-end
argument, then we need to replace PPP.  Doing so while preserving all
of the access controls that need to be provided is made possible by
integrating such authorization with the Mobile IP registration
process.

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

Certainly a good paper, and one of its points is that hop-by-hop
measures are often appropriate for purposes of optimization.  If
carriers have decided to spend resources on optimizations like the
above, who are we to argue?  Most of the standards work has already
been carried out in the Mobile IP working group and elsewhere.  If we
don't want to use them we can always fall back to Simple IP.

-Pete

---

From: Phil Karn <[email-masked]>
Date: Fri, 7 Jan 2000 17:13:41 -0800

>network.  The market will decide which one of us is right.

We agree that we should take this into account, even though I believe
it's a minority requirement. I argue that the right way to do it is to
put a FA in the mobile unit.

>2) Reduced consumption of address space.

This is also a red herring. In the simple IP service I envision, the
user could say at setup time whether he needs a globally routable
address, or if a net 10 address behind a NAT would be
satisfactory. The vast majority of mobile network applications are
pure clients, so they'd be happy with the NAT.  (As far as I can tell,
I don't get a choice with Sprint PCS. I get a net 10 address and the
NAT, take it or leave it.)

In the end, of course, we'll have no alternative but to deploy IPv6.
It'll have to happen when the pain of not doing so exceeds the pain of
transitioning. This discussion makes me think that may happen sooner
than I thought.

>writing clients for existing operating systems (yes, I'm talking about

I disagree. Most (all?) IP stacks already, or could easily, implement
virtual interfaces that support tunneling. I suspect this already
includes Windows.  A mobile host with a pair of interfaces (one real
and one virtual) would find it very straightforward to select between
the two.  Applications (usually servers, but possibly also long-lived
telnet sessions) that need a fixed address regardless of location and
are willing to pay the price in reduced performance would bind() to
the virtual interface. This would automatically cause them to use MIP.
Applications that don't care what local IP address they use (e.g.,
http, pop, smtp and other short lived clients) can bind to the real
physical interface and bypass all of the MIP mechanisms and
overhead. The two can coexist quite nicely on the same machine.

I've done something much like this on my home Linux system ever since
I got Road Runner cable modem service several years ago. My home
machine runs servers (sendmail, ssh), but Road Runner issues dynamic
IP addresses with DHCP.  My solution is much like dual-interface MIP
with a co-located FA, only I manage the tunnels manually instead of
with the actual MIP registration protocols.  ("Handoffs", i.e., IP
address changes, are usually infrequent, so this hasn't been too much
of a problem.  The "home agent" is a Linux box sitting on the Qualcomm
DMZ. I just ssh in and issue the appropriate routing commands). My
local clients (which account for the vast majority of my traffic) use
the RR-assigned address, so they communicate directly with their
remote servers without using the tunnel at all.  But when somebody
sends me mail to my static address, the inbound packets are first
routed to the machine on the Qualcomm DMZ, which encapsulates and
re-routes the packets to my current RR IP address.  My outbound
replies are also tunneled, but only to evade a source address ingress
filter in Road Runner's upstream path.

Contrast this with a mobile node that only supports one interface, and
a carrier-provided FA. MIP is either on or off, so if *any* mobile
application needs MIP, they're *all* forced to use it.

I could conceive of schemes that multiplex both kinds of traffic down
the one interface to the carrier, but that's obviously so much more
complicated and inelegant than the dual-interface approach that we
needn't consider it.

>traffic (using link-layer encryption) is good enough for a lot of

Only people who don't know any better. First of all, the link-layer
"encryption" in *all* of the digital cellular systems is a joke.  Even
so, the real hazard has always been sniffers on ISP Ethernets along
the way. Only end-to-end encryption (or possibly end-to-firewall
encryption in the case of remote access to a corporate network) can
provide any real security benefit.

>All of the proposals for non-transparent micromobility (HAWAII,

I confess that I'm concerned mainly with packet data on IS-95 CDMA,
because that's what I've done for Qualcomm. CDMA has a "soft handoff"
concept that can only be implemented down at the physical layer where
individual channel symbols can be combined. It is just not possible to
do it in Mobile IP on a per-packet basis. This means that CDMA systems
have (and will always have) substantial intra-network mobility that
greatly lessens the need for higher-layer mobility. A single CDMA
system generally covers an entire metropolitan area, although this
might not be true for some very large cities. In either case, the
average inter-system handoff interval (i.e., where MIP would be of
use) is extremely long compared with the average user session length,
to say nothing of the average user transaction length. (By
"transaction" I mean a TCP connection from start to finish, e.g., a
GET from a webserver, or a POP or SMTP session to relay mail.)

I understand that Mobile IP is being considered for intra-system
mobility in some dense micro-cellular environments. Here I have less
of a problem with it, since the routing inefficiencies are over
shorter distances. But this does not alleviate the need for a
co-located FA for the mobile user who needs true mobility, as he will
probably need to roam to other networks without FAs, and also to avoid
the use of wide-area MIP when it is not desired.

And if you do control your whole network, why not just use a standard
internal routing protocol like OSPF to keep track of your users as
they move?  Or you could punt with routing altogether and use Ethernet
switching (bridging).

>integrating such authorization with the Mobile IP registration

I haven't seen Chip's note yet, but there's another way to preserve
access controls in a "true packet environment": IPSEC.

>measures are often appropriate for purposes of optimization.  If

Actually, the statement was that lower-level functionality can
sometimes be justified as a performance enhancement. This is clearly
true; link level retransmission is the archetype.  I put a link-level
retransmission scheme into the radio link layer protocol I designed
for IS-95. I see no similar performance enhancement associated with
carrier-provided MIP, with the possible exception of reduced header
overhead (which has already been discussed).  On the contrary, I see a
very big performance penalty assocated with MIP, namely suboptimal
routing, and substantially increased network complexity.

Phil

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 9 Jan 2000 06:14:19 -0800

Hello Phil,

I'm a bit constrained for time, so I cannot respond to all
the points in your thoughtful notes.  But I notice the following
incongruity.

On the one hand, you say:

>               The vast majority of mobile network applications are
> pure clients, so they'd be happy with the NAT.

On the other hand, you say:

>                     I know I speak for many prospective users (the

Great paper, worth rereading.  But I don't see NAT as a way
towards promoting the design principles articulated in that
paper.  Or, towards promoting IPsec either, which is relevant
to other parts of your recent notes.

I might reformulate the basic design principle by observing that
applications that do not want to be mobility-aware must rely on
implementation of mobility in lower layers of the system design.

> transitioning.

Furthermore, IPv6 has a nicer mobility story.

Regards,
Charlie P.

---

From: Ramachandran Ramjee <[email-masked]>
Date: Mon, 10 Jan 2000 16:46:19 +0000

Phil,

I have been following your arguments in lurk mode and I agree with
most of the points you make (such as the use of colocated addresses
etc.)

However, I don't think that wireless data service deployment is being
held
back by the complexity of Mobile IP - in fact, Mobile IP is an extremely
simple protocol (If a client can have TCP, which it must, everything
else
is trivial!) It is the wireless side of things (bandwidth, price,
utility, compatability/reuse of telco infrastructure) that is
holding things back...I believe that it is fairly trivial to set up a
wireless data service with WaveLANs (with DHCP and Mobile IP as well)
but
when you add issues with CDMA/GSM base stations, power-saving/paging,
provisioning, interworking with voice services, etc., it gets
complicated.

The key question is does one just assume that packet data service will
just be web access and be an adjunct to current voice infrastructure?
If yes, just slap on a DHCP server with some AAA functionality,
an interworking function to current base stations with some
performance optimizations like header compression, a NAT for IP-address
starved ISPs and be done with it.

I think the Mobile IP community in general has a much more broader
vision wherein the network is completely made up of IP addressable
entities with air-interface specific processing relegated just to the
base stations, and all services are delivered through IP (including
voice).

Only time can tell how things will end up...

Finally, a personal pet peeve of mine...I think the different standard
bodies now are trying to mix up both these models and are coming up with
an ugly beast that is neither voice-centric nor data-centric...

Cheers,
Ram

P.S. I felt the need to debate one of your points: you say
CDMA has a "soft-handoff" capability that can only be implemented
at the physical (link?) layer. Isn't this another violation of the
end-to-end concept in itself? Why can't this "soft-handoff" service
be achieved at the IP-layer (I can easily engineer a bunch of
wavelan base stations to multicast IP packets during handoff for ONLY
those users/services that need this feature)?

---

From: Phil Karn <[email-masked]>
Date: Mon, 10 Jan 2000 12:16:59 -0800

>held back by the complexity of Mobile IP - in fact, Mobile IP is an
>extremely simple protocol (If a client can have TCP, which it must,
>everything else

Nothing is ever "simple" when you involve formal telephone standards
bodies, such as the TIA. The MIP protocol itself may be simple, but
the debates over mobility in the TIA clearly delayed deployment of a
packet data service.

To be fair, MIP wasn't the only culprit in the delay. Just as
significant (if not more so) was the carriers' insistence on making
asynch dialup modem emulation and fax support top priority, and giving
low priority to direct IP packet access. This continued even after we
succeeded in persuading the TIA to base the asynch data/fax service,
making packet data a subset of what's needed to support async
data/fax.

What I've always found truly astounding is when a carrier concedes
that a certain feature is best done end-to-end, but that it must still
be a mandatory network feature regardless of cost or delay because the
"average user" won't want to install the necessary software to support
the feature on his own computer.

When it comes to adding new features needed by their customers, even
Microsoft looks fast and responsive in comparison to most telephone
industry vendors. QNC is a good example; it's a kludge that exists
solely to bypass the foot dragging of certain base station vendors in
implementing CDMA IP packet data service, even though they had already
done async data & fax.

Phil

---

From: Phil Karn <[email-masked]>
Date: Mon, 10 Jan 2000 14:52:07 -0800

>those users/services that need this feature)?

CDMA forward link soft handoff works by combining the signals from
multiple cell sites down at the symbol (encoded bit) level before they
are even demodulated and Viterbi decoded. This often succeeds in
producing a good frame when *none* of the individual signals could be
decoded by themselves.

Yes, you could implement a scheme in Mobile IP that would multicast
the same packets across multiple cells. I suggested that very feature
years ago when the group was new. But it produces a good packet only
when at least one of the individual packets gets through.  That's much
better than nothing, but it cannot outperform true soft handoff. For
best performance, you need to do the handoff combining on a much
smaller granularity (the symbol level) than is possible anywhere above
the IP layer (where the smallest unit is an IP datagram).

CDMA soft handoff is an example of an optional performance enhancing
feature implemented at a lower layer, so it is in harmony with the
end-to-end model.

Phil