[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
replay revisited
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.
Follow-Ups: