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

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

Hi Luca,

>We can debate about this forever, but that does not mean that the DHCP
>specs we have today for IPv4 don't do a good job in distributing
>configuration information, and not only addresses. Otherwise how do you
>justify its widespread use?
>

Because it was there first and it did an OK job and there were no
competitors. And also, BTW, because Microsoft, the volume 
OS vendor for nomadic (as opposed to mobile) hosts, put it into their OS. It 
doesn't mean DHCP is the best way today with other choices available.

Moving forward (and this debate is all about futures, there is no
widespread, global mobility available today), I simply don't think
it is the right technical decision to take a protocol that was
designed to fill a hole in IPv4 routing and address provisioning 
for co-operatively managed enterprise networks but grew into a general purpose 
configuration protocol simply because there were no competitors, and
extend it into the protocol for configuring globally mobile IP hosts.

>I agree on the 3GPP2 comment, and I also agree on the fact that 3GPP2 today
>is the major utilizer of Mobile-IP. But I disagree with respect to a couple
>of points:
>
>1) Making Mobile-IP able to gracefully support DHCP does not mean that
>every Mobile-IP network *MUST* deploy and use DHCP. It only means that who
>*wants* to (e.g. corporate networks) will be able to do it.
>

If corporate networks want this, they should be arranging for VPNs with
their ISPs. DHCP was designed for and is primarily deployed in co-operatively 
managed, enterprise networks, not the kinds of wide area networks that mobile IP 
is being used for. The standard way to extend such networks remotely
is to set up a VPN. 

Here's an example of how extending DHCP to wide area
networks can go awry. Last year, a friend of mine signed up for
DSL service from the local telephone  company. After it was installed,
he turned on his Windows box, browsed into Network Neighborhood,
and ended up on his neighbor's hard drive. 

DHCP doesn't have the right kind of security characteristics for
wide area networks. VPNs do. I know there is work underway to address security
for DHCP, but since the design center for the protocol is enterprise
networks, the work is probably going to assume all kinds of supporting
infrastructure that may not be there for wide area cases.

So if we extend DHCP to wide area networks through mobile IP, we'd
end up having to go through another extensive security analysis
to figure out how to make sure that there were no security holes.
The two existing drafts are just the tip of the iceberg in terms of the
work needed.

>2) The fact that today's 3GPP2 clients use PPP and RADIUS to configure
>their addresses does not mean that they won't need something else to
>configure their (corporate?) home addresses in some scenarios.
>

Right, if they want to remotely extend this functionality, they should
use a VPN. That's how it is done today.

Now, perhaps there needs to be some work to address how to extend VPNs
to mobile, as opposed to nomadic, users, but that is orthogonal to
whether extensions to mobile IP are needed to support DHCP.

>Again, I would like to stress point (1), which I pointed out already in my
>previous e-mails: we are not talking about a mechanism that HAS TO be
>deployed. We are talking about leaving the possibility open for ISP's that
>want to use it.
>

And I'd like to stress that I don't believe it is the right technical
decision to use a protocol that was designed for co-operatively
managed enterprise networks in wide area networks. Again, as mentioned above, 
there are cases where this has been done that I've seen that have resulted
in not good stuff  happening. The two situations have different
characteristics with respect to security.

>I don't know if you read previous notes from Sandy's about this (I think it
>was a response to Pat), but this scheme won't just be so simple if the
>mobile goes home. Simply put, if the HA is responsible for a pool of
>addresses, the client will have to keep re-registering even if it is at
>home in order to defend the address.
>

So? If DHCP were used by the client, it would have to renew the lease
periodically anyway. What's the difference?

You didn't respond to my analysis about exactly what configuration information
we are talking about, but let me return to that point. Let's leave
IPv6 out of the picture, since I think we can both figure out better
ways to do this than DHCP (although I'm sure if DHCP gets integrated
with mobile IP in IPv4, people will want it for IPv6, which will only
perpetuate the problem).

Suppose we agree that service discovery information (3 on my previous email)
isn't a sufficiently good reason to integrate DHCP. There are other
ways to do service discovery, and, frankly, the mobile node may want to discover
this information locally rather than in the home network. For example,
if I want to print something, I'll want to print it locally, not back
in my office. There may additionally be some services that might
have to be discovered in the home network. The upshot is, there are
complexities to service discovery, and simply punching a reverse tunnel
with DHCP back to the home network isn't going to solve the problem.

Point 2  on my previous email was the DNS server. This is difficult
to bootstrap with service discovery. An IPv4 mobile node would need
to have this information configured because it cannot discover it, but it is not 
clear that providing it from the home network is the right way to go either. 
Signalling times may be lengthy if a home network DNS server is used, it might 
make more sense to get this information locally somehow too. I don't know
how the 3GPP2 network currently does this, but I suspect it is done
through Radius/PPP somehow. It seems to me that there may be work here
extending the current method, but probably DHCP is not the way to go either. 

Point 1 on my previous email was routability configuration. In IPv4,
this consists of the address, the subnet mask,  and the default router.
With mobile IP, the default router is supplied by the foreign agent,
so this information is not needed. The address can be supplied by the
home agent via mobile IP, so DHCP isn't needed for this either.

The upshot is that only the home subnet mask is must be somehow configured.
The two IDs are proposing a complex mechanism  with unknown security
characteristics consisting of reverse tunnels and DHCP relay agents in the home 
agent simply to provide the mobile node with the subnet mask? This doesn't make 
sense to me. It makes more sense to add a home agent registration reply 
extension that would provide the mobile node with its subnet mask (in fact, I 
may just write up an ID to do that).

In summary, DHCP is a protocol designed for enterprise networks. It
is not designed for wide area networks. We should not extend mobile
IP to support it, since there are better ways of doing host configuration
today than when DHCP was invented, that would work better in wide 
area networks.

		jak

			jak

---

From: Luca Salgarelli <[email-masked]>
Date: Fri, 13 Apr 2001 13:18:01 -0400

James,

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

> ... <snip>
> their ISPs. DHCP was designed for and is primarily deployed in
> co-operatively managed, enterprise networks, not the kinds of wide area
> networks that mobile IP is being used for. The standard way to extend
> such networks remotely is to set up a VPN. 
> 
> Here's an example of how extending DHCP to wide area networks can go
> awry. Last year, a friend of mine signed up for DSL service from the
> local telephone  company. After it was installed, he turned on his
> Windows box, browsed into Network Neighborhood, and ended up on his
> neighbor's hard drive. 
> 
> DHCP doesn't have the right kind of security characteristics for wide
> area networks. VPNs do. I know there is work underway to address security
> So if we extend DHCP to wide area networks through mobile IP, we'd end up
> having to go through another extensive security analysis to figure out
> how to make sure that there were no security holes.  The two existing
> drafts are just the tip of the iceberg in terms of the work needed.

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.

> ... <other snip>
> decision to use a protocol that was designed for co-operatively managed
> enterprise networks in wide area networks. Again, as mentioned above,
> there are cases where this has been done that I've seen that have
> resulted in not good stuff  happening. The two situations have different

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

> >I don't know if you read previous notes from Sandy's about this (I think
> >it was a response to Pat), but this scheme won't just be so simple if
> >the mobile goes home. Simply put, if the HA is responsible for a pool of

That Mobile-IP simply does not tell you that you have to keep registering
when you are at home.

> You didn't respond to my analysis about exactly what configuration
> information we are talking about, but let me return to that point. 

I did not respond because I think that we are talking about two different
models. 

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
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.

> Let's leave IPv6 out of the picture, since I think we can both figure out
> better ways to do this than DHCP (although I'm sure if DHCP gets
> integrated with mobile IP in IPv4, people will want it for IPv6, which
> will only perpetuate the problem).
> 
> Suppose we agree that service discovery information (3 on my previous
> email) isn't a sufficiently good reason to integrate DHCP. There are
> other ways to do service discovery, and, frankly, the mobile node may
> want to discover this information locally rather than in the home
> network. For example, if I want to print something, I'll want to print it
> locally, not back in my office. There may additionally be some services
> that might have to be discovered in the home network. The upshot is,
> there are complexities to service discovery, and simply punching a
> reverse tunnel with DHCP back to the home network isn't going to solve
> the problem.

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.

> Point 2  on my previous email was the DNS server. This is difficult to
> bootstrap with service discovery. An IPv4 mobile node would need to have
> this information configured because it cannot discover it, but it is not
> clear that providing it from the home network is the right way to go
> either.  Signalling times may be lengthy if a home network DNS server is
> used, it might make more sense to get this information locally somehow
> too. I don't know how the 3GPP2 network currently does this, but I
> suspect it is done through Radius/PPP somehow. It seems to me that there
> may be work here extending the current method, but probably DHCP is not
> the way to go either. 

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.

> The upshot is that only the home subnet mask is must be somehow
> configured.  The two IDs are proposing a complex mechanism  with unknown
> security characteristics consisting of reverse tunnels and DHCP relay
> agents in the home agent simply to provide the mobile node with the
> subnet mask? 

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.

> This doesn't make sense to me. It makes more sense to add a home agent
> registration reply extension that would provide the mobile node with its
> subnet mask (in fact, I may just write up an ID to do that).

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.

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

> In summary, DHCP is a protocol designed for enterprise networks. It is
> not designed for wide area networks. We should not extend mobile IP to
> support it, since there are better ways of doing host configuration today
> than when DHCP was invented, that would work better in wide area
> networks.

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.

Luca

---

From: Jim Bound <[email-masked]>
Date: Sun, 15 Apr 2001 22:23:31 -0400 (EDT)

VPNs have their major problems too like they created the need for Virtual
Routing Domains and IMO to make this short it sucks.

/jim

On Fri, 13 Apr 2001, James Kempf wrote:

> sense to me.. It makes more sense to add a home agent registration reply