[secdir] Secdir telechat review of draft-ietf-6man-comp-rtg-hdr-06

Brian Weis via Datatracker <noreply@ietf.org> Fri, 17 May 2024 18:02 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 83BECC14CF17; Fri, 17 May 2024 11:02:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Brian Weis via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171596892551.38219.631340796746494415@ietfa.amsl.com>
Date: Fri, 17 May 2024 11:02:05 -0700
Message-ID-Hash: XLFNPHUVQHQXEDV6O5UJLK3KMVWD66GT
X-Message-ID-Hash: XLFNPHUVQHQXEDV6O5UJLK3KMVWD66GT
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-6man-comp-rtg-hdr.all@ietf.org, ipv6@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Brian Weis <bew.stds@gmail.com>
Subject: [secdir] Secdir telechat review of draft-ietf-6man-comp-rtg-hdr-06
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/LI6xQ8mI9saZw7A30bIDlux7GJ0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

Reviewer: Brian Weis
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.

The summary of the review is Has Nits

The main issues of concern from my first review have been addressed:

— Describing dependance on ICMP messages

— Rationalization of how AH processing is affected, which is declaring
that a sender “MUST calculate the Integrity Check Value (ICV) over
the packet as it arrives at the destination node”.  This matches
the intent of RFC 4302, and is in fact possible for the CRH originator.

I still think the following comment from my original review is
important enough to mention, but I don’t consider it an issue.

“One general comment is that I would expect the network operators
in some networks  to deploy packet inspection devices (e.g., firewall,
intrusion detection) at choke points within the network. Because
the IPv6 Destination Address is changed hop-by-hop they cannot
simply compare the packets SA and DA to {source, destination} rules
simply by extracting the SA an DA from the packet. In order for
these packet inspection devices to validate based on endpoint
addresses they will need to be aware of the mapping of SIDs to IP
addresses. I think this issue is worth mentioning in Security
Considerations.”