|
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. |
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
