[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
replay revisited
It has occured to me that the term 'window size' kept making me think of
acknowledgement windows. But this isn't an acknowledgement window. There
is no concept of the sender somehow sending a few packets and then "waiting
for permission to send more" as they would in some sort of flow control
situation. All the processing logic of the receiver is self-contained,
inside the receiver.
Therefore, I believe there is no technical reason for the receiver to tell
the sender their 'replay history length' (I propose this as a clearer term)
and in fact there is no reason the Replay History Length need be a multiple
of 32, 64, or anything else. There might be some sort of cryptographic
safety issue, in which case it would be appropriate for a comment to be
made, with explanation, as to a requirement for minimum Replay History
Length. I believe a suggestion was made in Memphis that it has been found
that live Internet traffic can get as far as 40 or so packets out of sync
(i.e. packet (n+40) arriving before packet (n) and if that is so then I
guess we want to SUGGEST a minimum Replay History Length of 40 (which a
wise and lazy programmer on a 32-bit architecture platform would implement
as 64, I bet.)
>X-Authentication-Warning: dharkins-ss20.cisco.com: Host
localhost.cisco.com didn't use HELO protocol
>To: ipsec@tis.com
>Subject: replay revisited
>Date: Mon, 18 Aug 1997 15:40:31 -0700
>From: Daniel Harkins <dharkins@cisco.com>
>Sender: owner-ipsec@ex.tis.com
>
> I would like to again bring up the subject of replay prevention in the
>current (July 21st, 1997) AH and ESP drafts. I do this not because I "lost
>the argument" but because I feel the issue was not resolved. Mere response
>to a point does not settle an issue. Consider this a call for a straw poll.
>After a suitable period of time and debate the co-chairs can call a halt
>and render a decision either way.
>
> It is my contention that replay is for the benefit of the recipient of
>a packet and is purely a local policy matter. That contention causes me
>to take issue with three points in section 3.3.3 of ESP draft (and the
>similar verbage in the AH draft).
>
> 1. when using a KMP to establish SAs the receiver should notify
> the transmitter that it is doing replay protection and
> what the window size is.
>
> 2. window size must be a multiple of 32.
>
> 3. when using a window size other than the default of 64 the
> receiver must notify the transmitter during SA negotiation.
> (Note that this seems to contradict preceding verbage which
> says that a window size of 32 is MUST and 64 is SHOULD, but
> the number itself is not the point of contention).
>
> Issues one and three require capability in ISAKMP/Oakley which is currently
>not there. There is no way to inform ISAKMP peers of any aspect of replay.
> Issue two is also something that I don't think needs to be part of the
>protocol specification. If I choose to use a processor with a non-standard
>word size (e.g. I believe a decsystem 20 is a 36 bit machine) for my new
>IPSec-compliant toaster I see no reason to prohibit me from using a replay
>window which matches its word size (on the contrary I see an obvious benefit
>in doing so). Also, if I'm masochistic-- or just plain stupid-- and choose
>to implement a window size of 47 bits I see no reason to render an otherwise
>conformant implementation non-conformant.
> It would be more reasonable to strongly advise the use of window sizes
>which are a multiple of the word size of the processor of the box on which
>the code runs and also to strongly recommend against use of window sizes
>lower than 32 bits.
>
> The argument in favor of the above three points is that it aids in
>debugging. My response to this is that if such debugging is done in a vacuum
>one must always assume that the recipient is doing sequence number
verification.
>If he is not then the problem obviously lies elsewhere. If such debugging
>is not done in a vacuum and the other party is contacted in some way (a
simple
>phone call, checking an IPSec MIB, etc.) to help determine the cause then
>there is no reason to send this extra information (note I'm all in favor of
>including replay window information in a MIB).
>
> There is also the contention that it's simple to just add the appropriate
>attributes and accompanying verbage to the DOI to allow ISAKMP to satisfy
>these requirements. (Note though that it's also simple-- perhaps more
simple--
>to just strike the problematic text). This would change a significant point
>in the ISAKMP/Oakley exchange. We'd always operated on the notion that
>a responder in the exchange can not add or remove attributes from a SA offer.
>This prevents a man-in-the-middle attack. Of course we could also add verbage
>to the ISAKMP/Oakley draft expressly allowing *only* the new replay
attributes
>to be added or removed but this now makes the change more complicated both
in
>text added to drafts and modifications to code which is already
interoperable.
> The more complicated code is the more prone to bugs it is and bugs in
>security protocols can be catastrophic. I think it's important to weigh the
>benefits of change against this possibility. In the case of the contentious
>text in the AH and ESP document I see absolutely no benefit. It really is
much
>simpler to just strike the text from the AH and ESP drafts and add the
>aforementioned text suggesting window sizes be multiples of processor word
>size and not be less than 32 bits.
>
> Please let your opinion be known.
>
> regards,
>
> Dan.
>
>
>