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

"nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com> Wed, 19 June 2024 14:24 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 BFC4EC1DA1C7 for <ippm@ietfa.amsl.com>; Wed, 19 Jun 2024 07:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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 lXeRi9onDk71 for <ippm@ietfa.amsl.com>; Wed, 19 Jun 2024 07:24:38 -0700 (PDT)
Received: from sonic302-27.consmr.mail.ne1.yahoo.com (sonic302-27.consmr.mail.ne1.yahoo.com [66.163.186.153]) (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 8AF48C14F696 for <ippm@ietf.org>; Wed, 19 Jun 2024 07:24:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1718807077; bh=NcDaOYhiMUVz4JdfrxeNO7yFNHuFjEo/k3Fnbgzp6eE=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=frwMDJ0U4lMOdlPUOPtQE7WopiNQUKWhQ0r9fibiCcrAfbCRprgA58EncX6ql2LPOiU8nT0wLWv4IdkmJ4HFEoUj0PnjgE0IVx8lq45X/0s2pXT8ewsfiR64pJdRdNR+wLp7PD+WFARrBkqyxpViUlgCWS1nPBAgj0pKFsQbtM0TBVy3nnYT404LWQjo6CrQP04nq6o9k8uvG87K25KqRVwoxoinxQd879desuKNyoxWdyMUr56AOmXFdxKZ4aHHEiYfMJ+5ob9Gjt8JQUGzNGAxNiWxcgA9ojigLSksxp9hI0infPrPmAW1y3WoGpZpqVLAWHxI/dpZY6jX+zfPjA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1718807077; bh=h5IeZyrDptgazEuVF9sz/SdM14lAZ/I+FA8OptmXFsp=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Y2aPxkVMLLWzyrBtedmFnY7LjcLLx3NyBXSH2hWhXm7S1mHcb04q0iDvkOXd8Zk1scCc92TYbl+HhPfZQybYSHJkgLWzu4O7GavO4e4k0epm6eLfrtYgFgpDzxL0AnqiYuJjptSBcaU2hwiX6A0Z4IfbMgFdJdKvMM6XZJrNEWWCrWfttb9kqEUpYbLkoUUvP1JEsx3+ILFok/c/vH6tNfyuYE5PRr0IcXRgoSroFpoK9tp0hif2HdWnoR44UMCHrVUTE7jJP8QO21zOAW9FrrdfSGqqAcQ+tO8vD22hZZ9qpVXn3Cqbxgc4/bihAxW+ScreZbWTefyo4z2bhYP9vw==
X-YMail-OSG: Cn968h8VM1n4pQZWRvvPPVGMDu1ciURLvhJ_HaAARDWu5uKFjY1t1G.zRvDsGd8 XlRRw49TxHIgVLI9D9NU.rbHzljeq5NfFRE7_BOJpYu7rKaOsuw3RlpCiNMKPW72FrgshmCcMUkc _5e2gqsvEmGnUgbybpsRoXWPucY7qzUxRQowDK.OIAXXN0Pholh7Q4KHg1kEx4rddyqj6knezUGv L7i_BDZzPrTqSJwPeFjQMJZrvI4JkuUoEEoGgRS4RGSGjthDxmYpaWuNvR3lgD3I9JvFyMfNgeG_ syX1hPP22y_2q.N2DQ_xjNKioCNfnms80xlloV92K9WwZJTTZod7oYj1vVXJDfyhD_4sivwitELV HfO6VICNDxQAewe2sZhghA0eScKxMgEK8uLcdcxgPQz1ERver6.SKctDMZX1u1UQ4bfj.jDxooa5 JzSOCnd371xEUC0NJYP.qnWoFSq71n8uXDK9BeCnFM_bz3TrwA2MNFuEL_20MF3x5XdRSkSwVAh1 6xV5SSnTVnHH8KMv1ZQIeKXtvgfHeiwvA0xt2JBIfCxWgTjOqSFiysdHPaElBt6ZCdpZkNhBgHjO QHf.8pxUD9_dTkzRtGd4g50i_fv1wkuYAw6jQeoJtBdafquDGXFOlBaefa_Z.xcHOkJIjvL99.4X nYd12ntQr8jObkTZwWsh7BPNo5BszJhyk5iFlmezEI6zXP_Mn4p6qMJ1fOKpPj5HAoBwyj9OghDR q0aZfxa10tCKmPZ1uUDSqhsEW76cO_keLeU_hkxCFxmtwQmqb3mFHDn5.Oe7.1nE76g6SEndEvms ccePCM2yHWPTqeDWB.VDlRiQKTRn7LtUk7OuARNxPd7rGESu3s_.F1ot.eTW9SnqlOxfMSBUxram aHZkDIqC.L64cOpC6aw0yzblpXUHbTh.QevGKhQC6ZDC6iFH4iUwrtMMA95mKhPXLe9raw6A0lLg aGvP3Iher5NcMet5XnO.sfz___0Nb4ySKyc3.ncDuPjuk6lG.BPXeM_H6Iv6BDu8k43MuuPekmx0 LkMdZe5sHDqNMBQii5zMji3bMetUPbtRgjt4taHNbJsUZT0xczfE1seYk7mz8unXZMI9Mqf8u5qG I6.COfG4V0gDRFcuAoNPhthIkcQJk9udnd.erNPqvjbtmXzRK.mB9eJ8LB6ggL0UEnxWYpv7oRIY yGcf1lnOZQ8VylPRbFYtCNn60MSfscUa4wxNZxHyX4Gdout10ALx6iTyNdLmos3VCMDtV3BAoL0q 52rWanRltHmbcYdJSDi33TIJcMZccZeSial.2vb.c4rWT8QRrTw7bxByNOemIv2SiZ1dBqHToWKL t4vEt3w8AG45EIKhuSodTp5R2ldEUTH.2Va3uYHrcIF60OZ5LBsM57C4nsK_FHqNQ5D9jOokKMT1 UOrBvdLa03ncueDvKqFEI4e8jlFDMJBUmHybWOXOdDHEvNYSnTbXKwvr7qP4oMBk_K07RT88dTxm cM.40xAfYC4uIMrZ0aoFWKcryDt.kcKJ4s.wuzuUUUHiDGuHVenvvqy38or5Lxollvp8G_l2J6te HO.BauqE4aIJIMDkh0np3FnjU6IkZJeG2nj0pHsGC10rliT5eWnav23yF.z6zA3tSpls3AmcABCe gnkb8xmrWnXtCQlizNewrw6MacF1PbdBGHFcCBC_41vlV.xbplG4DEGSrmXQToyO7BiHV0OBZtzK uc2ydzRSZdDri4t9iDQjtlqNAKC5WWA0MNhu068sJ092rKZ1kncaEJGMx5SjUdV1xoY_4Dv4VGhu zeQ81N1OJOvmCMUVxVFvNcxZiXfUGNGaLU48c96FrPHuRUxg_.sAtKn4dXx5NJt47D1p8S_dVZTA DpD25ZwZvWI1DUEhsongJbV99WFCezclV1P5ukc0vuNpbXRrYVhI35glUfDbIgyCs6lbQpKXU8KZ u5a08Epjy6DnzjhKvYDigv4r1dy7EpFIoJQQbheIRcuy7qYZkv2yyYQmkAk2rhgxbmm25ZdlsLwk 8Jdmj2gfcVEEH7DfdUwobfc5yA.BhCtJ2qSgzjNk.g6oSq4pxGEedTyJo8gauAYiOCH1busVHV8h OWjsEIIDamksEbpqxRQss_u0uEIRNHGdr8MlaMNPUYmmNxkFR2_nbgvxUTr0cwZlAR_8siaPMuTb o2myBuh4IcY_IIErXwOErb1qsyW29B7tbFlt53SKBBkJVCMfD.9nZmJxN6d1qzOygfQtxn6TJzMW 6Qt2obxtBLGC4yH103ps1KTW2WQRwrZa4uWSrI8cxb.nECd_MKmpyPKTp7G7JynKlds6f0iI.Rlr h_cYyG1q6cBLVGGjtxkaMJ5GLNYbzVrhzC1PwPCYHyMf3s8KcEy436nbJTx4udPxnJGnm1LLN5sN Mlj6.T0NokHNaaMP.xM94Ofcy6sBwriDec_iFnx5Nhpy1z3B6kWDxgOxd9EDAJEhdrwvxOfkl2fQ j9eqjlaRIJzMuzO9EZRWm1ZDpb57vZyaFNLieIFQ8Lv7AyAcAA87ZeT5FUFAh8LEI7vnSOz_Ifku etWuHPrMHeopGGGBY4e5f8bzP6nS.8NAX0QYebvOtsFQqCNtr.sjL3b6OiI95ZlajhCANGOw2rKJ .II9XmLQVcV6K
X-Sonic-MF: <nalini.elkins@insidethestack.com>
X-Sonic-ID: 5fe41817-74c1-4007-a8d3-23796220d840
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Wed, 19 Jun 2024 14:24:37 +0000
Date: Wed, 19 Jun 2024 14:24:32 +0000
From: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
To: "draft-ietf-ippm-encrypted-pdmv2.all@ietf.org" <draft-ietf-ippm-encrypted-pdmv2.all@ietf.org>, IETF IPPM WG <ippm@ietf.org>, Warren Kumari <warren@kumari.net>
Message-ID: <951074823.7724247.1718807072150@mail.yahoo.com>
In-Reply-To: <CAHw9_i+6FZyEfRPr=z_1YzLBrB4oSCqgSfJ8cgLWCw9orPBO9Q@mail.gmail.com>
References: <CAHw9_i+6FZyEfRPr=z_1YzLBrB4oSCqgSfJ8cgLWCw9orPBO9Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_7724246_534245618.1718807072140"
X-Mailer: WebService/1.1.22407 YMailNorrin
Message-ID-Hash: 44SVH7YBGTEJDSHQCXUBQPLX2AVFFZBX
X-Message-ID-Hash: 44SVH7YBGTEJDSHQCXUBQPLX2AVFFZBX
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
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/Jh53WBZEABuP8nyBlMPyZ8ld0kY>
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>

Warren,

The updated draft is below:
https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/

Thanks for your review.
>  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. 
Done.
> 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. 
Done.
>  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?)
Changed to:
PDM metrics can help an attacker understand about the type of machine and its processing capabilities.  For example, the operational capabilities of either the client or server end hosts such as processing speed -- that is, if the system in question is very fast system or an older, slower device.  

> 3: I think that the following sentence can be dropped, or the two following sentences can be combined into one…

Does this refer to the next point?
>  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".
Changed to:
>  For example, during the debugging process using PDM header, it can mislead by showing there are no unusual server delays.

> 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.
Done.  We like your wording!
Changed to:
In this document, the Public Key is represented as pkX and the Private Key as skX (where X can be any client or server).

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

Removed.
>  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?
Yes.  Removed.
>  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…"
Section re-written to say:
If a client sends a packet with a PDM option which does not match the network policy, then the PDM option MUST be ignored and processing continue normally. The server SHOULD log such occurrences.  

Filtering at routers per [RFC9288] on filtering of IPv6 extension headers may impact the receipt of PDM / 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). 
Section on Global Pointers re-written to the following:

Global Pointer.  The existing PDM fields are identified with respect to the identifying information called a "5-tuple".
   The 5-tuple consists of:
      SADDR: IP address of the sender
      SPORT: Port for the sender
      DADDR: IP address of the destination
      DPORT: Port for the destination
      PROTC: Upper-layer protocol (TCP, UDP, ICMP, etc.)
   Unlike PDM fields, Global Pointer (GLOBALPTR) field in PDMv2 is defined for the SADDR type for the node.  Two SADDR address types are used:
   a)  Link-Local
   b)  Global Unicast
   Hence, there are two Global Pointers.
The Global Pointer is treated as a common entity over all the 5-tuples with the same SADDR type.  It is initialized to the value 1 and increments for every packet sent.  Global Pointer provides a measure of the amount of IPv6 traffic sent by the PDMv2 node.
When the SADDR type is Link-Local, the PDMv2 node sends Global Pointer defined for Link-Local addresses, and when the SADDR type is Global Unicast, it sends the one defined for Global Unicast addresses.
The reason for the Global Pointers is to provide a rough estimation of the the load on the node in question.  That is, if the node is sending many other packets to other destinations at the same time as this particular session.  Given that goal, if we combine the Link Local and Global Unicast, the traffic traversing the path over the LAN or VLAN (Link Local) would be combined with the traffic traversing the path over the internet or wide area network.  The nature of Link-Local and Global Unicast traffic is quite different, hence the two separate counters.

>  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 think at that point the Epoch would also be incremented.   So, given the example:
Epoch 1 -  PSNTP-500
Once PSNTP becomes 500 again, then EPOCH would be 2.  So:
Epoch 2 - PSNTP 500

>  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…
Replaced "rolled over" with when the PSNTP 16 bit counter exceeds 2^16 and reaches its initialization value again.
The entire section now looks as:
 *  An Epoch.
   The Epoch SHOULD be initialized to zero.  A change in the Epoch indicates that the SessionTemporaryKey has been rotated.
   When the Epoch exceeds 2^16, the SharedSecret SHOULD be re-negotiated.
The Epoch MUST be incremented when the Packet Sequence Number This Packet (PSNTP) 16 bit counter exceeds 2^16 and reaches its initialization value again.  Epoch MAY be incremented earlier, depending on the implementation and the security considerations.
The sender MUST NOT create two packets with identical PSNTP and Epoch.

>  Please let me know, LOUDLY, once you have had a chance to address these and I'll progress the document..

Thanks,

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

    On Wednesday, May 22, 2024 at 03:03:25 PM PDT, 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".



| 
| 
| 
|  |  |

 |

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

 |

 |




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