On Sat, 4 Sep 2010, Kalyani Garigipati (kagarigi) wrote:
: 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
: reset_window.
: The initiator will not know which message Id should be used to send the
: new notify.
:
It's true, you're right.
: 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
:
Ah, how could I miss that, I still had the new exchange type back in my
mind from the -00 draft which I read first and then didn't properly read
the -04. I'm currently in the midst of this same problem and started
yesterday looking for a solution and google gave the -00 draft first, only
later to notice the new version. Sorry about that, my confusion.
INFORMATIONAL exchange with message id 0 is definitely the best solution.
I'll probably implement the draft (need working solution soon), and of
course will support also the finalized version of the draft. Will need
some poor man's message id discovery though with peers that doesn't
support this (at least try DPDs before tearing down SAs).
Although, I'm still not sure if the ESP/AH seq number sync is needed. It
should be enough to start sending packets with new sequence numbers. The
anti-replay window will move automatically. Also, imagine a huge cluster
with tens of thousands of SAs, the number of notifications will grow
quickly (not to mention packet size when including lots of them in one
notify).
Pekka
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
