Yaron Sheffer writes: > I am thinking of symmetric IKE peers (gateways, or endpoints using > transport mode ESP; no EAP, rarely any NAT). Is there any reason why > the current draft cannot support this case in a symmetric manner?
Why do you need any protocol for that. Why does not normal IKEv2 be enough for that. I.e. if node A wants the node B to move to use some other location, it can simply connect to node B using that new location, and remove the old IKE SA. I.e. if scenario is really symmetric, there is no need to have any IKEv2 redirect protocol at all, everything can be done by the node by directly connecting using new location. It is quite hard to explain this thing as I have no idea what kind of scenario you are talking about. Can you give real example, what the nodes are and why do they want to redirect other end. MOBIKE is not restricted to the VPN client <-> VPN server situation, but is limited that node must stay same. I.e. it is moving between multiple addresses of node A and moving between multiple address of node B. It cannot ask node B to move from node A to node C. But if node A wants node B to use node C instead of node A, it can simply inform node C to make connection to B and delete its own IKE SA. It can also do this by just changing the back end routing or similar, so that return packets go to node C instead of node A and then node C will initiate connection to node B immediately when first packet arrives (if the situation is really symmetric). If we are talking about client and server situations where server wants to redirect client to some other server, then situation is no longer symmetric. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
