RE: [dhcwg] Leasequery: should it be standardized?

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25416 for ; Wed, 26 Feb 2003 16:04:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1QLE6c11186 for dhcwg-archive@odin.ietf.org; Wed, 26 Feb 2003 16:14:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLE6p11183 for ; Wed, 26 Feb 2003 16:14:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25360 for ; Wed, 26 Feb 2003 16:03:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLC6p11041; Wed, 26 Feb 2003 16:12:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1QLBfp11012 for ; Wed, 26 Feb 2003 16:11:41 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25260 for ; Wed, 26 Feb 2003 16:01:24 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h1QL4lb20945; Wed, 26 Feb 2003 15:04:47 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h1QL4lC11887; Wed, 26 Feb 2003 15:04:47 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 26 Feb 2003 15:04:47 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Kevin A. Noll'" , Kim Kinnear , dhcwg@ietf.org Cc: Ralph Droms , Thomas Narten Subject: RE: [dhcwg] Leasequery: should it be standardized? Date: Wed, 26 Feb 2003 15:03:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DDDA.741F7D68" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DDDA.741F7D68 Content-Type: text/plain; charset="ISO-8859-1" Kim/Kevin: I agree with Kevin's statements. I too think it is important that this is standardize by the IETF (which WG is less critical, though DHC WG seems like a good home to me because it is after all DHCP). I agree with Kevin's point about there needing to be some standard means to query the DHCP server's database about clients. For example, this might also be used by routers or other devices on the network to handle admission control. The first packet for an IP address that is not in the router's OK list (or hasn't been checked in a while) could be confirmed (IP + MAC) via leasequery. There are also other uses of this, for example for network monitoring. Perhaps there are other ways this problem could be solved, for example by finishing up an SNMP MIB for DHCP that allows this kind of information to be obtained. But, that road has been tried and has not been finalized. And, finally there are probably future uses of this kind of capability that we've never would have thought about. So, setting up something that is more flexible and powerful than just solving a very small and specific problem is, IMHO, the IETF way. Perhaps a fix is to state that the original problem statement was blah, blah, blah, and leasequery meets those needs, plus more. - Bernie Volz -----Original Message----- From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] Sent: Wednesday, February 26, 2003 3:17 PM To: Kim Kinnear; dhcwg@ietf.org Cc: Ralph Droms; Thomas Narten Subject: RE: [dhcwg] Leasequery: should it be standardized? Kim, At the risk of sounding foolish since I'm not an active participant in the WG... I think there is a need to standardize leasequery. It seems to me that the problem statement is the real issue. LeaseQuery should not be positioned in any way as an access control mechanism or *necessarily* involved in such, especially since there are other uses for this information. Leasequery is just what the name implies - a *standard* method for external entities (whether they be routers or some other system) to query the DHCP server for lease information. As it is today, there is no *standard* backend DHCP database that can be queried. Some use text files, some use LDAP, some use proprietary databases, etc. Therefore, the ability to query a DHCP server for lease information does not exist except through proprietary methods. This limits interoperability of the various vendors systems. For example, there is no way for vendor X to query vendor Y's DHCP server unless they cooperate outside the standards bodies. This functionality is not limited to routers (or other devices) using the information for access control. There are cases (not necessarily well documented) where systems external to the DHCP server need to find out about a lease for network management or troubleshooting reasons. One example is a helpdesk staffer trying to find out whether a device is up or down, but only knows the MAC address of the device. How does he/she find out the IP? Okay, DNS could be consulted, but it isn't authoritative for information regarding MAC-to-IP mapping, only NAME-to-IP mapping. There have been various schemes to store this information in DNS (e.g. the NAME is easily derived given the MAC, etc), but there are all kinds of issues that arise with this solution (what if we don't *want* that information in DNS, etc.) The stable storage statements in the current problem statement aren't necessarily relevant, either. My suggestion is that the problem statement be centered around making the DHCP server the *authority* for lease information. An alternative would be to write a new draft (maybe not within this WG) that would define a way to make some existing network database (probably DNS) authoritative for this information. I think we could come up with a better problem statement that would get your leasequery draft further down the road. Anyway, that's my 2 cents worth. --kan-- -- Kevin A. Noll, KD4WOZ Kevin.Noll@perfectorder.com CCIE,CCDP Perfect Order, Inc. 717-796-1936 -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Kim Kinnear Sent: Wednesday, 26 February, 2003 12:37 PM To: dhcwg@ietf.org Cc: Ralph Droms; Thomas Narten; Kim Kinnear Subject: [dhcwg] Leasequery: should it be standardized? Folks, We have come to something of a impasse on the leasequery draft, and I need *your* support if you believe we should continue to pursue this draft. =============================================================== Without considerable support from the DHC WG, we will halt work on the leasequery draft and all attempts to bring this work to standard status. =============================================================== If you believe that there is any value in standardizing the leasequery capability, please at least respond to this list ASAP with your positive support. If you have the time and expertise, please read the rest of this email and see if you can offer cogent arguments as to why this is work that the DHC working group should be pursuing. If we don't standardize the leasequery capability, each vendor of access concentrators and DHCP products that wish to use this approach will then need to work together (possibly in some other forum) to try to get their products to be compatible. Of course, it may well be that we are the only folks who see this as a useful capability, and so that may not be an issue at all. Thanks -- Kim ----------------------- Summary ----------------------- In case you haven't been following the email between Thomas Narten and myself, he has been questioning the problem statement of the leasequery draft. Ralph proposed a new problem statement, but Thomas feels that this whole capability is questionable. You are invited to respond to Thomas' arguments, which I have distilled as follows: 1. Doing anything in the DHC WG like supporting "access control in router type devices" is out of scope for the working group, and doesn't fit its current charter. 2. Access control in router type devices is not well enough understood to be sure that: a) leasequery is the right solution. b) any DHC-based approach is the "right" approach to solve this problem. 3. Until we are sure of 2(a), then we should not proceed with this work (I believe that this statement is implicit in Thomas' comments.) ----------------------- Background --------------------------- Here is Ralph's proposed problem statement: Router-type devices which want to enforce some level of access control over which IP addresses are allowed on their links need to maintain information concerning IP<-MAC/client-id mappings. One way in which these devices can obtain information about IP<-MAC/client-id bindings is through "DHCP gleaning", in which the device extracts useful information from DHCP messages exchanged between hosts and DHCP servers. However, these devices don't typically have stable storage sufficient to keep this information over reloads. There may be additional information that is useful to the device that cannot be obtained through DHCP gleaning. The leasequery request message described in this document allows a device to obtain information about IP<-MAC/client-id bindings from a DHCP server. This information may include currently active bindings, bindings involving previously assigned addresses for which the lease on the address has expired and static bindings for devices that are otherwise configured and not using DHCP for address assignment. Thomas' concerns center on the second paragraph above, and he says: Note, that above is pretty vague and doesn't say what information the access device needs. It's hard to look at the problem statement and say "yes, I understand the boundaries of the problem" and then "and the solution seems like a good match for the problem". Popping up a level, how is it even appropriate for the DHC WG to be doing work on "access control in router type devices"? One can argue that work of this broad a scope is well out-of-scope for this WG (e.g., look at the recently approved charter). I'm far from clear that work of this scope should be done in DHC or that the problem is well enough understood to conclude that DHC lease query is the right solution or that any DHC-based solution is the right one. What about routers wanting to do access control that don't use DHC, for instance? And note, I'm not raising these issue just to be a PITA. These are questions that I expect that the IESG would ask if I brought the document forward. Thus, I need to have reasonable responses to those questions. Otherwise, I can predict the likely outcome. My response to Thomas was: This approach to access control was developed by joint work with the folks building our access concentrators and several of us in the DHCP implementation group. They found that the functionality delivered to actual users was of sufficient value to those users to be worth the cost of engineering this particular solution. We supported them in moving the implementation forward. The solution was not based on the charter of the DHC working group either then or now -- it was based on a rather pragmatic approach to meeting the needs of users, which it has seemed to do. In my view at least, it fits within spirit of the DHC WG activities, and was a logical extension of the those activities. It isn't a comprehensive approach to any sort of security (nor was it designed to be such) -- it is a supporting piece of technology to one limited form of access control. Thanks for your interest in the leasequery capability. Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2DDDA.741F7D68 Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] Leasequery: should it be standardized?

Kim/Kevin:

I agree with Kevin's statements. I too think it is important that this is
standardize by the IETF (which WG is less critical, though DHC WG seems
like a good home to me because it is after all DHCP).

I agree with Kevin's point about there needing to be some standard
means to query the DHCP server's database about clients.

For example, this might also be used by routers or other devices on the
network to handle admission control. The first packet for an IP address
that is not in the router's OK list (or hasn't been checked in a while)
could be confirmed (IP + MAC) via leasequery.

There are also other uses of this, for example for network monitoring.
Perhaps there are other ways this problem could be solved, for example
by finishing up an SNMP MIB for DHCP that allows this kind of information
to be obtained. But, that road has been tried and has not been finalized.

And, finally there are probably future uses of this kind of capability
that we've never would have thought about. So, setting up something that
is more flexible and powerful than just solving a very small and specific
problem is, IMHO, the IETF way.

Perhaps a fix is to state that the original problem statement was blah,
blah, blah, and leasequery meets those needs, plus more.

- Bernie Volz

-----Original Message-----
From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com]
Sent: Wednesday, February 26, 2003 3:17 PM
To: Kim Kinnear; dhcwg@ietf.org
Cc: Ralph Droms; Thomas Narten
Subject: RE: [dhcwg] Leasequery: should it be standardized?

Kim,

At the risk of sounding foolish since I'm not an active
participant in the WG...

I think there is a need to standardize leasequery.

It seems to me that the problem statement is the real issue.

LeaseQuery should not be positioned in any way as an access
control mechanism or *necessarily* involved in such, especially
since there are other uses for this information.

Leasequery is just what the name implies - a *standard* method for
external entities (whether they be routers or some other system)
to query the DHCP server for lease information.

As it is today, there is no *standard* backend DHCP database that
can be queried. Some use text files, some use LDAP, some use proprietary
databases, etc. Therefore, the ability to query a DHCP server for
lease information does not exist except through proprietary methods.

This limits interoperability of the various vendors systems. For example,
there is no way for vendor X to query vendor Y's DHCP server unless
they cooperate outside the standards bodies.

This functionality is not limited to routers (or other devices)
using the information for access control. There are cases (not
necessarily well documented) where systems external to the DHCP
server need to find out about a lease for network management or
troubleshooting reasons.

One example is a helpdesk staffer trying to find out whether a
device is up or down, but only knows the MAC address of the device.
How does he/she find out the IP?

Okay, DNS could be consulted, but it isn't authoritative for information
regarding MAC-to-IP mapping, only NAME-to-IP mapping. There have been
various schemes to store this information in DNS (e.g. the NAME is easily
derived given the MAC, etc), but there are all kinds of issues that arise
with this solution (what if we don't *want* that information in DNS, etc.)

The stable storage statements in the current problem statement aren't
necessarily relevant, either.

My suggestion is that the problem statement be centered around making the
DHCP server the *authority* for lease information.

An alternative would be to write a new draft (maybe not within this WG) that
would define a way to make some existing network database (probably DNS)
authoritative for this information.

I think we could come up with a better problem statement that
would get your leasequery draft further down the road.

Anyway, that's my 2 cents worth.

--kan--
--
Kevin A. Noll, KD4WOZ Kevin.Noll@perfectorder.com
CCIE,CCDP
Perfect Order, Inc. 717-796-1936

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Kim
Kinnear
Sent: Wednesday, 26 February, 2003 12:37 PM
To: dhcwg@ietf.org
Cc: Ralph Droms; Thomas Narten; Kim Kinnear
Subject: [dhcwg] Leasequery: should it be standardized?

Folks,

We have come to something of a impasse on the leasequery draft,
and I need *your* support if you believe we should continue to
pursue this draft.

===============================================================
Without considerable support from the DHC WG, we will halt work
on the leasequery draft and all attempts to bring this work to
standard status.
===============================================================

If you believe that there is any value in standardizing the
leasequery capability, please at least respond to this list ASAP
with your positive support.

If you have the time and expertise, please read the rest of this
email and see if you can offer cogent arguments as to why this is
work that the DHC working group should be pursuing.

If we don't standardize the leasequery capability, each vendor of
access concentrators and DHCP products that wish to use this
approach will then need to work together (possibly in some other
forum) to try to get their products to be compatible. Of course,
it may well be that we are the only folks who see this as a
useful capability, and so that may not be an issue at all.

Thanks -- Kim

----------------------- Summary -----------------------

In case you haven't been following the email between Thomas
Narten and myself, he has been questioning the problem statement
of the leasequery draft. Ralph proposed a new problem statement,
but Thomas feels that this whole capability is questionable.

You are invited to respond to Thomas' arguments, which I have
distilled as follows:

1. Doing anything in the DHC WG like supporting "access
control in router type devices" is out of scope for the working
group, and doesn't fit its current charter.

2. Access control in router type devices is not well enough
understood to be sure that:

a) leasequery is the right solution.

b) any DHC-based approach is the "right" approach to
solve this problem.

3. Until we are sure of 2(a), then we should not proceed with
this work (I believe that this statement is implicit in Thomas'
comments.)

----------------------- Background ---------------------------

Here is Ralph's proposed problem statement:

   Router-type devices which want to enforce some level of access
   control over which IP addresses are allowed on their links
   need to maintain information concerning IP<-MAC/client-id
   mappings. One way in which these devices can obtain
   information about IP<-MAC/client-id bindings is through "DHCP
   gleaning", in which the device extracts useful information
   from DHCP messages exchanged between hosts and DHCP servers.

   However, these devices don't typically have stable storage
   sufficient to keep this information over reloads. There may
   be additional information that is useful to the device that
   cannot be obtained through DHCP gleaning. The leasequery
   request message described in this document allows a device to
   obtain information about IP<-MAC/client-id bindings from a
   DHCP server. This information may include currently active
   bindings, bindings involving previously assigned addresses for
   which the lease on the address has expired and static bindings
   for devices that are otherwise configured and not using DHCP
   for address assignment.

Thomas' concerns center on the second paragraph above, and he says:

   Note, that above is pretty vague and doesn't say what
   information the access device needs. It's hard to look at the
   problem statement and say "yes, I understand the boundaries of
   the problem" and then "and the solution seems like a good
   match for the problem".

   Popping up a level, how is it even appropriate for the DHC WG
   to be doing work on "access control in router type devices"?
   One can argue that work of this broad a scope is well
   out-of-scope for this WG (e.g., look at the recently approved
   charter). I'm far from clear that work of this scope should
   be done in DHC or that the problem is well enough understood
   to conclude that DHC lease query is the right solution or that
   any DHC-based solution is the right one. What about routers
   wanting to do access control that don't use DHC, for instance?

   And note, I'm not raising these issue just to be a PITA. These
   are questions that I expect that the IESG would ask if I
   brought the document forward. Thus, I need to have reasonable
   responses to those questions. Otherwise, I can predict the
   likely outcome.

My response to Thomas was:

   This approach to access control was developed by joint work
   with the folks building our access concentrators and several
   of us in the DHCP implementation group. They found that the
   functionality delivered to actual users was of sufficient
   value to those users to be worth the cost of engineering this
   particular solution. We supported them in moving the
   implementation forward.

   The solution was not based on the charter of the DHC working
   group either then or now -- it was based on a rather pragmatic
   approach to meeting the needs of users, which it has seemed to
   do. In my view at least, it fits within spirit of the DHC WG
   activities, and was a logical extension of the those
   activities.

   It isn't a comprehensive approach to any sort of security (nor
   was it designed to be such) -- it is a supporting piece of
   technology to one limited form of access control.

Thanks for your interest in the leasequery capability.

Kim

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C2DDDA.741F7D68-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg