Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay algorithm without bit-shifting

[Yaron Sheffer <[e-mail]>]

I mostly agree with Tero. But I think this would make for a nice independently-submitted, informational RFC.

Thanks,
    Yaron

On 05/19/2011 04:25 PM, Tero Kivinen wrote:

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).

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.