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

"nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com> Thu, 06 June 2024 21:37 UTC

Return-Path: <nalini.elkins@insidethestack.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 0B3D7C180B44 for <ippm@ietfa.amsl.com>; Thu, 6 Jun 2024 14:37:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 nvDH_S9VeMt5 for <ippm@ietfa.amsl.com>; Thu, 6 Jun 2024 14:37:18 -0700 (PDT)
Received: from sonic301-9.consmr.mail.bf2.yahoo.com (sonic301-9.consmr.mail.bf2.yahoo.com [74.6.129.48]) (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 06A1BC180B43 for <ippm@ietf.org>; Thu, 6 Jun 2024 14:37:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1717709836; bh=JtjbM9FJGDehEcE5E3ms+nUHfli54ONlf0wHWoTbYwQ=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=IKGVwNE+DS++TRR7s1xyzccuZftZ0rdUAO274MN+cwqmRiwcK+Vy5bhT5kyDv6FaH8aQcCzLvbtfcQcD081cDfChnS/R2M6olQ6qnDLXVDzzPZtbMBrAi6zm+vs8WDrE0o8uN4nv2L0gvM9UvYEkEi9a4kKA3YcVT+m/6x/mCb/JuCWbaKg8TCoNfCe9Sc5vaNEUPesWm11a1I7NKi9YUD2P8yuExcp5CtFR07BaZ9l0GSPhAiBJMK21t78MIHMXIXyPm/f/J683IluFO3M4kVIv+st01zL3V/AJ4PDWuMZ3rFBqPpnDXeNJnc1gZ2H/4ChQkMaMwGv4o2Np+PZ2lQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1717709836; bh=gc8Fxg3Zl9sDjbCvxgNCXTS7E7BOF9ewYDlMiPYj/Jq=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=WSZAPT8NwXyW0CM2BRIgwfxghG6H/I++cXARuK85v+V+UreH6wIpM7Nhifhc247Pte1d9aLPGyrv4FQ0llQDbs3P6JsBHPvKk3ZvHUrX60MCftiWAuipxeFDmou5IKO2byHhMBm+WPemKyoa8w0mHo/kgenxYxva+U5ptv0VChx9fIZyEIo316RDemQnmBEqHQj18G/47o0lVRDdYNsLlfR60JJynE4C3joV7D9w3ErkYHXQBUeOnzGjyLsv9Wnp0zJavHyjZfPRJoV1k5TL6fpFpEyQZSkBk+bo/4oTQKdYbDKSLrpMv3QWlZCZTMlPqMok+0o/JE7ydJ/GrRt6jw==
X-YMail-OSG: fUo7id4VM1mO7ZxGut3ivOTw_ZpVH3EAv9KOV192Uftuzb9QGbZTUa0x88T5prE nFaZJm0uFH8GDDdnobe9yfqh63yNQaDwePxOdXawfPCuzVwgqXmsZSqJQUe9A4c_iidJjCjLXUsT ydInJr6gvHwK3MSC7TWdIAw815y0JAoXJKGTp3CYjc_6oruKWkpZCQsVEKp7qDpNlsV3.ZIT_IYI s.QoYo.mS1DK8fue5NSzN_VLCmJP3cffmhhZoCe3.eX3tCGpNXk1jTlOs.LGhpssJS3FtVUsOMYe od_L9GYLHpjZb_qfCB.pBwA6FrQD4z1GbbjSamaq1fPPw1UH3OgfxRgH0E9PiO95J9nbeT73gQQz rboyoQWyHNC1DQp0aq4F1fGpJVEu8igAkJ8BiofME3TxOdjTO5cOnQdIHK9N9MPsEcTQwHuf4FD6 Tgs7tG5_yxIlctyfiAZIL0GLW4EaaYOYj0oBC1X.n58yRcIMxciNy_yJfJjuOD1U4x.cPTUk6Xx_ l27iIw70H.jCg7ygiWBbM93yrkMZ2IdJlHhGkElBV5wSlLDetS4tvw4rgS0mT2mS2fV5RSunZyRm h699uNNsy42hnDfG9YY_BsdYHQ4K_N365AjisIhPzzDkNNPGxTW0m_9weeHQZuB0EKq3gzFP7HSi VpK61gi9vPgLbl27NTK5maahkGGnJdA1D7d_zGILo97HE3UA01yzN70aW6qoz_FjJLnSc5wQFVye .stcYV2Tg.aezeqYosvBNWutKIflXQo1lL3.LPKCs55IX1khlu1h7B6N5Lfm2UmDrHEIcEJziwbR 1vGKk8jYYd8z7hPMur.VgZP_qSKFJdsT9ihqDzyBIr9cXkkl.arkIlVKzKJ411PnxksS3zk_ZP1u r_1rOyeT9Zh5ChBRep0UPYd61WBUeT8QWdaT7H9H.nki_deLUqFJHODQmnapCfHgNEs35AWgV30q HrJ4HknGjgLrcl9i8ycDYZ257hBJhQ4XMQ7Cy0DoeTk3v1egR15iSZJ8JfILzvaRKeK74MScpGPn kBFza2RdDhEW06emzGoVToHHsvEvTSo.BOJj_kQhp0ZahGE2W2UEofSW3.agH33ICtl9ShsOSx2u hufqJ5PLzDt8vEK6pAXD18xlp.5.ScEVwar3HEYxfiJWlgsggoYoTEEqSvLW8ye9N8A7CqhCIlPb 7NPJWeBREfF3wL4dEwDXTTDMdq8ZUl3DqujPkFXYaZtZBGnRit..vxyhzQrIvMeS5ZENvcaNB2Nl 4SPVxZrtvhcQnjKpjAwux1SjTOscQ_THkUbYOKGYhaOZng0VSLFr74GseHSPqYxsMVAuGXGvPjUF KxYsk9vIVGusQIHH_8ffjECI1HKsBFKZoBCmbMldFkCnVdnZH8r5RNUYqvvUPb0Yn9VejwBwA8N8 Y93KhQKuBMULbwvAQp46HrFV.Z0wPvbIz9VxAQ8hbm3_88LDSnHaIX8_k.6S38WtJd1pBp59hZYy Ga5uSWUE9NAZrLrtLAqe_2BE9F0GmbDzggxOiMfRJK2MWCyz6cVsmfqncEum3By6xJgY9.hjIW.R 93TR3p.qPq_ellclm2Dg.SR_vRDvUN5gc54ztNrbYTX7nfDRJckYr6soQEeMiw8S8PRr4ZES9yNy ht6MD2cOSPZV0tgTquGNOaS5OGNlM8mPUJYPIG08LByup2GJYctFroK8DPR9wVVFql1KFw392.We 6xif0Vo6.lLOHWUTmFXIc5ulC_4aYpg0bvyWVDk2ZaCovVzj2CJtHDPDzEju9uFLijXs.65daxW4 9.jhGHUwKFkfqFsvHzJOHRecTQ.tUI5rbvlLECdhUyVdFuGV._ds5YE5EnyHiefFqYPHVBxfnknB SCeTyzTvpvN93_apC8JFQvSHQJUQqr8.K_mAv81XNR6Fb3LWCKykSPivDif9SKNvi313BMITmr8P 8Wf1t7AO.ju2UPqVFEYqYLpN5xqLgU.nCGvxQK0iePTGN5E9KxBXFHntuqVURu9BYykc84Xw3dNU 1GN1JeBCa0lQRtUPYt9dyFWzCxibw3Ao9VXgl4ZwKtd_xWVtDilGxTy7xzFb3zI_mvyP8wCSFAI5 mgC1TwonvK4HC2EjTHLMJtlAs97tXq90QoKevHpXFangdkYAS.Uw7JlNxdhLctciwfGO3_4hfW6h NioSEdMpV51eNIS2O7UxIN.0CvfcUJlqMkPYZCKddWlDsHPjj_6dwRsC61HHWdcrqggGkDddqlhQ jSfzxR5ve7gFcjZu7qtiJWKA37DjMkAhzRjHPs5S3PjxEnZbm7dFFUKTxBF19w.raOqhe_JkMCoj W.vlxqgtZl7k-
X-Sonic-MF: <nalini.elkins@insidethestack.com>
X-Sonic-ID: a191bd4f-c648-4c2c-9e2b-021306d00e78
Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Thu, 6 Jun 2024 21:37:16 +0000
Date: Thu, 06 Jun 2024 21:37:14 +0000
From: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
To: Warren Kumari <warren@kumari.net>
Message-ID: <2020979255.1593560.1717709834569@mail.yahoo.com>
In-Reply-To: <CAHw9_iKo+aacY+EO+C5ubfJYRGw9osH1Yv9GOaG6KDLbfpyq+Q@mail.gmail.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> <CAHw9_iKo+aacY+EO+C5ubfJYRGw9osH1Yv9GOaG6KDLbfpyq+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1593559_108380385.1717709834564"
X-Mailer: WebService/1.1.22407 YMailNorrin
Message-ID-Hash: WKXCS7DVIDWGUMS3VOEDK2NAFVKPOEG4
X-Message-ID-Hash: WKXCS7DVIDWGUMS3VOEDK2NAFVKPOEG4
X-MailFrom: nalini.elkins@insidethestack.com
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" <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/9Gfn-3ExO3XtOCuDG-k-DkYH0oM>
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>

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

No problem!  Rwanda sounds amazing.  Have a great time.

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
https://www.insidethestack.com
PresidentIndustry Network Technology Councilhttps://www.industrynetcouncil.org 

    On Thursday, June 6, 2024 at 12:53:01 PM PDT, Warren Kumari <warren@kumari.net> wrote:  
 
 



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…

W

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

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".


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