Hi Paul,
On Wed, Dec 7, 2022 at 5:46 PM Tero Kivinen < <mailto:[email protected]> [email protected]> wrote: I started this last call almost a month ago, and I have not seen any discussion, comments or emails on the ipsec list. For me that would indicate that nobody has actually reviewed the document during the WGLC, and would indicate there is very little interest in publishing this document. I will keep the document in WGLC state for some time, but perhaps we should think whether there is enough interest to work on this issue at all. Sorry I thought / meant to reply. I think the concept is good, but I have questions on "supported" vs "accepted". From the initiator’s perspective it is more of “accepted”, since the initiator knows from the beginning who it is going set SA with, and thus have understanding how it is going to authenticate the peer. On the other hand, from the responder’s perspective it is more of “supported”, since at the time the responder sends this notification it has not yet received the initiator’s ID. The only information it has is its IP. Anyway, there is no negotiation, this is just an announcement. Often in these cases the support for all thee auth methods are there, it is just that for some connections we require one auth type and for another connection another auth type. This draft doesn’t solve all these problems, it solves some of them. To be able for the responder to further narrow down the list of acceptable auth methods based on the initiator’s ID, the responder has to have this ID. In IKEv2 the IDs are sent too late, in the IKE_AUTH. Actually, we can make it possible if the alternative scenario in the draft (outlined in Figure 3) is modified to include IDi in the IKE_INTERMEDIATE request. In this case the responder can actually base his choice of auth methods on the initiator’s identity. Do we want to add this functionality as an option? I am not sure sending indications in IKE_SA_INIT helps most cases, but it will help some if we remember the ones we received when it is time to generate the AUTH payload. adopting and talking about it more would be good. It has been adopted long ago :-) Regards, Valery. Paul
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
