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:[email protected]]
Sent: Friday, May 20, 2011 1:27 PM
To: Yaron Sheffer; Tero Kivinen
Cc: [email protected]; 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:[email protected]]
Sent: Thursday, May 19, 2011 6:45 AM
To: Tero Kivinen
Cc: Xiangyang zhang; [email protected]; 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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
