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

Warren Kumari <warren@kumari.net> Thu, 06 June 2024 19:53 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 0F15AC14F71D for <ippm@ietfa.amsl.com>; Thu, 6 Jun 2024 12:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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_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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DkJr9zwgrFXK for <ippm@ietfa.amsl.com>; Thu, 6 Jun 2024 12:53:01 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 AC0F3C14F69B for <ippm@ietf.org>; Thu, 6 Jun 2024 12:53:01 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-57a85cc2d96so1774652a12.2 for <ippm@ietf.org>; Thu, 06 Jun 2024 12:53:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; t=1717703580; x=1718308380; darn=ietf.org; h=cc:to:subject:message-id:date:references:in-reply-to:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gWeqbj82dgoGMSRKd4Fjupsm7ayeJGAkyi6/2vBC/68=; b=OoQ/yc1G2fdl9z9kh45LjvTTCmxJ7Rm4TZIyDHRyUuP9A0hWM1c7UIiLzUBgVnpcNQ 3uDNPCgxY+thUDHUOQ/txaY69icd8Au21mFTiM4YpJE+pZFoZzgjQuXgXh9Ksnjjf/BV hSI3TDqoKknZE4JbGBnlv+WKGw+w8QX4Dnf/Dysd5df3Tfzecc4btqMLL1hJSe7P2XQg T/Qxq2NeDE++3weozQBBIl6bYMNB2VmlKd7BzAmpd1LmxlwgSWrr8f1NM/pAS4gtktwG wTeZPbDqUUL/G3ZCvGyIzGX432RSkCOGkjOnfz1ojDXGoyIlNTllutMT5eiavslkIHKy RKGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717703580; x=1718308380; h=cc:to:subject:message-id:date:references:in-reply-to:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gWeqbj82dgoGMSRKd4Fjupsm7ayeJGAkyi6/2vBC/68=; b=gFAxFEZdxNp6jAia3liPYqvdEkgW843y/2yfgU7MTYDk2usizl/bw+8uXvVr6qY+xi t/0K9h8Yg4TImls4noRF9QDGaNrbq0LRpQq08aUDtioSHAalOJxbtz57YFqgoCY5E7Fp kVLMCBQAVuCDBCGdLnV4pLZRVJGuGjxOrBr72JLFRP0k34vDsa8JCHydRZz9mJkZXLV6 8p7V2l7KRp4Ci6c3RVWSXUS5/cRcGeBvMN31jgWsAuHgl3iGkxeTX2BhcIsWii0U3X5c JSpdZe+9lRO51dp6qJXi8nem+eInqLo15qvmRXEfxm8cFeprtirDC7O0JH/qEL+yL/M0 53yQ==
X-Forwarded-Encrypted: i=1; AJvYcCV2Oic6bfqVVSIT0w4vX1u1JochMCLToxP4sgG1AWNdBzY0lvdfWG5mL+zVU4C5Nmi5v1tzs1hBYjqU4GzQ
X-Gm-Message-State: AOJu0Yw1JD+P9SL3l6+g+QbxZgeieDcfKXH+W3OYhQlJkrLM68U2pSa1 3o04dlwURX6IgOtSllawuNB8p3vmfjRDqrnWQjKgs5GLTw9bRPKh4YINgIPTpN+YNN2W1SxqBuk 3H0eU4tROjz6jlGZsT8qLJsovWY29Yagnnt3sRw==
X-Google-Smtp-Source: AGHT+IHkztZ5f+UVL5RBITJ5ebiaEVVgvkVxqq+Aa1Qnmr2F2PeMAu9JsOATq49yv8/LzEeUfAI9WEaM+TLxtp4p0K4=
X-Received: by 2002:a50:9b03:0:b0:579:c015:5376 with SMTP id 4fb4d7f45d1cf-57c50864b96mr255044a12.4.1717703579718; Thu, 06 Jun 2024 12:52:59 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Thu, 6 Jun 2024 19:52:59 +0000
Mime-Version: 1.0
X-Superhuman-Draft-ID: draft001b509e531a82c4
From: Warren Kumari <warren@kumari.net>
X-Mailer: Superhuman Desktop (2024-06-06T01:32:47Z)
X-Superhuman-ID: lx3ock8a.90a7119f-028c-46cf-9b1a-920a800a5fa8
In-Reply-To: <2029865184.1569833.1717702961769@mail.yahoo.com>
References: <CAHw9_i+6FZyEfRPr=z_1YzLBrB4oSCqgSfJ8cgLWCw9orPBO9Q@mail.gmail.com> <CAHw9_i+uQamnxRqufN7H-HPBCVj7jCsZ=2eKXDOckJ9i=yVciQ@mail.gmail.com> <2029865184.1569833.1717702961769@mail.yahoo.com>
Date: Thu, 06 Jun 2024 19:52:59 +0000
Message-ID: <CAHw9_iKo+aacY+EO+C5ubfJYRGw9osH1Yv9GOaG6KDLbfpyq+Q@mail.gmail.com>
To: nalini.elkins@insidethestack.com
Content-Type: multipart/alternative; boundary="000000000000b2f0b5061a3e07c5"
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
CC: draft-ietf-ippm-encrypted-pdmv2.all@ietf.org, IETF IPPM WG <ippm@ietf.org>
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/7nc80Ovwy87QQfXr2GvIrE_VpBU>
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>

On Thu, Jun 06, 2024 at 3:42 PM, <nalini.elkins@insidethestack.com> wrote:

> Warren,
> Sorry, I am to blame.

No worries from my side, just wanted to make sure I wasn't the one holding
things up.

Just FYI, I'll be traveling next week (Rwanda, ICANN) and so might not get
to it immediately…


We have a new version.  I need to do a final review on it & plan to submit
> it by Friday morning.
> Where does the time go?
> Thanks,
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> https://www.insidethestack.com <http://www.insidethestack.com>
> President
> Industry Network Technology Council
> https://www.industrynetcouncil.org
> On Thursday, June 6, 2024 at 11:34:50 AM PDT, Warren Kumari <warren@
> kumari.net> wrote:
> 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…
> W
> 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
> _______________________________________________
> ippm mailing list -- ippm@ietf.org
> To unsubscribe send an email to ippm-leave@ietf.org