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

Re: Comments on draft-ietf-ipsec-new-auth-00.txt



Dan,

	Sorry to be late in responding, but intervening conferences have
kept me busy.  The message I get is that the idea of negotiating the use of
anti-replay, and of negotiating window size in AH (or ESP), is unattractive
for several reasons:
	- this is really a recipient security concern, and thus need not be
negotiated with the sender
	- it adds to the complexity of SA negotiation, making more work for
implementors
	- more complex negotiations introduce the opportunity for security bugs

These are all valid observations.  However, I do find the argument about
sender knowledge of the window size and fault isolation compeling.  Just
assuming that the receiver is enforcing AR abd that the window size is 32
is simple, but also simplistic.  Also, when I tend to use the phrase "I
don't find this argument compelling" it is usually wityh regard to changinf
the status quo, i.e., an argument should be compelling to warrant changing
the existing spec.  I note that there are published I-Ds for additional AH
transforms call for AR, but the base document does not, so a compliant
implementation that chose to implement AR would have to negotiate a
transform that included AR, separate from the default AR mode of no AR.
So, the argument that needs to be compelling is why one ought to change
from the published specs, which would require negotiation of AR.

Nonetheless, I propose the following compromise.  Have the sender always
transmit the AR counter, thus preserving the 8-byte AH alignment when using
the default auth data size of 12 bytes.  Allow the receiver to determine,
unilaterally, whether to check the AR counter, and to do so against a
window size chosen byb the receiver.  Make 32 the default window size, and
allow for large window sizes, in multiples of 32.  However, have the
receiver notify the sender of the selected window size (if any) as part of
the SA negotiation.  This simplifies the negotiation since only the
receiver needs tell the sender of the former's selected window size, but
now the sender has specific info about the security service parameters
empoyed on the SA.

This differs from the implementors' agreement only in the last detail.
Hopefully it does not introduce significant complexity (the receiver need
only declare a constant response if it's election of AR is constant) in the
code.

What does the WG say?  I'd like to receive straw poll votes on this.

Steve




Follow-Ups: