Reviewer: Rifaat Shekh-Yusef Review result: Has Issues # 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
