Last Call Review of draft-ietf-ipsecme-ikev2-auth-announce-06
review-ietf-ipsecme-ikev2-auth-announce-06-secdir-lc-shekh-yusef-2024-03-30-00

# Section 3.1

* The description of the exchange seems odd, as it starts with the responder,
instead of the initiator. I suggest that the description of the exchange starts
with the initiator, followed by the responder.

* I think it would make it easier for the reader if you explicitly describe the
new notify payload. How about adding the following text to the beginning of
section 3.1?

"This specification introduces a new IKE_SA_INIT packets Notify payload of type
SUPPORTED_AUTH_METHODS. This payload is utilized to convey the supported
authentication methods of the party sending the message, thereby facilitating
the negotiation of authentication mechanisms during IKE SA establishment."

* "Since the responder sends the SUPPORTED_AUTH_METHODS notification in the
IKE_SA_INIT exchange, it must take care that the size of the response message
wouldn't grow too much so that IP fragmentation takes place."

Is this limited to the responder? or should the initiator too take that into
considerations?

# Section 5

Second paragraph: I guess the potential for downgrade attack is not limited to
the NULL use case. If one of the supported methods is consider to be weaker
than the others, then an active attacker in the path could force the parties to
use that weaker method.