[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-new-auth-00.txt
At 09:05 PM 5/13/97 -0400, Stephen Kent wrote:
>
>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.
While I'm still not convinced that the receiver need say anything -- there
are many more parameters one could send for fault isolation, such as TCP
timer parameters
and various queue length limits -- this is probably a reasonable compromise.
I do feel fairly strongly that the AR field should always be present. When
fields
are in some sense optional, the question of whether or not to transmit them
turns
on the relative cost of possibly unneeded bytes versus the complexity of
dealing with variable-format headers. In this case, I expect that the AR
field will almost
always be used; thus, it's worth carrying even for the rare cases where it
would
be ignored. Besides, the 8-byte alignment is important for IPv6.
I ran some calculations on the space overhead for AH, using actual packet size
distributions. With no AR field, we could possibly truncate the hash
calculation to 8 bytes (though I suspect we'd actually use the full 16
bytes). The total space required was 6% over the base value. With AR, and
a 12-byte HMAC, the overhead was 9%. The difference of 3% is a small
fraction of the normal monthly traffic growth. I conclude that it's
irrelevant to performance. I believe that I'm using old size distribution
data, but since the trend has been towards increased packet sizes -- and
hence for less of a percentage hit for a fixed increment -- my numbers are
quite
conservative.