Subject: RE: Concerns about draft-ietf-pana-requirements-00

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 Feb 2002 09:17:43 -0500

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 2:00 PM
To: 'James Carlson'; Hesham Soliman (ERA)
Cc: [email-masked]
Subject: RE: Concerns about draft-ietf-pana-requirements-00

....

  > The logical conclusion is rather odd though: MIPv4 has one AAA
  > solution (perhaps warty; that's not PANA's problem), MIPv6 uses PANA
  > for AAA.  Is that an improvement?

=> No the conclusion is: You can always use PANA if you
need it. Due to the MIPv4 mess, you don't need
it if you're running MIPv4. In every other case
you can use it (like IPv4 nodes that are not mobile
or IPv6, MIPv6).

GT> As a side point. It is not clear to me that MIPv4 provides end node
authentication. The whole point of MIPv4 challenge/response is limited (and
I have pointed that out on the MIP mailing list) to key distribution so that
MIP messages can be authorized. To have general client authentication you
would need to extend challenge response so that when  the FA challenges a
mobile the mobile MUST Respond immediately! unlike the current text which
says that the mobile MUST add a signature to the registration request
if/when it wants to send one.

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 Feb 2002 09:25:50 -0500

James,

OK, I do not think this is leading anywhere...not anywhere nice anyway :-) 
I guess we can keep arguing like this for some time...and never reach an
agreement....I guess it is a matter of raff consensus so I will let others
comment.

Best Regards
George

-----Original Message-----
From: James Carlson [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 2:16 PM
To: George Tsirtsis
Cc: [email-masked]
Subject: RE: Concerns about draft-ietf-pana-requirements-00

George Tsirtsis writes:
> I am trying to understand your point but I am failing. I think the
> justification for PANA is very simple.

Obviously, I don't think the justification is at all simple.

> There are many protocols that support authentication as an add on, e.g.:
> 802.1X, MIPv4, PPP. There are also other protocols that one could add
> authentication on them e.g.: DHCP.

Agreed.

> The problem is that NONE of these protocols does not exist at all times
and
> in all scenarios.

Is that an implementation problem, a deployment problem, or a protocol
problem?  I would argue that we can solve only the protocol problems
here.  (And, if we fail, perhaps make the other two a bit worse.)

> Maybe even worst some of these protocols may coexist
> (e.g.: MIPv4 over PPPoE over 802.1X while DHCP is allocating the
addresses)
> in which case you may end up with multiple authentication sessions for the
> same thing. On top of all this there are a number of scenarios that are
not
> covered by any of the existing memchanisms e.g.: static access to IP
network
> via multiple L2 hops, the hotel scenario etc.

Exactly.  It is *only* those scenarios that I think are in scope for
PANA.  The other scenarios have solutions.

> Given also the principle that "A protocol should do one thing and do it
> well",  PANA provides a way out of the current mess and confusion. It will
> provide one way of doing authentication applicable to all scenarios. If
that
> is all you want to do then you will use PANA. In time, and if PANA is good
> and useful, other protocols may also be revised to delegate the
> authentication function to PANA but this will clearly take time and will
> depend on how good a job we do here.
> 
> Is this clear at all or am I confused and you are trying to make a
different
> point altogether?

I'm trying to make the point that in some cases, PANA will certainly
make the confusion you cite even worse.  For that hypothetical
MIPv4/PPPoE/802.1X+DHCP user, he'd have yet one more authentication
protocol in the mix.  How does that help?

PANA will very likely need discovery mechanisms and will need to run
before IP addresses are allocated (since this is usually security-
related).  This means that something like DHCP's hackery^Wmechanism to
send and receive IP datagrams with address 0 is needed.  Should PANA
duplicate this work?

More to the point: is it an intentional goal of this working group to
obsolete and replace all other link-layer related authentication
mechanisms?  Will we declare RFCs 1994, 2284, and 3118 obsolete?  If
so, is that really in-scope work for PANA (and does everyone agree
that it's ultimately the right thing to do)?  If not, then is this
really the all-encompassing solution that we're promising?

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: John Schnizlein <[email-masked]>
Date: Thu, 07 Feb 2002 10:02:54 -0500

Answer to specific question in context below:

At 07:29 AM 2/7/2002, Hesham Soliman (ERA) wrote:

>  > > Yes. Unless someone shows this is the only way, I rather 
>  > > want to see a solution that can accomodate IPv6 address 
>  > > autoconfiguration, and other methods.
>  > 
>  > I don't follow that at all.  
>  > In what way does draft-ietf-dhc-dhcpv6-22 inhibit 
>  > the use of stateless address autoconfiguration?
>  > 
>  > Why would invention of an entirely new protocol here be a 
>  > good thing?
>
>=> Because overloading DHCP, which is not necessarily
>needed in all IPv6 networks, is not a good thing either. 
>If it's a matter of having a separate module 
>of DHCP that can stand alone without address config, 
>then why call it DHCP??

Hosts in many IPv6 networks will still need configuration parameters
other than an IP address. For example, they need the address of a DNS
server if they want to use names rather than (long) addresses to
identify other hosts.

It seems quite natural to me to use "dynamic host configuration" to 
give a host whatever parameters it needs.

John

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 Feb 2002 11:35:49 -0500

-----Original Message-----
From: James Carlson [mailto:[email-masked]]
Sent: Thursday, February 07, 2002 4:18 PM
To: George Tsirtsis
Cc: [email-masked]
Subject: RE: Concerns about draft-ietf-pana-requirements-00

...
> 
> Also a side point. James C. keeps complaining that we seem to have decided
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^

I realize quite well that posting here with questions about
fundamental direction is likely to annoy or offend.  It would be nice,
though, to avoid ad-hominem arguments if it's at all possible.  Can we
keep to the technical issues?

GT> I have no intention to offend you and, so far, you have not offended me
either...so do not be so sensitive. I made a very technical point...you
think we (and not sure who we is) have decided to create a new protocol and
this has clearly not been decided. Please show me where in the draft
requirements says that a solution MUST be brand new and that extension of
existing protocol IS NOT acceptable. We created a set of
requirements....maybe we should be discussing those instead.

George

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 7 Feb 2002 17:51:58 +0100

> server if they want to use names rather than (long) addresses to

=> Check the DNS server discovery in IPv6. 

  > give a host whatever parameters it needs.

=> It seems that naturally we want to reduce 
cost, if we can do without an extra server why not ?
On the other hand I know that not everyone will
do that.

Hesham

---

From: John Schnizlein <[email-masked]>
Date: Thu, 07 Feb 2002 12:38:47 -0500

Reducing cost by doing without an extra server sounds good.
Then the question becomes which server (PANA or DHCP) is extra.

DHCP servers are widely deployed, with clients in many OSs.
PANA servers would need widespread client adoption to be useful.
Replacing DHCP with PANA probably does not reduce cost, even if
PANA could replace all of DHCP's functions (which I doubt).

My answer to the question: "Why call it DHCP?"
was simply that the function of giving hosts parameters is just
what DHCP does, not limited to allocating addresses.

BTW: I agree with George T that sending user authentication messages
through DHCP is not worthwhile.

Returning to the question of which is extra, we can recognize that
network-access authentication is solved for PPP, and solved for 802.1X,
so that PANA would be extra in those cases. For other cases, would not
EAP over UDP, which is already in last call in the ipsra WG, suffice? 
[draft-ietf-ipsra-pic-04.txt]

At 11:51 AM 2/7/2002, Hesham Soliman (ERA) wrote:
>  > It seems quite natural to me to use "dynamic host configuration" 
>  > to give a host whatever parameters it needs.
>

---

From: <[email-masked]>
Date: Thu, 7 Feb 2002 11:41:22 -0600

> > => Don't get that either. The ONLY reason for
> > relays is if you don't have an address with
> > scope beyond the link. Any other reason?
> 
> Yes.  Think IPv4.  Or is PANA only a solution for IPv6 problems?
> 

PANA is a solution that should work for both IPv4 and IPv6. The charter
is quite clear about it.

-Basavaraj

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 7 Feb 2002 19:03:24 +0100

> PANA could replace all of DHCP's functions (which I doubt).

=> why are you comparing PANA with DHCP ?
To me this is like asking: do we need need DHCP
more or DNS?

  > what DHCP does, not limited to allocating addresses.

=> But it's not what PANA does. Unless you call any
information from a server to a host: 'configuration 
parameters'. Then the whole world is running DHCP.

  > through DHCP is not worthwhile.

=> Agreed.

Hesham

---

From: Paal Engelstad <[email-masked]>
Date: Thu, 7 Feb 2002 21:26:55 +0100

Hesham,

I asked Alper on the list, without any objections, to add to the req. document that the PAA discovery should be specified as a module.

Discovery IS difficult. The DNS analysis shows that there are no obvious solutions to this problems. There are PROs and CONs which we may spend three years discussing on the list.

I anticipate that we will end up with DHCP as a discovery mechanism first, due to the time pressure we have to get PANA ready. And later we may develop some more appropriate mechanisms if deemed necessary.

Paal 

> 
> Fra: "Hesham Soliman (ERA)" <[email-masked]>
> Dato: 2002/02/07 Thu PM 05:49:42 CET
> Til: "'James Carlson'" <[email-masked]>, 
>    "Hesham Soliman (ERA)"
> 	 <[email-masked]>
> CC: [email-masked]
> Tema: RE: Concerns about draft-ietf-pana-requirements-00
> 
> discovery mechanism.
>   > > 
>   > > => Who needs to invent a new discovery mechanism ?
>   > 
>   > Some discovery is clearly needed: my only point there is that DHCP
>   > happens to have its own discovery mechanism.
> 
> => So what? there are other mechanisms already
> defined too. You don't have to do anything
> new.
> 
>   > >   > 	- does not require the invention of new relay 
>   > mechanisms for
>   > >   >           non-local PAAs.
>   > > 
>   > > => No one said that we will need a relay agent, we might
>   > > but it's not 100 % sure yet.
>   > 
>   > If DHCP can be used as experience, I think relays are likely to be a
>   > necessary evil.  Otherwise, you have to assume that the 
>   > access points
>   > necessarily implement the 'right' AAA protocol.
> 
>   > > => The problem is that all the arguments above boil
>   > > down to an overloading philosophy which has caused
>   > > MIPv4 to be linked so tightly with AAA.
>   > > If You're arguing that The Dynamic Host Configuration
>   > > Protocol be used for access control because
>   > > they've already got a way of discovering the
>   > > server... That doesn't make sense to me.
>   > 
>   > Not exactly; I have no particular love of DHCP.  
> 
> => Yet you keep pushing for overloading it :)
> 
> Instead, I'm
>   > questioning why so many of the PANA participants appear (to me, at
>   > least) to assume the use of a new protocol first, rather than
>   > exploring (and exhausting) the options available with the existing
>   > protocols.  DHCP happens to be one way to elucidate this.
> 
> => I don't share your perception of what
> PANA people think. We have discussed EAP
> and PIC on several account and we haven't
> ruled them out. 
> 
>   > 
>   > On the overloading issue, I'm still unconvinced that this is
>   > necessarily and obviously a bad thing.  It's clearly the case that
>   > assigning IP addresses, installing/removing filters, creating CoS
>   > associations and the like are all authorization functions 
>   > that depend
>   > on authentication.
> 
> => Clearly ? Some people don't see the point 
> of associating address allocation with authorisation.
> I don't think the association is so clear.
> 
>   > 
>   > So, where does this leave us?  
> 
> => In disagreement :)
> 
> Suppose we drain all 
>   > authentication out
>   > of the authorization mechanisms and PANA's authorization consists of
>   > merely the boolean response proposed.  This means that (timewise) a
>   > plausible exchange might be:
>   > 
>   > 	User               Access Point
>   > 	---------          ------------
>   > 	Discovery     ->
>   > 	              <-   "I'm here, please do PANA"
>   > 	PANA request  ->
>   > 	              <-   "OK, I know you"
>   > 	DHCP discover ->
>   > 	              <-   DHCP offer
>   > 	DHCP request  ->
>   > 	              <-   DHCP ack
> 
> 
> => I'm still amazed by the placement of 
> DHCP !
> How about:
> 
> 1. I've got an address and I'm here
> 2. Do pana
> 3. PANA done 
> 4. I've got access.
> 
> 
>   > 
>   > This leaves me confused.  How does the DHCP implementation (likely
>   > separate and perhaps even located on a different node) know that the
>   > user is authenticated at all?  
> 
> => What if we don't have DHCP?? A possible scenario
> in IPv6 don't you think ?
> 
>   > That assumes PANA deployment: the high hurdle here is adding a new
>   > protocol.
> 
> => Of course it does! why is it a high hurdle 
> to install an application on my laptop, phone ...etc ?
> Or do you mean for network operators.
> 
>   > > => No duplication, we're simplifying things.
>   > 
>   > If there's an existing mechanism in use, then this is clearly a
>   > duplication.
> 
> => The existing mechanisms do not satisfy
> our needs. See the example I mentioned
> earlier for details.
> 
> 
>   > > => OK how about this:
>   > > 
>   > >      node ----UMTS (HLR)--- internet
>   > >      node ---- PPP --- NAS----AAA
>   > > 
>   > > Why should an operator run two dual
>   > > authentication schemes ???
>   > 
>   > I agree he would not want to do so.  I also agree that avoiding that
>   > is an important goal.  I don't agree, though, that I can 
>   > make the leap
>   > from this to asserting that a new, global protocol is the 
>   > only way to
>   > do it.
> 
> => New or old is irrelevant for this discussion.
> We might end up using existing protocols. 
> The does _not_ mean we have to use DHCP though.
> 
>   > > Do you see why we need to replace things
>   > > and offer a simple solution?
>   > 
>   > Sure; provide more detail:
>   > 
>   > 	   <---end-to-end-use-of-EAP----->
>   > 	                            DHCP--AAA
>   > 	                           /
>   > 	node --- UMTS (HLR) --- access device -- internet
> 
> => No we will not use DHCP in all
> cases. UMTS allows stateless configuration,
> and proud of it :)
> 
>   > 
>   > 
>   > 	   <---end-to-end-EAP--->
>   > 	                   ---- AAA
>   > 	                  /
>   > 	node --- PPP --- NAS --- internet
> 
> => Why is PPP there again ? this might be 
> a WLAN right?
> I don't mind the EAP part though.
> 
>   > 
>   > Thus, as I said, with suitable deployment you end up with 
>   > exactly the
>   > same authentication mechanism end-to-end, and thus the same
>   > authentication infrastructure and the same maintenance.  
> 
> => Because you used EAP. The rest is not relevant.
> As I said (lost count) EAP is a potential
> solution.
> 
> 
>   > > 
>   > > => Ok but our deployment today is likely to increase.
>   > > Operators do often upgrade their systems to. 
>   > 
>   > You're going to have to wait for all of those old-fashioned 
>   > Windows XP
>   > systems to die off first.  
> 
> => Does windows XP stop you from installing a
> new application ??? I hope not.
> 
>   > We're not discussing this as an "option:" it's the user's required
>   > mechanism for access to the network.  What financial good 
>   > is a network
>   > deployment if only a very few people can access it?
> 
> => You're making too many deployment assumptions 
> that don't seem reasonable to me. Roaming between
> different access technologies is 'new' thing that 
> is hardly deployed anywhere. Operators want to
> spend money to deploy it...voila.
> 
> 
>   > The example I gave (admittedly somewhat facetious but still not
>   > completely unreasonable) assumed that the Frame Relay 
>   > client would set
>   > up his connection using an SVC and include authentication 
>   > data in the
>   > connection-setup message.  There's no way to send IP before the link
>   > is established; only the low-level signaling messages are 
>   > on the wire.
> 
> => Ok so we can call that L2 (very special L2)
> authentication.
> 
>   > 
>   > I suspect that analogous situations will continue to be 
>   > true on other
>   > link layers in the future.  I think PANA should probably 
>   > consider the
>   > implications of being unable to send *any* IP frames until a link-
>   > layer authentication is performed.
> 
> => PANA does not eliminate link layer authentication.
> The point is that L2 authentication has nothing 
> to do with access levels or the user on the 
> device. Unless of course you want to bundle 
> everything on the link layer... why would you
> do that ? We've already learnt from the cellular
> experience that this has its limits: works 
> on one link layer and does not allow roaming 
> without re-authentication AND we end up with
> operators having multiple authentication
> infrastructures. 
> So what was the reason for bundling everything
> on L2 ? :)
> 
> Hesham
> 
>

---

From: Paal Engelstad <[email-masked]>
Date: Thu, 7 Feb 2002 21:36:45 +0100

John,

> [draft-ietf-ipsra-pic-04.txt]

We do not need anything this complex. The only thing we need IMO is what EAPoP provides:

- An EAP-like message wrapper, and 

- 4 Mandatory Request/Response types:

  - NAK
  - Host-initiated Initial Authentication
  - Server-initiated Initial Authentication
  - Re-Authentication
  - Disconnect Notification

Modular approach. Lightweigt. Easy to deal with. Easy to specify.

See the draft EAPoIP-draft. 

Paal

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 11 Feb 2002 14:52:09 +0100

> > => Of course it can! I just gave you an example
  > > with cellular & WLAN. Where is PPP???
  > 
  > I thought that the point of PANA was to provide an all-encompassing
  > authentication transport for all network access.  Is this no longer
  > the case?  Or are you asserting that ISPs don't have to support
  > authentication on existing point-to-point links?

=> I didn't say that, I said take a solution that
works in all cases instead of several scenario-specific
solutions.

  > > => Basically, you do not want to accept that we should 
  > > replace a mechanism that only works in some 
  > > cases with one that works in all cases.
  > 
  > I'm looking for existing cases where there is a hole that 
  > PANA fills.
  > I'm still having a very hard time finding one.

=> Even after I gave you a very clear and realistic
example ?

  > 
  > For UMTS/3GPP, as best I can tell (decent technical data is hard to
  > come by), PPP is used.

=> No it doesn't use PPP in all cases. The 
several options are very long to describe
on email, but basically there are many deployment
cases where PPP does not exist.

  > Where's the gap?

=> I really hope I made it clearer.

  > >   > Where is the PANA requirement that "users" be the 
  > entities that are
  > >   > authenticated?
  > > 
  > > => First this is a 00 draft. Not withstanding that: 
  > > what identity do _you_ think should be sent to
  > > the authenticator? The entity that is paying 
  > > for the service or some other entity ?
  > 
  > That's really a private matter between the authenticator and
  > authenticatee.  I don't see how any working group can have 
  > any effect
  > on such private arrangements.

=> How can it be private? The device needs
to know which identity to send.

  > 
  > To illustrate the problem, let's create a hypothetical situation.  A
  > service provider creates "tradeable" mobile Internet devices.  The
  > devices have (built into them in some way) a set of credentials that
  > belong to the phone itself.  Users can buy or sell these devices for
  > (presumably) the cost of the remaining airtime assigned to those
  > credentials.  Users could 'refill' the airtime allotment by paying a
  > fee to the provider.

=> A similar thing already exists with GSM prepaid 
cards. The user is anonymous. In this business
model, the operartor essentially says: I don't
care who's using the phone as long as their
calls are paid for. The credentials on the
prepaid card are for an anonymous user. 
A similar (but not to be taken literally)
example is for the 'Guest' on a corporate
network: It can be anyone. 

  > 
  > So, for such a situation, what is the identity?  Where's the "user"
  > who needs to be authenticated?

=> See above. The credentials represent 
an anonymous user. It doesn't matter
who, as long as 'he' pays. This is one
business model and the identity passed 
in PANA could be [email-masked]
or something like that.

  > > => The one paying for the service. The one that
  > > the ISP will hold responsible if abusive material
  > > are sent from that device. 
  > 
  > That would appear to assume a particular deployment scenario.

=> Yes, one where the operators care about who's 
using their network. 

  > > => You're really twisting my claims. The SIM card
  > > is NOT a link identifier. It's a USER identifier. 
  > > You can wish to think of it as a link identifier
  > > and perhaps think the same of a NAI, but that's
  > > not the case. 
  > > SIM: SUBSCRIBER Identity Module.
  > 
  > I don't think it matters what that acronym stands for.  

=> Of course it does. Terminology relates to the use
of the function...Hopefully.

If I plug
  > *your* SIM into *my* phone, does the system think that I'm 
  > still me or
  > that I'm now you?  If it's the former, then it's authenticating the
  > user.  If it's the latter, then it's authenticating the link.

=> So if the system thinks that you're
me, then it's authenticating the user?
How does it authenticate the user in this
case?

Ok, I think I know why we're disagreeing. 
When I say 'user' I mean the 'user' as seen 
by the network. How could the network possibly
know who's using my phone right now??? Of course
they associate certain credentials with certain
users. That's why your bank tells you not to
write your PIN number on your ATM card !!

  > 
  > Why the focus on the "user?"  I'm still having trouble understanding
  > why that's a significant issue at all for a *protocol*.

=> What is the use of an authentication mechanism
that does not tell the operator who's being 
authenticated ??
The significance for a protocol is that it has to
define what fields are being carried in it. 
Alternatively we can just do a type-length
encoding and get people to put whatever they
want. But really, I'd love to know what
business model you're thinking of that makes 
you resist having the user identity.

  > > => If you choose to change the definition of 
  > > existing standards that's your choice, but 
  > > according to existing standards this statement
  > > is obviously wrong.
  > 
  > Really?  What standards am I changing?
  > 

=> You refer to the SIM as being a link 
authenticator and it's not. 

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 12 Feb 2002 12:01:59 +0100

> Yes; way different.  If the Mobile IP group doesn't want to 
  > define AAA
  > mechanisms, should PANA necessarily be doing their work for them?
  > 

=> Huh.....?
Please note: You don't have to have a MIP
implementation to gain access to a network!

The integration of AAA with MIPv4 is a clear
architectural hack and its causes do not exist
in IPv6...

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 12 Feb 2002 12:02:00 +0100

> 
  > L2 QoS marking or bandwidth control, for instance.  

=> QoS is definitely not a link specific issue, 
although the _realisation_ of QoS on L2 would
naturally vary from one link to the other. 

Suppose my L2
  > allows the user to request a given amount of bandwidth 
  > along with his
  > request for network access.  How does PANA authorize this?  Does use
  > of PANA imply that all users get some "nominal" bandwidth and then
  > upgrade following the PANA exchange?  

=> 
1. PANA authentication done
2. User profile is pushed to the 'right devices'
3. 'Right devices' can decide whether the user 
   is allowed to make a certain request or not. 
   This is not a QoS specific solution. 

Steps 2 and 3 are not in scope, but the hooks
for them can be.

If so, does that actually work
  > with existing admission control schemes?

=> Does the non-existing PANA work with existing
admission control schemes? 
I'm really struggling to understand what you're
aiming at. You're trying to shoot a solution
that does not exist because it doesn't work with
existing admission control schemes ??
Why not suggest whatever is missing to the 
requirements document?
If you disagree with the entire WG's purpose
(obviously) then let's limit the discussion
to that. Please don't assume a certain solution
and use that to shoot down a non-existent proposal. 
It's not helping. 

Alternatively you could try to get concensus for 
closing the WG. I'm not sure that such concensus
exists though.

Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 12 Feb 2002 12:01:59 +0100

> > I think Mobile IPv6 should indeed get some way to do 
  > authentication with
  > > EAP. Whether PANA or a Mobile IPv6-specific encapsulation 
  > of EAP is
  > > required or a best fit is still open for debate :-)
  > 

=> Why should any mobility protocol encompass 
network authentication? It's a protocol that 
manages routing of packets to an address. 
I know MIPv4 did that and IMHO this is a 
terrible way to go. 
If a user is to be authenticated to a network, 
it shouldn't matter whether they have a MIP
implementation on their machine or not. 
I might just want to have anonymous access
or I might not be mobile. Access to *IP*
service it what's needed, NOT *MIP* service.

Hesham