[Openswan dev] Re: [Openswan Users] Xauth Client extensions
mcr at xelerance.com
mcr at xelerance.com
Wed Apr 7 11:37:42 CEST 2004
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Henrik" == Henrik Nordstrom <hno at marasystems.com> writes:
Henrik> On Tue, 6 Apr 2004 mcr at xelerance.com wrote:
>> So, we will not put aggressive mode support into openswan 2.x
>> until we can:
>> 1) put in both initiator and responder support
Henrik> Both should be supported by OpenSWAN 1.0. Was supported in
supported, but not tested in a structured way. By this, I mean that
there is no test case for the code. That means that they may break with
>> 2) implement CPU limits on responder support such that a DoS is
>> not so trivial to cause.
Henrik> Always good.
Not, good -> essential.
as in, without the limits one would be knowingly be shipping broken
code. (Does that sound like any big software companies you know about?)
>> The hard part is the CPU limits - we have to change pluto such
>> that it it knows how much diffie-hellman work it has done, knows
>> how much of its timeslice is left, and can suspend computation on
>> aggressive mode clients and return to regular work.
Henrik> Isn't similar limits needed on main mode negotiations? Both
Henrik> need the same amount of DH calculations don't they? I admit
Henrik> it was long since I worked on aggressive mode, but I do not
Henrik> recall aggressive mode being different in this regard..
Do you remember the TCP SYN spoofing attacks?
Where one sends thousands of TCP SYNs from a forged source address.
The responding system creates thousands of TCP contexts, runs out of
space and then stops responding to legitimate traffic. Do you recall how
easy it was to do that to systems?
Aggressive mode works identically. Except that one does DH work
immediately upon receipt of a packet. This consumes both CPU and also
entropy, while TCP SYN reception just uses RAM.
Main mode does no work until a three-way handshake. Unfortunately, it
still consumes RAM. A main mode exchange must therefore come from a
location that can receive packets at a particular IP address. They can't
be forged in such a trivial way.
(IKEv2 has a stateless main mode method that consumes no ram).
So, would you run a kernel that didn't have TCP-SYN cookies?
If the answer is "no" then you should think carefully about running
with aggressive mode on.
The problem is solveable - like all problems, it is just a question of
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr at xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
-----END PGP SIGNATURE-----
More information about the Dev