Re: [secdir] SECDIR review of draft-ietf-dhc-dhcpv6-unknown-msg-05

Qi Sun <sunqi@csnet1.cs.tsinghua.edu.cn> Wed, 05 March 2014 09:28 UTC

Return-Path: <sunqi@csnet1.cs.tsinghua.edu.cn>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584F61A0391; Wed, 5 Mar 2014 01:28:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.793
X-Spam-Level: *
X-Spam-Status: No, score=1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH4nYrApIE-b; Wed, 5 Mar 2014 01:28:34 -0800 (PST)
Received: from mail.csnet1.cs.tsinghua.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4089F1A0392; Wed, 5 Mar 2014 01:28:24 -0800 (PST)
Received: from dhcp-a315.meeting.ietf.org (dhcp-a315.meeting.ietf.org [31.133.163.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.csnet1.cs.tsinghua.edu.cn (Tsinghua University (Postfix)) with ESMTPSA id C73C114983BB; Wed, 5 Mar 2014 17:03:53 +0800 (CST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary="Apple-Mail-31--907336436"
From: Qi Sun <sunqi@csnet1.cs.tsinghua.edu.cn>
In-Reply-To: <3605A730-DFCA-4A9B-9A30-7FAE4A938CBA@gmail.com>
Date: Wed, 05 Mar 2014 09:28:11 +0000
Message-Id: <0072CD75-BCD2-4759-A28E-92481E6D50D8@csnet1.cs.tsinghua.edu.cn>
References: <alpine.LRH.2.00.1403031101470.22583@sjc-xdm-112.cisco.com> <3605A730-DFCA-4A9B-9A30-7FAE4A938CBA@gmail.com>
To: Chris Lonvick <clonvick@cisco.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Sz35PPOILvIixE4w7meIjvTtunE
X-Mailman-Approved-At: Wed, 05 Mar 2014 08:06:57 -0800
Cc: draft-ietf-dhc-dhcpv6-unknown-msg.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] SECDIR review of draft-ietf-dhc-dhcpv6-unknown-msg-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 05 Mar 2014 09:28:38 -0000


Dear Chris,

Many thanks for your comments! 

About the Security Considerations section, how about we add the following clarification:

OLD:
6.  Security Considerations

  As the relay agent will forward all unknown types of DHCPv6 messages,
  a malicious attacker can interfere with the relaying function by
  constructing fake DHCPv6 messages with arbitrary type code.  The same
  problem may happen in current DHCPv4 and DHCPv6 practice where the
  attacker constructs the fake DHCP message with a known type code.
  ...

NEW:
6.  Security Considerations

  This document creates no new security issues that are not already
  present in RFC3315.  By explicitly documenting the correct handling
  of unknown messages, this document, if implemented, reduces any
  security exposure that might result from incorrect handling of
  unknown messages.  The following issues are issues that could already
  be present with section 23 of [RFC3315], but we discuss them in
  detail here as guidance for implementors.

  As the relay agent will forward all unknown types of DHCPv6 messages,
  a malicious attacker can interfere with the relaying function by
  constructing fake DHCPv6 messages with arbitrary type code.  The same
  problem may happen in current DHCPv4 and DHCPv6 practice where the
  attacker constructs the fake DHCP message with a known type code.
  ...

Would that be OK? 

Best Regards,
Qi
//Sorry if you received duplicate mails.



On 2014-3-3, at 下午7:07, Chris Lonvick wrote:


> Hi,
> 
> 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 document looks to be well thought out and almost complete.  I would like to see a statement in the Security Considerations section that this specification adheres to the Security Considerations section of RFC 3315, and augments it by describing the disposition of unknown messages.
> 
> Other than that, the only very minor nit that I have is that the second and third paragraphs of the Security Considerations section are a single thought and should be combined.
> 
> Thanks,
> Chris
>