Hi Vijay, On Thu, May 28, 2009 at 3:24 AM, Vijay Devarapalli <vi...@wichorus.com>wrote:
> Hi, > > On 5/26/09 10:10 PM, "Raj Singh" wrote: > > > Hi Vijay, > > > > I have some question on ikev2-redirect-10 draft. > > > > In section 5, > > ------ > > Once the client sends an acknowledgment to the gateway, it SHOULD > > delete the existing security associations with the old gateway by > > sending an Informational message with a DELETE payload. The gateway > > MAY also decide to delete the security associations without any > > signaling from the client, again by sending an Informational message > > with a DELETE payload. However, it should allow sufficient time for > > the client to setup the required security associations with the new > > security gateway. This time period should be configurable on the > > gateway. > > ------- > > > > Suppose after sending N[REDIRECT] in case of Gateway initiated redirect, > > there is a time gap for client to delete old SA and create new SA with > > redirected Gateway. > > > > During this time, IKE REKEY occurs from gateway or client, what should be > > the behavior, should it REKEY on old SA or defer the rekey ? > > The rekey should be deferred. The IKEv2 SA is going to be torn down anyway. Can you make a mention of this in the draft ? According to me, we can make it simple by saying that after REDIRECT, IKE SA will be marked for deletion i.e. we will send/accept only DELETE informational exchange on that SA. > > > > Also, when deleting IKE SA, due to redirect, is there any way to know > that > > this delete is sue to redirect ? > > Well, the gateway redirected the client. If following that, there is a > delete from the client, the gateway would know that the IKEv2 SA is being > deleted because it redirected the client. > > Anyway, does it matter? > It does. There is a time gap between REDIRECT and DELETE for the IKE SA. If any activity happens during that period due to valid reasons ( REKEY, DELETION due to lifetime etc.), we will not be sure what to do ? Also, for administrative purpose we need to know that DELETE happened due to REDIRECT or valid reasons. Accepting only DELETE after REDIRECT solves all these problems. > > Vijay > > Thanks, Raj
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
