RE: draft-ietf-rap-auth-policy-data-00.txt

["Hess, Rodney" <rodney.hess@intel.com>]

Thanks for your feedback, Tom.

Yes, the intent is to have a reordered windowing algorithm as you describe
below.  It would appear that the document's wording does not convey this
effectively enough.  I can   certainly pull in what you have written below
and tighten up the other references in the next draft.

Rodney


-----Original Message-----
From: Hall, Tom G. [mailto:Tom.G.Hall@wcom.com]
Sent: Monday, July 02, 2001 3:02 PM
To: 'rap@ops.ietf.org'
Subject: Re: draft-ietf-rap-auth-policy-data-00.txt


Good Day All, 

Seems like a good idea; overall, a very well written draft.
I had a few problems understanding the wording in places, 
but that will change as the draft heads toward RFC status.

- - -
I encourage anyone and everyone to pursue the key 
management issue. (pg.11) "It is likely that the IETF 
will define a standard key management protocol." We
really need this.

- - - 
I got a bit confused about the validation of sequence 
numbers. In one place it talked about storing the last 
N sequence numbers, then in another it said that a 
receiver only needs to save the highest sequence number 
seen, then later on I see a 'reordering window' that 
will allow for limited ... well, reordering of sequence 
numbers. But then it says something about both storing 
a number and therefore removing a number from the lower 
end of the list (reorder window). 

I shouldn't complain unless I'm ready to offer an 
alternative, so I propose the following text to describe 
the use of reordering windows for sequence numbers: 

- - - 
(all sequence numbers computed modulo 2^64) 

An authenticating receiver maintains a 'reorder window'. 
The window consists of a list of N consecutive sequence 
numbers. (N >= 1) The list shall begin with an initial
sequence number generated as described in Section 3.

Each number in the list shall have an associated 'flag' 
which indicates whether or not the receiver has received
that sequence number in a request message. 

The authenticating receiver shall: 
(1) Reject any sequence number less than the smallest number 
    in the list. 
(2) Reject any sequence number in the list that has been 
    seen before. 
(3) Accept any sequence number in the list that has never 
    been seen before, and then flag that number as having been 
    seen. 
(4) Accept any sequence number (S) greater than the largest 
    number in the list, and then create a new list containing 
    the numbers S-N+1 through S, inclusive, along with the flags 
    any numbers that also appeared in the old list. 

Example: (reorder window of size 10, Initial Sequence
Number =35,'+' means seen, and '-' means unseen)

Event   List 
-----   ---- 
Start   35-, 36-, 37-, 38-, 39-, 40-, 41-, 42-, 43-, 44- 
Get 37  35-, 36-, 37+, 38-, 39-, 40-, 41-, 42-, 43-, 44- 
Get 36  35-, 36+, 37+, 38-, 39-, 40-, 41-, 42-, 43-, 44- 
Get 35  35+, 36+, 37+, 38-, 39-, 40-, 41-, 42-, 43-, 44- 
Get 32  (reject as too small) 
Get 41  35+, 36+, 37+, 38-, 39-, 40-, 41+, 42-, 43-, 44- 
Get 36  (reject as duplicate) 
Get 42  35+, 36+, 37+, 38-, 39-, 40-, 41+, 42+, 43-, 44- 
Get 48  39-, 40-, 41+, 42-, 43-, 44-, 45-, 46-, 47-, 48+ 

Note that this algorithm also works for the strict case 
where N = 1. 

- - -
Regards,
-- Tom