Subject: [dhcwg] draft-forte-dhc-passive-dad-00.txt (exposition)

From: "David W. Hankins" <[email-masked]>
Date: Wed, 9 Nov 2005 17:57:09 +0000

Yesterday I briefly touched on the idea that leases are not assigned to
MAC addresses, so keying DAD on MAC responses is, to my mind, a protocol
violation.

Let me first explain that as of today you probably won't see significant
false positives.  99% of your clients are probably Windows, and Windows
sets the client identifier to the network card's physical ethernet
address.  The remaining 1% do not identify themselves by client identifier
at all (at least, not by default).

But, the dhcwg recently sent a draft to the IEST, draft-ietf-dhc-3315id-
in-v4, if memory serves, which we hope all clients will ultimately adopt.

So I suppose what I meant to say, is that basing DAD upon MAC address
erodes this body's work in bringing proper client identification to
the protocol - that is, unique identification beyond MAC address.

So hopefully now I've done a better job of explaining why some of us
are wary of it.

As for how this can manifest, some possible cases;

1) A client identified by DUID lives in a hard drive that moves among
   various systems.  Since the DHCP server is probably contacted when
   the system reboots into a new chassis, it can probably make a record
   of the hardware address and remain consistent.  So, this is a case
   where your draft 'probably' works (with some handwaving about wether
   or not both servers in a failover pair hear it, and other similar
   oddities).  It's also possible, but not terribly likely since I
   think no clients do this, that the client may choose to hold that
   lease until it expires.

2) A client with both an ethernet and wireless network interface on the
   same broadcast domain opts to roam between them.  Since the server
   gave both interfaces the same IP address, it can do this at will.  To
   counter this (to sense the false positive), the server would have to
   record all possible MAC addresses.  ISC at least doesn't do this today.

3) A client may find that its USB ethernet dongle, wireless card, or
   similar hot-swappable media may be undesirable, and choose to
   utilize a newer or thought-to-not-be-broken device.  If the client
   participates in Aboba's fine DNA proposal (let us imagine because
   this is a wireless network and the client remembers the lease it last
   had on the same SSID), it will not involve the DHCP server, it will
   only ARP probe the default gateway, and it will be using the same
   lease on the same network with a different MAC address.  There's no
   way for a server or for AUC to work around this, so far as I know.

All that said.  You've hit upon an interesting idea.  Although I tend to
think the MAC addresses sent by the AUC are not useful for DAD, I think
the IP addresses are *very* operationally useful.

If a lease is not in the active state, if it has not been allocated, then
it sure better not be utilized.  The server can sense, then, when a client
is about to be given an already-used lease, by noting recent activity on an
address (regardless of MAC) that is presently in the FREE (or BACKUP for
failover) states.  These can and should safely be moved to ABANDONED state.

The only "valid" situation I can consider the correct lease consumer getting
into this state is if its clock becomes unreliable in a way that causes it
to believe that its expiry time has not yet come to pass.  Or even something
so simple as someone killing dhclient after getting a lease.  Some skew
around the expiration time should be allowed, but not a great deal.

In either case, ABANDONing the lease is a perfectly reasonable thing to
do, if not simply notifying the server administrator, and I think would
well solve the problematic cases.

Also, there's one other problem with our current DAD (at lease in the ISC
DHCP server).  Currently, ISC DHCP does an ICMP Echo on every DHCPDISCOVER.
This is a problem with some clients that return to broadcast a DHCPDISCOVER
while they are still bound to their lease (probably because their
DHCPREQUEST timed out).  They answer their own ICMP Echo, the server senses
a duplicate address, and the client is NAKed for the lease it's bound to.

Of course, you might have already known this, but the simple answer is to
simply not ICMP Echo an ACTIVE lease.  I suppose it's not entirely topical
to your work, except that "DAD is hard," but your problem statement
reminded me of it.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

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

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 10 Nov 2005 10:24:17 -0800

David, Henning--

when I first ported the ISC server to our telco mainframes
we exclusively used "smart" Ethernet NICs that had a number
of remote management capabilities, from resetting the
adapter to power-cycling the host PC.  As a result, it was a
mandatory requirement of our operations staff to be able to
completely track IP address leases based on MAC address,
even when a Client Identifier was present.

The process was always slightly error-prone, especially when
the NIC was replaced mid-lease.

Even worse was the requirement that we identify IP address
leases based on the client Hostname.

Duplicate Address Detection *is* hard, and all measures we
attempt to resolve an address before assignment are by
nature incomplete, given such realities as equipment being
powered off.  Having [multiple] network elements such as
gateways and relay agents proactively listen for IP address
usage and match the addresses to "useful" identifiers
certainly is possible, but it seems to me that would best be
served by a new protocol that permitted DHCP servers to
query (broadcast to?) such "listener" network elements,
rather than having those elements continuously update the
servers through an extension to DHCP.

Let me restate all of that as numbered points:

1.  Duplicate Address Detection is difficult to do
successfully with low false-positive and false-negative
results, but difficult doesn't mean we shouldn't see if we
can improve the situation.

2.  I oppose a new protocol or extension to an existing one
in which network elements update DHCP servers with
associations between IP address and other identifiers, e.g.,
Client Identifier, MAC address, DUID, Hostname, or FQDN.

3.  I support a possible new protocol giving one network
element the ability to query other network elements for
associations between IP address and other identifiers.
Obviously, this needs careful thought to avoid introducing
potential new DDOS attacks or other bad behavior such as
password sniffing.

--Barr

> -----Original Message-----
> From: David W. Hankins
> Sent: Wednesday, November 09, 2005 09:57
>

*Snip!*

---

From: Andrea G Forte <[email-masked]>
Date: Thu, 10 Nov 2005 13:43:39 -0500

A few comments are inline.

>MAC addresses, so keying DAD on MAC responses is, to my mind, a protocol
I am not sure I understand what you mean with protocol violation. I do 
not see any protocol violation.
 From RFC 2131:
"for example, the 'client identifier' may contain a hardware address, 
identical to the contents of the 'chaddr' field"
and also
"If the client does not provide a 'client identifier' option, the server 
MUST use the contents of the 'chaddr' field to identify the client."

>the protocol - that is, unique identification beyond MAC address.
We will take the draft mentioned earlier into consideration and also 
wait for other comments regarding this particular issue (should we build 
drafts on drafts?).

As of today, most of the clients use MAC addresses as client 
identifiers. Once IPv6 will be adopted and/or (if the previous draft 
becomes RFC) the DHCP clients and servers will be upgraded, then a 
problem might arise, but I do not see that happening anytime soon to be 
honest. Inter-subnet and inter-network mobility are very critical 
problems that have a more immediate impact and need to be addressed.

There are a few points I want to clarify about our passive DAD (p-DAD).
In our architecture the main reason why we use the pair {MAC, IP} and 
not just IP is because we want to be able to detect users that are using 
an IP address without any authorization. This means that we want to 
detect an illegal use of IP addresses even if there is not a duplicate 
address situation.
This might be the case of a user with a valid IP address leaving the 
subnet without sending any DHCP_RELEASE; its lease would be still valid 
and it might be used by a malicious user for the amount of lease time 
that is left.
If all we want to do is nothing more than duplicate address detection, 
that is collecting information about the IP addresses currently in use, 
then no MAC information is needed and the AUC can just "tell" the DHCP 
server which IPs are in use so that the server does not assign any of them.

-Andrea

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 10 Nov 2005 20:13:21 +0000

> MUST use the contents of the 'chaddr' field to identify the client."

This is a misunderstanding which the DHCP protocol is still paying for.

Servers are actually required to treat the client identifier contents as
opaque (RFC2131 section 2).  The example of using a hardware address was
not only a bad idea, which has served only to confuse hundreds and spread
pain and agony throughout the world, it was merely an example.

More than this, the RFCs are inconsistent on the treatment of a single
client who chooses to identify itself inconsistently, or inconsistently
similarly.

To allocate a lease to a client identified client, to then allow this
client to continue to use its lease when it chooses to change its MAC
address (for whatever reason), and then to send this lease to ABANDONED
state when an outside agent "detects a duplicate", is a protocol violation.

The lease is assigned to the client identifier, not its MAC address.  The
client is allowed to change its MAC address and keep its lease.

Penalizing clients that change their MAC address without adjusting their
client identifer erodes the purpose of client identifiers and, in any
semblance of adoption of such practices, throws away a great deal of
this WG's work to date on the issue of client identification.

> wait for other comments regarding this particular issue (should we build 

Thank you.

> detect an illegal use of IP addresses even if there is not a duplicate 

Absolutely, as I was saying, leases that are in use but not ACTIVE are
very interesting operationally.  But, you have to bey very careful about
leases that /are/ ACTIVE, because at present there is no way from the
outside to tell what the client identifier of a given client actually is
without getting DHCP packets out of it.

I submit that the only reason you're using the client's MAC address is
because it is the only hammer in your toolbox.  As a former sysadmin, I
appreciate that.  As a DHCP Server programmer trying to offer "best
practice" advice, I don't.

I would say the current draft description of p-DAD could only legally
be used on leases upon which no client identifier has been stored (and
thus, the lease is in fact identified by the chaddr field).

For client-identified-clients you have a tough issue to solve.

Many DHCP Server implementations (all but ISC's as it turns out) have,
shall we say, liberally interpreted the meaning of chaddr-identical
client-identifiers.  You may wish to consider behaving similarly
liberally.

> server which IPs are in use so that the server does not assign any of them.

If this is in the requirements section, then I think the only answer is
very short lease times and strong cryptographic assurance the client has
the keys necessary to identify itself.

Because such a miscreant could just as easily assume the departing
system's MAC address.

The issue of "DHCP Authentication" has been a weak point here at the
DHC WG, in my opinion.  RFC3118 exists, but it's not widely implemented
(I believe, at least I'm certain it's not widely deployed).  Nor is
there a great deal of outcry for same.

I think most of the other people lurking on this list have saved this
issue for a rainy day, so to speak.  Collectively, I think we know it's
a problem, we know that RFC3118 doesn't solve it, but we're having a
hard time trying to find voice to say what would.

I think your p-DAD draft is awesome, if you will forgive me for the
vernacular.  I would be happier if it was more careful about the
identification of a client.  I am presently ambivalent about questions
of 'direction of information flow'.  Barr Hibbs is a smart guy, and
I think he might be onto something, but I have no strong reflection
on this subject yet myself.

I think the functions it describes would be terribly useful for sysadmins
worldwide regardless of the mechanics of transport.

I'm also somewhat embarassed that ISC DHCP has not adopted RFC3118.  In
my defense, for my years work at ISC on DHCP, I have been pressed constantly
to produce maintenance releases to correct serious shortcomings in the
existing software.  At the same time, I can't imagine arguing a case for
implementing it; I can't imagine it being useful to our software's users.
This is beyond mere 'chicken and egg' syndrome, vis a vis the lack of DHCP
client support.  I don't think a client-configured-authorization-mechanic
is going to work in an environment that on the whole needs to maintain
automatic configuration of clients.  "Please stand-by while the sysadmin
configures a key on your system" just doesn't work.

Hope this is helpful.