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

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 5 Jan 2006 15:43:03 -0800

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

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

---

From: "Andrea G. Forte" <[email-masked]>
Date: Tue, 10 Jan 2006 14:35:43 -0500

>sorry to have taken so long to reply to you, Andrea....
Gald to see you are back Barr. Hope you had a good Xmas and new year.
As usual, comments are inline.

-Andrea

>does work pretty well for you in a relay agent.
[Andrea]
Sorry about the confusion. Yes, we both agree that an AUC can be easily 
integrated in
a Relay Agent (RA) and that this is the most natural place for it.
What I was trying to say in a rather confusing way is that the messages 
that the AUC sends to the
DHCP server do not have to necessarely follow the same rules than normal 
RA messages
have to follow. In particular, AUC messages can be directly sent to the 
server without having
to go through other RAs (no relay necessary).

>why we really do need to address general DHCP security soon.
[Andrea]
Well, this is an issue that is already present today without any AUC. 
Infact all you need
to do as a malicious user is to answer to any ICMP echo request when the 
DAD procedure
is performed. This will cause DoS for that particular subnet as the 
server will wrongly think that all
the possible IPs are in use.
I still think that the AUC is not adding any extra vulnerability. They 
are all already there.
Once the problem of general DHCP security will be solved, AUC issues 
will automatically be
solved as well.

>during the offer process if its usage information is missing
[Andrea]
Yes, but then you might miss IPs that have been "taken" in between 
updates (in between polls) and this
might cause duplicate address. One solution to this would be to make the 
lifetime of the collected data
very short, this however would introduce too much overhead and would 
significantly degrade the performance of the
query mechanism that would then loose its purpose.

>be the way to secure that path.
[Andrea]
We seem to agree here. This would also take care of rogue AUCs/RAs.

>addressed about DHCP security and authentication.
[Andrea]
I do not know the details about this kind of devices and how the DHCP server
behaves with them. However, I would think that there has to be some kind 
of Client
ID for such devices ( I am thinking about draft 3315id).

>>>how the functionality might be implemented.
Yes, agree.

Thanks again,
-Andrea

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 11 Jan 2006 10:51:23 -0800

Andrea--

this is the most stimulating tech exchange I've had in a
while:  it's forcing me to consider a number of different
issues that we've let slide because no one has a great
proposal for how to simply administer the identification and
authentication of DHCP servers, relay agents, and clients.

I've trimmed the original message text a bit to keep this
from growing totally out of hand.

--Barr

> From: Andrea G. Forte
> Sent: Tuesday, January 10, 2006 11:36
>
*Snip!*
> >administration, but as you've noted below, the
> functionality does work pretty well for you in a relay
> >agent.
> >
> [Andrea]
> Sorry about the confusion. Yes, we both agree that an
> AUC can be easily integrated in a Relay Agent (RA) and
> that this is the most natural place for it.
> What I was trying to say in a rather confusing way is
> that the messages that the AUC sends to the DHCP server
> do not have to necessarily follow the same rules that
> normal RA messages have to follow. In particular, AUC
> messages can be directly sent to the server without
> having to go through other RAs (no relay necessary).
>
[Barr]
I'm glad you clarified that.  Your point about possibly
using a TCP session between the DHCP server and the
AUC/relay agent implied as much, and I was never at all
clear that message exchanges between the two are [in the
steady state] between hosts with known IP addresses.

> >>infrastructure.

*Snip!*

*Snip!*

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

*Snip!*

*Snip!*

> Once the problem of general DHCP security will
> be solved, AUC issues will automatically be
> solved as well.
>
[Barr]
Agreed.  We absolutely need to revisit the RFC3118 issues
that were raised about two years ago and see whether or not
there is a way out of the quagmire imposed by the base
assumptions that some external authority is always acting to
configure client and server authentication.

I've some ideas, but each of them has corresponding flaws
such that I'm not sure any of them are workable.

> >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.
> >
> [Andrea]
> Yes, but then you might miss IPs that have been "taken"
> in between updates (in between polls) and this might
> cause duplicate address.  One solution to this would be
> to make the lifetime of the collected data very short,
> this however would introduce too much overhead and would
> significantly degrade the performance of the query
> mechanism that would then lose its purpose.
>
[Barr]
Choice of a strategy requires more discussion, but what I'm
suggesting is similar to the way that DNS operates, with the
TTL of query results essentially variable depending on
considerations not part of the actual message exchange.

Essentially, your proposal for a DAD function that is
[largely] separate from IP address assignment is a
well-considered attempt to improve the performance of DHCP
in a world where we are increasingly demanding instantaneous
connectivity for highly mobile devices.  Recall, however,
the original duplicate address detection methods employed in
DHCPv4 are only "best effort" procedures, relying on
essentially unreliable mechanisms (ICMP ECHO and ARP.)

When I think about the impact of a malicious host saying,
"Yes, that IP address is in use," to each and every ARP
request it almost seems as if we are fighting a lost cause.
While I suppose that a smart switch with DAD features might
notice that a single host [switch port] is claiming multiple
identities within an interval too short for legitimate
address assignment and shut off the port connected to the
offending host, at first thought such a mechanism would
require a stateful switch that listens to and is mindful of
address assignment messages and other traffic.

> >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.
> >
> [Andrea]
[Barr]
So, let me attempt a summary:  we concur that using a TCP
session between hosts that are generators and consumers of
DAD information is probably the way to go.

> >>general problem.

*Snip!*

> I do not know the details about these kind of devices and
> how the DHCP server behaves with them.  However, I would
> think that there has to be some kind of Client ID for
> such devices (I am thinking about draft 3315id).
>
[Barr]
yes, the discussion came up in the context of 3315-syle IDs,
but I'm not yet sure that we've got a handle on the entire
NIC/media problem.  Although only a small number of the
defined media types (HTYPE field) are actually in use, we
MUST NOT be fixed on an Ethernet-centric world.  At the very
least, we've got FireWire, USB, "Space" Ethernet, and
possibly HDMI with which to contend.

I'll assert right now that the explosion in consumer devices
with networking capabilities will definitely impact any
procedures we devise for duplicate address detection and
mitigation, if simply because we can expect collisions
between media implementations of different eras.