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

A few observations about the replay issue


As I promised, I've spent some time doing some research on past wg
discussion on the replay issue.  As some of you may recall, this is not
the first time that we've had extensive discussion about this issue.  We
also discussed this issue extensively in Febuary through May of this
year.  As might be expected, we went round and around many of the same
issues that have been brought up recently.

One of the last messages back in May on this subject was written by Dan
Harkins in response to a proposal made by Steve Kent.  This message was
dated Wed, 14 May 1997 17:10:50 -0700:

>To: Stephen Kent <kent@bbn.com>
>Cc: ipsec@tis.com
>Subject: Re: Comments on draft-ietf-ipsec-new-auth-00.txt 
>In-Reply-To: Your message of "Tue, 13 May 1997 21:05:44 EDT."
>             <v03007800af9e7cd32425@[128.89.30.20]> 
>Date: Wed, 14 May 1997 17:10:50 -0700
>From: Daniel Harkins <dharkins@cisco.com>
>
>  Steve,
>
>> 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.
>
>  If I understand this correctly, the initiator of the KMP can choose to 
>add this attribute to his security suite offering to inform the responder of 
>his AR window size. He can also choose not to send it and the default is 
>assumed by the responder. Likewise, the responder can choose to send this 
>attribute back describing his AR window size regardless of whether the 
>initiator sent one (and the attribute value the initiator sends has no 
>bearing on the value the responder sends). In other words, this is not a 
>negotiable attribute; it is an informational attribute. If that understanding 
>isn't correct ignore the rest of this email but please straighten me out,
>
>  While complexity isn't introduced, something else is. We'd always understood 
>that the responder in the KMP would either accept or reject a proposed suite 
>of services in its entirety and not change anything in the offer or add 
>anything that wasn't in the offer. This changes that. 
>  Granted, it's a simple change and a check for "didn't add anything or change
>anything-- except for replay window size" is pretty easy, but I want the WG 
>to realize this change is being proposed before a show of hands. IPsec SA 
>negotiation takes place under the protection of the ISAKMP SA so I don't think 
>this is opening up a security hole.
>
>  In the way I understand this compromise, I'm fine with it.
>
>  regards,
>
>  Dan.

There were two other responses to Steve's proposal; one by Bill
Sommerfeld, and one from Steve Bellovin, which I include below:

>In-Reply-To: kent's message of Tue, 13 May 1997 21:05:44 -0400.
>	     <v03007800af9e7cd32425@[128.89.30.20]> 
>Date: Wed, 14 May 1997 16:17:07 -0400
>From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
>
>> Nonetheless, I propose the following compromise..... [text elided]
>
>Seems like a reasonable compromise.  It should not require significant
>code for the sender to ignore the additional attribute; the receiver
>need only send it if it supports variable replay window sizes (and
>thus already has significant additional complexity); and, if the
>receiver erroneously omits the attribute but does support
>larger-than-default windows, you can still interoperate.
>
>The attribute should be defined as "replay window *at least* this
>large"
>
>				- Bill


>Date: Wed, 14 May 1997 01:55:55 +0000
>To: Stephen Kent <kent@bbn.com>
>From: "Steven M. Bellovin" <smb@research.att.com>
>Subject: 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..... [text elided]
>
>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.... [text elided]


There were no other responses on the mailing list.  I can see how some
might have concluded that we had reached consensus, although given the
relatively few people (in relationship to the number who had been
participating on this thread for the past few months), it certainly was
a relatively weak show of consensus via silence on the part of most of
the participants.

More recently, there has been a lot of people taking issue with
precisely the point raised by Dan back in May --- namely, that changing
the ISAKMP packets to allow the receiver to inject an attribute that
wasn't part of the original proposed attribute set was unclean and
complex in its own way.  

As before, Steve Kent appears to be the main person argueing for this
feature, and the basis of his arguments is that it would make debugging
easier.  Personally, I find myself siding with Steve Bellovin in that
it's not clear that this one parameter by itself would be all that
useful.  Especially when you consider that implementations may decide
not to log the information about the replay window size, at which point
it really doesn't by the user anything anyway.  It's also not clear to
me that most ISP help desk personnel would have even the fastest clue
how to use this information.

I have another potential compromise which I think might answer
everyone's expressed concerns to date.  What if we were to remove any
mention of the replay window size from the ISAKMP negotiations, but
rather made this something which could be queried via SNMP?  Would that
make everyone happen?  We don't have to make any changes to the
attribute negotiation semantics, and for those who really think that it
would be helpful in debugging failed ipsec connections, programs will be
able to query the other host using SNMP.

What do people think?

						- Ted
Follow-Ups: