On Fri, 27 Dec 2019, Valery Smyslov wrote:
The successful exchange of SECLABELS_SUPPORTED notification only ensures that the responder won't ignore SECLABEL notification in requests to create IPsec SAs.
Over the hollidays, I tried to show weaknesses in this approach, but failed. I think Valery is right. Although, I'm not sure yet what an initiator requiring labels would do if the responder replied without the notify. Should it delete/retry the exchange, or start an IKE_AUTH with some kind of (new?) notify error ? Or should it go ahead regardless as to not leak to the network that this IPsec SA uses labels, and wait for the remote end to return an inevitable TS_UNACCEPTABLE? On the responder, I'll assume that it will continue in general with the IKE_SA_INIT reply even if it is missing the notify and it has some connections configured to use labels. Since it does not know for sure in all situation if its IKE_SA_INIT reply generated is for the proper connection (if it has multiple connections configured). So here too, after the responder receives Traffic Selectors of the non-label kind, it will return TS_UNACCEPTABLE.
OK, I think it's a right way to go. In fact I suggested it back in May 2018 :-)
I paid in time for my reluctance to be convinced by you and Tero at that time :) Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
