This is the only bit I'm competent to comment on: On 23-Sep-21 09:20, Michael Richardson wrote: ... > 4) I also noticed that there is a race condition between seeing the GRASP > AN_ACP and setting up the policy. > > Node A says, "AN_ACP", "I'm here". > Node B sees it, and initiates to Node A. > But, node A hasn't seen node B's AN_ACP yet, so node A hasn't got a policy > to talk to node A yet. The node B->A result is an IKEv2 > authorization/authentication failure. > Then node A will see node B's AN_ACP, install a policy, and initiate from > A->B, and everything is fine.
Sure. That's a generic race condition for any mutual-discovery type of bootstrap, isn't it? I assume that all nodes will be attempting ACP setup at some (reasonably low) frequency until it succeeds. So a failure due to a race condition (or anything else, actually) can simply be ignored: try again later. My only small suggestion would be to slightly randomize the wait time before trying again, so that the race condition is unlikely to recur. That would be a slight tweak on the RFC, which says "the RECOMMENDED period of sending of the objective is 60 seconds." > What could occur is that I could remove the very specific remoteip= in the > policy, and have a less specific policy that accepted a connection for > remoteid=* from any IPv6-LL. I'm not really crazy about that solution. No, it might even open a chink in the security armour. > I'm not actually sure that there is a problem. The issue is noise. Indeed. Fix it with more noise (randomization). Brian _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
