Gen-ART LC Review of draft-kelsey-intarea-mesh-link-establishment-05

Ben Campbell <ben@nostrum.com> Mon, 16 September 2013 21:54 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EF811E81CC; Mon, 16 Sep 2013 14:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.484
X-Spam-Level:
X-Spam-Status: No, score=-101.484 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_00=-2.599, MANGLED_LIST=2.3, SPF_PASS=-0.001, 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 6G5IeFcef9ql; Mon, 16 Sep 2013 14:54:29 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E029E11E81C8; Mon, 16 Sep 2013 14:54:28 -0700 (PDT)
Received: from [172.20.10.7] (mobile-166-147-071-235.mycingular.net [166.147.71.235]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8GLsQjC071650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Sep 2013 16:54:27 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Gen-ART LC Review of draft-kelsey-intarea-mesh-link-establishment-05
Date: Mon, 16 Sep 2013 16:54:27 -0500
Message-Id: <77DA9FC8-8E52-4090-8B02-49475E01E1C9@nostrum.com>
To: draft-kelsey-intarea-mesh-link-establishment.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Received-SPF: pass (shaman.nostrum.com: 166.147.71.235 is authenticated by a trusted mechanism)
Cc: "gen-art@ietf.org Team (gen-art@ietf.org)" <gen-art@ietf.org>, "ietf@ietf.org list" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2013 21:54:30 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-kelsey-intarea-mesh-link-establishment-05
Reviewer: Ben Campbell
Review Date: 2013-09-16
IETF LC End Date: 2013-09-16

Summary: This draft is almost ready to be published as a proposed standard. There are a few minor issues that should be considered prior to publication.

General: The draft is well written, and easier to read than many internet drafts.

Major issues:

none

Minor issues:

-- Applicability Statement

The applicability statement seems a bit lightweight.   I understand it is needed for some other IETF work; it might be nice to mention the specifics here (or in the introduction.) The assertion that this "extends 802.15.4" makes me wonder why this is an IETF effort rather than IEEE 802 effort--some IETF context would help.

-- section 5, 1st paragraph: "To avoid the cost and complexity of adding a second security suite, MLE reuses that of 802.15.4.  This document describes two security suites..."

The two sentences seem to contradict. Is this document describing security suites that are already in 802.15.4, or is it adding new ones?

-- section 7.8: Delay

Can you offer guidance on how to choose a delay value?

-- section 7.9,  paragraph starting with "Update messages SHOULD..."

What is the rational for SHOULDs instead of MUSTs? Can you offer guidance on when it might make sense to violate these? What might happen if one does?

-- section 8: "Outgoing link configuration and advertisement messages SHOULD be secured..."

Can you be more precise than "secured"? Does this mean "signed", "encrypted", or both? Also, what would be the consequences of violating the SHOULD?

-- section 8, paragraph 6: "... MUST be delayed by a random time between 0 and MAX_RESPONSE_DELAY_TIME seconds."

What's a reasonable resolution for that random time? I note that MAX_RESPONSE_DELAY_TIME is set to 1 second. I assume a random number between zero and one is not what you have in mind. :-)

-- section 8, paragraph 9: "Because MLE messages do not require complex processing and are not relayed, a simple timeout scheme is used for retransmitting."

You mention forwarding multiple hops two paragraphs back; do you mean something different here? There are other mentions of forwarding in the draft that makes me wonder about the assertion that messages "are not relayed".

-- section 8, last paragraph:

Can you offer guidance on an appropriate resolution for the random multiplier?

-- section 9, paragraph 3: "Unsecured incoming messages SHOULD be ignored."

Why not MUST? Also does this imply the requirement to secure messages in the first place should have been MUST?

-- section 9, paragraph 4: " A device SHOULD maintain a separate incoming MLE frame counter for each neighbor."

What happens if it doesn't?

-- Security Considerations:

I'd like to see a bit more on the consequences of accepting unsecured messages. The normative requirement says SHOULD NOT accept unprotected messages, instead of MUST NOT, so I assume that you contemplate that implementations may have reasons to accept unsecured messages. 

It's also worth some discussion of securing at the 802.15.4 layer vs at the MLE layer, since that's mentioned a few times in the draft


Nits/editorial comments:

-- section 4.1, 1st paragraph: " ... (addresses, node capabilities, frame counters)..."

Is that list exhaustive or exemplary? A "that is" or "for example" would help. Also, missing a conjunction before last element.

-- section 7.8, last line: "Values to be confirmed..."

Do you expect that to be removed prior to publication? If you think that IANA might not confirm the values, it might be better to use placeholders that refer back to the IANA Considerations section.  (Note that this occurs several times throughout the draft.)