Group Key Management using IKEv2
draft-ietf-ipsecme-g-ikev2-22

[Ballot comment]
I support Roman's DISCUSS regarding Section 9.2.  In addition to that, I suggest putting each new registry in its own subsection, and each specific action or group of actions in Section 9.3 in their own subsections.

Regarding the SHOULD in Section 2.3.1, what's the alternative?  Why is there a choice here?

[Ballot discuss]
Thanks for the document. It is very clear. I have some questions and comments
we should talk through, but nothing that I think will be a problem.

I wonder why the design for GSA_AUTH is not more genericly done, so that
it would be possible to mix regular IKE/Child SAs with GSAs ? It seems
things are now tied to the IKE_SA_INIT followed by GSA_AUTH, but there
is no CREATE_CHILD_SA method to start a GSA_AUTH ?

It seems the problem of a fast changing group membership is somewhat
ignored (as compared to MLS that made it a fundamental part of the
protocol). There is enough room in the current design that this can
probably be added at a later stage, if this document sees deployment
and such scale issues become a problem.

Now for specific text issues:


I don't fully understand this sentence:

        After the GM and GCKS complete the IKE_SA_INIT exchange, the
        GSA_AUTH exchange MUST complete before any other exchanges defined
        in this document can be done. GSA_AUTH is used to authenticate
        the previous exchanges, exchange identities and certificates.

If an IKE_INTERMEDIATE was required, this would happen after the IKE_SA_INIT,
but before the GSA_AUTH exchange. Also, wouldn't it be valid to setup either
a regular IKE SA with Child SA, or a Childless SA, and only then decide to
run a GSA_AUTH exchange? In which case "GSA_AUTH is used to authenticate
the previous exchanges" makes no sense.


Initiator (GM)                  Responder (GCKS)
--------------------            ------------------
                          <--  HDR, SK{IDr, [CERT,] AUTH, N}

Figure 5: GSA_AUTH Error Response

Why would the responder in this case send its AUTH payload? Compare this to
RFC7296 error handling here:

        If the error occurred on the responder, the notification is
        returned in the protected response, and is usually the only
        payload in that response.

I would omit the AUTH payload in this case to keep it the same as regular IKEv2.


        Depending on its policy the GCKS MAY combine these two
        methods. For example, it may use the GSA_INBAND_REKEY to deliver
        key to the GMs in the group acting as senders

Does this not assume those GMs MUST keep the IKE SAs up? Otherwise how can the GCKS
send a GSA_INBAND_REKEY message? Is it expected to be able to reach all GM's by
_initiating_ a new IKE SA? I haven't seen specified that the GCKS can initiate
an IKE SA, so I assume this is not possible. Perhaps then the GCKS should send
a notify in GSA_REGISTRATION to signal to the GMs to keep the IKE SA open ?



Do we _really_ have to support IPCOMP ?? :(


        The digital signing is applied to the concatenation of two chunks: A and P.

Why is just signing Chunk A or just Chunk P not enough?


What is the Responder SPI set to for a GSA_REKEY IKE message that is broadcast to all GMs?


        If a Data-Security SA is not rekeyed yet and is about to expire
        (a "soft lifetime" expiration is described in Section 4.4.2.1 of
        [RFC4301]), the GM SHOULD initiate a registration to the GCKS.

Wouldn't this cause all DM's to simultaniously try to do IKE to do GCKS?
Maybe at the very least, suggest some "fuzz" is used with the timer to
ensure not all GMs rekey at the same second.

A similar problem happens after a REKEY_SA Delete operation. Maybe suggest
some "fuzz" in the timing there as well? (although I guess every member
wants to reconnect as fast as possible as to not miss any messages :/ )


Should some of these payloads have the Critical Flag set? I am not sure
if matters much, as a peer not supporting this will fail anyway and if
G-IKE is not used, these payloads do not appear (or if they do, it is
broken anyway)


        (*) If AEAD encryption algorithm is used, then INTEG transform
        MUST NOT be specified, otherwise it MUST be specified.

It's ugly but I would also allow None as INTEG transform for AEAD. It has happened in
the past and libreswan had interop issues with some peers due to no integ vs integ of 'None'.


AUTHORIZATION_FAILED doesn't appear to be associated with G-IKEv2 by its name, and might
get picked up my implementers who just look at the list to see what error to pick. Perhaps
renaming it to GROUP_AUTHORIZATION_FAILED to make it more clear this is specific to G-IKEv2?

Similar perhaps for REGISTRATION_FAILED -> GROUP_REGISTRATION_FAILED ?
And SENDER -> GROUP_SENDER ?


The Security Considerations doesn't state that each GM basically needs to trust all other GMs
not to share the content with members outside the group.

[Ballot comment]

        The set of keys may include keys for encryption and authentication

I would say "encryption and/or authentication" to include AEAD keys?


        The second exchange GSA_AUTH is similar t

Saying "second" is confusing here. it is not the second time the GSA_AUTH is used.


        The GM may include an SAg payload declaring which Transforms it is willing to accept.

The transform for the "IKE SA "(Rekey SA?) right? Not the GSA (Data-Security SA?)


        If the group member finds the policy sent by the GCKS is unacceptable,

I would preface this with text saying "if the GM has been successfully
authenticated", to make it more clear we are talking about something
unrelated to the previous section.  Maybe also say "and the GM has
authenticated the GCKS but finds the policy sent unacceptable"

        by initiating the GSA_REGISTRATION exchange and sending IDg
        along with the NO_PROPOSAL_CHOSEN notification in it

I would avoid "with" and "in it" as it makes it less clear what is in what. Perhaps:

        by initiating the GSA_REGISTRATION exchange with the IDg payload
        and the NO_PROPOSAL_CHOSEN notification payload.

I assume in this case one would omit SAg payloads as well? So maybe say:

        by initiating the GSA_REGISTRATION exchange containing only the IDg payload
        and a NO_PROPOSAL_CHOSEN notification payload.

(I now see this is explained in Figure 8, so maybe you can also just reference
that instead of explaining it here in detail?)



        A GM requesting registration contacts the GCKS using the IKE_SA_INIT exchange.

I am still puzzled by insisting on the GSA_AUTH in this way. Why is this not orthogonal
to the exchange? Eg why can't you do a regular IKE SA and then a CREATE_CHILD_SA like
GSA_AUTH exchange? I assume I will see something like this later on, in case the GM
wants to join more than one group?

        Other transform types SHOULD NOT be included as they will be ignored

Why not MUST NOT ?

        The GCKS MUST ignore SPI length and SPI fields in the SAg payload.

That is a bit weird. If the SPI length is set to 255 but there is no space in the packet
for this, I would expect it to return an INVALID_SYNTAX and not "MUST ignore". Eg this
MUST ignore would require special code handling. Maybe say "MUST NOT use" ?


I am not a multicast expert, so this might be a wrong question but:

        and it is not going to receive back the data it sends, then it
        MUST install this SA only in the outgoing direction.

What normally determines "is not going to receive back the data it sends" ? If it is
part of the group, wouldn't it always get the traffic? Just that now the traffic
doesn't match an SA so it will be dropped by the IPsec subsystem with an error
there is no matching SA? Or does signaling you don't want to receive the data back
prevent you from receiving the packets?

        The GSA KEK policy MUST include the attribute
        GSA_INITIAL_MESSAGE_ID with a first Message ID the GM should
        expect to receive if it is non-zero.

Is the "if it is non-zero" a condition on the "MUST" ? It reads a bit odd. Like as
implementer if the KEK policy has no GSA_INITIAL_MESSAGE_ID is the policy INVALID_SYNTAX
or not ? Maybe:

        If the first Message ID the GM should expect to receive is non-zero, the GSA KEK policy
        includes the GSA_INITIAL_MESSAGE_ID with the expected non-zero value.

I don't understand what this means:

        In the latter case outer source and destination addresses are
        taken from the inner IP packet.

Is that the only thing taken from the inner packet? Or if everything is
taken from the inner packet what is "address preserving" about this version
of tunnel mode?


        The (encrypted) retransmitted messages MUST be bitwise identical
        and should be sent within a short time interval (a few seconds)

So is there is much point to do this then? If there is a flaky connection,
it is often going to be a few seconds, so this quick retransmit is not going
to be very helpful.

        The group member then downloads the new ....

I don't like the term "download" here? Isn't it just processed from the same
packet? It is not a separate 'download' action. Similarly, What is called
Key Download Payload here, I have seen called Key Package (Payload) elsewhere,
eg MLS.

        If it is a sender and does not hold a current Sender-ID value

I believe that just means it is not a sender and it wants to become a sender?

NITS

        This exchange follows the IKE_SA_INIT exchange

I read follow as "follows the design" not "follows in time". Perhaps:

        This exchange happens after the IKE_SA_INIT exchange



The other one is -> The second new exchange type is

an specific IKE SA -> a specific IKE SA

an multicast mode -> a multicast mode

I would remove:

        , so it is assumed that readers have an understanding of this protocol

and:

        It is assumed that readers are familiar with the IKEv2 protocol, so this document skips many details that are described in [RFC7296].

[Ballot comment]
Thanks for working on IKEv2. Thanks for Gorry for his TSVART review.

I am supporting Roman's discuss on lack of instructions for DE for doing the job.

[Ballot discuss]
** Section 9.2.  This section defines a number of registries that have an allocation policy of “Expert Review”.  However, this document does not provide guidance to the designated expert on what to approve.  See Section 4.5 of RFC8126.

** Section 9.3. Shouldn’t the code points referenced in this section which currently reference “[draft-yeung-g-ikev2-07]” be updated to reference this document (e.g., 39 – 41 of “IKEv2 Exchange Types”, 50 – 52 of "IKEv2 Payload Types", 45-46 of "IKEv2 Notify  Message Error Types", 16429 of “IKEv2 Notify Message Status Types”)?

[Ballot comment]
Thank you to Robert Sparks for the GENART review.

** Section 9.2.  Should all the new registries created by this section have an addition column added to them to be “Reference” that points to the specification further explaining the code point?

** Section 9.2.  The registries “Group-wide Policy”, "Group Key Bag Attributes" and "GSA Attributes" have a “Format”, “Multi-Valued” and/or “Protocol” but the meaning of those columns is not explicitly stated.

[Ballot comment]
# Internet AD comments for draft-ietf-ipsecme-g-ikev2-20
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

### S4.4.2

* "UDP encapsulation of ESP packets [RFC3948] cannot be specified in
  G-IKEv2 and thus it is not used for the multicast Data-Security SAs."

  I didn't immediately follow why this should necessarily be true. If
  there's an explanation, or a link to section I didn't properly grok,
  some brief addition might be nice.

## Nits

### S1

* "where multicast communications indicated with double line" ->
  "where multicast communications are indicated with a double line"

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ipsecme-g-ikev2-17. If any part of this review is inaccurate, please let us know.

IANA has questions about some of the actions requested in the IANA Considerations section of this draft.

The IANA understands that, upon approval of this document, there are seventeen actions which we must complete.

First, in the IKEv2 Exchange Types registry in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

the registrations for the following exchange types will have their references changed to [ RFC-to-be ]:

Value Exchange Type
----------------------------
39 GSA_AUTH
40 GSA_REGISTRATION
41 GSA_REKEY

Second, also in the IKEv2 Exchange Types registry in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

a new exchange type will be registered as follows:

Value Exchange Type Reference
-------------------------------------------------------------
[ TBD-at-Registration ] GSA_INBAND_REKEY [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the IKEv2 Payload Types registry also in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

the registrations for the following payload types will have their references changed to [ RFC-to-be ]:

Value Next Payload Type Notation
----------------------------------------------------
50 Group Identification IDg
51 Group Security Association GSA
52 Key Download KD

Fourth, in the Transform Type Values registry also in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

three changes are to be made:

-> First, transform type: 5; Description: Extended Sequence Numbers (ESN) is to have its description changed to:

Type: 5
Description: Anti-Replay Protection (ARP)

IANA Question --> Should the reference for this transform type be changed to [ RFC-to-be ] or have [ RFC-to-be ] added to the existing reference?

-> Second, two, new registrations are to be added to the transform type values registry with a reference of [ RFC-to-be ] as follows:

Type Description Used In
----------------------------------------------------------------------------
[ TBD-at-Registration ] Key Wrap Algorithm (KWA) IKE, GIKE_REKEY
[ TBD-at-Registration ] Authentication Method (AUTHMETH) GIKE_REKEY

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

-> Third, the existing registrations for Types 1 through 5 in the registry are to have their "Used In" fields changed as follows:

Type Description Used In
---------------------------------------------------------------------
1 Encryption Algorithm (ENCR) IKE, GIKE_REKEY and ESP
2 Pseudo-random Function (PRF) IKE, GIKE_REKEY
3 Integrity Algorithm (INTEG) IKE, GIKE_REKEY, AH, optional in ESP
4 Key Exchange Method (KE) IKE, optional in AH, ESP
5 Anti-Replay Protection (ARP) AH and ESP

IANA Question --> Should the reference for these transform types be changed to [ RFC-to-be ] or have [ RFC-to-be ] added to the existing reference?

IANA Question --> Should the "Used In" field for transform types 6 through 12 be changed in any way?

Fifth, in the Transform Type 5 - Extended Sequence Numbers Transform IDs registry also in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

a single new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Attribute Type: Signature Algorithm Identifier
Format: TLV
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Sixth, the Transform Type 5 - Extended Sequence Numbers Transform IDs registry also in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

will be renamed to:

Transform Type 5 - Anti-Replay Protection Transform IDs

Seventh, in the newly renamed Transform Type 5 - Anti-Replay Protection Transform IDs registry also in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

a single new registration will be made as follows:

Number: [ TBD-at-Registration ]
Name: Not Used
Reference: [ RFC-to-be ]

Eighth, in the IKEv2 Notify Message Error Types registry in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

two registrations will have their references changed to [ RFC-to-be ]:

Value: 45
Notify Message Error Type: INVALID_GROUP_ID
Reference: [ RFC-to-be ]

Value: 46
Notify Message Error Type: AUTHORIZATION_FAILED
Reference: [ RFC-to-be ]

Ninth, also in the IKEv2 Notify Message Error Types registry in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

a single new registration will be made as follows:

Value: [ TBD-at-Registration ]
Notify Message Error Type: REGISTRATION_FAILED
Reference: [ RFC-to-be ]

Tenth, in the IKEv2 Notify Message Status Types registry also in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

the existing registration for:

Value: 16429
Notify Message Status Type: SENDER_REQUEST_ID

will have its reference changed to [ RFC-to-be ] and be renamed as follows:

Value: 16429
Notify Message Status Type: SENDER
Reference: [ RFC-to-be ]

Eleventh, in the IKEv2 Security Protocol Identifiers registry also in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

a new identifier will be registered as follows:

Protocol ID: [ TBD-at-Registration ]
Protocol: GIKE_REKEY
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Twelveth, in the IKEv2 Authentication Method registry also in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

the existing registration for:

Value: 0
Authentication Method: Reserved
Reference: [RFC7296]

is to be changed to:

Value: 0
Authentication Method: NONE
Reference: [RFC7296]

IANA Question --> Should the reference for this authentication method be changed to [ RFC-to-be ] or have [ RFC-to-be ] added to the existing reference?

Thirteenth, a new registry is to be created called the Transform Type [ TBD-at-Registration ] -- Key Wrap Algorithm IDs registry where [ TBD-at-Registration ] matches the value in IANA action four above. The new registry will be located in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

The registry will be managed via Expert Review for values 0-1023 as defined in [RFC8126]. Values 1024-65535 will be marked as available for Private Use. There are initial registrations in the new registry as follows:

Key Wrap Algorithm Value Reference
---------------------------------------------------
Reserved 0 [ RFC-to-be ]
KW_5649_128 1 [ RFC-to-be ]
KW_5649_192 2 [ RFC-to-be ]
KW_5649_256 3 [ RFC-to-be ]
KW_ARX 4 [ RFC-to-be ]
Unassigned 5-1023
Private Use 1024-65535

Fourteenth, a new registry is to be created called the GSA Attributes registry. The new registry will be located in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

The registry will be managed via Expert Review for values 0-16383 as defined in [RFC8126]. Values 16384-32767 will be marked as available for Private Use. There are initial registrations in the new registry as follows:

GSA Attributes Value Format Multi-Valued Protocol Reference
-----------------------------------------------------------------------------------
Reserved 0 [RFC-to-be ]
GSA_KEY_LIFETIME 1 TLV NO GIKE_REKEY, AH, ESP [ RFC-to-be ]
GSA_INITIAL_MESSAGE_ID 2 TLV NO GIKE_REKEY [ RFC-to-be ]
GSA_NEXT_SPI 3 TLV YES GIKE_REKEY, AH, ESP [ RFC-to-be ]
Unassigned 5-16383
Private Use 16384-32767

Fifteenth, a new registry is to be created called the Group-wide Policy Attributes registry. The new registry will be located in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

The registry will be managed via Expert Review for values 0-16383 as defined in [RFC8126]. Values 16384-32767 will be marked as available for Private Use. There are initial registrations in the new registry as follows:

GW Policy Attributes Value Format Multi-Valued Reference
----------------------------------------------------------------------
Reserved 0 [ RFC-to-be ]
GWP_ATD 1 TV NO [ RFC-to-be ]
GWP_DTD 2 TV NO [ RFC-to-be ]
GWP_SENDER_ID_BITS 3 TV NO [ RFC-to-be ]
Unassigned 4-16383
Private Use 16384-32767

Sixteenth, a new registry is to be created called the Group Key Bag Attributes registry. The new registry will be located in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

The registry will be managed via Expert Review for values 0-16383 as defined in [RFC8126]. Values 16384-32767 will be marked as available for Private Use. There are initial registrations in the new registry as follows:

Group Key Bag Attributes Value Format Multi-Valued Protocol Reference
-----------------------------------------------------------------------------
Reserved 0 [ RFC-to-be ]
SA_KEY 1 TLV YES, NO GIKE_REKEY, AH, ESP [ RFC-to-be ]
Unassigned 2-16383
Private Use 16384-32767

Seventeenth, a new registry is to be created called the Member Key Bag Attributes registry. The new registry will be located in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

The registry will be managed via Expert Review for values 0-16383 as defined in [RFC8126]. Values 16384-32767 will be marked as available for Private Use. There are initial registrations in the new registry as follows:

Member Key Bag Attributes Value Format Multi-Valued Reference
------------------------------------------------------------------
Reserved 0 [ RFC-to-be ]
WRAP_KEY 1 TLV YES [ RFC-to-be ]
AUTH_KEY 2 TLV NO [ RFC-to-be ]
GM_SENDER_ID 3 TLV YES [ RFC-to-be ]
Unassigned 4-16383
Private Use 16384-32767

We understand that these seventeen actions are the only ones required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

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-12-10):

From: The IESG
To: IETF-Announce
CC: debcooley1@gmail.com, draft-ietf-ipsecme-g-ikev2@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, kivinen@iki.fi
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Group Key Management using IKEv2) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document: - 'Group Key
Management using IKEv2'
  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-12-10. 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


  This document presents an extension to the Internet Key Exchange
  version 2 (IKEv2) protocol for the purpose of a group key management.
  The protocol is in conformance with the Multicast Security (MSEC) key
  management architecture, which contains two components: member
  registration and group rekeying.  Both components are required for a
  GCKS (Group Controller/Key Server) to provide authorized Group
  Members (GMs) with IPsec group security associations.  The group
  members then exchange IP multicast or other group traffic as IPsec
  packets.

  This document obsoletes RFC 6407.  This documents also updates RFC
  7296 by renaming a transform type 5 from "Extended Sequence Numbers
  (ESN)" to the "Anti-Replay Protection (ARP)" and by renaming IKEv2
  authentication method 0 from "Reserved" to "NONE".




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/



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?

The document has a long history - the -00 version was published in March 2010.
Since then the authors of the document were changed several times, so that
no one of the original authors remains.

The concept of the document was started more like a standalone protocol
(like GDOI) and since then migrated to more like a complex extension to IKEv2.

Since the draft addresses a specific problem of protecting multicast traffic
with IPsec, it is of interest only for some part of IPsec community. It is
believed that all interested parties reviewed the draft and the consensus is
broad enough.

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

No.

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.

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)?

There were few implementations of the earlier versions of the draft,
they are incompatible with the current version. No implementations
of the current version exist to my best knowledge.

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

No external reviews were done.

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.

Not applicable.

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]?

Not applicable.

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.

Not applicable.

## 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 have reviewed the document and provided comments, and the authors have
incorporated my comments. I think the document is needed, and is ready to
be handed off to the AD.

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?

No directorate reviews have been done yet. There should not be any issues
identified. It will require review from at least secdir.

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?

Proposed Standard. The document defines a protocol for protecting
the multicast traffic with IPsec, thus the Proposed Standard type is the
proper one.

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.

Current authors have indicated that they do not know any IPRs on the draft, but
there were several previous authors contributing to this draft, and we have not
tried to contact them to request confirmation.

No IPRs currently disclosed.

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.

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 (except incorrect warnings about the missing references, as this draft uses
the format [CERTREQ] to indicate optional payloads, and idnits tries to interpret them
as references).

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

References have been correctly split between informative and normative.

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

All normative references are freely available.

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.

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.

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.

The document obsoletes RFC 6407. This is listed in the title page,
is mentioned in the Abstract and is discussed in the Introduction.
The document also updates RFC 7296. This is listed in the title page and
is mentioned in the Abstract in detail.

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 document contains extensive IANA considerations section that creates
several new expert review policy registries. It also updates some of the
IKEv2 registries. I have reviewed those and they seems to be ok.

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.

This document creates 6 new registries with IANA policy "Expert Review" in the
IKEv2 registry page. One of the authors and the document shepherd are expert
reviewers for IKEv2 registries, and most likely will also be experts for the
new created registries (as the newly created registries will be part of the
IKEv2 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?

The document has a long history - the -00 version was published in March 2010.
Since then the authors of the document were changed several times, so that
no one of the original authors remains.

The concept of the document was started more like a standalone protocol
(like GDOI) and since then migrated to more like a complex extension to IKEv2.

Since the draft addresses a specific problem of protecting multicast traffic
with IPsec, it is of interest only for some part of IPsec community. It is
believed that all interested parties reviewed the draft and the consensus is
broad enough.

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

No.

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.

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)?

There were few implementations of the earlier versions of the draft,
they are incompatible with the current version. No implementations
of the current version exist to my best knowledge.

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

No external reviews were done.

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.

Not applicable.

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]?

Not applicable.

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.

Not applicable.

## 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 have reviewed the document and provided comments, and the authors have
incorporated my comments. I think the document is needed, and is ready to
be handed off to the AD.

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?

No directorate reviews have been done yet. There should not be any issues
identified. It will require review from at least secdir.

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?

Proposed Standard. The document defines a protocol for protecting
the multicast traffic with IPsec, thus the Proposed Standard type is the
proper one.

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.

Current authors have indicated that they do not know any IPRs on the draft, but
there were several previous authors contributing to this draft, and we have not
tried to contact them to request confirmation.

No IPRs currently disclosed.

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.

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 (except incorrect warnings about the missing references, as this draft uses
the format [CERTREQ] to indicate optional payloads, and idnits tries to interpret them
as references).

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

References have been correctly split between informative and normative.

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

All normative references are freely available.

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.

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.

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.

The document obsoletes RFC 6407. This is listed in the title page,
is mentioned in the Abstract and is discussed in the Introduction.
The document also updates RFC 7296. This is listed in the title page and
is mentioned in the Abstract in detail.

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 document contains extensive IANA considerations section that creates
several new expert review policy registries. It also updates some of the
IKEv2 registries. I have reviewed those and they seems to be ok.

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.

This document creates 6 new registries with IANA policy "Expert Review" in the
IKEv2 registry page. One of the authors and the document shepherd are expert
reviewers for IKEv2 registries, and most likely will also be experts for the
new created registries (as the newly created registries will be part of the
IKEv2 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/