IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option
draft-ietf-ippm-encrypted-pdmv2-09

[Ballot comment]
I'm uneasy about the SHOULDs in Section 5.2.  What are we trying to say here differently than the "should" instances elsewhere in this section?

[Ballot discuss]
In Section 5.2, you have:

  The server and client implementations SHOULD support PDM, unencrypted
  PDMv2, and encrypted PDMv2.

As I parse this, it makes it possible that an implementation does none of these.  Is that okay?  Or if a client supports only PDM and the server only supports unencrypted PDMv2, both are compliant, but they will fail to interoperate.  Is that okay?  Do we need at least a common minimum?

This is reminiscent of SPF's original specification, which had a similar problem.

[Ballot comment]
I support I'm uneasy about the SHOULDs in Section 5.2.  What are we trying to say here differently than the "should" instances elsewhere in this section?

[Ballot comment]
I'm uneasy about the SHOULDs in Section 5.2.  What are we trying to say here differently than the "should" instances elsewhere in this section?

[Ballot discuss]
This document is not ready and needs to justify its use cases and implementation
choices much better. When it folds in encryption schemes, it needs to document
exactly what bytes go over the wire for establishing the security contexts between peers.

Details follow below.



        Inferring from the PDM data, the attack can launch a timing attack.
        For example, if a cryptographic protocol is used, a timing attack may
        be launched against the keying material to obtain the secret.
       
Can't the attacker already infer these from the packet stream, even without PDM data?

        PDM metrics may also help the attacker find out about the network
        speed or capabilities of the network path.  For example, are there
        delays or blockages?  Are there alternate or multiple paths?
       
Similarly here, doesn't the attacker already infer this based on timing of the packets?

       
In fact, RFC 8250 in The Security Considerations says this too:

        Let us discuss fingerprinting of the end host first.  It is possible
        that seeing the pattern of deltas or the absolute values could give
        some information as to the speed of the end host -- that is, if it is
        a very fast system or an older, slow device.  This may be useful to
        the attacker.  However, if the attacker has access to PDM, the
        attacker also has access to the entire packet and could make such a
        deduction based merely on the time frames elapsed between packets
        WITHOUT PDM.


The remaining part of 8250's Security Considerations mostly talk about
revealing the application, which the port reveals as well, so now this
concern would apply only to v6 IPsec packets?

Second, wouldn't adding encryption of data significantly modify the timings so
that performing the measurements would invalidate the measurements ?

Section 3

The encryption is not specified. How is this done? Which kind of key exchange
is used? If so, how would this key exchange affect the measurements? Also, if
doing a key exchange anyway (eg tls or ike) why not just use ike/ipsec or tls
and protect the entire stream data. This would also hide the port, which also
fingerprints the application used?


Section 3.3

I don't understand how the unencrypted and encrypted length can be the same size?
Unless something like a one time pad is used.

Section 5

Why use HPKE together with another key exchange to prove identities? If you use
TLS or IKE, you already basically end up with a shared key. This can be used
with a simple KDF to create keying material. I don't understand why the setup
with yet another private/public key with HPKE is needed. Key Exchanges are
very expensive, far more than encryption/decryption or hashing/KDF operations.

        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.

If 8250 does not provide a method for this (and I don't see it does),
this SHOULD does a lot of work.  It basically Updates: 8250 but without
providing a specification on how it actually modifies the IPPM protocol.

        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.

How does the server know this network policy?

Section 6:

        As discussed in the introduction, PDM data can represent a serious
        data leakage in presence of a malicious actor.

I don't think it did show "serious data leakage". In fact, 8250 considers it
not serious. See my reasoning above.


        An implementation SHOULD attempt to detect if PDM data is forged or
        modified by a malicious entity.

How could it do this? Can you describe this in steps that an implementer could
use to detect this?


        An unauthorized party MUST NOT be able to send PDM data and MUST NOT
        be able to authorize another entity to do so.

How could it do this? Can you describe this in steps that an implementer could
use to detect this?

Section 6.4

I believe it is misunderstood when HPKE should be used, and when regular key
exchanges which authenticate and setup an encryption key should be used. The
use case for HPKE has a lot more to do with creating groups of participants
that share a symmetric key, and is not used for 1-on-1 peer exchanges.

Section 7

I don't think this section is written properly. It should be about the security
considerations of the specification. Instead if seems to be clarying the use
case for the specification, something it already did in the introduction.

        attackers with the ability to intercept packets can conduct passive attacks

"intercept" is an unclear word to use for a passive capability. Intercept can mean
"prevent delivery" as well as "see while in transit".

        In these cases it is suggested to use IPSec ESP [RFC4303]
        in tunnel mode (in which case the PDMv2 can be used unencrypted).

Indeed, this also protects the protocol and port numbers. The case for encrypted PDMv2
is therefor very weak.


        A direct consequence of modifying the performance data could be,
        for example, to hide an ongoing QoS violation, or to create
        a fake QoS violation, with consequences on the violation of
        Service Level Agreements.

If you have an attacker in your network that can modify packets, the cited
issues are the least of your concern? In fact, your authorized endusers
can do the exact same thing as these attackers.

If an attacker can insert or delete packets on your network, again performance
measuring seems to be the least of your concern. Note that dropping or inserting
packets would also disrupt TCP streams and UDP applications that use their own
sequence numbers to detect packet loss or duplicates.

IANA Considerations

I would expect an encrypted version of PDM to use a new option in the
"Destination Options and Hop-by-Hop Options" registry, and not re-use
the 0x0F value for unencrypted PDM. Why was it decided not to make this
clear distinction?

[Ballot discuss]
This is interesting work, but it currently reads as if it is a guidance (informational) draft.  There are many missing details and significant issues with the crypt parts of the draft:

Section 3.3, encrypted PDMv2 header:  If AES GCM is used, then there will be data expansion for the IV and integrity mechanisms.  The encrypted PDM Data cannot possibly be the same size as the unencrypted header.

Section 5.1:  Please reference a normative source for how this should be done.  Using the TLS handshake is a good option.  Referencing it would take care of many missing details.  Currently, there are not enough details here to make it possible to implement securely.

Section 6.4:  Again recommend a normative reference that will handle all of these details.  Currently this section is not sufficient for implementation.

[Ballot comment]
Section 3.3, Epoch:  please state that this value starts at 0, and is incremented every time a new SessionTemporaryKey is updated.

Section 3.3, Global Pointer:  Agree w/ John Scudder's comment on this (including the privacy section comment).  It is not a pointer.  If the name isn't entrenched, it should be changed.

Section 3.3, reserved bits:  Classically, these should be verified to be correct (i.e. all 0) and then ignored.  Given this is inside the encrypted header, it should not cause a DOS.  Please add the 'verify to be all 0' requirement.

Section 5.2:  Why is this so far down in the draft?  Recommend moving it up closer to the top of the draft.

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-ippm-encrypted-pdmv2-09

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tommy Pauly for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to Carlos Bernardos, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-ippm-encrypted-pdmv2-09-intdir-telechat-bernardos-2024-10-21/ (and I have not seen any reply to Carlos' review)

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

## Section 3.2

Does the "global pointer" also count packets without PDMv2 ?

## Section 3.3

`The nonce MUST NOT be reused in different sessions.` what is a session in this context?

## Section 5.1

As noted in the comment part of this ballot, not all communications (e.g., ESP tunnel) have layer-4 ports. So, what are the value of SrcPort & DstPort in the HPKE inputs ? (text saying 0 in this case perhaps ?) The text in section 3.4 of RFC 8250 is not sufficient here.

## Section 5.2

Should there be mention that not only the authentication is out of scope but also the choice of crypto algorithms even if some are recommended ?

[Ballot comment]

# COMMENTS (non-blocking)

## IPv6 reviews ?

Was there an explicit ask to review this I-D by 6MAN ?

Especially since the basis RFC 8250 is unclear about where to Destination Options header with PDM is located in the presence of a Routing Header. I.e., clarifications would be welcome for this I-D updating RFC 8250.

## PDM ?

Should "PDMv1" be used everywhere for the legacy PDM?

## Section 3

I find the location of the packet format weird in the flow, let's first describe terminology?

## Section 3.2

Unsure how to parse `The existing PDM fields are identified with respect to the identifying information called a "5-tuple"` Does it mean that the fields are per 5-tuple ?

What are the values of the port fields when there are no layer-4 ports ? E.g., for an ESP tunnel.

Should "(including ULA)" be added to the global SADDR address types ?

Like John Scudder, I find the term "global pointer" not appropriate, should rather be "aggregated packet counter", I am also quite skeptical about its usefulness as it is per IPv6 address (not counting IPv4, LLDP, ...) and we all know that there are several IPv6 addresses per node, moreover, in the case of a loopback address, then it is not even related to a specific interface. Anyway, it does not hurt.

## Section 3.3

The HTML rendering of the encrypted packet format has twice the top line.

Suggest using aasvg for better rendering of the packet layout.

The whole part describing the fields is badly rendered in HTML, it is really mixed up.

Please ensure that the "Vrsn" field name is used in the description (no need for the reader to guess).

Suggest to have a 3rd figure with "PDM data" to make it clear that both types carry the same information, or repeat the fields in encrypted packet with a vertical bar indicated encrypted.

## Section 4

What about protocols having no concept of "ports", e.g., an ESP tunnel.

"Session" should be defined.

As "pkx" and "skx" are used twice in the text, including once for their definition, unsure whether these are useful acronyms.

## Section 5.2

Should it rather be "Operational Considerations", esp with the mention of RFC 9288 ?

## Section 5.2.1

s/continue processing the header/continue processing the extension headers chain/

## Section 6

Title: s/Security Goals/Security Properties/ in the hope that this is not an aspirational goal but an actual property.

## Section 7.1.1

A glimpse from my past "FDDI" ;-)

## Appendixes

The appendix A is rather empty, suggest removing it (as well as the clearly empty appendixes B & C).

# NITS (non-blocking / cosmetic)

## Abstract

s/Destination Option/Destination Options/ (per RFC 8200) (and no need to define the "DO" acronym as it does not seem to be used in the document)

## Section 4

`A A temporary key` ?

[Ballot discuss]
Thanks to Marc Blanchet for the ARTART review.

I agree with his comments.

I think the appendix section A.2 should probably be removed.

If it is necessary to specify the details of HPKE more concretely, that should be done in the body of the document.

I also agree with Roman's DISCUSS on mandatory to implement algorithms and HPKE.

### Discuss

HPKE has a PSK Mode (and AuthKEM Mode), but this document does not mention which modes of HPKE are supported.

It was not obvious to me how the salt and nonce values are used.

Typically HPKE supports auxiliary application information using info and aad:

https://datatracker.ietf.org/doc/html/rfc9180#name-auxiliary-authenticated-app

I see this sentence:

Encrypted PDMv2 has most of the metadata fields encrypted except for PSNTP which is also used as a nonce in HPKE AEAD.

I would suggest explaining exactly what you are setting the value of "info" and "aad" too, and perhaps include some test vectors.

[Ballot comment]
Thanks to Marc Blanchet for the ARTART review.

I agree with his comments.

I think the appendix section A.2 should probably be removed.

If it is necessary to specify the details of HPKE more concretely, that should be done in the body of the document.

I also agree with Roman's DISCUSS on mandatory to implement algorithms and HPKE.

HPKE has a PSK Mode (and AuthKEM Mode), but this document does not mention which modes of HPKE are supported.

It was not obvious to me how the salt is used.

Typically HPKE supports auxiliary application information using info and aad:

https://datatracker.ietf.org/doc/html/rfc9180#name-auxiliary-authenticated-app

I would suggest explaining exactly what you are setting the value of "info" too, and perhaps include some test vectors.

[Ballot discuss]
** Section 6.4
  It is RECOMMENDED to use the HPKE framework that incorporates key
  encapsulation mechanism (KEM), key derivation function (KDF) and
  authenticated encryption with associated data (AEAD).  These multiple
  schemes are more robust and significantly more efficient than other
  schemes.  While the schemes may be negotiated between communicating
  parties, it is RECOMMENDED to use default encryption algorithm for
  HPKE AEAD as AES-128-GCM.

Is there a reason why there is not a mandatory-to-implement algorithm?  How is interoperability between independent implementations expected if no mandatory algorithm is specified?

[Ballot comment]
** Thanks for the detailed analysis in Section 7.

** Section 6.2
  An implementation SHOULD attempt to detect if PDM data is forged or
  modified by a malicious entity.

-- When should implementations ignore that the data is forged or modified?

-- What does “SHOULD attempt” mean in terms of implementation guidance?

** Section 6.4
  It is RECOMMENDED to use the HPKE framework that incorporates key
  encapsulation mechanism (KEM), key derivation function (KDF) and
  authenticated encryption with associated data (AEAD).

Please make RFC9180 a normative reference.

[Ballot comment]
Section 4, paragraph 3
>    *  Server: An Endpoint Node which has a listening port and sends PDM
>      data to another Endpoint Node.

Would it not be better to say "sends PDM data to the Client"? Or are you saying that the Server can send data to another Endpoint Node at the behest of the Client that requested the data?

Section 5.1, paragraph 1
>    The two entities exchange a set of data to ensure the respective
>    identities.  This could be done via a TLS or other session.  The
>    exact nature of the identity verification is out-of-scope for this
>    document.

Does HPKE support mutual authentication? If not, is there another method other than what TLS does with certificates that is defined today to do mutual authentication?

Section 6.2, paragraph 1
>    An implementation SHOULD attempt to detect if PDM data is forged or
>    modified by a malicious entity.  In other terms, the implementation
>    should attempt to detect if a malicious entity has generated a valid
>    PDM header impersonating an endpoint or modified a valid PDM header.

Is it just the headers, or can a malicious user not change the PDM data and cause integrity issues?

Section 7.1.1, paragraph 2
>    a.  Being on the same LAN: The simplest way for an attacker to launch
>        a passive attack is to be on the same Local Area Network (LAN) as
>        the victim.  Many LAN configurations, such as Ethernet, 802.3,
>        and FDDI, allow any machine on the network to read all traffic
>        destined for any other machine on the same LAN.  This means that
>        if PDM packets are sent over the LAN, the attacker can capture
>        them.


Is this true? In today's switched networks, you have to either mirror the traffic from the port where the client and server are connected, or you have to be on that port. What you say is true for a bridge, but not for a switched network.

Section 7.1.1, paragraph 2
>    b.  Control of a Host in the Communication Path: If the attacker has
>        control over a host that lies in the communication path between
>        two victim machines, they can intercept PDM packets as they pass
>        through this compromised host.  This allows the attacker to
>        collect metadata without being on the same LAN as the victim.

This is the first time the concept of a "Host in the Communication Path" has been introduced. Till now there were Endpoint Nodes, Clients and Servers. Can this concept be introduced and explained before citing it here? For example, under what circumstances would there be such a Host?

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Terms "his" and "her"; alternatives might be "they", "them", "their"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4, paragraph 7
>    *  SessionTemporaryKey: A A temporary key used to secure data for
>      only the current session

s/A A/A/

Found non-HTTP URLs in the document:

* iiesoc.in

These URLs in the document did not return content:

* https://ameyand.github.io/PDMv2/draft-elkins-ippm-encrypted-pdmv2.html
* iiesoc.in

Section 3.3, paragraph 5
>  unsigned number. This field is initialized at a random number and is increm
>                                ^^^^^^^^^^^
Do not mix variants of the same word ("initialize" and "initialise") within a
single text.

Section 3.3, paragraph 5
> igned number. Global Pointer is initialized to 1 for the different source ad
>                                ^^^^^^^^^^^
Do not mix variants of the same word ("initialize" and "initialise") within a
single text.

Section 3.3, paragraph 43
> e data for only the current session s/A A/A/ 5. Protocol Flow The protocol w
>                                      ^^^
Possible typo: you repeated a word.

Section 4, paragraph 6
> * An Epoch. The Epoch SHOULD be initialized to zero. A change in the Epoch in
>                                ^^^^^^^^^^^
Do not mix variants of the same word ("initialize" and "initialise") within a
single text.

Section 5.1, paragraph 8
> RFC8200. The Option Type identifiers is coded to skip over this option and co
>                                      ^^
The verb form "is" does not seem to match the subject "identifiers".

[Ballot discuss]
Thanks for this document. I have one point I'd like to have a discussion about:

## DISCUSS

I was surprised not to see any discussion of the global pointer in the privacy considerations. I didn’t see any helpful discussion of deployment assumptions in the present document, but RFC 8250 says,

  Advantages include:
…
  2. Ability to span organizational boundaries with consistent
      instrumentation.

That implies to me that a given server might simultaneously be providing instrumentation to clients within different organizations. A reasonable default assumption is that it’s inappropriate to leak information about one of these clients to another. One might argue that even the metrics RFC 8250 exposes can leak some information to a savvy endpoint, but the global pointer does so explicitly and by design: one client now gets to find out what the aggregate packet rate to other clients is.

It seems as though this deserves explicit treatment in the security and/or privacy considerations. Or of course if I’ve missed something (e.g. this kind of data exposure between clients was always the expectation and everyone but me knows this) please help me see that.

[Ballot comment]
## COMMENT

### Global Pointer naming

I found the name “Global Pointer” curiously opaque. It’s not a pointer in any conventional sense. I’m sure there’s some perfectly sensible historical reason for this nomenclature, but if I were picking a name ab initio that wouldn’t be it. “Global Packet Count” seems more descriptive, for instance.

### Section 6.4

      The basic mechanism is to encrypt the
  symmetric key with the public key by joining both yields.

I don’t understand what this means. In particular, “by joining both yields” doesn’t make sense to me. If I remove those four words, the sentence scans fine. Would it be reasonable to do that deletion?

[Ballot discuss]
# Internet AD comments for draft-ietf-ippm-encrypted-pdmv2-09
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Discuss

### S3.3

* The draft says "difference between the two types of headers is determined
  from the Options Length value" but then shows two diagrams each with
  22 bytes post-"Option Length"-field contents and also:

  Option Length

      0x22: Unencrypted PDM
      0x22: Encrypted PDM


  which would seem to amount to 34 bytes.

  Possibly I'm just missing something obvious, or I've completely misread
  diagrams and/or the text, but how does an implementation distinguish
  between these two formats?

[Ballot comment]

# Internet AD comments for draft-ietf-ippm-encrypted-pdmv2-09
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S5.1

* If I understand this correctly a new SessionTemporaryKey MUST be
  renegotiated every 2^32 packets.  Can you include a calculation to show
  approximately how often this turns out to be?

  I've probably done my math wrong, but assuming 1500 byte packets, a
  1 Gpbs link, and host sending at line rate I'd estimate a rollover
  about every 14 hours. If the packets are smaller the rollover is even
  faster

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ippm-encrypted-pdmv2-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-10-15):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ippm-encrypted-pdmv2@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, tpauly@apple.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option) to Proposed Standard


The IESG has received a request from the IP Performance Measurement WG (ippm)
to consider the following document: - 'IPv6 Performance and Diagnostic
Metrics Version 2 (PDMv2) Destination
  Option'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-10-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  RFC8250 describes an optional Destination Option (DO) header embedded
  in each packet to provide sequence numbers and timing information as
  a basis for measurements.  As this data is sent in clear-text, this
  may create an opportunity for malicious actors to get information for
  subsequent attacks.  This document defines PDMv2 which has a
  lightweight handshake (registration procedure) and encryption to
  secure this data.  Additional performance metrics which may be of use
  are also defined.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document received support and reviews from the WG as a whole, although
the primary reviewers and commenters were a slightly different subset from
the normally most active IPPM members. This is due to the fact that IPPM
has several different "tracks" of participation, where subsets of the community
are more focused on their own topics. However, the consensus and support
of those who did comment was pretty clear.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversies. Much of the development and iteration on the draft
was in trying to refine the security aspects, and going back and forth with SECDIR
reviewers.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No discontent has been epxressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, implementations have been tested at hackathons with results presented
at WG meetings.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is a new version of a protocol previously developed in IPPM, and
is primarily focused within the group.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews like these required.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal validation.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I think the document is clearly written and ready for Area Director review.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document went through three rounds of SECDIR review, which helped refine
the document and address many issues. I believe this was the primary area that
needed to provide input, since this document was mainly about adding
encryption support.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This is requesting Proposed Standard, which is appropriate as a new protocol
version of a standards track RFC (RFC 8250). The datatracker does reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All authors have confirmed that they are not aware of any IPR related to this
document, and no other WG members have brought up any IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all authors have confirmed their willingness to author.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits found.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

There are two informative references that could be considered as normative:
- RFC4303 for IPsec ESP, which is mentioned as an option for encapsulation
- RFC9180 for HPKE; this is an informational IRTF document, but has been normatively referenced in other RFCs, like RFC9458

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No such normative references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No, but it may be good to promote RFC9180 to a normative downref.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No such references.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document does not change the state of any other RFC, although it could be considered
to have it update or obsolete the older PDM (v1) RFC8250. I don't think this is
necessary, but could be done if the IESG finds it to be clearer.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA Considerations section is empty, as this document relies on the registration
of an IPv6 destination option from RFC8250. If this document were to update or obsolete
RFC8250, then the IANA Considerations could update the reference.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document received support and reviews from the WG as a whole, although
the primary reviewers and commenters were a slightly different subset from
the normally most active IPPM members. This is due to the fact that IPPM
has several different "tracks" of participation, where subsets of the community
are more focused on their own topics. However, the consensus and support
of those who did comment was pretty clear.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversies. Much of the development and iteration on the draft
was in trying to refine the security aspects, and going back and forth with SECDIR
reviewers.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No discontent has been epxressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, implementations have been tested at hackathons with results presented
at WG meetings.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document is a new version of a protocol previously developed in IPPM, and
is primarily focused within the group.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal reviews like these required.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal validation.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

I think the document is clearly written and ready for Area Director review.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document went through three rounds of SECDIR review, which helped refine
the document and address many issues. I believe this was the primary area that
needed to provide input, since this document was mainly about adding
encryption support.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This is requesting Proposed Standard, which is appropriate as a new protocol
version of a standards track RFC (RFC 8250). The datatracker does reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All authors have confirmed that they are not aware of any IPR related to this
document, and no other WG members have brought up any IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, all authors have confirmed their willingness to author.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No nits found.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

There are two informative references that could be considered as normative:
- RFC4303 for IPsec ESP, which is mentioned as an option for encapsulation
- RFC9180 for HPKE; this is an informational IRTF document, but has been normatively referenced in other RFCs, like RFC9458

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

No such normative references.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No, but it may be good to promote RFC9180 to a normative downref.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No such references.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document does not change the state of any other RFC, although it could be considered
to have it update or obsolete the older PDM (v1) RFC8250. I don't think this is
necessary, but could be done if the IESG finds it to be clearer.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IANA Considerations section is empty, as this document relies on the registration
of an IPv6 destination option from RFC8250. If this document were to update or obsolete
RFC8250, then the IANA Considerations could update the reference.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/