Skip to main content

Last Call Review of draft-ietf-dhc-subnet-alloc-
review-ietf-dhc-subnet-alloc-secdir-lc-melnikov-2011-06-23-00

Request Review of draft-ietf-dhc-subnet-alloc
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-06-21
Requested 2011-06-17
Authors Richard A. Johnson , Kim Kinnear , Mark Stapp
I-D last updated 2011-06-23
Completed reviews Secdir Last Call review of -?? by Alexey Melnikov
Assignment Reviewer Alexey Melnikov
State Completed
Request Last Call review on draft-ietf-dhc-subnet-alloc by Security Area Directorate Assigned
Completed 2011-06-23
review-ietf-dhc-subnet-alloc-secdir-lc-melnikov-2011-06-23-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This I-D details a new DHCP option to request dynamic allocation of a


subnet, give specifications of subnet(s) allocated, and report 


allocation usage statistics.






The Security reference points to RFC 2131 and RFC 3118. I think this 


adequately describes denial of service due to a rogue delegating router 


advertising bogus prefixes, as well as denial of service due to a 


malicious DHCP client masquerade as a legitimate client and claiming all 


resources to itself. RFC 3118 says that it can be used in combination 


with this option to provide some level of mutual DHCP server and client 


authentication and thus addresses threats mentioned above, although it 


has its limitations. (However I am not a DHCP expert and haven't studied 


RFC 3118 in details.) I can't think of any other threats not described 


in the Security Considerations section.





Other issues I found in the document:

Major:

3.3.  Subnet-Name Suboption format

   The Subnet-Name suboption may be used in order to pass a subnet name
   to the server for use during allocation.  This name may be used for
   any purpose but is intended to tell the server something extra about
   the needed subnet; for example, "sales department", "customer 1002",
   "address pool FOO", or some such.  The "name" should NOT be NULL
   terminated since the "len" field already specifies the length of the
   name.  The "Name" in this suboption is simply a number of octets and
   need not be ASCII text.



The last sentence: if it doesn't need to be ASCII you need to specify 


whether it is a textual string or a binary string. In the former case 


you also need to specify which character set is used in this field. 


Ideally it should be UTF-8 [RFC3629].





Minor:



It would be good to describe upfront that this option is only specified 


for IPv4 and not for IPv6.





3.2.  Subnet-Information Suboption format

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |       2       |     Len       | Flags     :c:s| SP1, SP2, ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Len   = Length of the sub-option (min. length of 8) (1 octet)
   Flags = Various flags which apply to ALL Subnet Prefix
           Information fields specified in this suboption.
           Unused flags must be zero.

Are unused flags ignored by a recipient if non zero?

(Similar question regarding Section 3.1)

3.2.1.  Subnet Prefix Information block format

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Network                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Prefix     |     Flags |h|d|   Stat-len    |  Optional stats...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Addr   = IPv4 network number (4 octets)

Did you mean "Network"? There is no "Addr" in the table above.

3.2.1.1.  Subnet Usage Statistics

   Fewer fields may be included than what is specified in any current
   RFC, but all fields which are included MUST remain in order specifed
   here.



Can you elaborate on what this mean? Does it mean only including 1 or 2 


of the specified fields?