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

RE: Some comments on JFK

Eric,

	Ack! You are right, my appologies.

	I think we need to be very clear as to what the initial round trip
is achieving. If al we need to do is to protect against the DoS attack then
it is better to reconfigure the exchange so that DoS protection is an option
for the responder if it discovers it is under DoS attack.

	The specification cannot force the responders to implement DoS
protection, it can only require compliance with a certain message set. The
cookie does not by itself provide DoS protection, only if the responder has
some ability to filter out DoS attacks from particular IP addresses is there
an actual protection against DoS.

	Sending the key exchange data in the initial exchange has the
advantage of allowing the responder to make an informed decision as to
whether to accept the request, defer it with a cookie challenge or reject it
on the basis of the information in the request.

I->R   Request [x]

R	Are we under DoS attack?
	No perform key agreement, send R->I Response [x]
	Yes from specific sources 
		Is I a specific source?
			Yes, send R->I Reject [x]
			No, send Response [x]
	Yes, from difuse source
		Send Challenge [x]

	This may appear to be complex, but that is the nature of a good DoS
response. An implementation may still opt to implement challenges under all
circumstances at the cost of always requiring an extra round trip.
	
	I reiterate the assertion that it is too early to go down grovelling
at the bit level. We should look at the abstract protocol before getting
into message size measuring contests. 
	

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227


> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Monday, December 03, 2001 2:10 PM
> To: Hallam-Baker, Phillip
> Cc: Angelos D. Keromytis; ipsec@lists.tislabs.com
> Subject: Re: Some comments on JFK
> 
> 
> "Hallam-Baker, Phillip" <pbaker@verisign.com> writes:
> 
> > [1  <text/plain; iso-8859-1 (7bit)>]
> > > Yes, but purpose of forcing the initiator to spend cycles 
> before the
> > > responder is for DoS prevention, not rate throttling of legitimate
> > > initiators, no?
> > 
> > Carefull, you don't 'force' the initiator to spend cycles before the
> > responder. What you actually do is to force the initiator 
> to prove that
> > it can recieve packets sent to the purported initiator 
> address before 
> > the responder spends cycles.
> > 
> > The initiator can send any old junk to the respinder and 
> the responder
> > will not know until the cycles are spent.
> This was exactly my point. 
> 
> The draft says:
> 
>    The Initiator bears the initial computational burden
>    and must establish round-trip communication with the Responder
>    before the latter is required to perform expensive operations.
> 
> This text suggests that the fact that the initiator performs
> the DH operation first protects against DoS. As far as I can
> tell it does not.
> 
> -Ekr
> 
> -- 
> [Eric Rescorla                                   ekr@rtfm.com]
>                 http://www.rtfm.com/
>

Phillip

Follow-Ups: