[OPSEC] Opsdir telechat review of draft-ietf-opsec-probe-attribution-08

Linda Dunbar via Datatracker <noreply@ietf.org> Tue, 11 July 2023 21:16 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsec@ietf.org
Delivered-To: opsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 529D8C16B5A4; Tue, 11 Jul 2023 14:16:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Linda Dunbar via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-opsec-probe-attribution.all@ietf.org, last-call@ietf.org, opsec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168911017532.56574.17514712166783156444@ietfa.amsl.com>
Reply-To: Linda Dunbar <linda.dunbar@futurewei.com>
Date: Tue, 11 Jul 2023 14:16:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/m2qHCOLFL3O5EmzIYNE2NeB0OHg>
Subject: [OPSEC] Opsdir telechat review of draft-ietf-opsec-probe-attribution-08
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.39
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jul 2023 21:16:15 -0000

Reviewer: Linda Dunbar
Review result: Has Issues

I have reviewed this document as part of the Ops area directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Ops area directors.
Document editors and WG chairs should treat these comments just like any other
last-call comments.

Summary: This document suggests some simple techniques for a source to identify
its probes.

This is my second time reviewing the draft. (last review was the -05 version).
Thanks for the authors replies, which helps me understand the draft much
better. However, there are still unsolved issues: - Is the "Probe" another ICMP
message?  Does the "probe" have an ICMP Header? or just simple "Echo" request?
- Should a new ICMP code be specified so that target nodes can decode the
content carried by the ICMP message?

Thank you,
Linda