[Last-Call] Secdir last call review of draft-ietf-ippm-ioam-conf-state-05

Chris Lonvick via Datatracker <noreply@ietf.org> Sat, 01 October 2022 01:38 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5626FC14CE2A; Fri, 30 Sep 2022 18:38:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Chris Lonvick via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-ippm-ioam-conf-state.all@ietf.org, ippm@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166458829634.58025.903256113392180198@ietfa.amsl.com>
Reply-To: Chris Lonvick <lonvick.ietf@gmail.com>
Date: Fri, 30 Sep 2022 18:38:16 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/eajWoclFFz711sUPcvwjukFHUgo>
Subject: [Last-Call] Secdir last call review of draft-ietf-ippm-ioam-conf-state-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Oct 2022 01:38:16 -0000

Reviewer: Chris Lonvick
Review result: Has Issues

Hi,

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.

The summary of the review is Ready with Issues.

The Security Considerations section doesn't give any guidance regarding errors,
boundaries, or limits. For example, the specification requires that certain
fields MUST be set to 0, but no guidance is given of what a receiver is to do
if it receives a packet with that field not set to 0. Similarly, the
specification requires that a list of IOAM Namespace-IDs be transmitted. What
should a receiver do if the list includes duplicate entries, or if it receives
a Namespace-ID that is not defined? Please add some bounds checking and limits
in the Security Considerations section.

The specification frequently references RFC 9197, which appears to have a
well-developed Security Considerations section. It would be appropriate if the
Security Considerations section of this ID were to reference that Security
Considerations section and require that implementations of this specification
follow the guidance given there.

Other than those issues, I found the document to be understandable and well
written. I found no nits.

Regards,
Chris