[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed changes to the DES-CBC, HMAC and Replay Prevetion

Security         Transform.
In-Reply-To: <19961002113835adams@161.44.128.127>
Organization: cisco Systems
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

[co-chair hat off; 
 just personal opinions, based in part on experience with the NRL codebase]

In article <19961002113835adams@161.44.128.127> Rob Adams wrote:
>The following are changes I'd like to make to the above document.  I've 
>posted comments about the changes to the list and didn't get a lot of 
>comments.
>
>I've made the following changes:
>     1) added a new transform specified by a different IANA number for 
>        packets including an IV.

	I do not see any real advantage to this.  

	IPsec Security Associations already have a fair number of attributes
defined (see RFC-1825).  The presence or absence of a separate IV field is
just an IPsec SA attribute, nothing more.  There is NOT significant extra code
here, just an if/else branch based on the value of a particular element of the
IPsec SA.

>     2) made the replay window size NON-negotiated.  It is left to the 
>        implementation.

	I find implementation-defined replay window sizes strongly undesirable.

	Different IP sessions have different security requirements.  The size
of the replay window relates directly to the quality of the provided security.
The ability to implement different security properties for different sessions
is an important feature of IPsec.  The replay window size should be
negotiated.

	For example, a major auto manufacturer might want to have a small
replay protection window for traffic transiting certain countries for
increased security at the cost of higher chance of losing some out-of-order
packets while having a larger replay protection window for less security but
less chance of lost out-of-order packets for traffic that never leaves the
domestic US auto industry community.

Ran
rja@cisco.com