-----Original Message-----
From: Tero Kivinen [mailto:[email protected]]
Sent: Thursday, May 19, 2011 6:26 AM
To: Xiangyang zhang
Cc: Tina Tsou; [email protected]
Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay
algorithm without bit-shifting
Xiangyang zhang writes:
> This proposal addresses two major issues in IPsec anti-replay service:
> 1. Some high end security router can configure thousands of bits for
> anti-replay window. For example, Juniper can configure up to 4096
> bits. The bit-shifting for this window is a tremendous burden,
> resulting in the performance drop.
> 2. High-end network processor could have multiple crypto cores to
> access the window. In order to check and update the window, the
> exclusive lock must be obtained.
If I have understood correctly the algorith listed in the rfc4302 etc
is only for illustrative pseudo-code, the actual implementations may
be different (and at least our implementation do not use bit-shifting
at all as it would be way too inefficient).
[xiangyang] Three RFCs describe almost the same algorithm.
For illustrative pseudo-code, it shifts bits when the window
is updated (Page 41 in RFC4303). Definitely it is efficient
if bit-shifting is bypassed.
In addition, the check and set of the specific bit is also
simplified here. In old method, the location of the bit
depends on both the largest sequence number received and
the current sequence number. Instead,
it only depends on the sequence number currently received.
The anti-replay checking in the IPsec is local matter to the
implementation and does not have any interoperability requirements in
addition that the sequence number field is always present.
This draft provides nice alternative algorithm to the one provided in
the RFC, but as the algorithm listed in the current rfc is not
mandated anyways and there is no externally visible differences in the
algorithms I do not see reason to document this as RFC.
This would be better as techinal paper about providing faster
algorithm for the anti-replay checking.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
