[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments about draft-ietf-ipsec-ike-01.txt
I see.
If this is a concern to the Network Administrator, then he should configure
his IKE lifetimes to be 8K, if he truly wants his maximum to be 16K
shouldn't he?
> -----Original Message-----
> From: Tamir Zegman [mailto:zegman@checkpoint.com]
> Sent: Thursday, June 24, 1999 3:06 AM
> To: Stephane Beaulieu
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Comments about draft-ietf-ipsec-ike-01.txt
>
>
> Consider a theoretical scenario in which an attacker filters
> out some of the IKE
> packets passed between Alice and Bob.
> Assume that alice and Bob negotiated an IKE SA that is
> supposed to be restricted
> to 16K of encrypted data.
> Alice and Bob sent 10K of IKE encrypted packets each but only
> 5K got to the
> other side.
> The attacker has now 20K of encrypted data which could (again
> theoretically)
> allow him to mount an attack.
>
> Stephane Beaulieu wrote:
>
> > What's wrong with one peer thinking that it's IKE SA is
> used up before the
> > other peer does? If one peer notices that an IKE SA is
> about to expire, he
> > should establish a new one and send a DELETE for the old one.
> >
> > <I'd like to comment that due to the symmetric nature of
> IKE SA's (an IKE
> > peer can use the same <IKE SA for both encryption and decryption),
> > <it seems difficult to enforce a limitation on the number
> of negotiations or
> > the amount of data <encrypted with the IKE SA.
> > <Since packets can get lost (especially notifications) the
> two IKE peers can
> > get out of sync <regarding the number of negotiations they
> had or the amount
> > of data they encrypted. This can lead <to a scenario in
> which one side
> > thinks that the IKE SA has been out used while the other
> side <thinks it is
> > still valid.
> > <Time restrictions seem to work fine as long as we don't
> travel at speeds
> > close to the speed of light.
> >
>
Follow-Ups: