[secdir] secdir review of draft-ietf-roll-unaware-leaves

Carl Wallace <carl@redhoundsoftware.com> Wed, 09 December 2020 12:42 UTC

Return-Path: <carl@redhoundsoftware.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 624093A0F47 for <secdir@ietfa.amsl.com>; Wed, 9 Dec 2020 04:42:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
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 DJvaNEnzpfkJ for <secdir@ietfa.amsl.com>; Wed, 9 Dec 2020 04:42:45 -0800 (PST)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5373A0F3A for <secdir@ietf.org>; Wed, 9 Dec 2020 04:42:44 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id w79so1000775qkb.5 for <secdir@ietf.org>; Wed, 09 Dec 2020 04:42:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=FEKw/aByUnEONU+qrCUh4+gDE/H7ZfurgzRCr/pF21I=; b=rbVK0Qf+FV8oUcnSgHarK6NDmfH1NVbeKS/LP9UgmCXBbA7+saQy59ccsCW7+fW741 nGvxk594CmC7+vblHCafNXc0cTtKTo41NeEkoEuBOz2TLZueqAUqcGrYkS1U7j7vFsq6 zXEvP81OBj3vBaYoRptBu8r/0WylX2pesuAAY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=FEKw/aByUnEONU+qrCUh4+gDE/H7ZfurgzRCr/pF21I=; b=FfZlQolrH053cXPWqO7tSGsrunu1u9M3Z4TX3w3CERMHEfgB9nHkHoA06KoVGUerTr RW3MvB03aT21u1iLagIXGlauQbVegdCYjdmagEz8jRryAMNF3/0Fk30ZB3ffmRSyY9v6 7doQRmcqQtiPLpJT7UcIKxQHsuyVSWHV1FZMFYvov5WUqmE5mFA4NQ+Y8VmDf8Gw7Tyr SNViWwsmQMavQ4T26vXoasUN+4w+OWwjaECEscfD6X2Y+6W6YNWwvmLNqqe1J92NbWpp GVtTLWjSIcTFoCzoeWk0m6rEqFLQMujMQmVCOa6FKzqwwlHUZLFbKRgbM8Nf1vKZJLiZ U6BQ==
X-Gm-Message-State: AOAM5318EFbS9LkdLYHQX2YCmtae1jRIRzB23HOgzsHOQUExIqGc8teN ZAT29WjFOF6+kRUVX9T1HCJzwnqrPZv58Uqn
X-Google-Smtp-Source: ABdhPJzdQPThw5srXV6b/ffYfIJdXo4ASdr/ykq4vd+HwHZMTDjPcduseYnI917VFlfxIJ+xhrjaaA==
X-Received: by 2002:a37:c04:: with SMTP id 4mr2751697qkm.491.1607517763645; Wed, 09 Dec 2020 04:42:43 -0800 (PST)
Received: from [192.168.2.16] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id x2sm766063qtw.3.2020.12.09.04.42.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Dec 2020 04:42:42 -0800 (PST)
User-Agent: Microsoft-MacOutlook/16.43.20110804
Date: Wed, 09 Dec 2020 07:42:42 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: <draft-ietf-roll-unaware-leaves.all@ietf.org>, <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Message-ID: <ACF455F8-E259-4E93-94F1-19B52EEE2420@redhoundsoftware.com>
Thread-Topic: secdir review of draft-ietf-roll-unaware-leaves
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/dmLRgWOu6PcYcRdn8FpjnYOwbRU>
Subject: [secdir] secdir review of draft-ietf-roll-unaware-leaves
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 09 Dec 2020 12:42:46 -0000

I 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments.

This specification updates RFC6550, RFC6775, and RFC8505, to provide routing services to RPL Unaware Leaves that implement 6LoWPAN ND and the extensions therein. The changes described in the draft largely consist of defining some previously undefined reserved flags (including corresponding inclusion of ROVR in existing message), redefining some status messages and extending use of an existing message for additional mode of operation. Some questions and comments are below. These could all be categorized minor nits focused on improving clarity.

General
- The document feels long given the magnitude of changes. There are some explanatory sections that may be better off left as references to the normative specs. As someone unfamiliar with ROLL, I found reconciling explanatory text here with source docs difficult in spots.

Section 1
- In the introduction, the reference to RFC6687 in the first sentence of the third paragraph seems misplaced. While the term 'path stretch' appears in that document, the concept being referenced doesn't seem to match and may be better served by a reference to section 3.1 of RFC 6550.

Section 4.3.1
- The last sentence in section 4.3.1 probably belongs in (or should be repeated) in Section 8. It seems odd to feature fresh standards language in a section that is providing background but not in the section enhancing the referenced doc.

Section 5.1, 5.3 and 5.4
- There are a number of "is expected" instances that may benefit from being written as SHOULD/SHOULD NOT or MUST/MUST NOT.

Section 5.2
- Language is unclear on whether decapsulation is required by a RUL. The statement "the RUL, as an IPv6 Host, must be able to decapsulate the tunneled packet" is inconsistent with the last statement in the paragraph. Maybe change first statement to "If a RUL supports terminating an IP-in-IP tunnel...".
- The statement "the Root terminates" may benefit from a SHOULD. The sentence establishes when a SHOULD would not apply already. [USEofRPLinfo] has a SHOULD when making this same point in 4.1. Replacing this entire paragraph with the fourth paragraph in section 4.1 may be the right thing to do.

Section 6.1:
- What does "if the ’F’ flag is reset" mean? Does it just mean set to 0?
- In the ROVRsz definition, why would values above 4 result in size being unknown? Maybe this should say the meaning is unknown for values above 4. 
- It states "an implementation SHOULD propagate the whole Target Option" when ROVRsz is greater than 4. In what cases should the whole target option not be propagated? 
- Should there be a "prefix length field MUST indicate 128 bits when F flag is set" instead of ignoring the length and assuming 128? 
- Should this section require bits not claimed by this spec to be set to zero as in 6550? This assumes this spec is only claiming 5 of 8 bits. That may be worth clarifying as well.

Section 7
- What does "A 6LR and a Root that support this specification MUST implement the Non-Storing DCO" mean? The only definition of "non-storing DCO" appears to be in the previous paragraph, which does not apply to the 6LR.

Section 9
- What does 'reset' mean in second paragraph? It seems to mean "not set".

Section 9.2.1
- This section begins by noting no changes are defined for the described process that is defined by various other specs. The section describes many requirements including some that look to be new, i.e., first paragraph below the bulleted list.