[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: swamping security
Joe, et al,
> So, it might be the case that, in order to avoid swamping attacks,
> we need two kinds of authentication:
>
> - whole packet (to keep converstations secure)
>
> - header only (for fast processing to check for
> swamping)
I actually think the "end system" answer to swamping attacks is to keep
minimal state at SYNRCVD time until you get a "correct" ACK from your SYNACK.
(This is TCP-speak for saying that you send a verifier [ISS --- sequence
number] to the proposed correspondent and see if that verifier comes back [as
an ACK number, in this case].)
Greg
From: Ron Rivest <rivest@theory.lcs.mit.edu>
Date: Fri, 20 Sep 96 17:14:38 EDT
Message-Id: <199609202114.AA17657@swan.lcs.mit.edu>
To: ipsec@TIS.COM
Subject: Using cookies to defeat syn-flooding
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Here is a thought on a scheme for defeating swamping (syn-flooding)
attacks, together with an improvement suggested by Butler Lampson.
Since I'm not an expert on network protocols, it needs review by those
who are...
Flooding attack (paragraph to define problem and establish terminology):
Assume that the scenario is that machine A receives a SYN packet
allegedly from machine B. Currently A returns its own SYN packet, after
logging the connection request in a queue. If the original SYN packet
was bogus, and had a spoofied source ip address, then A is left waiting
for B to complete the handshake until timeout, tying up A's resources.
With many bogus SYN packets received, A is clogged up and A's legitimate
users are denied service.
Analysis:
The problem is that A is allocating resources (i.e. making queue entries)
with every SYN packet received.
The idea:
Defer A's allocation of resources until A has some confirmation that
B is "real". (I.e. until the third message of the three-message protocol
is received from B).
How:
When A receives the first SYN packet, it does NOT generate a queue
entry. Rather, it sends B, as part of its return SYN packet,
a "cookie" that contains the information that the queue entry would have:
-- source id of the SYN packet received
-- when to time the connection request out
-- port number
-- other stuff (?)
The cookie would contain this material in the clear, together with
a cryptographic checksum (MAC) on this data, computing from the data
of the cookie and a secret key known only to machine A.
When B replies, he returns the cookie, which A checks. A cookie with
an invalid MAC is discarded. A cookie with a good MAC that has not
timed out and which has not already been honored will generate a new
connection. (Note that to prevent replays A must keep track of which
connections have been opened within the last cookie-time-out period,
but A does not need to keep track of cookies that have never been
returned.)
In this way, syn-flooding is defeated.
Improvement:
Butler Lampson suggested that the cookie might actually be squeezed
into the current protocol. I don't know enough of the details to
tell. He thought that A's return SYN includes a 32-bit number which
is returned (slightly modified) in B's final ACK. This might be used
to store just the MAC for the cookie, if the rest of the cookie could
be reconstructed from the material already in the second message.
More likely, the 32-bit quantity would have to code both the time-out
and the MAC. (Allocate say 12 bits for time out to the minute mark
and 20 bits for checksum; change to a new crypto key whenever every
2^{12} minutes.)
It would be neat if this improvement could fit within the current
implementation of IPv4.
Perhaps something like this would be valuable for IPv6 in any case...
Comments appreciated ...
Ron Rivest
From: Ron Rivest <rivest@theory.lcs.mit.edu>
Date: Fri, 20 Sep 96 17:39:12 EDT
Message-Id: <199609202139.AA17662@swan.lcs.mit.edu>
To: ipsec@TIS.COM
Subject: Resistance to swamping attacks via Kim Tom's idea
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Kim Toms (below) suggested a cryptographic function that is easier to
verify than to compute. The sender of a packet P would have to compute
a quantity f(P), such that the receiver would be able (VERY EASILY) check
that this computation was proper. Here is a simple idea:
Let k be a small integer (e.g. k=10)
Let P be the packet data
The sender of a packet must also send along a tag T such that:
the low-order k bits of MD5(P || T) are all zero
(Here || denotes concatenation.)
MD5 acts like a "random" function, and the sender would have to check
approximately 2^k values of T before finding one that works.
The receiver has only one MD5 computation to perform, and so he is able
to check packets 2^k times more efficiently than an attacker can generate
them.
The expected length of T is k bits, and the chance that T will be longer
than c*k bits is approximately exp{-k*(c-1)}, so allocating space in the
packet for T can probably afford 2k bits easily. (E.g. for k=10, the
chance that the length of T is greater than 20 is about 10^-434).
I'm not terribly excited about the proposal overall, but just wanted to
point out that the cryptography is available to make it doable, as desired.
Cheers,
Ron Rivest
==============================================================================
Date: Fri, 20 Sep 1996 01:50:35 GMT
From: "Kim L. Toms" <kim@morningstar.com>
Subject: Re: resistance to swamping attacks.
Reply-To: Kim Toms <kim@morningstar.com>
I'm no expert in cryptography, but it seems to me that what is needed is
a function which is expensive for the originator of a packet to
calculate, but cheap for the receiver to verify. This will make sure
that the source of a swamping attack must have a much larger CPU than
the receiver. I don't know if there are any such functions, but perhaps
the cryptographically sophisticated among us could enlighten?
To: touch@isi.edu
Cc: sommerfeld@apollo.hp.com, kim@morningstar.com, ipsec@TIS.COM
Subject: Re: resistance to swamping attacks.
Date: Fri, 20 Sep 1996 16:45:38 -0400
From: Steven Bellovin <smb@research.att.com>
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609230725.aa26132@neptune.TIS.COM>
> From sommerfeld@apollo.hp.com Fri Sep 20 11:57:22 1996
> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld ow
ned process doing -bs
> To: touch@isi.edu
> Cc: kim@morningstar.com, ipsec@tis.com
> Subject: Re: resistance to swamping attacks.
> Date: Fri, 20 Sep 1996 14:57:02 -0400
> From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
>
> > Aren't authentication functions symmetric, almost by definition?
> >
> > Joe
>
> well, RSA signatures aren't (expense depends on the length of the
> exponent and the public exponent is usually made short so signature
> verification is fast at the expense of making signing expensive) but
> those are clearly too expensive to use in per-packet transforms.
>
But then you're authenicating the signature, but not the packet
itself, no?
In that case, I can replay a signed connection-establishment request
with random source addrs.
Depends on what you sign. In my note, I said ``in principle''....
Date: 23 Sep 96 11:26:00 GMT
From: "SPARKS::WEAVER" <WEAVER%SPARKS.decnet@hydra.dra.hmg.gb>
Subject: ISAKMP Exchanges
To: ipsec <ipsec@TIS.COM>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609230746.aa26548@neptune.TIS.COM>
I would like to get a feel for the demand, if any, for a
simple EXCHANGE for ISAKMP:
Comments or even a suggestion ?
Elfed
weaver@dra.hmg.gb
Date: 23 Sep 96 11:20:00 GMT
From: "SPARKS::WEAVER" <WEAVER%SPARKS.decnet@hydra.dra.hmg.gb>
Subject: ISAKMP implementations
To: rja <rja@cisco.com>
Cc: ipsec <ipsec@TIS.COM>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609230745.aa26527@neptune.TIS.COM>
rja wrote :-
> There are non-US implementations of ISAKMP already. For example,
>DRA/Malvern (UK) has an implementation of ISAKMP for UNIX. Dan Harkins
>of cisco has done some interoperability testing with DRA/Malvern already,
>more interoperability testing is planned.
Yes, DRA - Malvern (UK) does have a prototype implementation of ISAKMP
version 4.
This prototype has been used, successfully !, to interoperate with Dan
Arkins/cisco
ISAKMP version 4 implementation.
Currently, (well, when time permits !) we are upgrading the protoype to the
ISAKMP
version 5 specification. We would like to have a protoype that supports the
ISAKMP/Oakley exchange ready for interoperability testing by the December IETF
- We shall see ;-)
> If vendors implement the "PF_KEY Key Management API version 2" (I-D should
>be coming out soon), then anyone can build any key management daemon they want
>and drop it on top of that API without needing kernel sources.
We are currently looking at modifying a publicly (European) available version of
IPsec with which to use our ISAKMP implementation and intend to implement
"PF_KEY Key Management API version 2".
Two questions I expect many will want answered:
1. Will the code be publicly available -
Personally, I dont believe there will be a problem with this.
2. When will it be available -
When it supports, the mandatory exchanges and the PF_KEY API.
Elfed
weaver@dra.hmg.gb
From: Germano Caronni <caronni@tik.ee.ethz.ch>
Message-Id: <199609231120.NAA01210@kom30.ethz.ch>
Subject: The skip-info mailing list
To: skip-info@skip.org, Project SKIP <skip@tik.ee.ethz.ch>,
Bernhard Plattner <plattner@tik.ee.ethz.ch>, ipsec@TIS.COM
Date: Mon, 23 Sep 1996 13:20:56 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL24 PGP6]
Content-Type: text
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
The SKIP internal mailing list 'skip-info@tik.ee.ethz.ch' has moved. It is
now located at skip-info@skip.org.
If you are already a subscriber, your subscription will hopefully have
been moved to the new list. Otherwise, to subscribe, send email to
majordomo@skip.org, with the folowing text in the body (not subject) of
your message:
subscribe skip-info
Friendly greetings,
Germano Caronni
From: narayanasamy senthil vadivu <senvad@hotmail.com>
To: ipsec@ans.net
Cc: senthilvn@future.futsoft.com
Subject: Reg. security attributes mentioned in ISAKMP draft
Content-Type: text/plain
Message-Id: <96Sep21.063857pdt.1463609(4)@constitution.hotmail.com>
Date: Sat, 21 Sep 1996 06:38:57 -0700
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Hi Steve Kent,
As there is reference in the ISAKMP draft, june 13, 1996 to
this email address for quering more on the security attributes
mentioned for security association (SA), I am sending this mail.
Please do send description of these attributes and as well as
information on what other drafts can be referred for SA.
Thanks
senthil vadivu.
---------------------------------------------------------
Get Your *Web-Based* Free Email at http://www.hotmail.com
---------------------------------------------------------
From: narayanasamy senthil vadivu <senvad@hotmail.com>
To: ipsec@ans.net
Cc:
Subject: Regarding Security Association Attributes
Content-Type: text/plain
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Mon, 23 Sep 96 10:17:17 EDT
Message-ID: <9609231017.aa28736@neptune.TIS.COM>
Hi,
Please let us know as what are the web sites that can give
more information on the security attributes of security association
(SA). Also, please provide the information that you have.
Thanks
senthil
---------------------------------------------------------
Get Your *Web-Based* Free Email at http://www.hotmail.com
---------------------------------------------------------
References: