RE: issue 11 -- window size

Tero pointed this out to me at the bakeoff.  Suppose your peer's window size
is 1; you send him a DPD (which he doesn't respond to).  Eventually, you
delete your SA, but you can't send him a request to do the same.  The peer
will eventually figure it out, hopefully.

-g 

> -----Original Message-----
> From: Bill Sommerfeld [mailto:[email protected]] 
> Sent: Wednesday, March 30, 2005 1:45 PM
> To: [email protected]
> Cc: 'Geoffrey Huang'; 'Jari Arkko'; [email protected]
> Subject: RE: [Mobike] issue 11 -- window size
> 
> On Wed, 2005-03-30 at 16:37, Stephane Beaulieu wrote:
> > This is only the case though if you assume that a mobility request 
> > should have a higher priority than a 'normal' request.  That normal 
> > request, if deadlocked due to mobility change, I would think would 
> > eventually time out, thus clearing up the window for the 
> mobility request to get through.
> 
> it appears that IKEv2 doesn't work that way.  quoting from
> draft-ietf-ipsec-ikev2-17.txt:
> 
>    An IKE endpoint MUST NOT exceed the peer's stated window size for
>    transmitted IKE requests. In other words, if the responder 
> stated its
>    window size is N, then when the initiator needs to make a 
> request X,
>    it MUST wait until it has received responses to all requests up
>    through request X-N.
> 
> in other words, if you don't hear back from the peer at all, 
> you can tear down the IKE association but you can't abandon a 
> request in progress and keep going forward through the sequence space.
> 
> 						- Bill
>