[ippm] AD Review of: draft-ietf-ippm-encrypted-pdmv2

Warren Kumari <warren@kumari.net> Wed, 22 May 2024 22:03 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B125CC14F5F9 for <ippm@ietfa.amsl.com>; Wed, 22 May 2024 15:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7Ihl0sRomoU for <ippm@ietfa.amsl.com>; Wed, 22 May 2024 15:03:19 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53644C14F5F2 for <ippm@ietf.org>; Wed, 22 May 2024 15:03:19 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2e73359b900so34970121fa.2 for <ippm@ietf.org>; Wed, 22 May 2024 15:03:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; t=1716415397; x=1717020197; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=4lKwy+ccmLJTKzuAQCnCkVKcId3xQ7R+g82b2s5xZoE=; b=DeKGlHSva4sctNHPAndYH86jU+tbX9iEptL1Bt8QID1LcIquCgMa1aqiL0rnG7SP4+ Ut92helm3R5D863Hum5H3Fq8JaEO3GLxyR0V4WKAPcGzrHuOTKlXlHPr27UO18e/ci+W aub4C1FX9R40O/4u9d+rpQrMTnVLGBMNe4nS97EZ3tIxrtJsqtN66z71y3pEDf1mKWgx PVsGxLAdphKVRG9FOBNztH1DIVK5pARonPwwU+FPxXsoFDVz9ZlXTwk1QCfyCQGvQnJ9 /Lz1bcQkiEEL53uU6kX3AsSWrRQ1APURYW2ZrEcPh3TCZszDVAdtfauz+7Lp5/M1Oczp hIag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716415397; x=1717020197; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=4lKwy+ccmLJTKzuAQCnCkVKcId3xQ7R+g82b2s5xZoE=; b=h9QvPyjmve7+QmMCxc+07N81mElNyQzNF0P1vrO4skq57O7OURTJBb5pBy+9BAL+RT 1D/Pd4935Ed7J7VSos7eQZB27cNtp786xXIipYwVrPvHesqACdRg0cn0uzVoLxU5GtXZ V3cVi6+UydPNjgoWhG9UEo6KDnhR+jJUrWTuoYYfRtS/OqGD2R1u17TrCzulNIfn9oTI sbltVMqHIWzygSXUr7um8l6lHgz7qtFohsVbyHkk9SKUsNdNkR/vIfupCq56dvB3xVPK zugd5nXCHO3XxsgosD0mxeBI/d9fk9+w0wAmknIdpFNVlTzAYbMljzD6Q/Alk/1wpc4N HDxg==
X-Forwarded-Encrypted: i=1; AJvYcCXW3tnrghUxcapH2XspGhlM6KuYfqSpKqreuVCyxstV9hR1SkQh5sfdJLY+zDYsCF5Wa63Vx9m/VNKbdY0T
X-Gm-Message-State: AOJu0YwDZuAm5yV8QGiDiw6H9OGhlyaKiKdX00FmBBjAr/y3jwiJ6p3V 1fthH/dmZvtdeQQK+13hNNXeEorBY7zJqiyVoaCp/o0RP8D3dLyKDD1GOKeapnuhUmR6W3VLZUO tDVcy1OqPqt31MMMEFeaiGjPkWRT4YqVAMVJtoA==
X-Google-Smtp-Source: AGHT+IHDpYSuQFNFErq7eK9GU2paorfJaX2ri+rfbR55I/IhbVRlYZKkxpxzYps1Z/49us/cJOmUctRCmIeZclWxXsI=
X-Received: by 2002:a2e:9c94:0:b0:2e3:603e:4697 with SMTP id 38308e7fff4ca-2e94969deadmr19692071fa.36.1716415396493; Wed, 22 May 2024 15:03:16 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Wed, 22 May 2024 18:03:15 -0400
Mime-Version: 1.0
X-Mailer: Superhuman Desktop (2024-05-21T21:22:51Z)
X-Superhuman-Thread-ID: draft008892fb2da40e38
X-Superhuman-ID: lwideajt.a16ed940-0dc8-4174-bd11-c58479814005
X-Superhuman-Draft-ID: draft001721b1d5cff798
From: Warren Kumari <warren@kumari.net>
Date: Wed, 22 May 2024 18:03:15 -0400
Message-ID: <CAHw9_i+6FZyEfRPr=z_1YzLBrB4oSCqgSfJ8cgLWCw9orPBO9Q@mail.gmail.com>
To: draft-ietf-ippm-encrypted-pdmv2.all@ietf.org, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fedf1906191219e7"
Message-ID-Hash: CQF5JRNKCKKFAF2JZJ2V6CKQFDX25GXJ
X-Message-ID-Hash: CQF5JRNKCKKFAF2JZJ2V6CKQFDX25GXJ
X-MailFrom: warren@kumari.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ippm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [ippm] AD Review of: draft-ietf-ippm-encrypted-pdmv2
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Owner: <mailto:ippm-owner@ietf.org>
List-Post: <mailto:ippm@ietf.org>
List-Subscribe: <mailto:ippm-join@ietf.org>
List-Unsubscribe: <mailto:ippm-leave@ietf.org>

Hi there, authors (and WG),

Thank you for writing draft-ietf-ippm-encrypted-pdmv2 - "IPv6 Performance
and Diagnostic Metrics Version 2 (PDMv2) Destination Option"
<https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/>.

Unfortunately I think that that the document still needs some work before
I'm ready to advance it to IETF LC / IESG Eval.

I think that the largest issue is that the ordering of the sections doesn't
make the document very easy to read —- the majority of Section 4 and
Section 5 don't make much sense until and unless you have read Section 6. I
think that much of my concern can be addressed by simply moving Section 6
before Section 3.


Nits / comments:
Section 1  - Introduction
1: "The current PDM is an IPv6 Destination Options header…"
Can you please expand PDM on first use? Yes, I know it is expanded in the
title, but I think it would be good it include it in the narrative as well.


2: "PDM metrics can help an attacker understand about the type of machine
and its processing capabilities."
Which machine, and what about it? (e.g : something like "...can provide
information to an attacker about the operational limits and network
capabilities of the machine sending the metrics" or similar?)

3: I think that the following sentence can be dropped, or the two following
sentences can be combined into one…

4: "... it can mislead the person showing there are …"
I think you are missing a word after "person" - perhaps "by"? In addition,
perhaps "the person" isn't great — much of this might be consumed by
tooling, so perhaps just drop "the person".

Section 3 - Terminology
5: "pkX  (Public Key) and skX (Private Key).  Where X can be, any client
or  any server."
This doesn't seem very clearly written - perhaps something like "In this
document, the Public Key is represented as pkX and the Private Key as skX
(where X can be any client or server)." or similar.

6: You are using the terminology "SharedSecret" and "SessionTemporaryKey"
further down in the document, but haven't included it here. You claim to be
using "Session Key", but it doesn't appear anywhere in the document other
than in the "Terminology" section.


Section 4.1.  Client - Server Negotiation
This section says:
"Each Client and Server derive a "SessionTemporaryKey" by using HPKE Key
Derivation Function (KDF), using the following inputs: [...]"
and then as the end of the section there is:
"The SessionTemporaryKey using a KDF with the following inputs:
   *  SrcIP, SrcPort, DstIP, DstPort, Protocol, SharedSecret, Epoch."
I'm assuming that the second one is just left over from earlier edits?


Misc:
I'm confused by:
"4.2.2.  Use Case 2: Server does not allow PDM or PDMv2

   If a client sends a packet with PDM and the network policy is to only
   allow encrypted or unencrypted PDMv2, then the PDM / PDMv2 header
   MUST be ignored and processing continue normally."
I'm really unclear what this is trying to say — there feels like a
disconnect in the section header and the text? Even if that is the case, I
think that the use of the term "PDM / PDMv2 header" here is confusing —
would it be OK to just say something like "the PDM option"?

This is made more confusing with the next paragraph:
" The server SHOULD log such occurrences but MUST apply rate limiting to
any such logs.  The implementor should be aware that logging or returning
of error messages can be used in a Denial of Service reflector attack.  An
attacker might send many packets with PDM / PDMv2 and cause the receiver to
experience resource exhaustion."
But the text above says that the "the network policy is to only  allow
encrypted or unencrypted PDMv2…"


I found the text describing the "Global Pointer" in Sec 6.2 unclear — it
took me quite a few readings to work out (and I'm still unclear!) that
there are two Global Pointers, one for LL and one for Global addresses — I
suggest rewording the "Unlike PDM fields, Global Pointer (GLOBALPTR) field
in PDMv2 is defined for the SADDR type.  Following are the SADDR address
types considered:" text.
Even saying something like "defined per SADDR type" would make this clearer
(unless I'm completely wrong, I'm still unclear on the scope of this).


I'm also somewhat confused by:
"Epoch
12-bit unsigned number.
Epoch field is used to indicate the valid SessionTemporaryKey.

Packet Sequence Number This Packet (PSNTP)
      16-bit unsigned number.
      This field is initialized at a random number and is
incremented sequentially for each packet of the 5-tuple.
      This field is also used in the Encrypted PDMv2 as the encryption
nonce.  The nonce MUST NOT be reused in different sessions."

and:
"The Epoch MUST be incremented when the Packet Sequence Number (PSN)
   This Packet (PSNTP) is rolled over.  It MAY be incremented
earlier, depending on the implementation and the security considerations.

   The sender MUST NOT create two packets with identical PSNTP and Epoch."

I suspect that I'm missing something very fundamental here, but even if the
Epoch is not 'incremented earlier', after 2^(12+16) packets in a flow, this
will wrap and you will generate packets with identical PSNTP and Epoch.
This is only 286 million packets — what am I missing?

I am also unclear what exactly "rolled over" means in:
"The Epoch MUST be incremented when the Packet Sequence Number (PSN) This
Packet (PSNTP) is rolled over." I'm **assuming** the obvious "when the 16
bit counter exceeds 2^16 and overflows", but PSNTP is initialized at random
— so, if it happens to be initialized at 65535 should it roll over after 1
packet, or do you mean when it next reaches 65535? I assume the former, but
it's unclear…

Please let me know, LOUDLY, once you have had a chance to address these and
I'll progress the document..

W