Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdmv2-05

Dhruv Dhody <dhruv.ietf@gmail.com> Sat, 27 January 2024 09:53 UTC

Return-Path: <dhruv.ietf@gmail.com>
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 2FDF0C19ECBB for <ippm@ietfa.amsl.com>; Sat, 27 Jan 2024 01:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=gmail.com
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 bun8c-P7tFrt for <ippm@ietfa.amsl.com>; Sat, 27 Jan 2024 01:53:25 -0800 (PST)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 5AA2BC14CEF9 for <ippm@ietf.org>; Sat, 27 Jan 2024 01:53:25 -0800 (PST)
Received: by mail-qt1-x829.google.com with SMTP id d75a77b69052e-42a35c720b8so7057761cf.3 for <ippm@ietf.org>; Sat, 27 Jan 2024 01:53:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706349204; x=1706954004; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NE1cypRcVZj2HpeDK9j2krnAlXmgj6nzTNCmBoqem5g=; b=A/Q0OC8i5RBJEVWiLwGNBT62fKOv68j0gYYS7ZVCS49P6CYA4HFPmC63HL7VOx/+Q8 Iq3OrSb9CxylgvXpXxHd+RRoglnxq1uuiGGiCc45eR8UGS8pRRi3p/YrJbqWRYdforgY sPlWxh4zSGmjJ75iw2Oz/ucd81vMPc7SVeciqvQhCeC7mMQBGZdWl+2GQepYGBlO59G3 TR2LFYEWf6ELErCQyQB0K9vgbIDL/Y/l8geWxm4z7RGBbrJ+Nz8V4VUwUkABANK6r2Hm 8wM7DPFUgt1ier0z7ndtJYP98VbrMGK+3VYi90ohRSJQFIBZIw91sujn/BD1c181o77d C/ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706349204; x=1706954004; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NE1cypRcVZj2HpeDK9j2krnAlXmgj6nzTNCmBoqem5g=; b=XuF5d+0rtIWIRlNi5mN07Lnd28fg57a08aqHeAfVhj3aW9PiSbStXLnGiUhPMpGcYp 2PEKEu2k8kDjYueoD9csD5yJQ9cWs6wnAjkZAsMp7yJNXjVo7bWAwfYcq69OnN8yZzJU lkePXyPnQQDbWGbSATKH4T5OB367zhyP6G4404Cp/aA3mmkoVjI83l3b8A5wgTMb209n NFE1VLlZrZIPvS7QWhhqAHj/XOXGLdpiO+vs+7mfsMI/XblayT54Cy3Xy5bRMpoP5O01 P1cvbYzSJD0HKX5m4wGAG+AL5NHgYIPOE/UOg7THrw6DC3hREP+ZstY4JCqYuQ7itypB zO2w==
X-Gm-Message-State: AOJu0Yy3oNNAdKbabfTNbLHNLDFg5dz6OjjIYpL4k85FIdDJEZ/GSXr1 fQLCTh11We6QIXo04aCv+obktH+veBX5p7JMfGCxL8+s5zjM48iHLsljVXK3jhdqMnCmRnUE8nQ IMq6ld8i93qQXgjmmIRtaRb5c118=
X-Google-Smtp-Source: AGHT+IECCRB87Efr+rvhu97Id/OBrmAmyyz4+/3wmBNZ0aXWFpnIGQfMU2CeLdiRHuJeJjOlNMOPf1Uk6Yf8D/4xeg8=
X-Received: by 2002:ac8:5dd0:0:b0:42a:5371:b83d with SMTP id e16-20020ac85dd0000000b0042a5371b83dmr1652367qtx.96.1706349204179; Sat, 27 Jan 2024 01:53:24 -0800 (PST)
MIME-Version: 1.0
References: <61AC7432-55A9-4E65-A1FE-CB23B3B414B0@apple.com>
In-Reply-To: <61AC7432-55A9-4E65-A1FE-CB23B3B414B0@apple.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Sat, 27 Jan 2024 15:22:47 +0530
Message-ID: <CAB75xn7__cjMrGWjTXv8-QgZ4+AoGiXWQAaJob0_zLJLOPbPzA@mail.gmail.com>
To: Tommy Pauly <tpauly@apple.com>, Nalini Elkins <nalini.elkins@insidethestack.com>
Cc: IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002d8ca4060fea6283"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/rAmWnN2tnKxtF0fPWE3jjCfhsn0>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdmv2-05
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jan 2024 09:53:29 -0000

Hi,

I support this work, but here are a few comments that should be handled
before sending the I-D to our AD.

## Suggestions/Query
* I am assuming that the procedures specified in RFC 8250 continue to
apply. That should be stated explicitly.
* Section 3, Is it correct to say the difference between a client and
server is that it is the client that initiates the session? Maybe just
state that and other properties are for any endpoint node.
* Shouldn't there be some backward compatibility text to explain cases like
-- what happens when a node does not understand PDMv2 and thus expected a
length of 10 as per RFC 8250 but finds a different length. Also I wonder
how one decides if a client should use PDM, unencrypted PDMv2 or encrypted
PDMv2. There should be specific text that says that the server MUST respond
with the same mechanism. Are all mechanisms mandatory to implement?
Basically we need more text...

## Minor
*  Section 1, Consider changing Man-In-The-Middle to Machine-In-The-Middle
as per
https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/
- Section 1, it would be good to introduce what PDMv2 is before stating
"PDMv2 adds...".
- Section 3, mentions terms pkX and skX but never use it, is there a reason
they are defined?
- Section 9, you are reusing the option type 0x0F defined in RFC 8250, you
don't need to ask IANA to assign one!
- Section A.1, is there a reference to the primary-secondary architecture
mentioned?

## Nits
* Section 1, s/current PDM/PDM [RFC8250]/
* Section 4.1, expand HPKE, KEM, KDF (you do that later on in section 5.4,
but it should be done here). Also PSN.
* Don't capitalize "CAN" as it is not a BCP14 keyword. Maybe use MAY?
* Section 6.3, the formatting for field descriptions is hard to follow.
* s/Reserved Bits/Reserved/ - add it MUST be set to zero on transmission
and ignored on receipt.
* s/RFC3552/[RFC3552]/
* Remove appendix B and C as they are empty

Thanks!
Dhruv

On Tue, Jan 9, 2024 at 10:56 PM Tommy Pauly <tpauly=
40apple.com@dmarc.ietf.org> wrote:

> Hello IPPM,
>
> This email starts a Working Group Last Call for "IPv6 Performance and
> Diagnostic Metrics Version 2 (PDMv2) Destination Option”,
> draft-ietf-ippm-encrypted-pdmv2-05.
>
> https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-encrypted-pdmv2-05
>
> Please review the document and send your comments in response to this
> email, along with whether you think the document is ready to progress.
>
> This last call will be three weeks long, and end on *Tuesday, January 30*.
> In parallel, we have requested another SECDIR review.
>
> Best,
> Tommy & Marcus
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>