[Openswan dev] Re: [Openswan Users] Xauth Client extensions

[mcr at xelerance.com]

-----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
no notice. 

    >> 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
resources.

- --
]       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

iQCVAwUBQHQSMIqHRg3pndX9AQH13QP5AXDNUOoZRlFZXA7MJL3tzdBqzX12WP7O
5AvgAT77aP6tUKmsfltWhdgg7RK1TEsVo1vPB9UuyZ3SENx0+LVdwhuLoFbXg2rF
NltR7gpOubSB6YRIAPqrkE9/Ph3h2BER/FH1CpJCS9dGrnyhJRXvMLuqXSWONtdw
L2mPYFblxqs=
=t5cm
-----END PGP SIGNATURE-----