[secdir] secdir review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03

"ietfdbh" <ietfdbh@comcast.net> Sat, 31 August 2013 15:46 UTC

Return-Path: <ietfdbh@comcast.net>
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 8861D21F9B18 for <secdir@ietfa.amsl.com>; Sat, 31 Aug 2013 08:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.437
X-Spam-Level:
X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8fW5gI2+Qhh for <secdir@ietfa.amsl.com>; Sat, 31 Aug 2013 08:46:01 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC0A21F99DD for <secdir@ietf.org>; Sat, 31 Aug 2013 08:46:01 -0700 (PDT)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta06.westchester.pa.mail.comcast.net with comcast id KSEp1m0011YDfWL56Tm1SQ; Sat, 31 Aug 2013 15:46:01 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta20.westchester.pa.mail.comcast.net with comcast id KTm01m00b2yZEBF3gTm0G1; Sat, 31 Aug 2013 15:46:01 +0000
From: ietfdbh <ietfdbh@comcast.net>
To: secdir@ietf.org, draft-ietf-dhc-dhcpv6-solmaxrt-update@tools.ietf.org, iesg@ietf.org
Date: Sat, 31 Aug 2013 11:46:00 -0400
Message-ID: <017901cea661$313309b0$93991d10$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac6mXFvpdp2QCrMlQbuC7It9OmMcYg==
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377963961; bh=7ULXZdzbiBbRwEWcv+1q/CWMKDONH/QZluwdnIhUQjo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=mSgyrSG3wA/ASH4ivs2rwPbPpFF1K+Do2tOMCoW5Z64ZgJWrMtcsmd76Cb+h7gPSL pmCZmX9odX4aD1A6RoVG0+Ccl9kq0UBT9FHiEJ9wJw75arPGSg/wHtPNc71XSU60C9 fzhv96IhcPs3qlEXZicPdwLPIs0SZNwOJkffFTBpOfl4uuhxPQScmvL2CedImzmq1f IvoWmRRjHDP+MBVqzEeC3pnGME0zW0p9pe8W2DS3U2Ufyk/yfeKURK9XeHD3FsNztB kJi1J95eKWIa8oPCh1yeDLjxlELU2kwdJ7/Xs6lvNwIfYoVVkl0defDl2RXR+xB8SH GK3ke6lDr7cTA==
Subject: [secdir] secdir review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03
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: Sat, 31 Aug 2013 15:46:07 -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.

The document describes a change to the values of DHCPv6 Options for Solicit
and Information timeout values (SOL_MAX_RT and INF_MAX_RT).

I am not very knowledgeable about DHCPv6 options, but I have a few
questions.
1) section 6 says " the client MUST process an included SOL_MAX_RT option
and/or an included INF_MAX_RT option"; this could be interpreted as OR even
if both are present. Hopefully no implementer would make that choice, but
they could claim compliance if they did. 
It would be tighter to say they MUST process SOL-MAX-RT and MUST process
INF_MAX_RT ...
2) section 7 says " A DHCPv6 client MUST include the SOL_MAX_RT option code
in an Option Request option [RFC3315] in any message it sends."  Is this
really required for every message?
3) if #2 is true, then section 8 seems to have some unnecessary
conditionals. "the server will send option SOL_MAX_RT and INF_MAX_RT only if
.... the client requested those options ...". Doesn't section 7 say the
client is REQUIRED to request these options?
4) similar to question #3, in section 8 paragraph 2, the server responds to
" a client that has included the SOL_MAX_RT option code in  an Option
Request option"; doesn't section 7 REQUIRE that the client include this?
Ditto for paragraph 3 and INF_MAX_RT?
5) In security considerations, the potential security **impact** of a
malicious server setting a high value isn't discussed.
6) On a related note to #5, are there operational considerations if a DHCPv6
server choose to set an arbitrarily high value? Could there be economic
benefit for a server to do this, leading some requesters to use a different
server either for load-balancing or servicing only priority customers? What
impact could such behavior create in a network that an operator should
consider?
7) In IANA considerations, you define OPTION_SOL_MAX_RT and
OPTION_INF_MAX_RT, but discussion of sending these options in sections 7 and
8 don't mention these codes; they refer only to SOL_MAX_RT and SOL_MAX_RT. I
don't know much about registering DHCP options; is this correct?

David Harrington
ietfdbh@comcast.net
+1-603-828-1401