Subject: RE: [dhcwg] lease query question

From: "Cosmo, Patrick" <[email-masked]>
Date: Tue, 11 Feb 2003 13:41:38 -0800

>Thus, knowing that an address is reserved, but
>not currently in use, doesn't seem to be info the 
>relay agent really needs. Am I missing some other 
>important detail here?

Here's one example:

some relay agents provide an "Host Authentication" feature where they only
fwd data from an device using an IP address that the device "really does
own". This is an attempt to prevent IP spoofing. The relay agent determines
who "owns" an IP address (who was actually leased the address) by gleaning
the DHCP messages that pass through it, or through DHCP lease query. In the
case where a device is manually configured with an IP and is not performing
DHCP, the DHCP service may be configured with a "static address" for the
device to indicate that the device really does "own" that IP address. The
relay agent can determine and recognize this fact through the use of DHCP
lease query.

There may be other current examples, or future uses not yet considered. It's
all about flexibility I think.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Tuesday, February 11, 2003 12:51 PM
To: Kim Kinnear
Cc: [email-masked]; [email-masked]; Woundy, Richard
Subject: Re: [dhcwg] lease query question 

Hi Kim.

>         Having said that (which is true), I don't see significant
>         deviation from at least my conceptualization of the
>         current problem the leasequery protocol/draft solves.

I guess I do. I could imagine solving the simple problem by having
just a pair of messages (request and reply), with the reply saying
"yes there is a lease" or "no there is not" and not having the R bit
at all. Thus, I'd like to understand whether and why the more complex
solution is really necessary. Ideally, this would follow from the
problem statement.

>         There are implementations of this capability in the field
>         today, and the actual draft is informed by not only our
>         intellectual exercises in protocol design but by actual
>         implementations and actual users of those implementations
>         with real requirements.  If you think there is dramatic
>         mis-match between the problem statement with the actual
>         protocol, we can certainly revise the problem statement
>         to whatever degree you deem necessary.

Well, one can always revise a problem statement to make sure that a
proposed solution follows from it. But that isn't generally the way to
get good protocols. What I would rather understand is the actual
problem, independent of the solution. If it happens that the solution
is a reasonable one given the problem statement, that would be
great. But if there are simpler solutions, they should be considered
too.

So far, you've provided a very high-level, general problem
description. From it, I don't see the need for some of the proposed
protocol features.  I really do want to understand if the proposed
solution is the best one for the actual problem.

>         So, for instance, if a "real" DHCP client was talking to
>         the DHCP server, it would give the client a lease (as
>         opposed to telling the client that it had a lease at some
>         point in the past).  However, the client for a leasequery
>         request isn't looking for a lease -- it is looking for
>         information *about* a lease.  Allowing a server to return
>         information that indicates that a lease existed for a
>         client at sometime in the past may well be useful to a
>         device which is trying to rebuild its state, since this
>         is information that it normally would have available if
>         it had not lost its state.

The above is not obvious to me. Why should the relay agent care if an
address used to be in use on a particular link in the past? I would
think that the relay agent shouldn't be creating ARP state based on
that because:

 - in fact that address might be in use by a different node elsewhere
   on a different link now (and the server responding might not know
   that because its not coordinating properly with the other server).

 - if the lease is no longer valid, presumably the device using that
   address shouldn't be using that address anymore (after all, it
   didn't renew the lease). So why should the relay agent forward
   packets for that address to the site where a device used to be in
   the past?

>         The R bit is designed to allow a device which uses DHCP
>         gleaning to also operate correctly in the event that some
>         IP addresses are "hard coded" or "hand configured".  In
>         this case, if the DHCP server is supplied with a
>         reservation for the hand configured IP<->MAC
>         relationship, then if the DHCP client asks for an IP
>         address, it will get the proper one.

Makes complete sense for normal DHC usage.

>	  More importantly,
>         the leasequery client doesn't have to be configured with
>         the hand-configured IP address, since it can determine
>         which IP addresses are "allowable" from the results of a
>         leasequery.  This is indeed a capability that the
>         leasequery protocol allows that isn't possible in a
>         straightforward way without it.

The above I don't follow, for the reason I mentioned above. Seems to
me, the relay agent shouldn't be populating it's ARP cache *unless*
there is a valid lease. Thus, knowing that an address is reserved, but
not currently in use, doesn't seem to be info the relay agent really
needs. Am I missing some other important detail here?

Thomas
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Thomas Narten <[email-masked]>
Date: Tue, 11 Feb 2003 22:00:22 -0500

> the DHCP messages that pass through it, or through DHCP lease query.

I understand and agree with everything so far.

> In the case where a device is manually configured with an IP and is
> not performing DHCP, the DHCP service may be configured with a
> "static address" for the device to indicate that the device really
> does "own" that IP address. The relay agent can determine and
> recognize this fact through the use of DHCP lease query.

So, the client  isn't using DHC, but we're going to configure the DHC
server about that client anyway and the relay agent is going to use
leasequery to get info from the DHC server about those  addresses,
even though DHC (as in the RFC 2131) isn't even being used for these
addresses?

Is this indeed part of the problem statement?

I'll note also that the above problem can't be solved by DHC gleaning,
since the client isn't using DHC. So, the above isn't just about
restoring gleaned information after losing state.

But having said that, couldn't the DHC server just respond with "I
have a lease" for the hardcoded configuration information, even if it
(in some sense) doesn't? What the relay agent presumably cares about
is whether an address is in use on a certain link. It doesn't really
care _how_ the DHC server knows about those addresses. Right?

Thomas

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 12 Feb 2003 10:48:21 -0500

Thomas,

Patrick did an excellent job of explaining the motivation behind
this particular part of the problem statement in the leasequery
draft (from the second point on page 2):

      2. The access concentrator can perform IP source address verifica-
         tion of datagrams received from the access network.  The verif-
         ication may be based on the datagram source hardware address,
         the incoming access network port, the incoming virtual circuit,
         and/or the transmitting modem.

I have some additional comments, indented, below.

>even though DHC (as in the RFC 2131) isn't even being used for these

        Yes, since the utility of this "host authentication"
        feature or "source address verification" feature (call it
        what you will) has been found to be less broadly
        applicable in practice than it was in theory.  It is
        certainly useful, but it would be more useful if it
        worked on networks which were not configured solely using
        DHCP enabled clients.

        Thus, practical experience has shown that the solution we
        originally architected and deployed would be even more
        useful if we added some small things to the leasequery
        capability.  That was the source of my comment about this
        becoming a second generation capability -- it has truly
        evolved over time.

>Is this indeed part of the problem statement?

        Yes, it is now.

>restoring gleaned information after losing state.

        You are correct.

>(in some sense) doesn't?

        Yes, and this is what it does.

> What the relay agent presumably cares about

        It may well be that an access concentrator will use the
        reservation to decide that it will allow this IP address
        to work from any port, but then remember that port and
        not allow it from any other port.  This is because there
        may not be option-82 information configured for that
        reservation.  In this case, the fact that it is a
        reservation may well be key to the access concentrator's
        ability to allow the IP address to be used.

        On the other hand, we don't know for sure that someone
        won't create an access concentrator that might want to
        prohibit leasequery information for any *but* real DHCP
        clients, we decided to put this bit of information into
        the leasequery capability.

        Indeed, there may well be other decisions an access
        concentrator might with to make based on this information
        that I haven't even imagined at this time.  

        I believe that our job is to create capabilities that
        serve a well defined need in a clear and easily
        implemented (to be interoperable) manner.  I *also*
        happen to believe that if we do our jobs right, people
        will use these capabilities in ways that we have not yet
        imagined to do things that are innovative and useful for
        end-users.  Thus, I believe that in a capability such as
        leasequery where the primary goal is to return
        information to an access concentrator, we would be
        missing the point if we failed to deliver something as
        simple and possibly basic as the source of the rest of
        the information.

        It isn't as though we had to invent a new message
        exchange or anything -- that would have been overkill.
        However, since we have the information it seems foolish
        to withhold it on some philosophical grounds given we are
        talking about one bit, and we can certainly imagine ways
        in which it might well be useful.

        Kim