[secdir] draft-ietf-6lowpan-nd-18.txt SECDIR Review
Donald Eastlake <d3e3e3@gmail.com> Tue, 03 January 2012 02:22 UTC
Return-Path: <d3e3e3@gmail.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 523F521F8516; Mon, 2 Jan 2012 18:22:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.181
X-Spam-Level:
X-Spam-Status: No, score=-104.181 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 Dqr9fnbV50EB; Mon, 2 Jan 2012 18:22:08 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4879221F8484; Mon, 2 Jan 2012 18:22:08 -0800 (PST)
Received: by laah2 with SMTP id h2so6650091laa.31 for <multiple recipients>; Mon, 02 Jan 2012 18:22:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=IQvnxZ0XgODSKWDWOLhwoJuXch0YyYOnG6jzDXiM/ms=; b=MoEzxSb31UUQC4mC1sWNVwAW+i2LXay5g521QIPrf8l1F4buUkWCVFzLZgHLapuwyJ 4TnBikfw+dSVUddDlzTbFqG72pZyNWmVQMAgR4yEyKZTraUf+6d8wOoBMDwkR7nqxGnH AuALNi94yLrodNcnjphPDmcjRE/QdB585bQ3E=
Received: by 10.152.128.196 with SMTP id nq4mr42814850lab.35.1325557327272; Mon, 02 Jan 2012 18:22:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.112.99 with HTTP; Mon, 2 Jan 2012 18:21:46 -0800 (PST)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 02 Jan 2012 21:21:46 -0500
Message-ID: <CAF4+nEGOc03tz6LiV6g1Xqx7HfHdKpPdLgxU-UBJzYcGEanfbw@mail.gmail.com>
To: draft-ietf-6lowpan-nd.all@tools.ietf.org, iesg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: secdir@ietf.org
Subject: [secdir] draft-ietf-6lowpan-nd-18.txt SECDIR Review
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: Tue, 03 Jan 2012 02:22:09 -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. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes optimizations to IPv6 neighbor discovery (ND) for low-power lossy networks, such a IEEE 802.15.4, that limit or do not support multicast and may have other network differences. It makes 8 extensions to IPv6 Neighbor Discovery. SECURITY CONSIDERATIONS: Although this is a fairly extensive and complex specification, the Security Considerations appear to be adequate. The Security Considerations depend heavily on the assumption of lower level security of the link layer that prevents tampering with or replaying the messages involved. Versions are created of some ND address messages which are no longer restricted to one hop by a hop-count test but these versions are not permitted except where explicitly configured and are not allowed to change Neighbor Address Caches. These assumptions and mechanisms appear to be sufficient. Finally, the Security Considerations section suggest future investigation of the use of Secure Neighbor Discover (SEND). POSSIBLE Security Considerations: Section 4.3: There seems to be no discussion of how rapidly the Version Number could change and whether there is any risk of it incrementing >8K while some cached value was not updated resulting in sequence number arithmetic confusion. Section 7.2 on Context Configuration and Management does not indicate what the consequences of improper management might be. MINOR: I found the first sentence of Section 1.5 to be hard to understand and of slightly questionable grammar. In Section 3.3, should "A host retransmits the Address Registration option until it is acknowledged by the receipt of a Address Registration option." be augmented by adding "with zero Statius" at the end. In Section 4.1, page 17: "... amount of time in a unit of 60 seconds that ..." is peculiar wording. Does it mean "... amount of time in units of 60 seconds that ..." (which might better be "... amount of time in units of a minute that ...")? Or does it mean "... amount of time as a fraction of the unit of 60 seconds, with the decimal point just before the first bit of the field, that ..."? - ditto Section 4.2, page 18. - ditto Section 4.4, page 21. == OK, now that I've read the rest of the document, I guess these 16-bit fields are supposed to max out at ~18 hours. That seems to imply that it is really "... amount of time in units of 1 second that ...", something I would never have guessed from the original wording. In Section 4.3, for "... sequence number arithmetic ..." suggest adding a reference to [RFC1982] which is already including in the normative references. In Section 4.4, for first occurrence of "ip-over-foo", suggest adding an Informative reference to [RFC3092]. TYPO: Replace "an Neighbor" with "a Neighbor" globally. Section 10.3.2: "the its" -> "its" Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com
- [secdir] draft-ietf-6lowpan-nd-18.txt SECDIR Revi… Donald Eastlake