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

Sean,

Thanks for the comments

1. The code will be encapsulated including the copyright.  Is the pseudo-code better than actual C code?
2. The reference is normative.

Regards

Xiangyang

-----Original Message-----
From: Sean Turner [mailto:turners@ieca.com] 
Sent: Thursday, May 19, 2011 7:48 AM
To: Tina Tsou
Cc: ipsec@ietf.org; 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
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>