Group Key Management using IKEv2
draft-ietf-ipsecme-g-ikev2-22
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2025-03-16
|
22 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-22.txt |
2025-03-16
|
22 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2025-03-16
|
22 | Valery Smyslov | Uploaded new revision |
2025-03-14
|
21 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2025-03-11
|
21 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2025-03-11
|
21 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2025-03-10
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2025-03-10
|
21 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2025-03-06
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2025-03-06
|
21 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2025-03-04
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2025-03-04
|
21 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2025-02-25
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2025-02-25
|
21 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2025-02-18
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2025-02-12
|
21 | (System) | RFC Editor state changed to EDIT |
2025-02-12
|
21 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2025-02-12
|
21 | (System) | Announcement was received by RFC Editor |
2025-02-12
|
21 | (System) | IANA Action state changed to In Progress |
2025-02-12
|
21 | Jenny Bui | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2025-02-12
|
21 | Jenny Bui | IESG has approved the document |
2025-02-12
|
21 | Jenny Bui | Closed "Approve" ballot |
2025-02-12
|
21 | Jenny Bui | Ballot approval text was generated |
2025-02-11
|
21 | (System) | Removed all action holders (IESG state changed) |
2025-02-11
|
21 | Deb Cooley | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2025-02-11
|
21 | Roman Danyliw | [Ballot comment] Thank you to Robert Sparks for the GENART review. Thanks for addressing my DISCUSS and COMMENT feedback. |
2025-02-11
|
21 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2025-02-10
|
21 | (System) | Changed action holders to Deb Cooley (IESG state changed) |
2025-02-10
|
21 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2025-02-10
|
21 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2025-02-10
|
21 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-21.txt |
2025-02-10
|
21 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2025-02-10
|
21 | Valery Smyslov | Uploaded new revision |
2025-02-07
|
20 | Paul Wouters | [Ballot comment] Thanks for the discussion and the new text provided. I have updated my ballot to 'Yes' |
2025-02-07
|
20 | Paul Wouters | [Ballot Position Update] Position for Paul Wouters has been changed to Yes from Discuss |
2025-02-06
|
20 | (System) | Changed action holders to Brian Weis, Valery Smyslov (IESG state changed) |
2025-02-06
|
20 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2025-02-06
|
20 | Murray Kucherawy | [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 … [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? |
2025-02-06
|
20 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2025-02-05
|
20 | Paul Wouters | [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 … [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. |
2025-02-05
|
20 | Paul Wouters | [Ballot comment] The set of keys may include keys for encryption and authentication I would say "encryption and/or authentication" to include … [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]. |
2025-02-05
|
20 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2025-02-05
|
20 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2025-02-05
|
20 | Orie Steele | [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele |
2025-02-05
|
20 | Zaheduzzaman Sarker | [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 … [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. |
2025-02-05
|
20 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2025-02-05
|
20 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2025-02-04
|
20 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2025-02-03
|
20 | Roman Danyliw | [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 … [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”)? |
2025-02-03
|
20 | Roman Danyliw | [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 … [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. |
2025-02-03
|
20 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2025-02-01
|
20 | Erik Kline | [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 … [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" |
2025-02-01
|
20 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2025-01-31
|
20 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2025-01-29
|
20 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2025-01-28
|
20 | Gunter Van de Velde | [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde |
2025-01-16
|
20 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-20.txt |
2025-01-16
|
20 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2025-01-16
|
20 | Valery Smyslov | Uploaded new revision |
2024-12-28
|
19 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-19.txt |
2024-12-28
|
19 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2024-12-28
|
19 | Valery Smyslov | Uploaded new revision |
2024-12-16
|
18 | David Dong | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2024-12-16
|
18 | Russ Housley | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Russ Housley. Sent review to list. |
2024-12-12
|
18 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Russ Housley |
2024-12-12
|
18 | Jenny Bui | Placed on agenda for telechat - 2025-02-06 |
2024-12-12
|
18 | Deb Cooley | Ballot has been issued |
2024-12-12
|
18 | Deb Cooley | [Ballot Position Update] New position, Yes, has been recorded for Deb Cooley |
2024-12-12
|
18 | Deb Cooley | Created "Approve" ballot |
2024-12-12
|
18 | Deb Cooley | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2024-12-12
|
18 | Deb Cooley | Ballot writeup was changed |
2024-12-11
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2024-12-11
|
18 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-18.txt |
2024-12-11
|
18 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2024-12-11
|
18 | Valery Smyslov | Uploaded new revision |
2024-12-10
|
17 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-12-09
|
17 | David Dong | 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 … 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 |
2024-12-09
|
17 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2024-12-08
|
17 | Robert Sparks | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Robert Sparks. Sent review to list. |
2024-11-27
|
17 | Russ Housley | Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Russ Housley. Sent review to list. |
2024-11-24
|
17 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Russ Housley |
2024-11-21
|
17 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2024-11-19
|
17 | David Dong | IANA Experts State changed to Reviews assigned |
2024-11-19
|
17 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2024-11-19
|
17 | Cindy Morgan | 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 … 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. |
2024-11-19
|
17 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2024-11-19
|
17 | Deb Cooley | Last call was requested |
2024-11-19
|
17 | Deb Cooley | Ballot approval text was generated |
2024-11-19
|
17 | Deb Cooley | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2024-11-19
|
17 | Deb Cooley | Last call announcement was changed |
2024-11-19
|
17 | (System) | Changed action holders to Deb Cooley (IESG state changed) |
2024-11-19
|
17 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2024-11-19
|
17 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-17.txt |
2024-11-19
|
17 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2024-11-19
|
17 | Valery Smyslov | Uploaded new revision |
2024-11-14
|
16 | Deb Cooley | comments on the draft here: https://mailarchive.ietf.org/arch/msg/ipsec/vMu3B4cpfFGlCmJiS1991ouQrok/ |
2024-11-14
|
16 | (System) | Changed action holders to Brian Weis, Valery Smyslov (IESG state changed) |
2024-11-14
|
16 | Deb Cooley | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2024-11-11
|
16 | Deb Cooley | Ballot writeup was changed |
2024-11-11
|
16 | Deb Cooley | IESG state changed to AD Evaluation from Publication Requested |
2024-11-07
|
16 | Tero Kivinen | # 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 … # 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/ |
2024-11-07
|
16 | Tero Kivinen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2024-11-07
|
16 | Tero Kivinen | IESG state changed to Publication Requested from I-D Exists |
2024-11-07
|
16 | (System) | Changed action holders to Deb Cooley (IESG state changed) |
2024-11-07
|
16 | Tero Kivinen | Responsible AD changed to Deb Cooley |
2024-11-07
|
16 | Tero Kivinen | Document is now in IESG state Publication Requested |
2024-11-06
|
16 | Tero Kivinen | # 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 … # 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/ |
2024-11-06
|
16 | Tero Kivinen | Changed consensus to Yes from Unknown |
2024-11-06
|
16 | Tero Kivinen | Intended Status changed to Proposed Standard from None |
2024-11-06
|
16 | Tero Kivinen | Notification list changed to kivinen@iki.fi because the document shepherd was set |
2024-11-06
|
16 | Tero Kivinen | Document shepherd changed to Tero Kivinen |
2024-11-02
|
16 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-16.txt |
2024-11-02
|
16 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2024-11-02
|
16 | Valery Smyslov | Uploaded new revision |
2024-10-21
|
15 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-15.txt |
2024-10-21
|
15 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2024-10-21
|
15 | Valery Smyslov | Uploaded new revision |
2024-09-04
|
14 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-14.txt |
2024-09-04
|
14 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2024-09-04
|
14 | Valery Smyslov | Uploaded new revision |
2024-08-21
|
13 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-13.txt |
2024-08-21
|
13 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2024-08-21
|
13 | Valery Smyslov | Uploaded new revision |
2024-08-20
|
12 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-12.txt |
2024-08-20
|
12 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2024-08-20
|
12 | Valery Smyslov | Uploaded new revision |
2024-02-26
|
11 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-11.txt |
2024-02-26
|
11 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2024-02-26
|
11 | Valery Smyslov | Uploaded new revision |
2023-10-19
|
10 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-10.txt |
2023-10-19
|
10 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2023-10-19
|
10 | Valery Smyslov | Uploaded new revision |
2023-04-19
|
09 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-09.txt |
2023-04-19
|
09 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2023-04-19
|
09 | Valery Smyslov | Uploaded new revision |
2023-04-14
|
08 | Russ Housley | Request for Early review by SECDIR Completed: Not Ready. Reviewer: Russ Housley. Sent review to list. |
2023-04-10
|
08 | Gorry Fairhurst | Request for Early review by TSVART Completed: Ready with Issues. Reviewer: Gorry Fairhurst. Sent review to list. |
2023-03-29
|
08 | Tero Kivinen | Request for Early review by SECDIR is assigned to Russ Housley |
2023-03-28
|
08 | Yoav Nir | Added to session: IETF-116: ipsecme Wed-0630 |
2023-03-27
|
08 | Magnus Westerlund | Request for Early review by TSVART is assigned to Gorry Fairhurst |
2023-03-27
|
08 | Tero Kivinen | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2023-03-27
|
08 | Tero Kivinen | Requested Early review by TSVART |
2023-03-27
|
08 | Tero Kivinen | Requested Early review by SECDIR |
2023-03-09
|
08 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-08.txt |
2023-03-09
|
08 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2023-03-09
|
08 | Valery Smyslov | Uploaded new revision |
2022-10-06
|
07 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-07.txt |
2022-10-06
|
07 | Valery Smyslov | New version accepted (logged-in submitter: Valery Smyslov) |
2022-10-06
|
07 | Valery Smyslov | Uploaded new revision |
2022-04-06
|
06 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-06.txt |
2022-04-06
|
06 | (System) | New version accepted (logged-in submitter: Valery Smyslov) |
2022-04-06
|
06 | Valery Smyslov | Uploaded new revision |
2022-03-21
|
05 | Tero Kivinen | Added to session: IETF-113: ipsecme Fri-1230 |
2022-03-18
|
05 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-05.txt |
2022-03-18
|
05 | (System) | Forced post of submission |
2022-03-18
|
05 | (System) | Request for posting confirmation emailed to previous authors: Brian Weis , Valery Smyslov |
2022-03-18
|
05 | Valery Smyslov | Uploaded new revision |
2022-01-10
|
04 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-04.txt |
2022-01-10
|
04 | (System) | New version accepted (logged-in submitter: Valery Smyslov) |
2022-01-10
|
04 | Valery Smyslov | Uploaded new revision |
2021-11-08
|
03 | Tero Kivinen | IETF WG state changed to In WG Last Call from WG Document |
2021-11-08
|
03 | Tero Kivinen | Added to session: IETF-112: ipsecme Mon-1200 |
2021-07-11
|
03 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-03.txt |
2021-07-11
|
03 | (System) | New version accepted (logged-in submitter: Valery Smyslov) |
2021-07-11
|
03 | Valery Smyslov | Uploaded new revision |
2021-01-11
|
02 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-02.txt |
2021-01-11
|
02 | (System) | New version accepted (logged-in submitter: Valery Smyslov) |
2021-01-11
|
02 | Valery Smyslov | Uploaded new revision |
2020-07-12
|
01 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-01.txt |
2020-07-12
|
01 | (System) | New version accepted (logged-in submitter: Valery Smyslov) |
2020-07-12
|
01 | Valery Smyslov | Uploaded new revision |
2020-07-11
|
00 | (System) | Document has expired |
2020-01-08
|
00 | Valery Smyslov | This document now replaces draft-yeung-g-ikev2 instead of None |
2020-01-08
|
00 | Valery Smyslov | New version available: draft-ietf-ipsecme-g-ikev2-00.txt |
2020-01-08
|
00 | (System) | New version accepted (logged-in submitter: Valery Smyslov) |
2020-01-08
|
00 | Valery Smyslov | Uploaded new revision |