Subject: Re: [mobile-ip] dynamic home addressing as a WG item??

From: James Kempf <[email-masked]>
Date: Fri, 13 Apr 2001 15:21:54 -0700 (PDT)

Hi Luca,

>this is a loooong mail :-). I'll try to be brief:
>

Yes, well, it doesn't look like we have much that we agree on here.
Hopefully, now that our views are known, we can agree to disagree.
Maybe somebody else out there in SMTP land has an opinion?

>I don't think we are "extending" DHCP to go wide area. I see the
>HA(-FA)-Mobile tunnel as an extension of the home (or corporate) network in
>the wide-area. That extension can also be made secure using IPSec. If you
>accept this model at least for some scenarios, why can't you put DHCP *on
>top* of it? That tunnel simply enables your mobile to operate exactly as if
>it were at home, with exactly the same security characteristics (provided
>IPSec works well...). At the very least this is as secure as the basic
>Mobile-IP is.
>

Extending the corporate network to mobile (as opposed to nomadic) users
by defining a VPN-like overlay on top of mobile IP is a very interesting
and relevent technical topic. We could certainly open a mailing list,
collect drafts, even hold a BOF on it, might make a good working group.

But that is not what is being proposed. What is being proposed in
draft-thuel-mobileip-tt-01.txt and draft-glass-mobileip-agent-dhcp-proxy-01.txt
is to either relay or punch a temporary tunnel back to the home network.
After the relay or temporary tunnel is done, the mobile node is still
in the remote network. The mobile node is not a node on the home network, this 
is extending DHCP to the wide area, as I said.

It simply does not solve the problem of configuring a mobile node.

>This is simply not true if the model is the one I outlined above.
>

The two proposals under discussion don't address the model you outlined.
They address something far simpler and more dangerous. Like the 
camel's nose in the tent.

> 
>> So? If DHCP were used by the client, it would have to renew the lease
>> periodically anyway. What's the difference?
>
>That Mobile-IP simply does not tell you that you have to keep registering
>when you are at home.
>

So maybe this is a defect in mobile IP that needs to be fixed.

>In my mind, the model is that Mobile-IP serves as an extension of your
>home-network when you go away. In that scenario, the configuration

This is, in my mind, erroneous. People are talking about doing
location based services on the mobile node. It's a completely different
model than the VPN/nomadic model. Nobody talks about location based
services for a VPN/nomadic model.

>information are exactly the same that my PC gets through DHCP today when I
>power it up in my office, i.e. DNS servers, domain name, default gateway,
>plus possibly IMAP server and HTTP proxy.
>

Agreed, there may be some configuration information that the mobile
may need from the home network. The IMAP server is a good example.
But in a wide area networking situation, these could better be delivered
by AAA. 

>Why not? It seems to be solving it well for clients that are at home.
>Again, my point is that you might want to apply the same model for some
>nomadic users that use Mobile-IP.
>

I disagree. I think the wide area, mobile model is different from
the nomadic model. I think the difference is what makes the mobile
model interesting. Like, for example, location based services.
Most nomadic users don't care about this, because they are sitting
somewhere and not moving, connected up into their corporate network.
If they care, then they only need to access location based service
info once, like, for example, browse the web page for Dallas-Fort Worth
airport while they are sitting in the departure lounge with their
laptop. With mobile users, it gets more interesting. The services
change as you are walking down the street, or thorough the airport mall. 

I can't imagine how a static, one time, non-attribute based configuration
mechanism like DHCP could possibly deal with providing the kind of
rich, multifacted, time-varying configuration needed by a mobile user.
Integrating it with mobile IP will only confuse the issue.

>Hmmmm, if you want to access nodes that are inside your corporate network
>that you reach through Mobile-IP (plus possibly IPSec) you will need to use
>a DNS server which is inside your corporation.
>

Agreed, but, again, this could be delivered via AAA, as, I presume
it is today in 3GPP2.

>You don't need to add any DHCP relay agent to the HA using Transient
>Tunneling: you just need to have the client act like one, which is trivial.
>The Home Agent can be a stock RFC2002/2794/3024-compatible one.
>Transient-tunnel does not modify standard Mobile-IP at all.
>

But you still have to punch the tunnel. After the tunnel goes away,
the mobile node is thrown back onto the remote network, where
the configuration info it gets from DHCP may or may not make sense.

A simple example. Suppose I am a mobile user and I want to use
the local DNS server in the DFW airport to find location-based
information on the location of shops selling gifts, because I want
to buy one to take home for my wife. If I get my DNS server force-configured
from my home network via DHCP, I can't find a thing locally.

>This coul be fine if these are really the only configuration parameters you
>need. If you really need something more (see my note on corporate-DNS
>above), you are really making a routing protocol (MIP) the distributor of
>configuration information.
>

AAA isn't MIP, it's AAA. Having MIP do the routing protocol configuration,
as is done in IPv6, and some other technique, like AAA, do the 
home network service configuration makes more sense to me than using an 
enterprise based protocol like DHCP. There still needs to be some
way of discovering locally available services, however.

>Furthermore all this is fine until you go home, where you would have to
>keep registering with your HA to "defend" your registration information.
>

Right, so we change MIP to let you do this via MIP.

>I assume you have read draft-thuel-mobileip-tt-01.txt: I don't think we are
>extending Mobile-IP *at all*: we are simply outlining a way to use a
>Mobile-IP tunnel to have DHCP run on top of it, which by the way means that
>we are not extending DHCP either to wide area networks, if you accept the
>notion that a Mobile-IP tunnel buys you a transparent extension to your
>home network.
>

Yes, I read it, and, like I said, I think it is extending DHCP to wide
area networks. Once the transient tunnel goes away, the mobile node
is left high and dry on the remote network, where the configuration
information from the home network may or may not make sense. 

It makes sense to me that there needs to be some way of configuring
routing parameters. MIP is a routing protocol, so let's use it for
configuring routing parameters.

Furthermore, it also  makes sense to me that there may need to be some
way of configuring home network parameters on a mobile node, like
the IMAP server, maybe DNS if the mobile node wants to get back
into the corporate network, but also maybe NOT DNS if the mobile node
wants location based services in the roamed network. Like I said,
this is a complex issue,  it needs proper study, and it is not aimeable
to a simple hack like punching a temporary tunnel back to the home agent, or
having the home agent act like a DHCP relay.

		jak

---

From: "Sandy Thuel" <[email-masked]>
Date: Mon, 16 Apr 2001 18:29:53 -0400

Hi James,

 Sorry for the delay as I try to dig myself out
of my email backlog.  BTW, thanks for your 
thoughtful comments on this issue.

 After reading through the several emails you
and Luca recently sent about this subject, I 
thought it would be useful to highlight what
I perceived were the key issues/concerns and 
offer some comments.  Let's try to clear out
the air and see where we've gone so far.
Please let me know if I missed or
mis-understood something important. 

There seem to be three primary questions 
intertwined in these recent discussions:

A) What is the MN's home networking model?
B) What constitutes *home* configuration state? 
C) Who should allocate *home* configuration state? 
  
My summary for each:

A) What is the MN's home networking model?

  You are correct in that our home networking models
  differ.  I assume the traditional Mobile IP
  notion of a home network, as the network to which 
  the MN belongs (in enterprise networks terms, the
  MN's home LAN; in cellular networks terms, the
  MN's service provider's home access network).
  I assume that the MN gets a home address assigned
  from the address pool of its home network
  regardless of where the MN is.  In addition, I
  assume the MN would like to have access to
  other services offered *in* its home access 
  network such as DNS.  Beyond that, I make no
  assumptions about where the MN tends to live
  and how often it moves.  Of course, I assume
  the MN also needs an address from its local
  access network and may also want to get some
  other local configuration parameters there too
  (e.g., printers). 

  Can you clarify the home networking model you
  assume? You suggested in a previous message that
  the MN would get a *home* address from the 
  local access network: 

 "So a possible, even likely, situation is 
 that the mobile node gets a locally   
 assigned home address every time it comes 
 up in someone's network....jak"

  I don't understand how this works.   Are you
  advocating a model where the MN has no 
  fixed notion of a home network (i.e.,
  the MN 'makes' the network it powers up on 
  serve as its home network)?

  I think having a clear understanding of our 
  home networking model will help clarify some
  confusion. 
  
  BTW, let me emphasize that the configuration 
  state we are talking about dynamically
  allocating to a MN is strictly home 
  network configuration state and yes, we are
  talking about configuring it remotely (across
  a WAN).
  
B) What constitutes *home* configuration state? 

  Your classification of configuration state
  was a nice step in the right direction. Allow
  me to distinguish just two categories for
  discussion purposes:
  - routing and identity related: IP address, 
    subnet mask, gateway router, domain name
  - service (discovery) related: DNS,
    HTTP proxy, IMAP server, NTP server,
    printers, LDAP servers, etc.

C) Who should allocate *home* configuration state? 

   (This is where the fire gets hot.)  You
   seem to suggest the following solution: let
   Mobile IP allocate the IP address and subnet
   mask to the MN adding whatever extensions 
   are needed to make it happen (= a new Mobile
   IP extension for the subnet mask + changes to
   the Mobile IP standard so the client sends 
   registrations while at home).  Let service
   discovery handle informing the MN of available
   services where possible.  Otherwise, rely on 
   AAA to inform the MN (e.g., DNS).

   (Q: In your model, how does the MN get its
   domain name? Through AAA? Also, how would the
   MN discover its gateway router in the absence
   of an FA?)

   There are several issues with this model.
   First, we have a strong difference of opinion
   regarding the issue of changing the Mobile IP
   standard to require client registrations while
   at home and extending it to piggyback routing
   related config. state.  You don't seem to think
   it's a big deal to do this.  We do, particularly
   in the short-term, as we try to expedite 
   the deployment of M-IP.  Changes of this nature
   are very costly and they take time to be
   adopted.  In addition, we must be careful in
   thinking that a "tiny" extension to Mobile IP
   will solve the problem.  Today we extend it to
   handle the subnet mask, tomorrow... (you get 
   the picture).

   Now, is DHCP the end-all solution? Of course
   not.  DHCP is not God's gift to mankind any
   more than PPP/Radius are (no offense intended).
   But DHCP *is* here, now, and used quite
   extensively.  I'll grant you that mobile phones
   with DHCP clients aren't available today at
   my favorite phone retailer and I would concede
   that there are concerns about doing DHCP over
   the air.  But there many other devices besides
   cellphones which are mobile, wireless and have
   DHCP clients.  I just don't buy the argument
   that if-cellphones-don't-need-it-today-then-it
   must-not-be-needed.

   On the security issue you have a real, valid
   point.  DHCP is clearly not secure today
   even though there's a lot of ongoing work to 
   fix this. Running DHCP over a secure Mobile IP
   tunnel would at least not open any new security
   loopholes due to remote access.  There is
   still the known vulnerability of DHCP to
   attacks within the home network.  So, what are
   we to do? Wait for DHCP to become secure before
   we can use it? Wait for configuration-related 
   extensions to AAA to come out so we can use
   them? Wait for Mobile IP to be changed to
   handle configuration state out to the MN?
   Pick two out of three? Pick all three? It's
   not clear to me which of these (and many other
   scenarios we can dream up) will eventually 
   win.  But what I can't understand is why we
   can't give the option of enabling the use of 
   what's already in place today.  We are not
   proposing any changes to neither Mobile IP
   nor DHCP, but just telling you how you could
   use them together to do remote configurations
   of MN's if you want to.  Your remote MN with
   its DHCP client will be at least as secure as
   if it were roaming within its home network.
   If and when DHCP is made secure, kudos for
   this solution.  And if someday AAA manages
   to undertake dynamic configuration duties
   under its wings, operators can go ahead and 
   use it instead of DHCP.  What's so evil 
   about this? 

Regards,
Sandy