On 5/19/11 6:56 PM, Xiangyang zhang wrote:
Sean,
Thanks for the comments
1. The code will be encapsulated including the copyright. Is the pseudo-code
better than actual C code?
I think that's up to you. I don't have strong preference either way.
2. The reference is normative.
Figured ;)
spt
Regards
Xiangyang
-----Original Message-----
From: Sean Turner [mailto:[email protected]]
Sent: Thursday, May 19, 2011 7:48 AM
To: Tina Tsou
Cc: [email protected]; Xiangyang zhang
Subject: Re: [IPsec] Draft-zhang-ipsecme-anti-replay: IPsec anti-replay
algorithm without bit-shifting
In section 3 please add the appropriate license for code components
(http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.pdf).
In a nutshell encapsulate the code with:
<CODE BEGINS>
code goes here
<CODE ENDS>
and right after<CODE BEGINS> include the following:
/*
Copyright (c) 2011 IETF Trust and the persons identified as authors
of this code. All rights reserved.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
In section 6 you need to say whether the references are normative or
not. I assume normative.
spt
On 5/10/11 3:45 PM, Tina Tsou wrote:
Hi,
Victor and I just submitted
https://datatracker.ietf.org/doc/draft-zhang-ipsecme-anti-replay/
IPsec anti-replay algorithm without bit-shifting
This document presents a new method to do anti-replay check and
update, which becomes one alternative to the anti-replay
algorithm in RFC 4302 and RFC4303. The new method will deem the
bit-shifting unnecessary. It will reduce the number of times
to slide the window. In addition, it makes bit-check and
bit-update easier as it does not depend on the low index of the
sliding window. It is especially beneficial when the window size
is much bigger than 64 bits, for example, 1024 bits.
IPsec employs one anti-replay sliding window protocol to secure
against an adversary that can insert the messages inside the
network tunnel. This method still inherits the sliding window
protocol, but use one or more redundant bytes to ease the update
of sliding window. The bit-shifting is deemed unnecessary with
updating the high and low index of the window, which is especially
efficient in case of the big window size. Thus the method reduces
the number of times to update the window.
In addition, the bit location is fixed for one sequence number,
thus makes the bit check easier and faster.
Comments are more than welcome.
We keep our promises with one another - no matter what!
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
