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

[Raj Singh <[e-mail]>]

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 <[e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Raj Singh
> *Sent:* Wednesday, July 22, 2009 8:52 AM
> *To:* [e-mail]
> *Subject:* [IPsec] [IKEv2] Questions on windowing in IKEv2
>
>
>
> 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
>
>
>
> Scanned by Check Point Total Security Gateway.
>
>
> Email secured by Check Point
>
>