IPsec Anti-Replay Algorithm without Bit Shifting
draft-zhang-ipsecme-anti-replay-07

[Ballot discuss]
I believe that either the interoperability considerations for increasing the window should be documented in the draft, or the IESG should add some warning label as an IESG note to this draft. My recommendation is to add a paragraph that discusses the implications. I'm hoping the authors could suggest text.

[Ballot comment]
We should let this document be published. That being said, I do have a number of comments that are perhaps best directed to the RFC Editor and the authors.

>and it reduces the number anti-replay window is adjusted.

This text does not parse.

> For high-end multi-core network
> processor with multiple crypto cores, a window size bigger than 64 or
> 128 is need due to the varied IPsec processing latency caused by
> different cores.

I think it is a very bad idea to use implementation strategies that cause significant
packet reordering. In particular, the interoperability implications towards implementations
(many) that happen to employ 32 or 64 bit windows... not to mention impacts to higher layer
protocols.

In my opinion, the document needs to describe its interoperability implications. I'm not sure if the
IESG needs to require that or if that's just something that the RFC Editor should ask the authors
to do, but this obviously has an affect to the ability of an implementation to work with another one.

> In such a case, the window sliding is tremendous
> costly even with hardware acceleration to do the bit shifting.

Really? In an implementation that has to run complex cryptographic operations on each word in the packet? I can imagine hardware solutions where bit shifting is really easy :-)

In any case, isn't this just an example of the use of good old circular buffers (http://en.wikipedia.org/wiki/Circular_buffer)? Elements in the buffer are bits indicating whether or not the sequence number has been seen, and in addition to the circular buffer pointers you have to keep a value that indicates what the first (or last) sequence number in the window is. Then you check for a packet that has been seen with

    seqno >= windowstart &&
    seqno <= windowstart + WINDOW_SIZE - 1 &&
    circbuffer->table[circbuffer->first + (seqno - windowstart) % WINDOW_SIZE]

Or something along those lines. Is this all you are doing, or am I missing something? If so, I found the description in the body of the document unnecessarily complicated.

[Ballot comment]
- Should this have the vendor name in the title?
That'd be the "Futurewei IPsec anti-replay..."

- last sentence of abstract is unclear - I'm not
sure what's being reduced.

- intro, 2nd sentence: s/The mechanisms/The mechanism/

- introp, last para:
  s/For high-end/For a high-end/
  s/is need/is needed/

- I don't get this: "We hide one block from the window."
Probably just needs re-phrasing.

The draft draft-draft-zhang-ipsecme-anti-replay-03
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

This Informational draft presents an alternate method to do the
checks and updates for IP Authentication Header (AH) and algorithm in
RFC 4302 and RFC 4303. The new method will obviate the need for
bit-shifting, and it reduces the number of times the anti-replay
window is adjusted.

Sean Turner has reviewed this draft, and helped its authors to
improve it.

Thanks, Nevil (ISE)

--
Nevil Brownlee (ISE), rfc-ise@rfc-editor.org