Re: [secdir] secdir review of draft-ietf-ntp-dhcpv6-ntp-opt-04.txt

"Benoit Lourdelet (blourdel)" <blourdel@cisco.com> Fri, 18 September 2009 09:26 UTC

Return-Path: <blourdel@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF2B3A698A; Fri, 18 Sep 2009 02:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2QUwYrpZatn; Fri, 18 Sep 2009 02:26:17 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2E8543A696D; Fri, 18 Sep 2009 02:26:17 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlcAAE3vskqQ/uCLe2dsb2JhbACbIgEBFiQGnxWIUAErCI92BYJBCIFTgV0
X-IronPort-AV: E=Sophos;i="4.44,408,1249257600"; d="scan'208";a="49686832"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2009 09:27:09 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8I9R9Xj022734; Fri, 18 Sep 2009 11:27:09 +0200
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8I9R9oQ008021; Fri, 18 Sep 2009 09:27:09 GMT
Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Sep 2009 11:27:09 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 18 Sep 2009 11:27:09 +0200
Message-ID: <877805C876DB9243984870AAD14107624B4E55@XMB-AMS-103.cisco.com>
In-Reply-To: <016001ca252c$25904100$70b0c300$@net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: secdir review of draft-ietf-ntp-dhcpv6-ntp-opt-04.txt
Thread-Index: AcolLCTTApFFO1pSRNWe+MFZxKd61gSif6mg
References: <016001ca252c$25904100$70b0c300$@net>
From: "Benoit Lourdelet (blourdel)" <blourdel@cisco.com>
To: "Glen Zorn" <gwz@net-zen.net>, <iesg@ietf.org>, <secdir@ietf.org>, <richard.gayraud@free.fr>, "Brian Haberman" <brian@innovationslab.net>, "Karen O'Donoghue" <kodonog@pobox.com>
X-OriginalArrivalTime: 18 Sep 2009 09:27:09.0468 (UTC) FILETIME=[3232FDC0:01CA3842]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4901; t=1253266029; x=1254130029; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=blourdel@cisco.com; z=From:=20=22Benoit=20Lourdelet=20(blourdel)=22=20<blourdel@ cisco.com> |Subject:=20RE=3A=20secdir=20review=20of=20draft-ietf-ntp-d hcpv6-ntp-opt-04.txt |Sender:=20; bh=Fz3o/IONw/68qv6r1nC2NORHKosW9fr1jHLzTNCE87M=; b=Ec8IIkdejSR8Ht8IOQwhzdbWyssS4Udm68FQS7wsOGjAByPmZkMrZXEH8f IRE8BrD80LpV+AHXDDWkBnCw01iZpq6y2iASmZXBXIi1j29ovwmrrbie2ZGW fGMB8ZjTl1;
Authentication-Results: ams-dkim-2; header.From=blourdel@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
X-Mailman-Approved-At: Fri, 18 Sep 2009 06:39:40 -0700
Subject: Re: [secdir] secdir review of draft-ietf-ntp-dhcpv6-ntp-opt-04.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 18 Sep 2009 09:26:19 -0000

Hello,

The comments that require discussion are signaled by BL>>

The rest of the comments are taken into account.

Benoit

-----Original Message-----
From: Glen Zorn [mailto:gwz@net-zen.net] 
Sent: Tuesday, August 25, 2009 4:31 AM
To: iesg@ietf.org; secdir@ietf.org; Benoit Lourdelet (blourdel);
richard.gayraud@free.fr; 'Brian Haberman'; 'Karen O'Donoghue'
Subject: secdir review of draft-ietf-ntp-dhcpv6-ntp-opt-04.txt

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.



EDITORIAL

Global: s/an NTP/a NTP/
        s/an FQDN/a FQDN/


In section 2., the acronym "DHCPv6" should be expanded on first usage.

The first paragraph of section 2.1 says:

   When using DHCPv6 to offer NTP Server location, and if
   there is a need to distribute a device with a hardcoded
   configuration, this configuration MUST NOT include server location
   that is not part of the organization that distribute this device.

s/distribute/distributes in the last line.
I don't understand what device is under discussion.  Is it a DHCP
server?  A
DHCP client?  Also,

   Typical usage of this option is to specify an NTP Server that is part
   of the organization that operates the DHCPv6 server.

This seems less clear than it should be to me; suggest rephrasing,
perhaps
as 

  This option will typically be used by the organization operating the
DHCPv6 
  server to provide data regarding the location of its own NTP server.
BL>> that is the point. The  suggested usage is to have the DHCPv6
server and the NTP server pointed to in the same organization.
This to prevent overloading public servers.


The second paragraph of section 2.1 says:

   DNS can be used to redirect misconfigured clients
   to an unexisting IPv6 address instead of having to change the address
   of the NTP server itself.

I don't know exactly what an "unexisting IPv6 address" is, nor why it
would
be a good thing to redirect misconfigured clients to one.  Also, the
acronym
"FQDN" should be expanded on first usage.
BL>> The idea is to blackhole malicious traffic.


The third paragraph of section 2.1 says: "The DHCPv6 option for NTP is
then
restricted to server location."  This construction is a little bit
clumsy, I
think; suggest changing to "The DHCPv6 option for NTP is therefore
restricted to server location."


In the first paragraph of section 3.0, the acronym "SNTP" should be
expanded
upon first usage; suggest changing "This option serves as a container
for
all the information related to one NTP server or SNTP server." to "This
option serves as a container for all the information related to one NTP
or
Simple Network Time Protocol (SNTP) [RFC4335] server."  This will also
take
care of one of the unused references mentioned below.

BL>> RFC4330 instead.

The second paragraph of section 3.0 says:

   While the FQDN option offers the most deployment
   flexibility, resiliency as well as security, the IP address options
   are defined to cover cases where a dependancy to DNS is not
   desirable.

I think that the readability of this sentence could be improved; suggest
changing to 

   While the FQDN option offers the most deployment Flexibility and 
   resiliency as well as security, the IP address options are defined 
   to cover cases where a DNS dependency is not desirable.


The last paragraph of section 3.0 says:

   This document does not define any priority between the client's
   embedded configuration and the NTP servers or SNTP servers discovered
   via this option.  

Suggest changing to 

   This document does not define any priority relationship between the
client's
   embedded configuration (if any) and the NTP or SNTP servers
discovered
   via this option.  


In the heading of section 4, capitalize "use" or just change the heading
from "Examples of use" to "Examples".


Section 4 seems somewhat less than useful to me, especially since the
examples are inconsistent: the FQDN example uses the exact encoding of
the
FQDN, but the unicast and multicast address examples do not.  I suggest
either making the examples consistent by putting the actual address
encoding
of the addresses in the address examples or just getting rid of section
4
altogether.

BL>> If that works for everybody I remove the example section for now.

The references to RFC 4075 and RFC 4330 are defined but never used.

BL>> RFC4330 is no in use. RFC4075 is in use in the new version of the
ID that explain its relation to RFC4075.

Hope this helps.

~gwz