RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt

["Housley, Russ" <rhousley@rsasecurity.com>]

David:

> > The consequences for reusing a sequence number are significantly
> > different than the consequence of reusing a CTR mode key stream.
>
>Agreed.
>
> > Therefore, I think
> > that it is worth a few extra bits of overhead to make sure that the
> > per-packet value is managed inside the security boundary.
>
>But why not make the per-packet value that's managed within the security
>boundary be the sequence number?  If an LFSR is used to generate explicit
>IVs, then it will need to be generated and managed within the security
>boundary.  An LFSR is no easier to manage than an integer, since both types
>share the same properties w.r.t. the storage and movement of data.  If the
>ESP sequence number is generated within the security boundary, it can be
>used to provide secure anti-replay protection as well as secure per-packet
>values for counter mode.

The point of the compromise it to accommodate both assurance implementation 
approaches and both IV generation approaches.  In one of these four cases, 
the sequence number and the IV will be identical.  In the other three 
cases, they will probably be different values.

When the sequence number is assigned within the assurance boundary, and an 
integer counter is being used to generate the IV, the same value could be 
used for the sequence number and the IV.  Of course, in my proposal, it 
gets carried twice in the packet.

Russ