Document: draft-ietf-dhc-server-mib-10
Reviewer: Spencer Dawkins
Date: March 29, 2004

  * This draft is basically ready for publication as a Proposed Standard, but has (very minor) nits that should be fixed before publication. 
--------------------------------

     3.2. Textual Conventions Introduced in this MIB 

        One conceptual data type has been introduced in this document.  No 
        changes to the SMI or SNMP are necessary to support this convention. 

Spencer: (from the "needle in a haystack" department - which data type was it?)

     3.2.1. Dhcpv4PhysicalAddress 

        This data type contains the type of hardware address represented by 
        MacAddress, as defined for ARP messages, the length in octets of 

Spencer: "as defined for ARP messages" where?

        MacAddress, and the actual layer 1 hardware address. 


     3.3. BOOTP and DHCP Counter Groups 

Spencer: the guidance about computed values in this section is very much appreciated...

        This section describes some of the management information that can 
        be derived from the objects provided in the counter groups. 

     3.3.1.  Discontinuities 

Spencer: Isn't this a generic concern that has nothing to do with DHCP?
But it certainly looks like the common thread from the three scenarios is
"tough luck, and you may not even detect a discontinuity"...     

     8. Security Considerations 

        Some of the readable objects in this MIB module (i.e., objects with 
        a MAX-ACCESS other than not-accessible) may be considered sensitive 
        or vulnerable in some network environments.  It is thus important to 
        control even GET and/or NOTIFY access to these objects and possibly 
        to even encrypt the values of these objects when sending them over 
        the network via SNMP.  These are the tables and objects and their 
        sensitivity/vulnerability: 

          o  dhcpv4ServerRangeTable 

          o  dhcpv4ServerClientTable 

        These two objects, in conjunction, provide an observer with a 
        current view of the available and assigned addresses allocated by 
        this server.  Such knowledge can be used to manually configure a 
        host computer with a valid IPv4 address for the network managed by 
        the DHCP server.  This could be part of either a Theft of Service 
        scheme or a Denial of Service attack wherein rogue (pseudo-)hosts 
        simply claim and defend IPv4 addresses either to subvert accounting 
        for their use or to disrupt the network for legitimate hosts. 

        It is thus important to control even GET access to these objects and 
        possibly to even encrypt the values of these objects when sending 
        them over the network via SNMP.  Not all versions of SNMP provide 
        features for such a secure environment. 

Spencer: This seems slightly excessive to me - if I understand the point,
seems like the rogue nodes could do pretty much the same thing, less neatly,
without access to these values (claim and defend IPv4 addresses whether you
read them out of the DHCP table or just listened to DHCP for a few minutes
and started guessing). Security would not be wrong, but doesn't seem like
it would solve lots of problems once and for all... a similar point appears
later in the same section, as

        Denial of Service attacks on a DHCP server are conceivable by 
        flooding the SNMP (sub-)agent with requests, tying up host system 
        and server resources processing SNMP messages.  The authors know of 
        no way to wholly prevent such attacks, but have attempted to 
        construct relatively simple tables to minimize the work required to 
        respond to messages. 


     9. References 

        One normative reference is currently an Internet-Draft, nearly ready 
        for Working Group Last Call.  This reference MUST be updated when 
        the draft advances to RFC status. 

Spencer: "oh, noooooo...."