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

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 20 June 2011 21:38 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481AF11E8207; Mon, 20 Jun 2011 14:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.274
X-Spam-Level:
X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggXvugGTd7qN; Mon, 20 Jun 2011 14:38:48 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 604AD11E80C5; Mon, 20 Jun 2011 14:38:48 -0700 (PDT)
Received: from [188.28.254.65] (188.28.254.65.threembb.co.uk [188.28.254.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <Tf-95QA-uS-=@rufus.isode.com>; Mon, 20 Jun 2011 22:38:46 +0100
Message-ID: <4DFFBD93.3090709@isode.com>
Date: Mon, 20 Jun 2011 22:37:23 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dhc-subnet-alloc.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [secdir] secdir review of draft-ietf-dhc-subnet-alloc-12.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jun 2011 21:38:49 -0000

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?