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

No Subject

WAA07116 for ipsec@tis.com; Mon, 18 Aug 1997 22:09:13 -0700 (PDT)
Message-Id: <199708190509.WAA07116@snow.NSD.3Com.COM>
Subject: Re: replay revisited
To: ipsec@tis.com
Date: Mon, 18 Aug 97 22:09:12 PDT
In-Reply-To: <199708182240.PAA12359@dharkins-ss20>; from "Daniel Harkins"
at Aug 18, 97 3:40 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-ipsec@portal.ex.tis.com
Precedence: bulk

I apologize in advance if this has already been covered 
in previous email exchanges but why isn't replay protection
at the receiving end a MUST in non-manual keying situations?

If someone goes as far as encrypting data for security 
purposes, he may as well also protect himself against 
replay which does not require much processing power 
compared to encryption.

I do not see much benefit to issue 3 either unless knowing
the window size allows the sender to take corrective measures
during the same SA.

- Ly



> 
>   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: