[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replay revisited
Dan,
> 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.
Yes, ISAKMP/OAKLEY does not currently support this facility, just as it
does not support SAs that have a granularity finer that IP address pairs.
In talking with Derrell Piper, the DOI document editor, at the Munich
meeting I got the impression that this change would be easy, but I defer to
Derrell on this point.
> 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 requirement for a window size that is a multiple of 32 is motivated
purely by ease of implementation concerns. A couple of years ago I
suggested using a bit mask to track received packets within the window, to
allay concerns over the implementation costs of supporting anti-replay.
Jim Hughes provided sample code for doing this in his I-Ds, demonstrating
that the general notion worked efficiently. Since CPU registers tend to be
32 or 64 bits in length, it was suggested (by Bob Moskowitz?) that the
integral multiple of 32 was an appropriate constraint on window sizes.
However, I agree that a word size multiple is appropriate, and the multiple
of 32 accommodates modren processors with either 32 or 64 bit
architectures. You're right, the old DEC-20 is at a disadvantage here and
the WG needs to decide if that's acceptable, or not. Finally, the current
draft, at Bob Moskowitz's suggestion, calls for a default window size of
64, with 32 as a minimum.
> 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).
Cheryl Madson pointed out in Munich that the sender needs to know whether
sequence number cycling is a fatal, auditable error, or not. The only
reason that cycling should trigger such a response is if the receiver is
enforcing anti-replay. This argues that the receiver must notify the
sender of its intent to enforce anti-replay for an SA.
I thought the focus of our argument was whether the receiver needed to
inform the sender of the window size, in the cases when anti-replay was in
effect. The argument I have made was that without such information, the
sender has a harder time trying to trouble shoot if there are connection
problems. Consider a user connecting to some sort of (non-HTTP) server.
If the user has problems, the user will contact his help desk, which then
will try to isolate the problem. The folks responsible for the IPsec
implementation at the far end may not be readily available (e.g., bacuse of
time zone differences) or may not be suitably motivated to quickly assit in
identifying the problem. Thus I have advocated making as much info as
possible available at the sender's IPsec implementation to facilitate such
trouble shooting. It is not clear that the info in the MIB at the
receiver's end would be readable by the management folks at the sender's
end, so the alternative is being able to get realtime assistance from folks
at the receiver's end. For the reasons cited above, and others, this may
not always be practical or expedient.
> 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.
I defer to Derrell as to how easy or hard it is to accommodate this
feature, as noted above. We both agree that simpler code is potentially
more secure, but providing for good management support also is a laudable
goal.
The best argument I have heard in favor of not reporting window size was
the suggestion Christian made at the meeting, i.e., the possibility of
allowing dynamic window sizes based on observed packet drop rates. This is
clearly a much fancier approach to window management that we have ever
diuscussed in the WG. Moreover, upon futther reflection, it seems very
susceptible to denial of service attacks. Specifically, I can replay
packets that are likely to be outside of the current window. You can
reject them out of hand, or you can validate them and decide that they
might be legitimate but oustide of the window, and thus decide to enlarge
the window. As the window grows larger than the word/register size, its
management becomes more expensive, for every packet received (since one
must shift multi-word quantities if there are any gaps in the received
packet space, something an atacker may be able to effect by selective
deletion). In generalk I would suspect than other approaches to dynamic
window management would encounter similar performance penalties, although I
certainly can't prove this conjecture.
So, on the assumption that simple window management is less prone to error
than complex window management, and on the assumption that fault isolation
should be facilitated if the complexity costs are not very great, I still
recommend reporting the size of the window selected by the receiver. Note
that there still appears to be a need for the receiver to notify the sender
if the receiver has enabled anti-replay, for the reason cited above (the
sender counter overflow error response).
Steve
Follow-Ups:
References: