Subject: [IPsec] [IKEv2] Questions on windowing in IKEv2

From: Raj Singh <[email-masked]>
Date: Wed, 22 Jul 2009 11:22:25 +0530

Hi Group,

According to IKEv2bis-04, section 2.3

-----------------------------------------

   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.  An IKE endpoint MUST keep a copy of (or be able
   to regenerate exactly) each request it has sent until it receives the
   corresponding response.  An IKE endpoint MUST keep a copy of (or be
   able to regenerate exactly) the number of previous responses equal to
   its declared window size in case its response was lost and the
   initiator requests its retransmission by retransmitting the request.

----------------------------

Now, suppose responder window size is N.
Initiator send a request (X-N) but Initiator does get
response for request no (X-N) say due to n/w flapping.
So initiator schedules this request for re-transmissions
but between the time intervals of re-transmission n/w comes UP
and request no. (X-N+1) to (X) goes fine i.e. these request get response.
Now, initiator wants to make another request i.e. request no.
(X+1). But according to draft it can't make that request as it has
not received the response for request no (X-N) even though there is
only one outstanding request in transit.

Also draft says:
---------------------------
 The SET_WINDOW_SIZE notification asserts that the sending endpoint is
   capable of keeping state for multiple outstanding exchanges,
   permitting the recipient to send multiple requests before getting a
   response to the first.
------------------------

That means windowing is for outstanding request.
So in above mentioned scenario even though there is only 1
outstanding request and window size is N but we are not able to send
next request because of windowing definition.

Maybe i am missing something here.
Please elaborate the on the behavior in above scenario.

Regards,
Raj

---

From: Yoav Nir <[email-masked]>
Date: Wed, 22 Jul 2009 10:39:28 +0300

Hi Raj.

Too many variables, let's assume values without loss of generality.

Suppose N=3, and you have send requests 17, 18 and 19. Because of the network problems, you got responses for 18 and 19, but not *yet* for 17.

What the draft (and RFC 4306) says, is that you keep retransmitting 17, until you get a response.  Before that, you can't begin transmitting #20. If your retransmissions of #17 time out (after "at least a dozen retransmissions over at least 2 minutes") then you assume that the peer has died, and silently discard the IKE SA.  This will usually not happen in the above scenario, because once the network is back, the responder will also reply to #17.

Hope this helps

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Raj Singh
Sent: Wednesday, July 22, 2009 8:52 AM
To: [email-masked]
Subject: [IPsec] [IKEv2] Questions on windowing in IKEv2

Hi Group,

Also draft says:

   response to the first.

------------------------

Regards,

Raj

Scanned by Check Point Total Security Gateway.

Email secured by Check Point

---

From: Yoav Nir <[email-masked]>
Date: Wed, 22 Jul 2009 12:03:43 +0300

No. All the draft says, is that to send 20, you need to have received answers to everything up to and including 17. You don't get to always have three outstanding requests.

________________________________
From: Raj Singh [mailto:[email-masked]]
Sent: Wednesday, July 22, 2009 11:57 AM
To: Yoav Nir
Cc: [email-masked]
Subject: Re: [IPsec] [IKEv2] Questions on windowing in IKEv2

Hi Yoav,

Do you think this behavior contradicts with definition of windowing mentioned in draft that if responder window is 3, initiator can have 3 outstanding request ?

Regards,
Raj
On Wed, Jul 22, 2009 at 1:09 PM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:

Hi Raj.

Hope this helps

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Raj Singh
Sent: Wednesday, July 22, 2009 8:52 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [IPsec] [IKEv2] Questions on windowing in IKEv2

Hi Group,

Also draft says:

   response to the first.

------------------------

Regards,

Raj

---

From: Raj Singh <[email-masked]>
Date: Wed, 22 Jul 2009 14:27:20 +0530

Hi Yoav,

Do you think this behavior contradicts with definition of windowing
mentioned in draft that if responder window is 3, initiator can have 3
outstanding request ?

Regards,
Raj

On Wed, Jul 22, 2009 at 1:09 PM, Yoav Nir <[email-masked]> wrote:

>  Hi Raj.
>
>
>
> Too many variables, let’s assume values without loss of generality.
>
>
>
> Suppose N=3, and you have send requests 17, 18 and 19. Because of the
> network problems, you got responses for 18 and 19, but not **yet** for
> 17.
>
>
>
> What the draft (and RFC 4306) says, is that you keep retransmitting 17,
> until you get a response.  Before that, you can’t begin transmitting #20. If
> your retransmissions of #17 time out (after “at least a dozen
> retransmissions over at least 2 minutes”) then you assume that the peer has
> died, and silently discard the IKE SA.  This will usually not happen in the
> above scenario, because once the network is back, the responder will also
> reply to #17.
>
>
>
> Hope this helps
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Raj Singh
> *Sent:* Wednesday, July 22, 2009 8:52 AM
> *To:* [email-masked]
> *Subject:* [IPsec] [IKEv2] Questions on windowing in IKEv2
>
>
>
> Hi Group,
>

---

From: "Amjad Inamdar (amjads)" <[email-masked]>
Date: Wed, 22 Jul 2009 14:53:19 +0530

Hi Yoav,
 
Any benefits of this behaviour over allowing 'window-size' outstanding
requests at any given time.
 
Thanks,
-Amjad

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Yoav Nir
Sent: Wednesday, July 22, 2009 2:34 PM
To: 'Raj Singh'
Cc: [email-masked]
Subject: Re: [IPsec] [IKEv2] Questions on windowing in IKEv2

No. All the draft says, is that to send 20, you need to have received
answers to everything up to and including 17. You don't get to always
have three outstanding requests.

Hi Yoav,

Regards,
Raj

Hi Raj.

Suppose N=3, and you have send requests 17, 18 and 19. Because of the
network problems, you got responses for 18 and 19, but not *yet* for 17.

What the draft (and RFC 4306) says, is that you keep retransmitting 17,
until you get a response.  Before that, you can't begin transmitting
#20. If your retransmissions of #17 time out (after "at least a dozen
retransmissions over at least 2 minutes") then you assume that the peer
has died, and silently discard the IKE SA.  This will usually not happen
in the above scenario, because once the network is back, the responder
will also reply to #17.

Hope this helps

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Raj Singh
Sent: Wednesday, July 22, 2009 8:52 AM
To: [email-masked]
Subject: [IPsec] [IKEv2] Questions on windowing in IKEv2

Hi Group,

and request no. (X-N+1) to (X) goes fine i.e. these request get
response.

Also draft says:

   response to the first.

------------------------

Regards,

Raj

---

From: Yoav Nir <[email-masked]>
Date: Wed, 22 Jul 2009 13:05:10 +0300

Window size limits the amount of responses that the responder has to remember.

After receiving requests 17, 18 and 19, the responder needs to remember those three responses, because if it gets a retransmission, it should reply with the old response.

When request #20 arrives, it is safe to discard #17.  If it was still valid for the initiator to send request #17 again, the responder would have to retain all the old responses indefinitely.

________________________________
From: Amjad Inamdar (amjads) [mailto:[email-masked]]
Sent: Wednesday, July 22, 2009 12:23 PM
To: Yoav Nir; Raj Singh
Cc: [email-masked]
Subject: RE: [IPsec] [IKEv2] Questions on windowing in IKEv2

Hi Yoav,

Any benefits of this behaviour over allowing 'window-size' outstanding requests at any given time.

Thanks,
-Amjad

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir

Hi Yoav,

Regards,
Raj

Hi Raj.

Hope this helps

Hi Group,

Also draft says:

   response to the first.

------------------------

Regards,

Raj