Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdmv2-05
"nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com> Sun, 25 February 2024 15:16 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 C8875C1522A0 for <ippm@ietfa.amsl.com>; Sun, 25 Feb 2024 07:16:09 -0800 (PST)
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, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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=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 tk9KRzn3e-mH for <ippm@ietfa.amsl.com>; Sun, 25 Feb 2024 07:16:05 -0800 (PST)
Received: from sonic315-26.consmr.mail.ne1.yahoo.com (sonic315-26.consmr.mail.ne1.yahoo.com [66.163.190.152]) (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 4DEF7C15108B for <ippm@ietf.org>; Sun, 25 Feb 2024 07:16:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1708874164; bh=/1CrlOaakiX3207XOo3Wbdhi98w6NXiuvwz4xNDHZuI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=adY+grA/bUrtnnCGXUGg6iSQbBLv/xtyw5YiBBdaYjpraHke1V+j13GXhvH7csr6ofqzoppruioCrPY6ukVAdgFkJLhwZWHicoOV2nq6rxSDNzXvPVSrRMUjCjXYTTcjv7lqJsFIho/EQXq49VnI2uRCEju/O5LP+0w2EC3exfU4tt0p3Uni9reYc2X9sydEEDlU7LYFIcQi73VjTlnT0I17ZxlLRdg7oSdVqPEvU+k/zJGep46LaT41OmdG7ZVXxJbdkV2x638GVqQWIcozeytp2LoerKDs3CfQ8rihaQNr/F+dAs86Fq789OwdedbHDqeF+kNl9CXMerC5EwmIQg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1708874164; bh=wjjTNh7wC31bqiwucJyR1HSvNr9tvgF+eBCcbR0C43f=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=fqfRchbQ9Y2rhqyimhV2Po050hoV3C9asCriVLl2W7+SLMm9UBcVVpW8b7xgYQ1IZ17wo8oyVzt9M2nQpQlkILKxB8NhCWhWLM24qGCAZBLWSd+LmSj0RH7nHQA9gVvLhPpX6+zNfLHm37OOSSpixQzTMWQwGiPd1jAS/G2VNps3j74ctcmiiGjyR8kcb7pwvta6KKCXVmeONLHvzYxdukEVMTzX6gElj3FszWdFBRceluyNQPYLFEbzK+tjSne/je5IALnbEV0LPWswISaXvqGt5NtZm7YDWdXQIKXrzjW8D/VpdoeTLPvKmHO0h9vBpDrbtkMroVgXIzq2L0n5Pg==
X-YMail-OSG: WP13bbQVM1k2F4W3karQK5tSWSflPx.J.C5hs1kK0fVM2WeaRrLzX6xvNP6mdA2 .KoSZ7n38Q3Q5xWGvfrnLjmopwId7PCvM6WJmoYOlcL.Dngsu7ndlvx_rGTpHhNqczqlNTgdNiCO dtdNnFJ8FHNM_SQ_v8ZsblESdAkgv4yq5r6mjZG2hgy5CWqOtpjGi3y5bS_tn9NKgkvrJhb0ZRxk ERlPhszYIsf1mY6u1rIAuNXSzXW1d_exzhHBH3bzSYrqoMERp23SqvVNhTpvafvXBQR5pDzsR.Ky IfnIpy27gfubaW6kZz0m0wuhaSACMCyCW2Iw72hnMMkJepYAFaPeyjwsTc8gr0HMxvNj42SyAA5y 7xkOciVepc3duEcQ5URn3lRTpNVUVhIiOH36c1l056doPMfH91PNqDVU03TSv7ggnBHxdRzThI6B iKAUOqKiXDrKB0X0jZW4KNazsQ_dEccoV5ZsQKgiShM5V_NGLw5r2KNrFr8wnpRnQ2XFafzAPg.t xqc_eM7pFCGk94TEDKoQnbEoUNfdKWk6k_i80XtMKE8c4UF9Jpe8CM1xiJLm_vVfLAFjmX9ke2In tA7CXh_RZZIBnm_PfIyIDkvPHmeVu.GpWdUSgN1ycuLiL7ZdYC0z8BCVfaavL5cGsLzHSlMSvHDz q0b08y4vqqXtiYbO6HHrt7a31XUBhgwGXPxUHK8sZTSZ1R5FwIgMsrv8veQ2gLNhVcNaoKC32ifG DlBUAg11US.O4q5AwVceP.0GisprSzUiYXsTvOFvaooR6wGI5tNp1vSSXVhPknyFQiU794f7cuky bcYvQbuwWm7EylJCkasjwFQimOhQAHFOCrMFj72Ca4TgPXNw62ddahNknpH2M.36wazsnJDbNCaI rgEZvVZcZxUuGPuDUVk5O2b_OnLH6.aHmNToOSQK31mJslXM5_Z5NESg5XNJqQBUQ40.LQQXUK3t _1vkuDYkRATyXiC2JhJksTwdJHk6383FmYoQZxXH3yD5RzsWC7P0LTqNkLVf4t5D3ENxVwBcwMY_ MX35.oHRQDJx6vMjCIMHCaRGztdGW7GTyx7Ny6Xi9cJkdFWidbJii5q.ZAGgYaInBCd1p8G0S753 W8ZbYJyNOAcYdtHh.z5BeXBj.sfquMJG26cVlZ481Qq0T7TXQyoZX9f_mHkTKoZ8KMPlULqCwiKs 7O7g2lqL5tDnliEj6g9fQ8RBP5tNSIZe1AdyJ3tDWlHwumn2En7aOmfmC6cFmFK6qoKGgJZ4uQQz t.dYfwssrU1Bk8oj2zmIXtLIvW8Ropb.P.cu0I9DQ13ZOVTkj3eMmZbk8NtQnnBGI08NJGo04IZ9 0xLqEws7CylRhjPTcSSu4kIIW_4WFCSV0dH3zOEPS2l0Sk1bpV8kdN6p6F9soBOJwC4W8NZQYmWq bBa6rANY9x.WvQerbSyiy00LZeuoVL9CSIatEPIRX5SAd.18uTeEbCfLwJhUi.P_kxmNiS5Q.e1R czwpsdkO722Q6Bc7Yjuw50lIcyQdlr4pM8J_r4dN81IwSgdjJSszC2i97jKkPNjqAojeRfbQe7ck JSXY5xINNs7aOxkzBrjlVsOjIab9LicvwuLGxs8OQkuTb.mOiwEEul6KcZSzM5lwxW_tOc9rhKTX ivj8JYFQqxtA_9jRfmBIWR.ck.IytkUZ8uTkU8I4ObD8PfQyQyfg.okVxnm9SK5960YZfKEs3Di_ udqMx_LzZt.WpPmFGfggBn3R_n5z5VZ3h84mBljHCKA6zE8Cm4sze_UlmGIMZDf1mAMTSf5yrMeY nAedaXmiA45SPVoLQiY6pCXOgL36W8MvyOP1nzi.qF1lUWYyHLG4pyyN9BiSRBE53kj1Azpk.CCR HczXK7Ktop7Kzhks2Fe9sfqwuvGvKL_kPCedgcKIKo3WeJoNKUm14Tbgm_MdvpJiJH63SfXIe7RD oqKx0g4pmp6dRuPpzMhyQ6ypCccm6i2LOdPTgCNi6uSfMl4SxPLGsAoVjPx02jV.0CbuhoQMj8WF co64Mu6sSY3CgXzQEsr.oDab0CrIYo62iS5Fc0YaSlkOdqDesaYhMN_lfwgveAVTTAtpyLLLLO4W WTmWeBIYlaLAJ_fl6eqNKHyQNOvnwXduF0iZLVQrtb9qFqVsZjADBJbgMTMA3eibcw_gjBVxkCWb CO.mldaL0AKRvfNL8Ig6JawqAdwa0HQ6Qv4p7PJuu9cpghkG7hrBsI7sAIvnQQ9yIQFsWA90WsPe xAvSc3r4fj8o8.rskbQUGGBCJ9WFiHQcEJuCJ2RE4gbPoCdEgNHYfI6aSnnTX07qq07E7yKAz7A_ ieJH2jRqoYHkTkr7wGoXO2nBdFHubGF4MQtNkcGROHl4aCsocgAYr1K_e7OI.VrLfls7fGgM7p9j ciS4dCubyLAvwqytnOKctePL4tsh2Yo1UaLanTPWzyzHHmF_b30Vp6tetog.8ePY0BWiUHYZ_PqP BmyjDRJ2yANirvZisDmFU8uRTxome_dpJKbwUEGs9.7L5stjb_XYVd40NFQIOdR2oKKb9DeEPmQI Ph8E7OnjuuabqXbtzTn5Dz3C.70e9HiYLKJ.Ln7RFvdqiOdbXM92MH8A9rH4Z9E3.54tq3AzR5tA 73ZbOE17Rg0rmt0hVpjwZH1LqmjIkMBolS1pq3JjT1rqhZ60.Hf8kxu_TngzCAtK_wlLjgeyHuXk JCybbRfPAGEECKgINoAC_l9PwF1v9mKliVn9IE3JI0cDS0jdRgHoeILnAbIrY3SPZGz3MYbrCMOs 5DwgeAKT6DPEt4rYwR6YBw.fHtLG8
X-Sonic-MF: <nalini.elkins@insidethestack.com>
X-Sonic-ID: 05804a2c-1b37-4846-b6ff-5f408cd05309
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Sun, 25 Feb 2024 15:16:04 +0000
Date: Sun, 25 Feb 2024 15:16:01 +0000
From: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
To: Tommy Pauly <tpauly@apple.com>, Dhruv Dhody <dhruv.ietf@gmail.com>
Cc: IETF IPPM WG <ippm@ietf.org>
Message-ID: <1575868539.484245.1708874161623@mail.yahoo.com>
In-Reply-To: <CAB75xn7__cjMrGWjTXv8-QgZ4+AoGiXWQAaJob0_zLJLOPbPzA@mail.gmail.com>
References: <61AC7432-55A9-4E65-A1FE-CB23B3B414B0@apple.com> <CAB75xn7__cjMrGWjTXv8-QgZ4+AoGiXWQAaJob0_zLJLOPbPzA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_484244_1798742682.1708874161618"
X-Mailer: WebService/1.1.22103 YMailNorrin
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/9XmsTJdxsLHsZyFtAnlA5xpOtJM>
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: Sun, 25 Feb 2024 15:16:09 -0000
Dhruv, Thanks for your comments. Please see inline. A new version of the draft has also been posted which incorporates these changes. https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/ Nalini Elkins CEO and Founder Inside Products, Inc. https://www.insidethestack.com PresidentIndustry Network Technology Councilhttps://www.industrynetcouncil.org On Saturday, January 27, 2024 at 01:53:25 AM PST, Dhruv Dhody <dhruv.ietf@gmail.com> wrote: 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. Done > * 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. Done > * 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... Added text below: 4.2. Implementation Guidelines How should a network administrator decide whether a client should use PDM, unencrypted PDMv2, or encrypted PDMv2? This decision is a network policy issue. The administrator must be aware that PDM or unencrypted PDMv2 might expose too much information to malicious parties. That said, if the network administrator decides that taking such a risk within their network is acceptable, then they should make the decision that is appropriate for their network. Alternatively, the network administrator might choose to create a policy that prohibits the use of PDM or unencrypted PDMv2 on their network. The implementation SHOULD provide a way for the network administrator to enforce such a policy. The server and client implementations SHOULD support PDM, unencrypted PDMv2, and encrypted PDMv2. If a client chooses a certain mechanism (e.g., PDM), the server MAY respond with the same mechanism, unless the network administrator has selected a policy that only allows certain mechanisms on their network. 4.2.1. Use Case 1: Server does not understand PDM or PDMv2 If a client sends a packet with PDM or PDMv2 and the server does not have code which understands the header, the packet is processed according to the Option Type which is defined in RFC8250 and is in accordance with RFC8200. The Option Type identifiers is coded to skip over this option and continue processing the header. 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. 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. The routers involved may have implemented filtering as per [RFC9288] on filtering of IPv6 extension headers which may impact the receipt of PDM / PDMv2. The organization which manages the network within which PDM / PDMv2 is sent should take care that the filtering of extension headers is done correctly so that the desired effect is obtained. ## 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/ Done. >- Section 1, it would be good to introduce what PDMv2 is before stating "PDMv2 adds...". Done. >- Section 3, mentions terms pkX and skX but never use it, is there a reason they are defined? Added references. >- Section 9, you are reusing the option type 0x0F defined in RFC 8250, you don't need to ask IANA to assign one! Changed. >- Section A.1, is there a reference to the primary-secondary architecture mentioned? Removed. ## 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 Done. With the exception of Appendix B and C, as I believe the RFC editor does this. 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. IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option | | | | | | | | | | | IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Op... RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers... | | | 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
- Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdm… Dhruv Dhody
- [ippm] WGLC for draft-ietf-ippm-encrypted-pdmv2-05 Tommy Pauly
- Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdm… Tommy Pauly
- Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdm… Mohit P. Tahiliani
- Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdm… nalini.elkins@insidethestack.com
- Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdm… Tommy Pauly
- Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdm… nalini.elkins@insidethestack.com
- Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdm… Hamilton, Robert
- Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdm… nalini.elkins@insidethestack.com
- Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdm… nalini.elkins@insidethestack.com