RE: replay field size

[Roy Pereira <[e-mail]>]

>> We should be able to just plug in a new cipher algorithm and a new 
>> digest algorithm without having to re-invent the wheel.  Just plug 
in
>> their identifiers and go...

>There _is_ more to it than just identifiers.  Different algorithms 
have
>different modes and different resulting data sizes and IVs and so 
forth.
>With AH HMAC SHA-1 there was the question raised of using the 
standard
>160-bit SHA-1 output or truncating to use 128-bits of SHA-1 output.
>If one truncates, then the method/process of truncation needs to
>be openly and clearly specified.  Just assigning identifiers will
>tend NOT lead to interoperable implementations.  Additional 
structure
>to the base specifications will help, but is probably not a panacea.

Ran, my point was that a very large portion of the existing transform 
drafts contain the exact same words and definitions.  Yes, more than 
an identifier would be required for some algorithms, but again there 
exists quite a lot of the specification wording that overlap.  Rules 
for such things as truncating a digest (or padding it) would be better 
defined in a common draft (ESP and/or AH).

If there was a common method to obtain a variable length IV and 
variable length keys from keying material, then this information would 
not have to be in every transform draft.

Why should all ESP transform drafts list the ESP structure, define 
replay protection, and define how to obtain keying?  These common 
specification sections only need to be specified once.