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

Warren Kumari <warren@kumari.net> Thu, 06 June 2024 18:34 UTC

Return-Path: <warren@kumari.net>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B14F9C14F6A5 for <ippm@ietfa.amsl.com>; Thu, 6 Jun 2024 11:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2SqNYvlCtLbN for <ippm@ietfa.amsl.com>; Thu, 6 Jun 2024 11:34:35 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 4EBAEC14F61D for <ippm@ietf.org>; Thu, 6 Jun 2024 11:34:34 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2e96f29884dso14226791fa.0 for <ippm@ietf.org>; Thu, 06 Jun 2024 11:34:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; t=1717698873; x=1718303673; darn=ietf.org; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=wZS+38fnn8Y1hCjF0nqxw3Yjy/pKwcxqzqgWLzcocIE=; b=OMg+Br70xCcJysTGi/cfktvUFzFG04r3lRoTl8PImI6y+3Yby6/jvy8eWpH300VlvH NU5iaEOSAbPvWFc3iv2+d3OrA6PsRUSeP6b9L/0+Z9/Ir8JqvL7pu21ITqJInOJshl0m X+HcVlWLc0I0skeel6/FEZK32zGDxV90Fmfng76Tk0yRlN65kkQNaHgT6c7GwnpdvN83 Em2ReRi38mJYCZZlIHss7+Qd+K2TIOfmbulPdyOnaooFo9jnqaFskv4kXtm68881/oS2 iq71ItlAO/Eo8Bu1Oo08REkWn76OKLu5mMrj35hstV4INq/tDIFY+uClvKJEQL3hIgIz rDOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717698873; x=1718303673; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wZS+38fnn8Y1hCjF0nqxw3Yjy/pKwcxqzqgWLzcocIE=; b=gQVkHk2Fv+y3NPF7V2IFILVz5BjSdJO4QTmh7nu1sMMs6LQ0oYYI1oOutrW7JcWmF0 vKBerjgAQyPeLdpQLqcBPRHkjFbJgmntn1WbHtUq5hs0cqMWZEW81asov7QEsnmweGdv HB2K3/+ZmDzLGiPzYezfv6TCwNUgs6yrUyCxMjc1U1mlLcUKxQFI8WhhOHqb99+A9W9R U3t4UFQNpWJ+exYR+rhlr2YDOAmnUn+kksMdzFiri7rT19LjmXVbDKBChYLbnouSI8nW y8uI+qwBXiIeDykm8kY180WYWr8S26ORS26xSWyf7skGijqctMxcfsC74TnF9nLmsLs+ xFYA==
X-Forwarded-Encrypted: i=1; AJvYcCVnIQX+QkVKmlK6uZNmc/aX7Pv51lP3pLTTnylLoU+cGu7N1+3hhwSh9gsPyuqqMg6YVunqhMmQGnqu1UTZ
X-Gm-Message-State: AOJu0YyXoGB8tfRCctWBNIqQLpsMAMyMxSzg2qbg0/h3XsRSnSsWN7dy POXfvxVQhNqJibO4Ft/SoJ39WJwn680Djv2Sd3VVs6wNWwsgOAqiKAXKAJ6Yvm1zttMbbgQhumH h198H3HFQ8ehk6MDh5WJkoNZGZsZP+7yWXxG6iw==
X-Google-Smtp-Source: AGHT+IElNKIX/Fc2/XPI9Gx5+aM2shM40xIFtYiNgbZmSGhtaviWXWeiT3SPvkiAMI8fFSLORWbDJohVEbO5CRKdj3I=
X-Received: by 2002:a2e:9782:0:b0:2ea:7a33:2c09 with SMTP id 38308e7fff4ca-2eadce7a499mr2943081fa.32.1717698872380; Thu, 06 Jun 2024 11:34:32 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Thu, 6 Jun 2024 20:34:31 +0200
Mime-Version: 1.0
X-Mailer: Superhuman Desktop (2024-06-06T01:32:47Z)
X-Superhuman-ID: lx3ljbsq.33c6e4ce-e6b8-4587-9799-e2dd1cabcbb6
X-Superhuman-Draft-ID: draft0057e907f9ea4643
In-Reply-To: <CAHw9_i+6FZyEfRPr=z_1YzLBrB4oSCqgSfJ8cgLWCw9orPBO9Q@mail.gmail.com>
References: <CAHw9_i+6FZyEfRPr=z_1YzLBrB4oSCqgSfJ8cgLWCw9orPBO9Q@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 06 Jun 2024 20:34:31 +0200
Message-ID: <CAHw9_i+uQamnxRqufN7H-HPBCVj7jCsZ=2eKXDOckJ9i=yVciQ@mail.gmail.com>
To: draft-ietf-ippm-encrypted-pdmv2.all@ietf.org, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001eb021061a3cef6d"
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] Re: AD Review of: draft-ietf-ippm-encrypted-pdmv2
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/svhUk7VdxtuYbGTewbIFke3_eoo>
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 (& WG),

It's been a few weeks - I just wanted to confirm that y'all had received
this and were working on it…


On Wed, May 22, 2024 at 6:03 PM, Warren Kumari <warren@kumari.net> wrote:

> 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