-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "jamal" == jamal <hadi@xxxxxxxxxx> writes:
jamal> Krisztian,
jamal> To take a rough estimate of 5K users, how often do you think
jamal> these replay messages will be generated?
jamal> Is there a (clever) way to avoid transporting them and still
jamal> achieve an accurate failover?
Yes there are some heuristics one can apply.
First, on receiver, if you are the slave, you need no information at
all. Replay counters monotonically increase, so any packet you get >
than you saw before is okay. As such, you can easily tradeoff risk of
replay attack vs number of messages to carry.
On transmit, you have to be accurate on the lower bound, but if your
lower bound is *too high*, that's okay. there is just a hole in the
replay counter, and that's okay too.
So, once you decide on the update rate master->slave, and if you know
approximately how many packets/second are going through on the master,
you can take packets/second * 1/update-rate and tell the slave to start
at that number if it has to take over.
(Note that you have to acount for packets-in-flight, which may
actually be substantial, and IPsec has no way to know what the RTT is,
unlike TCP. It could steal the info from TCP, if TCP had a session
open, which as a gateway, it would not do..
Some have suggested having IKE keep a TCP session up just for
this information.)
] Train travel features AC outlets with no take-off restrictions| firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@xxxxxxxxxxxxxxxxxxxxxx http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQY5ecIqHRg3pndX9AQEl6gP+OeX08RaO60c9BOXqNoqkb6PvUcBX1t9v
mdaNpkUA+iy6RpYQwcBxfN4G4yvwwbO9JDgPRK/k/Wh6zmY4dBLgtiG1tlFaEUcf
6HRBmBSmIbDUpFkAYGdSJuQxhGDas6sxi4MF6tIsaZUtJzqO+Xp5HtrauzTH56VV
vswtfMy8z7k=
=FV58
-----END PGP SIGNATURE-----
|