Subject: [dhcwg] draft-forte-dhc-passive-dad-00.txt - client ID support

From: Andrea G Forte <[email-masked]>
Date: Tue, 22 Nov 2005 14:01:41 -0500

Dear all,

at the last IETF meeting it was decided that two main issues should have 
been addressed for p-DAD. One was the amount of traffic introduced 
between the AUC and DHCP server, the other issue was the support of the 
client-ID instead of the MAC address.

Regarding the amount of traffic introduced between the AUC and the DHCP 
server, we are currently taking some measurements so that later we can 
show you some numbers.

For adding client-id support to the p-DAD we were thinking of the 
following:
the AUC can create two tables, one is the table with {MAC, IP} pair that 
we already have and it is built by listening to normal *non DHCP* 
traffic; the second table would contain {DUID, MAC} pairs and it would 
be built by listening to DHCP traffic*only*. In particular we might be 
able to use DHCP_REQUESTs only. The two tables are independent. The 
first one tells us which IPs are being used for which MAC, while the 
second one tells us each MAC to which client ID it corresponds to. If 
the AUC detects the same IP with two different MACs, it checks the 
second table to see if the two MACs belong to the same client (that is 
have the same DUID) or not. If they do, then the AUC will not send 
anything to the DHCP server, otherwise it will as a duplicate IP address 
might have occurred.
The packet format between AUC and DHCP server would be something like this:
_________________________
| Flag | ID (6 bytes) | IP address |

where flag indicates if the client-ID option is being used or not. In 
the latter case we would have the normal scenario based on the MAC 
address which is why we have the ID field 6 bytes long in the packet. 
The IP address is the possible duplicate IP address.

All comments are as always wellcome.

-Andrea

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2005 13:21:09 -0600

That seems like a good idea in principal, but why not just use the 
pre-existing table inside of the DHCP server?

---

From: Andrea G Forte <[email-masked]>
Date: Tue, 22 Nov 2005 14:32:48 -0500

I am not sure I follow. Which pre-existing table are you referring to?
One of the goals of having the two tables in the AUC is that in this way 
the traffic between AUC and DHCP server can be reduced by the AUC 
looking at both tables and only then decide if to send a frame to the 
server or not.

-Andrea

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Nov 2005 15:00:58 -0600

> looking at both tables and only then decide if to send a frame to the

The problem with snooping on the network is that it means that you are going 
to have an incomplete picture of what's going on.   In the case of ARP 
caching, that's okay, because if you don't have the information in the cache, 
you're no worse off than you otherwise would have been.   In the case of a 
MAC address to client identifier map, though, if an entry in the map is 
missing, you're going to report an address conflict to the DHCP server when 
no address conflict exists.   So I think a potentially lossy cache doesn't 
work in this case.

The more I think about this, the more it seems that it can't really work.   
The problem is that you need to have an accurate table mapping client 
identifiers to MAC addresses.   But there is nowhere on the network where you 
can get this table.   The reasons are as follows:

1. DHCP server can get MAC addresses.   But only if it's on the same wire as 
the client; otherwise it doesn't see the wire MAC address of the client - it 
sees the wire MAC address of the router that delivers the relayed packet.

2. Relay agent can get MAC addresses.   Okay, this is workable, but now you 
have a custom relay agent that you have to write.

3. Not all media use MAC addresses.   No workaround for this, other than 
declaring that PDAD doesn't work on such media.

4. Snoop.   This doesn't work because in practice you can't be sure of 
successfully snooping every packet.

So I guess if you're willing to deploy special relay agents and you're willing 
to say PDAD doesn't work on firewire or infiniband, you can make it work.   
It's probably a very reasonable line of research.   But I don't see it 
turning into something that could be readily deployed in a production 
environment, unless you can talk Cisco, Juniper, and all the other vendors 
into updating their relay agents.

---

From: Andrea G Forte <[email-masked]>
Date: Tue, 22 Nov 2005 17:17:29 -0500

Please read inline comments.

>no address conflict exists.   So I think a potentially lossy cache doesn't 
This is true. However, you have to keep in mind that the AUC just tells 
the DHCP server which IPs are
currently in use and which ones might *potentially* be in conflict. It 
is up to the DHCP server to make
the final decision. If the AUC finds an IP address in use for which 
there is no entry in the MAC-client ID
table, it means that someone is using an IP address that has been 
configured manually (as there was no
DHCP traffic for that MAC). The AUC will then inform the DHCP server 
about this IP. If this IP has
not yet been assigned by the DHCP server, the server will put this IP in 
the "not free" IP address pool so
that it does not get assigned later on; if this IP has legally been 
assigned by the server and we have
somehow missed the DHCP traffic for that MAC, the server will either 
just ignore the
frame from the AUC or inform the AUC about the false positive.

>sees the wire MAC address of the router that delivers the relayed packet.
Yes, the AUC on the DHCP server would not make much sense.

>have a custom relay agent that you have to write.
This is the way I have implemented it so far and it seems to be the best 
fit. The AUC is a module that runs in
a separate thread of the existing ISC relay agent. It is very easy to 
integrate in existing relay agents.

>declaring that PDAD doesn't work on such media.
Or, perhaps, the DHCP server could inform the AUC about these particular 
clients.

-Andrea

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 22 Nov 2005 19:52:06 -0800

I've been thinking about this for the last few days and
suspect that the capability to detect duplicate addresses
might be generally useful to more than just DHCP clients and
servers.

That said, I'm pretty sure that the AUC proposed in Andrea's
draft is roughly the equivalent of a DHCP relay agent:
something that most likely will be implemented as an
embedded component of other network equipment such as
routers or switches (only for network segments without a
router.)

At this point, a DHCP server and relay agent each have some
knowledge of a client based on what they know to be
absolutely correct (the gateway address from which a packet
is received and the network address assigned by the server,)
and what they reasonably assume to be correct (the client
identification in one of several possible forms, including
none, and the client hardware address, although there are a
few troubling cases.)

Presumably a relay agent would, unless compromised, always
accurately report what it knew of IP address usage
associated with client identity, so in the simple case, only
the nearest relay agent need be queried during duplicate
address detection by the server.

In the more general case, a trust relationship needs to be
established between the server and all relay agents, similar
to RFC 3118 authentication, for a number of reasons
including (1) verified identity of the server and relay
agents, (2) reasonably guaranteed integrity of the
address-identity association, and (3) reasonable prevention
of spoofing and some other attacks.

This would require that a server determine (mostly
passively, but perhaps by some mechanism to actively poll
the network) the existence of relay agents.  A server could
then multi-cast queries to the relay agents when probing to
see if an address about to be assigned is known to be in
use, or direct specific inquiries to the relay agent(s)
closest to the last known client holding an address lease to
determine if the client identity-IP address association is
still in use.

In short, I think that Andrea's proposal should be folded
into the definition of a relay agent, that some additional
server-to-relay agent functionality may be required, and
that authenticated message exchange is probably needed to
prevent malicious behavior.

--Barr

> -----Original Message-----
>

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 22 Nov 2005 20:01:51 -0800

The appropriate question is whether or not media such as
Firewire and InifiniBand are or will be in sufficient use
along with a DHCP server such that this is a show-stopper?

If such media types are an insignificant or minor part of
our networks, maybe the most straightforward thing is to
declare duplicate address detection not possible for those
media types.

If, on the other hand, the occurrence of such media is
expected to be significant or dominant, then it's back to
the drawing board.

--Barr

> Not all media use MAC addresses.   No
> workaround for this, other than

---

From: Andrea G Forte <[email-masked]>
Date: Wed, 23 Nov 2005 11:53:05 -0500

Please read the inline comments.
Thank you.

>of spoofing and some other attacks.
We did not consider much security issues in our draft. This choice was 
taken because
we felt that there were bigger security problems in the general DHCP 
framework. So,
just fixing the ones related to our draft only, would have not helped much.
However I agree. Security is a big concern and all the suggestions 
expressed above
should be taken into serious consideration.

>determine if the client identity-IP address association is
I do not understand why multicast would be of any use. The DHCP server 
already knows
from which Relay Agent a request is coming from, so it would ask to that 
Relay Agent only.
Also, I do not see the advantages of a query mechanism as opposed to the 
mechanism we propose.
As we will show with some measurements, the load between AUC and DHCP 
server is very low.
Quering a Relay Agent (RA) per each DHCP transaction seems like it might 
actually introduce
more traffic than with the proposed approach depending on what kind of 
information the response
to these queries would contain. Also, a duplicate or unauthorized 
address being in use would not be
discovered by the DHCP server until a query takes place, even though the 
AUC/RA might
have known for quite some time. This might be important if in the future 
we think of ways to
address the problem of how to deal with unauthorized users just taking 
an IP address they like.

-Andrea

>>>That seems like a good idea in principal, but
>>>      
>>>
>>why not just use the
>>    
>>

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 23 Nov 2005 10:00:31 -0800

[Barr]
> >In the more general case, a trust relationship 
> >needs to be established between the server and all
> >relay agents, similar to RFC 3118 authentication,
> >for a number of reasons including (1) verified
> >identity of the server and relay agents,
> >(2) reasonably guaranteed integrity of the
> >address-identity association, and (3) reasonable 
> >prevention of spoofing and some other attacks.
> >
[Andrea] 
> We did not consider much security issues in our 
> draft. This choice was taken because we felt that
> there were bigger security problems in the general
> DHCP framework.  So, just fixing the ones related
> to our draft only would have not helped much.
> However I agree.  Security is a big concern and 
> all the suggestions  expressed above should be
> taken into serious consideration.
>
...I am aware of a few areas in which authenticated 
DHCP transactions are seen as a true business 
requirement, so revisiting 3118 and the operation of 
relay agents may be the logical next step.  When I 
wrote the above reply the potential for spoofing and 
other attacks (point 3) was in my mind.

[Barr]
> >passively, but perhaps by some mechanism to actively
> >poll the network) the existence of relay agents.  A 
> >server could then multi-cast queries to the relay
> >agents when probing to see if an address about to be
> >assigned is known to be in use, or direct specific
> >inquiries to the relay agent(s) closest to the last
> >known client holding an address lease to determine
> >if the client identity-IP address association is
> >still in use.
> >
[Andrea]
> I do not understand why multicast would be of any 
> use.  The DHCP server already knows from which Relay
> Agent a request is coming from, so it would ask to
> that Relay Agent only.  Also, I do not see the
> advantages of a query mechanism as opposed to the 
> mechanism we propose.  As we will show with some
> measurements, the load between AUC and DHCP server
> is very low.  Querying a Relay Agent (RA) per each
> DHCP transaction seems like it might actually 
> introduce more traffic than with the proposed
> approach depending on what kind of information the
> response to these queries would contain. Also, a
> duplicate or unauthorized address being in use
> would not be discovered by the DHCP server until a
> query takes place, even though the AUC/RA might
> have known for quite some time.  This might be 
> important if in the future we think of ways to
> address the problem of how to deal with 
> unauthorized users just taking an IP address they
> like.
> 
Yes, the server knows from which relay agent a 
message is received, but that is the NEAREST agent 
to the server -- only the agent nearest to the client 
(if this functionality is integrated into a router, 
for instance) would be aware of the client's use of 
an address if not assigned by a server.  Since there 
is no way for a server to have a priori information 
about where in the interconnected network segments a 
potentially rogue user of an address is located, 
multicasting a query to the known routers is a 
reasonable way to get the coverage desired.  This is 
certainly no worse than broadcasting an ICMP ECHO to 
all subnets -- recalling that many operators 
intentionally disable PINGs because of abuse 
potential, and where PINGs are permitted, a 
potentially lengthy timeout period must elapse 
before non-use can be assumed -- and may be a less 
burdensome process overall.

As Ted pointed out, this is a non-trivial 
modification to the relay agent functionality, but 
there are potential benefits:  (1) broadcast ICMP 
ECHO and reply traffic is eliminated, at least for 
DHCP, (2) ARP messages originating in a DHCP client 
probably can be eliminated as well, (3) by 
eliminating the ICMP and ARP message [exchanges] the 
total elapsed time for address lease acquisition may 
be significantly reduced, with benefits for wireless 
operators, (4) the availability of associations 
between hardware address (and possibly, client 
identification) and IP address outside of the DHCP 
server may be useful in other contexts such as 
network management and inventory or AAA and intrusion
detection.

>From the perspectives of servers and clients, the
changes are straightforward:  in place of ICMP ECHO
probing, the server queries the AUC/relay agents;  a
client simply eliminates ARP probing, trusting that
the offered address is unique because of a strong
trust relationship between DHCP servers and AUC/relay
agents.

Of course, collisions still can occur, either from
innocent use of a fixed address or with  malicious 
intent.  With the AUC/relay agent functionality 
integrated into routers (and possibly switches) it
should be possible to detect nearly all duplicates.

--Barr

---

From: Andrea G Forte <[email-masked]>
Date: Wed, 23 Nov 2005 13:58:51 -0500

[Barr]

>burdensome process overall.
[Andrea]
We know exactly from which Relay Agent/network segment the request came
from (or where a rogue user is located). Usually the DHCP server looks 
at the
'giaddr' field to tell from which Relay Agent the request is coming 
from. The
'giaddr' field contains the IP address of the Relay Agent nearest to the
*client* requesting the IP address.
 From RFC 3046:
" [...] the relay agent SHALL forward any received DHCP packet
   with a valid non-zero giaddr WITHOUT adding any relay agent options.
   Per RFC 2131, it shall also NOT modify the giaddr value. "

Also, I do not see why the AUC can't just send the information directly
to the DHCP server without involving any Relay Agent.

[Barr]

>network management and inventory or AAA and intrusion
[Andrea]
In my previous email I was trying to explain that if we think to address
problems such as intrusion detection, we should use a more responsive
mechanism than a query based one. In this case, having the AUC send
packets to the server when some condition occurs (i.e. unauthorized
IP address being used), might be better.

-Andrea

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 23 Nov 2005 20:23:41 -0800

> [Andrea]
> We know exactly from which Relay Agent/network 
> segment the request came from (or where a rogue
> user is located). Usually the DHCP server looks 
> at the 'giaddr' field to tell from which Relay
> Agent the request is coming from.  The 'giaddr'
> field contains the IP address of the Relay Agent
> nearest to the *client* requesting the IP address.
> From RFC 3046:
> " [...] the relay agent SHALL forward any 
> received DHCP packet with a valid non-zero giaddr
> WITHOUT adding any relay agent options.  Per RFC 
> 2131, it shall also NOT modify the giaddr value."
> 
> Also, I do not see why the AUC can't just send 
> the information directly to the DHCP server
> without involving any Relay Agent.
>

[Barr]
I certainly see the validity of a host performing a
single dedicated function, tracking IP addresses
actually in use along with some client identifier,
in detecting duplicate addresses in use, but as a
practical matter I believe the functionality will
be implemented in a router that also implements the
functionality of a relay agent.

At the risk of going down a giant rat hole, there is
some troubling language in RFC 3046, specifically,
"...valid non-zero giaddr...."  How is the validity
of the received giaddr validated?

I assert that the AUC would have the same problem of
being validated as a legitimate source of warnings
about potentially duplicated IP addresses.

That is only to say that my opinion is that we must 
solve the security issues first.  Of course, I will
continue to support integration of the AUC and relay
agent functionality because I believe that is a 
natural pairing.

> [Andrea]
> In my previous email I was trying to explain that 
> if we think to address problems such as intrusion
> detection, we should use a more responsive
> mechanism than a query based one.  In this case, 
> having the AUC send packets to the server when
> some condition occurs (i.e. unauthorized

[Barr]
We probably agree about more than this exchange may
indicate, but I dispute the notion that having the 
AUC send packets on each occurrence of some condition
of interest occurs would be better.  Taking the 
example of an IP address being used without having 
seen a DHCP protocol exchange could easily be 
harmless -- many hosts do not have address leases,
utilizing fixed addresses.  Typically gateways, 
servers, various managed devices, and printers do 
not use either BOOTP or DHCP.  The only way to avoid
false reports would be to provide the AUC with 
network configuration information, and as it would
of necessity be different from BOOTP/DHCP server
configuration, there is the classic problem of 
consistency with which to contend.  Additionally,
having the AUC push announcements of detected events
towards the DHCP server requires potentially a very
significant change in server operation, not just to
receive and understand the notifications, but also
to deal with the possible loss of such messages (if 
using UDP) or the loss of a connection (if using TCP.)

While I think that the functionality of the AUC may
very well be a useful tool for intrusion detection or
to supplement AAA and network management capabilities
I also assert that a growing list of network services
receiving pushed announcements could easily turn into
its own denial of service attack by a rogue host 
intentionally spoofing many different MAC addresses
and IP address associations.

So, we have a number of things to work out, from the
basic philosophy of how to better perform duplicate
address detection, to securing the mechanism, to
how the functionality might be implemented.

I'm going to be totally inaccessible for e-mail until
December 4, so don't take my lack of response during
the interim as lack of interest or acquiescing to your
well-mounted arguments.

--Barr