Re: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

Lars Eggert <lars@eggert.org> Mon, 11 October 2021 10:08 UTC

Return-Path: <lars@eggert.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CE03A095A; Mon, 11 Oct 2021 03:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrUbC7W3KNEq; Mon, 11 Oct 2021 03:08:33 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD0C3A08CD; Mon, 11 Oct 2021 03:08:32 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:a867:7af:b73f:3db4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 4F6F1600A84; Mon, 11 Oct 2021 13:08:23 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1633946903; bh=jH2G+uv4GsFwtcQWCbx3k+Yat+PCcrjVWk3apIxxnP0=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=uWfjVTTy6VCU0n27uiYocUB8YSZQqyB+X4qgb6YdmMGMNyNqGhMGFqVmW7vSfluoP EjAQwoglNRYrPi+XTrvuqZgkbjEAPgtqFupad+aAtjGl58FUrIZXiX6vfkKdR96yUB EXbaMIbXQnTaELvtCW3aOYuEtLUTU7iP/hNW+5GA=
From: Lars Eggert <lars@eggert.org>
Message-Id: <5A3DB972-AC12-40A2-970D-1846F916AD6E@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_F7E74C30-AAB5-4776-A838-146F3EC462CC"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)
Date: Mon, 11 Oct 2021 13:08:21 +0300
In-Reply-To: <162824256748.9012.15703111505505730185@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, otroan@employees.org, ipv6@ietf.org, 6man-chairs@ietf.org
To: draft-ietf-6man-ipv6-alt-mark@ietf.org
References: <162824256748.9012.15703111505505730185@ietfa.amsl.com>
X-MailScanner-ID: 4F6F1600A84.A36D1
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YWoPXiWBSku-EKtj6O1ncxeX-uQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Oct 2021 10:08:41 -0000

Hi,

I looked at the diff between versions -08 and -10 to see if my DISCUSS was addressed:

On 2021-8-6, at 12:36, Lars Eggert via Datatracker <noreply@ietf.org> wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 2.1. , paragraph 4, discuss:
>>   Therefore, the IPv6 application of the Alternate Marking Method MUST
>>   NOT be deployed outside a controlled domain.
> 
> That's not what Section 6 says, which allows use outside a controlled
> domain (across the Internet) if protection is applied?
> 
> Section 2.1. , paragraph 4, discuss:
>>   Some scenarios may imply that the Alternate Marking Method is applied
>>   outside a controlled domain, either intentionally or unintentionally,
>>   but in these cases, IPsec authentication and encryption MUST be used.
> 
> How can one require use of IPsec for an unintentional use outside of a
> controlled domain? If the header leaks by accident, surely it's unreasonable to
> expect that IPsec had been set up to catch any and all such possible leakage?

the way I understand the additions in -10 is that a "controlled domain" is supposed to be some networks that either directly peer or interconnect with VPNs (like IPsec). I consider this part of my DISCUSS addressed.

> Section 5.3.1. , paragraph 2, discuss:
>>   It is important to note that if the 20 bit FlowMonID is set
>>   independently and pseudo randomly there is a chance of collision.
>>   Indeed, by using the well-known birthday problem in probability
>>   theory, if the 20 bit FlowMonID is set independently and pseudo
>>   randomly without any additional input entropy, there is a 50% chance
>>   of collision for 1206 flows.  So, for more entropy, FlowMonID can
>>   either be combined with other identifying flow information in a
>>   packet (e.g. it is possible to consider the hashed 3-tuple Flow
>>   Label, Source and Destination addresses) or the FlowMonID size could
>>   be increased.
> 
> It seems odd to define a dedicated FlowMonID, but make it so short that it is
> basically not usable in many realistic scenarios. If other parts of the packet
> headers need to be inspected to disambiguate FlowMonID collisions, this (1)
> should at least be more carefully specified in this document (since every node
> will need to do it in the same way) but (2) probably argues for a much longer
> FlowMonID - why not make it 64 bits or longer?

Some changes were made with regards to the FlowMonID, but I don't think they address my points above.

First, the ID is still too short to be useful by itself in moderately busy networks, even when centrally assigned (with the overheads that that entails) - it can only distinguish ~1M concurrent flows, and much less than that with random assignment.

Second, doing lookups based on the FlowMonID together with other fields still seems underspecified. There is text that all devices in a domain need to use the same lookup mode (FlowMonID only or combined with other fields), but nothing is specified with regards to how a combined lookup needs to be implemented everywhere. Doesn't this measurement scheme rely on consistent hashing of such fields everywhere?

Thanks,
Lars