vijay kn writes: > Praveen/Ahmad,> Some vendors don’t support Reauth. In this case what > to do?
There is no specific need for reauth on the protocol level. You create new IKE SA, you create new Child SAs, you delete old IKE SA. Everything is just standard IKEv2 and all implementations support that on the protocol level. For the SGW end everything looks like the client just reconnected. For the client end you need bit more code. I.e. when client notices that policy has changed so that REDIRECT support should be turned, then instead of sending your new INFORMATIONAL exchange, it will simply do the reauthentication. This is much easier to implement than what you suggested. Also as people have already pointed out, there is NO POINT of disabling feature on the implementations, especially if you can already now see that you might need it at some point. If it cause problems because of bugs, fix those bugs. If the client implemenation does not support REDIRECT, then upgrade it, and upgrade usually means that you need to start IKE SA again anyways... > I think we are slightly deviating from our original topic. I do not think there is problem here that requires solving. We already have REDIRECT. There are ways to use it. There is way to enable it by doing reauthentication. There is actually another way to do the same thing, i.e. using MOBIKE to dynamically move SAs from one IP-address to another, and of you support suitable methods of transfering SA information to another host you can use that to move all or some IKE and IPsec SAs from one host to another without causing any disruptions. On the other hand you need to send MOBIKE_SUPPORTED in IKE_AUTH, so you cannot enable that on the fly either... And one of the use cases in RFC4621 (MOBIKE Design document) is multihomed servers, i.e. the MOBIKE do allow both ends to move. The rendezvous is outside the scope of MOBIKE, so both ends cannot move at the same time without keeping at least some of the addresses intact. > Why to do reauth which is an expensive operation when you can just intimate > the SeGW that u support redirect via an INFO msg. If you do not want to do expensive operations, then enable the REDIRECT support from the beginning... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
