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

[Tina Tsou <[e-mail]>]

Yaron, Tero, and Sean,
If Sean could be the sponsor AD, I'm happy to submit it as an independent
submission.
 
We keep our promises with one another - no matter what!
 
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
 
From: Xiangyang zhang [mailto:[e-mail]] 
Sent: Friday, May 20, 2011 1:27 PM
To: Yaron Sheffer; Tero Kivinen
Cc: [e-mail]; Tina Tsou
Subject: RE: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay
algorithm without bit-shifting
 
I agree.   Actually our intention is to provide informational RFC.  We do
not change the sliding
window protocol for integrity service.  It just provide one alternative, or
better alternative
in most cases, to the one specified in IPsec RFCs.
 
Thanks,
 
Xiangyang
 
From: Yaron Sheffer [mailto:[e-mail]] 
Sent: Thursday, May 19, 2011 6:45 AM
To: Tero Kivinen
Cc: Xiangyang zhang; [e-mail]; Tina Tsou
Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay
algorithm without bit-shifting
 
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.