[IPv6]Paul Wouters' Discuss on draft-ietf-6man-comp-rtg-hdr-09: (with DISCUSS and COMMENT)

Paul Wouters via Datatracker <noreply@ietf.org> Thu, 30 May 2024 04:17 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D82C14F6B8; Wed, 29 May 2024 21:17:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171704262081.33609.3979711900040222907@ietfa.amsl.com>
Date: Wed, 29 May 2024 21:17:00 -0700
Message-ID-Hash: AEBZ6O5GDCA6EDBCU2BPXT2CA7Y3J5JN
X-Message-ID-Hash: AEBZ6O5GDCA6EDBCU2BPXT2CA7Y3J5JN
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.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@ietf.org, 6man-chairs@ietf.org, ipv6@ietf.org, bob.hinden@gmail.com
X-Mailman-Version: 3.3.9rc4
Reply-To: Paul Wouters <paul.wouters@aiven.io>
Subject: [IPv6]Paul Wouters' Discuss on draft-ietf-6man-comp-rtg-hdr-09: (with DISCUSS and COMMENT)
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1wd1Un_bat2p9ssx4yac8-SU-xw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Owner: <mailto:ipv6-owner@ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Subscribe: <mailto:ipv6-join@ietf.org>
List-Unsubscribe: <mailto:ipv6-leave@ietf.org>

Paul Wouters has entered the following ballot position for
draft-ietf-6man-comp-rtg-hdr-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-comp-rtg-hdr/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to Brian Weis for his multiple SecDir reviews.


        In this document, one node trusts another only if both nodes are operated by the same party.

Is this configured through provisioning that is out of scope? Or is there a
protocol to figure this out? It seems this is based on marking each interface
as "operated by me" or "operated by someone else". If so, why not clearly state
this?

        The CRH is compatible with end-to-end IPv6 Authentication Header
        (AH) [RFC4302] processing. This is becasue the source node MUST
        calculate the Integrity Check Value (ICV) over the packet as it
        arrives at the destination node.

I do not understand this. The source node using AH, as per Appendix A.1:

As the packet travels from S to I2:
Source Address = 2001:db8::a
Destination Address = 2001:db8::2

So the AH header will be created based on Destination Address 2001:db8::2

As the packet travels from I2 to D:
Source Address = 2001:db8::a
Destination Address = 2001:db8::b

When D receives the packet, Destination Address is now 2001:db8::b, and
thus the AH packet signature will fail (as it should, the packet was modified!)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I don't understand the different syntax used in Fig 1 and 2,
eg the open box and dots. It makes it look like there is
more difference than just the SIDs taking 32 or 64 bits.
Is it trying to explain padding in Fig 1 but not Fig 2?

        PING and TRACEROUTE report 16-bit CRH SIDs for CRH-16, and 32-bit CRH SIDs for CRH-32.

Is this confusing protocols with implementations? Does my
linux ping report this, or the netbsd ping, or the 1995 bebox computer's ping
support this newly defined CRH too?