A gentle reminder. On Thu, May 28, 2009 at 8:37 AM, Raj Singh <rsjen...@gmail.com> wrote:
> 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
