|Main Archive Page > Month Archives > ipsec archives|
What is the message Id that can be used to send the informational
exchange while sending RESET_WINDOW notify? I find that your approach is
similar to this draft as
1. Initiator(failover) and responder(peer) agree upon the new range of
message Id's and ignore the lost message Id's.
Both the approaches define new notifies and need to send a informational
exchange to carry the notifies.
1. If window size is say some five and range expected is 4-8, and if
peer has got all four requests with values 5,6,7,8 and 4 is lost, then
there would be no message id that can be used to send the notify
The initiator will not know which message Id should be used to send the
And here the problem is not only to send the request, but also to
receive the request. The failover device should also know the
permissible range in which it can receive the requests from the peer.
The idea to send a new informational exchange with message Id zero was
thought only because when the failover takes control it would not know
what message Id it can use to know the peer window values .This is the
basic problem of message Id synchronization, so having new notify itself
will not help.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf
Of Pekka Riikonen
Sent: Saturday, September 04, 2010 4:14 PM
Cc: firstname.lastname@example.org; email@example.com
Subject: Re: [IPsec] Comments draft-kagarigi-ipsecme-ikev2-windowsync-04
On Fri, 3 Sep 2010, Pekka Riikonen wrote:
: something like next_message_id += window_size / 2, and be happy.
: implementation must ensure it never sends more than the increment
: window size of 1 doesn't work to begin with). Why was the window size
: by default to 1 anyway? Is there a reason why this wouldn't work?
This doesn't actually work. I think I'm seeing some ambiquity in the
when window size > 1. But, there's still ways to make this work easier
than with new exchange.
We could add new RESET_WINDOW notify that, when received inside a valid
window will reset the left side of the window to the value requested.
failover (assuming window size > 1), the online node can send the
notification to reset the window to the new value. Responder clears the
old states in the window as initiator has now deemed them lost.
Responder must reply with its N(RESET_WINDOW).
At the same time we should add GET_WINDOW_SIZE notify which initiator
use to request/require responder to set the window size. Responder
respond with SET_WINDOW_SIZE of at least the same size. So when
sends its N(SET_WINDOW_SIZE) it could at the same time require the
responder to send it too.
All these notifications in the ikev2bis should be "MUST be supported".
And then of course there's the poor man's way, where implementation
the failover could keep sending empty INFORMATIONAL's with new message
ids, and wait until it receives response. It now knows the message ids
to both directions. This requires that the message ids are synced in
cluster after every packet, so that node has recent values in the
IPsec mailing list
IPsec mailing list