RE: draft-forte-dhc-passive-dad-00.txt - client ID support

sorry to have taken so long to reply to you, Andrea....

comments are in-line....

--Barr

> -----Original Message-----
> From: Andrea G Forte
> Sent: Monday, December 05, 2005 10:00
>
> >>[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.
> >>
>
...I really am biased against adding another server to be
administered, especially another physical server (network
host.)  Obviously, combining the functions in another,
existing device on the network still requires
administration, but as you've noted below, the functionality
does work pretty well for you in a 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.
> >
> [Andrea]
> Yes I agree, as was pointed out in the draft, the
> natural place for the AUC would be on a router
> and in particular on a relay agent.  In our current
> implementation the AUC is part of the relay agent.
> In any event this does not prevent the AUC from
> talking directly to the DHCP server.
>
...no matter how or where the proposed functionality is
placed, there will be either protocol changes or a new
protocol.  As I think about this, your position that solving
the general problem of DHCP security is certainly one of the
fundamental issues the WG needs to address, but until we
have made some progress on DHCP security, including a
revisit to authentication, I'd rather not add a new protocol
for the servers to process, nor increase message traffic
during address assignment.  Does this mean I'm interested in
stepping up to the plate again to work on these issues?
Yes, definitely.

> >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]
> I think this is a bigger issue. The problem is
> not to secure the AUC, but to secure the whole DHCP
> infrastructure. The AUC does not introduce any new
> vulnerability by itself. The vulnerabilities that are
> present are there because of everything else not
> being secure.
>
...well, yes and no...  a rogue relay agent can no more
easily be detected than a rogue AUC, but because the relay
agent is so simple in function, it's pretty hard to design a
very effective network attack using one (ignoring the
obvious case of connecting a spurious network segment.)  A
rogue AUC could have a much more widespread impact on the
network.

> >>[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.
> >>
> >
> >[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.)
> >
> [Andrea]
> False positives sent by the AUC are not that
> critical. The AUC just sends a warning to the DHCP
> server saying "I am detecting something potentially
> irregular", the DHCP server then takes a decision
> based on the AUC reports and on its lease/
> configuration file. The DHCP server will be aware
> of static IPs used in the IP pool it manages
> (printers, servers, etc). One of the thing to worry
> about might be the extra traffic between the AUC
> and the DHCP server due to false positives. This
> traffic however would be very small and it would
> occur only at the AUC's table expiration time.
> Furthermore, false positives triggered by the AUC
> could easily be corrected by the DHCP server. When
> a false positive is detected by the DHCP server,
> then the server could send a packet to the AUC
> to inform it to ignore a particular IP address for
> a longer time, that is, the AUC would set a longer
> expiration time for that address in its table.
> Overhead for a query-based mechanism and pushing
> mechanism would be about the same. However, the
> pushing mechanism would be more responsive and
> also it would inform the DHCP server about
> addresses in use "out of band" and not during the
> address acquisition process. Performing this kind
> of task *during* the assignment process
> introduces unnecessary delay, as small as it might
> be. This is particularly critical in mobile
> environments where clients need to acquire a new
> IP as fast as possible.
>
...I very much disagree about the effect of false positives.
My biggest concern is the potential for a denial of service
attack from a rogue AUC that simply tells the DHCP server
(and any other device that is listening to the potential
conflict reports that EVERY MAC address in use on a network
segment is a duplicate.  Because of load-balancing and
failover, that attack could quickly spread to multiple
servers and then the entire network.  Yet another example of
why we really do need to address general DHCP security soon.

If we did have a secure DHCP protocol, with detection and
authentication of not just clients, but also relay agents
and AUCs, then I don't think there is that much difference
in the performance of push vs. pull strategies.  True,
querying an AUC during the address assignment process can
slow it, but unlike issuing an ICMP ECHO and waiting for
timeout, the DHCP server could invoke a strategy that polled
the AUCs periodically when the server is idle, set a
lifetime for the data collected, and only query the AUC
during the offer process if its usage information is missing
or out of date.

On the other hand, an implementation of the two-message
protocol exchange would presumably not wish to wait for any
sort of PING or ARP response, so having the AUC push
potential conflicts to the server would be extremely useful.

After rattling on this afternoon responding to you, I think
that we've got several areas to discuss at length before
settling on any solution.

> Either model is reasonable, I guess, it depends
> on how much logic we want to put on the AUC and
> how much we want to add to the DHCP server.
> There is a tradeoff between performances and
> implementation and we need to decide which one
> would make more sense.
>
> Having a secure TPC connection between AUC and
> DHCP server is something quite useful in terms
> of both security and packet loss.
>
...your point is well-taken, and it raises for me the
possibility of reexamining the operation of relay agents:  a
TCP connection between DHCP servers and relay agents might
be the way to secure that path.

> At this stage, we wanted to consider the AUC for
> DAD purposes and not really for intrusion
> detection. Intrusion detection introduces a
> whole new set of problems. It would be very
> interesting though to see how the present
> mechanism might be extended for intrusion
> detection. All I am saying is that we should
> probably go one step at the time.
>
...yes, I am just observing that DAD and ID are very similar
in this specific context, that of gaining network
connectivity.

> >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.
> >
> [Andrea]
> In my opinion, the case of MAC spoofing is a more
> general problem. In such a case we would have to worry
> about bigger possible damage like the exhaustion of
> the IP pool which would also last past the attack
> until the leases expire.
>
...as Ted pointed out at the last WG meeting, there are
several different types of media where we cannot expect a
MAC address, so we have one more general problem to be
addressed about DHCP security and authentication.

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

*Snip!*

> Thank you for all of your comments. This exchange
> of ideas is making all of this much more interesting.
>
> -Andrea
>
...definitely exercising my grey matter a bit!

--Barr