IETF Last Call Review of draft-ietf-ipsecme-ikev2-downgrade-prevention-05
review-ietf-ipsecme-ikev2-downgrade-prevention-05-genart-lc-dunbar-2026-06-12-00

Request Review of draft-ietf-ipsecme-ikev2-downgrade-prevention
Requested revision No specific revision (document currently at 08)
Type IETF Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2026-06-12
Requested 2026-05-29
Authors Valery Smyslov , Christopher Patton
I-D last updated 2026-08-13 (Latest revision 2026-07-01)
Completed reviews Genart IETF Last Call review of -05 by Linda Dunbar (diff)
Opsdir IETF Last Call review of -05 by Dhruv Dhody (diff)
Secdir IETF Last Call review of -05 by Yaroslav Rosomakho (diff)
Assignment Reviewer Linda Dunbar
State Completed
Request IETF Last Call review on draft-ietf-ipsecme-ikev2-downgrade-prevention by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/ru1gLWh3qMqK1JKQ9ifXm9Lqdis
Reviewed revision 05 (document currently at 08)
Result Ready w/nits
Completed 2026-06-12
review-ietf-ipsecme-ikev2-downgrade-prevention-05-genart-lc-dunbar-2026-06-12-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-ipsecme-ikev2-downgrade-prevention-??
Reviewer: Linda Dunbar
Review Date: 2026-06-12
IETF LC End Date: 2026-06-12
IESG Telechat date: Not scheduled for a telechat

Summary: This draft updates IKEv2 by adding a negotiation signal and modified
AUTH transcript so both peers authenticate the same full IKE_SA_INIT
conversation, preventing attackers from silently downgrading the connection to
weaker key exchange methods or stripped extensions

Major issues: None

Minor issues: None

Nits/editorial comments:

- Section 6 says the responder includes the notification “regardless of whether
it was received in the request or not,” and later says the modified
authentication calculation is used only if a peer both sent and received the
notification. Just wondering what to do when only one direction contains the
notification.

- Section 4: s/Having these preconditions the goal of the attacker is to
eavesdrop/Given these preconditions, the goal of the attacker is to eavesdrop/

- should expand PQ/T on the first use.

Best regards,
Linda Dunbar