Re: [dhcwg] lease query question

[Kim Kinnear <[e-mail]>]

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.

At 10:00 PM 2/11/2003, Thomas Narten wrote:
>"Cosmo, Patrick" <[e-mail]> writes:
>
>> >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.
>
>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?

        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.


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

        You are correct.


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

        Yes, and this is what it does.

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

        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



>Thomas 

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg