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

From: Andrea G Forte <[email-masked]>
Date: Mon, 05 Dec 2005 12:59:38 -0500

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

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

>  
>
>>[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
assignement process, introduces unecessary 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.

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.

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.

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

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

Thank you for all of your comments. This exchange of ideas is making all 
of this much
more interesting.

-Andrea

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

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