[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: replay revisited
We took out the replay attribute in ISAKMP for a purpose and I don't
wish to see it back again. We also did away with replay size
negotiation (or notification) a longer time ago, and I really don't want
to see that back again.
>----------
>From: Daniel Harkins[SMTP:dharkins@cisco.com]
>Sent: Monday, August 18, 1997 6:40 PM
>To: ipsec@tis.com
>Subject: 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: