[secdir] Secdir last call review of draft-ietf-v6ops-cpe-slaac-renum-04

Christopher Wood via Datatracker <noreply@ietf.org> Wed, 09 September 2020 23:16 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 423333A043A; Wed, 9 Sep 2020 16:16:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christopher Wood via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: last-call@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.16.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159969337123.15697.6820068156665930267@ietfa.amsl.com>
Reply-To: Christopher Wood <caw@heapingbits.net>
Date: Wed, 09 Sep 2020 16:16:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/JjJjEJim2DU7auNV1j90VGNUyZU>
Subject: [secdir] Secdir last call review of draft-ietf-v6ops-cpe-slaac-renum-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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 Sep 2020 23:16:11 -0000

Reviewer: Christopher Wood
Review result: Has Nits

Summary: Has Nits

Comments:

- Section 3: is it possible for an attacker to send DHCPv6 Prefix Delegations
with lifetime=0 to CE routers that support LAN-side DHCPv6 and amplify
Reconfigure messages to supporting clients? (I don't know if this is a concern
or part of the threat model, but this did seem to be a case of possible
request/response asymmetry.) - Section 4: rationale for these default values,
if available, might be worth including. (Why not make them shorter? What are
the tradeoffs?) - Section 6: it might be worth noting what happens if stable
storage is unavailable or otherwise compromised when trying to store prefix
information. What happens if the "A" or "L" bits are modified? (I suspect
nothing dangerous, but it's not clear to me whether or not integrity is
important.)

Nits:

- In some places "\"Valid Lifetime\"" is written as "valid-lifetime" -- should
these be made consistent?