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

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: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
>>
>