[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cookie verification
The Photuris protocol also has a concept of responder enforcing resource
limit per peer, in the cookie exchange step. Although the attacker may
spoof different source IP addresses, to overcome this limit, the attacker
must also be able to receive the cookie responses for all the packets,
which may not be so trivial, because he is spoofing the IP source address
on the cookie requests.
-chinna
On Thu, 9 Dec 1999, Valery Smyslov wrote:
> On 9 Dec 99, at 10:55, Sami Vaarala wrote:
>
> Sami,
>
> > Kanta,
> >
> > > Hi,
> > > The use of IKE Cookie in a draft
> > > http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt
> > > is better in terms of statelessness.
> >
> > Indeed it is: the first message does not require a responder
> > to store state. An approach similar to this one (with
> > regards to re-sending the data in the first message later)
> > could work for other IKE modes as well, without making the
> > exchanges longer. I wonder if this could be done easily
> > using a "standard transform" to a given stateful mode?
>
> I thought about this also. Resending the data in the first message
> later has its disadvantages when the amount of data is big enough.
> And it is the first IKE packet where this often may be true - unlike
> the other IKE packets, which size is limited (unless you send a lot
> of certs or VendorID payloads), the first packet may contain SA with
> hundreds of proposals. Resending such amound of data only for anti-
> clogging purposes seems not to be a reasonable. Perhaps adding one
> more roundtrip of pure cookie exchange would be better. But,
> unfortunately, in any case it requires modification of IKE.
>
> > As an aside, how do you prevent an attacker from doing a
> > "cookie jar" attack? A malicious initiator can initiate
> > new exchanges by sending the first message and receiving
> > the second message of each exchange, and then calculate
> > the appropriate third messages corresponding to each new
> > exchange -- without sending them immediately. After
> > collecting eg 1000 valid responses, he can send them all
> > at once to swamp the responder.
> >
> > Admittedly, the attacker will have to do a roughly equal
> > amount of work, but over a longer period of time (and thus
> > he will not be swamped). The responder can not know how
> > old each of the messages are, so he will accept them.
> > (The local secret for cookie generation can, of course,
> > be changed once in a while, but that interval may be
> > long enough to pull the attack off?)
>
> I guess, in this case you need to change local secret with an
> interval equal to one you agree to accept your cookie within (more
> precisely, you need to change it twice more frequently and keep two
> last secrets and try both).
>
> > If the responder cookie in the draft included time, the
> > responder could roughly estimate the age of the cookie
> > (and thus the exchange) upon receiving the third message,
> > and refuse to participate if the cookie is older than eg
> > 15 seconds.
> >
> > As I said earlier, our cookie generation method allows us
> > to determine the age of the cookie with quite a good
> > resolution. If applied to this draft, upon receiving the
> > third message the responder would verify the cookie and
> > determine its age (eg resolution of a second). It would
> > then ignore the message if it was older than what we're
> > willing to accept.
> >
> > If you'd be interested I could document the cookie generation
> > method we're using -- perhaps this would be useful for your
> > draft?
>
> Please, do it. I think it would be useful anyway.
>
> > Sami
> >
> > --
> > Sami Vaarala (sami.vaarala@netseal.com)
> > NetSeal Technologies
> > http://www.netseal.com/
>
> Regards,
> Valera Smyslov.
>
>
chinna narasimha reddy pellacuru
s/w engineer
References: