[6lo] Secdir last call review of draft-ietf-6lo-multicast-registration-16

Scott Kelly via Datatracker <noreply@ietf.org> Sat, 30 March 2024 18:21 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C693C14F6B5; Sat, 30 Mar 2024 11:21:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Scott Kelly via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: 6lo@ietf.org, draft-ietf-6lo-multicast-registration.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171182290049.29863.677175473205471754@ietfa.amsl.com>
Reply-To: Scott Kelly <scott@hyperthought.com>
Date: Sat, 30 Mar 2024 11:21:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/eTu4ft-4kFc2yrzGvJxntMi2-Cc>
Subject: [6lo] Secdir last call review of draft-ietf-6lo-multicast-registration-16
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2024 18:21:40 -0000

Reviewer: Scott Kelly
Review result: Has Nits

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.

>From the introduction, “This specification Extends [RFC8505] and [RFC9010] to
add the capability for the 6LN to subscribe anycast and multicast addresses and
for the 6LR to inject them in RPL when appropriate.”

I want to start by saying that I have little experience with the protocols
described in 8505 and 9010; I’d suggest that the AD have my security-related
comments double-checked with someone who has both security expertise and
expertise in these protocols.

As a general comment, it took me several passes to make sense of the
introduction. It seems to aim toward explaining the gaps motivating this RFC,
along with the building blocks this document uses to fill those gaps. It might
help readers to explain this from the outset, and to explicitly call out which
is which. There are still some paragraphs/sentences there whose purpose I don’t
understand.

For the security considerations, I have 2 suggestions: first, it currently
calls out the “security section” of RFC 8505. Shouldn’t it also call out the
security considerations of RFC 9010? Second (and I’m not sure about this), does
this extension potentially permit any new bad behavior (distinct from 8505 and
9010) that should be called out? I don’t understand the protocol nuances well
enough to say, but I’d have felt more certain if it said so explicitly.