[secdir] secdir review of draft-ietf-dhc-subnet-alloc-12.txt

[Alexey Melnikov <[e-mail]>]

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?