Hi Yoav, Any benefits of this behaviour over allowing 'window-size' outstanding requests at any given time. Thanks, -Amjad
________________________________ From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Wednesday, July 22, 2009 2:34 PM To: 'Raj Singh' Cc: ipsec@ietf.org 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. ________________________________ From: Raj Singh [mailto:rsjen...@gmail.com] Sent: Wednesday, July 22, 2009 11:57 AM To: Yoav Nir Cc: ipsec@ietf.org 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 <y...@checkpoint.com> 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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Raj Singh Sent: Wednesday, July 22, 2009 8:52 AM To: ipsec@ietf.org 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 Email secured by Check Point
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
