Subject: [mobile-ip] NAI/need for identifiers

From: [email-masked]
Date: Wed, 16 May 2001 10:35:32 +0200

HI, (My first mail on an IETF list so I know I have done something wrong.)

This is a cry of confusion from an employee of a "large" Norwegian operator.

Could you please explain to me how the NAI, other identifiers and the IP
address are used to  meet the following requirements (which I jotted down
very quickly):

The required separate identifiers for service provisioning are as follows:
·	Subscription
·	User
·	Terminal
·	Session
All four are required, and it is yet unclear to me how this is solved. These
identifiers are needed to accommodate e.g. security and the following three
levels of mobility:
User mobility (i.e. the user can freely move between different terminals as
long as authorised to do so)
Terminal mobility (i.e. the terminal is allowed to change access point/point
of attachment within the given level of authorisation)
Service mobility (i.e. a authorised user may access, possibly personalised,
services from any point of attachment)
The identifiers are also required to allow operators to maintain the
following bindings:
·	Session <-> terminal (e.g. for charging record)
·	Terminal <-> user <-> subscription
·	Terminal <-> subscription (i.e. computer to "computer"
communications)
·	User <-> services

For reasons of number portability and competition it has to be possible to
change the subscription without changing any of the other identifiers. It
also has to be possible for users (and terminals) to be member of more
subscriptions at the same time. (I.e. the above bindings or relations are
many to many.)

Inge
--------------------------------------------
Inge Grønbæk
Telenor FoU
Postboks 83,
2027 Kjeller, Norway
Phone (DDI): (+47) 63 84 88 57,
(mobile): (+47) 91 88 17 77.
Telefax.: (+47) 63 81 00 76.
E-mail: [email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 16 May 2001 09:12:14 -0700

Hello Inge,

> This is a cry of confusion from an employee of a "large" Norwegian operator.

You're not the only one experiencing confusion.  In fact, maybe a lot
of people including myself are confused.

I'll at least give my tentative answers.  But before that, I'd like
to suggest that Mobile IP, as a protocol, should be considered to be
a protocol that deals (solely) with terminal mobility.  I think that
trying to extend Mobile IP, for example, to handle service provisioning
based on subscriber profiles, would be a mistake.  We might wish to
add a QoS descriptor to the Registration Request, but that would be
about as far as it could go.

Responding to needs expressed by 3G standards groups, the mobile-ip
working group standardized a way to use NAI in Registration Request
messages when the mobile node didn't have a home address, and to
enable some authorization procedures.  In my opinion, this should not
be stretched to replace the node's IP address by its NAI.  I would
instead hope that the IP address be the basis for the protocol.
A lot of this was technically driven by the perceived lack of IPv4
addresses.  It is quite possible to imagine that the NAI would be
completely unnecessary for mobility management for IPv6.

Whether or not the IP address should be used for subscriber management,
or user mobility, is another question.  I don't even know if the
mobile-ip working group is the right place for the discussion.  It
certainly doesn't seem to be an issue for a group in the routing area
of the IETF, which mobile-ip is.  I would think that the whole
discussion fits better as a discussion about database or policy
management, than figuring out where to send packets.

So now you know my frame of mind for the following guesses at answers.

> The required separate identifiers for service provisioning are as follows:

Could be NAI

> ·       User

Could be NAI

> ·       Terminal

Should be IP address

> ·       Session

NAI is not sufficient for this, and from the discussion I don't
think that IP address is the right handle either.

> ·       Terminal <-> subscription (i.e. computer to "computer"

I think that these bindings SHOULD NOT be part
of the protocols under consideration within the 
[mobile-ip] working group.  Maybe they belong in
the [aaa] working group.   Maybe there will be some
effects within the context-transfer subgroup of
[seamoby], because these look like pieces of context
that might follow a device around as it carries out
the necessary operations for seamless mobility.  But
I would think that the way the bindings are created
and managed is, in the main, something that works at
the application level.  Maybe there will be some
signaling from the protocol stack to the application
when something changes the execution context for the
application.  That's a lot different than making the
management of these bindings into a routing-area
protocol item.

> subscriptions at the same time. (I.e. the above bindings or relations are

These true statements reinforce my earlier suggestions about how
the bindings should be managed, which again should be at the
application level.

Regards,
Charlie P.

---

From: Arthur Ross <[email-masked]>
Date: Wed, 16 May 2001 09:47:18 -0700

>identifiers are needed to accommodate e.g. security and the following three

[snip]

Once again, this thread is nibbling around the edges of a much larger, very
important discussion.

My apologies to those of you who have already seen this from my prior
posting to the SEAMOBY list, but it is germane to this thread too.

<RANT>

We talk at great length about hosts, mobile nodes, etc., but the notion of
"host" or "node" is getting fuzzy. Originally [ARPANET] "hosts" were big
computers that filled rooms, had squads of people caring for & feeding
them, and the protocols were designed with that implicit mindset. But
nowadays, when the
embodiments of the "hosts" may cost just pennies, may be flyspeck-sized,
and may
be found in all sorts of non-traditional, often low-tech kinds of
places/things,
the concepts need revision.

My strong feeling is that the questions to be addressed should be things like:

   * What are the entities that are the endpoints of the communication? When
     the address space is large enough [IPv6] to give every cell of every human
     being and every grain of sand on earth its own IP address, perhaps the
     model and uses of it need to be re-thought.

   * What is MEANT by "mobility"? Or alternatively what is it that is moving?
     I can envision many possible answers/opinions.

   * How are those endpoints identified for various purposes? A major example:
     paging - IP address, as in MIP, is [perhaps] meaningful for routing
     purposes, but meaningless in the application context. One could envision
     a concept whereby there are various "views" of the endpoint space
     applicable for different sorts of applications (e.g. routing, logical,
     name-based, geographic, organizational hierarchy, demographic group,
     etc.). In this light, paging/addressing might be viewed/implemented
     as a kind of distributed database query.

   * What is the nature of the "identity" associated with, say, individual
     humans, that provides the basis/data for authentication? I'm thinking
     of something like a great-grandson of the SIM card concept, for example
     [... or maybe you will begin every session with a request to "spit in the
     little spitoon" on your laptop for the DNA analysis that authenticates
     the session. ;-) ].

   * Is a broader concept of the "addressable individual" needed? [I have in
     mind functional pseudo-persons, associated with business & organization
     roles, databases of various kinds, etc.]

   * Is a "discovery" functionality needed? I.e. a generic method for exposing
     the internal structure of subnets and/or databases? I.e. a way of creating
     the local streetmap of an unfamiliar neighborhood? This might be
especially
     important if the "mobile" entities have internal, time-varying structure
     [think, for a simple example, of folks in vehicles on the highway, each
     potentially with his PDA, phone, medical monitoring device, plus the
     "smart car" itself, etc., all of which are communicating through a
     wireless gateway of some kind; just such things are currently under
     development].

   * What are the business and regulatory models? Giant electro-political
     hot potato, but very important, IMHO. The regulatory folks need to clean
     up their act if the mythical "wireless Internet" is to be anything other
     than hype and snake oil.

     I have in mind here a complete re-think of the spectrum license auction
     notion. I personally believe that auctioning the ether was, and still is,
     a bad idea, not in the long term public interest. The pro-auction
     argument is that real estate-like ownership is a prerequisite if
     investors are going to pony up the huge capital expenditures needed to
     build the "next generation" networks. The fallacy here, IMHO, is the
     PSTN-centric mindset. If what you are talking about is universal,
     readily-available wirless IP service, starting from a telephone network
     is very obviously a bad way of doing it. IMHO wireless IP access
     should be viewed, for regulatory purposes, as more like a public utility
     than the proverbial "walled garden" for which the owner charges at the
     tollbooth. You could make a lot of money by letting someone charge for the
     air we breathe too, but in neither case is it good public policy.
     There are many aspects to this, and many ways of pulling it off, as I
     have tried to convince the FCC for some time now.

   * What replaces the "walled garden" wireless air interfaces? Good question.
     I have some opinions as to what it MIGHT be, but other opinions may
     [read: "undoubtedly will"] differ. This will be, I hope, the subject of
     this new "wireless internet" discussion group.

</RANT>