Reviewer: Reese Enghardt Review result: Ready with Nits 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-auth-announce-06 Reviewer: Reese Enghardt Review Date: 2024-03-29 IETF LC End Date: 2024-03-31 IESG Telechat date: Not scheduled for a telechat Summary: The document is clear and concise, and it is ready for publication. I have a few minor suggestion to make the document more comprehensible to non-expert readers. Major issues: None. Minor issues: Abstract: As a non-expert reader, the following phrases appear to contradict each other: "indicate the list of supported authentication methods" sounds like different algorithms, "configured with multiple different credentials to authenticate each other" sounds like different certificates but potentially using the same algorithm. If this proposal is most applicable to scenarios where IKEv2 partners use different algorithms or methods, please consider saying so explicitly in the abstract. Section 1: If there are several credentials, why not just try them one by one - is it just performance reasons (key exchange takes longer), or is there another reason? Please consider adding a sentence as additional motivation for this new mechanism. Section 3.1: "it includes a new status type notify SUPPORTED_AUTH_METHODS in the IKE_SA_INIT response message" Have a hard time parsing this sentence. Is "notify" part of the name of the new status type? Please consider rephrasing this sentence. "If the following conditions are met:" Either of the conditions or both of the conditions? "[…] then the responder may choose not to send actual list of the supported authentication methods in the IKE_SA_INIT exchange and instead ask the initiator to start the IKE_INTERMEDIATE exchange for the list to be sent in" Is this a MAY? Why is it not a MUST, as above it says "the responder […] must take care that the size of the response message wouldn't grow too much so that IP fragmentation takes place"? Why does using the IKE_INTERMEDIATE exchange fix the problem of IP fragmentation? Please consider adding a brief explanation here. Section 5: "Note, that this is not a real attack, since NULL authentication should be allowed by local security policy." Why is it not a real attack then? If NULL authentication is allowed among other methods, surely downgrading to NULL authentication is still a problem? Or should the second sentence instead say "NULL authentication should NOT be allowed by local security policy"? Nits/editorial comments: Section 1: "The problem may arise when there are several credentials of different type configured on one peer" "type" -> "types"? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
