-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Jonathan" == Jonathan Stone <jonathan@dsg.stanford.edu> writes:
    >> has a similiar problem with ACQUIREs
    >> they are not reliable under memory exhaustion. To solve this problem,
    >> one must scan a /proc system, which has a 4k page problem.

    Jonathan> I dont get that. How is grabbing pages at random any more
    Jonathan> reliable than socket buffers (nevermind the 4k limit
    Jonathan> braindamage)?  Don't feel obliged to answer that, though:
    Jonathan> I may not want to hear the answer. 

  The /proc interface on Linux <2.4 can only fill a single 4k page at a
time. A single file, /proc/net/ipsec/eroute/all, lists, in ASCII all of
the SPD, including those entries in the "%hold" state (which is the
state after the acquire went up, and possibly got lost). Due to the way
that the file is formatted, at the 4k boundary, there can be corruption.
  (Linux 2.6 fixes much of the proc file system's race conditions, and
the correct answer is to have a directory of files, one per SPD entry)
  
    >> The plan to fix things is to have the keying deamon send requests down
    >> to the kernel that would get returned with ACQUIRE's. If one can't
    >> allocate an available ACQUIRE, the packet that caused it would get
    >> dropped. 

    Jonathan> Seems reasonable so far. The IKE daemon can decide (or be
    Jonathan> configured) on the limits it expects to handle; request
    Jonathan> and pin pages appropriately; 

  Exactly.

    >> Basically, unreliable PF_KEY is a bad idea. 

    Jonathan> Yep.  Remember: rough consensus and working code.

    Jonathan> If ACQUIREs aren't expected to work reliably, then IPsec
    Jonathan> cannot be expected to work reliably. (I encourage you to
    Jonathan> quote that in the IEFT IPSEC WG, should RFC-2367 ever come
    Jonathan> up). And I for one refuse to 

  As you say, RFC-2367 is Informational.
  There is a lot of interest in revising it, but no time.

    Jonathan> required.  Maybe its time you re-read RFC-2367.  Kernel-generated
    Jonathan> messages are ``special'', and they need not be broadcast to every
    Jonathan> listener:

  Yes, true. But, because it is sometimes a broadcast system, it means
that it is hard to have clear back-pressure (not impossible, just hard).
  I have yet to see a situation where the broadcast nature of the system
was really a feature.
  
    >> So, the acquires should get dropped as a unit, not part of them.

    Jonathan> You mean each ACQUIRE should be either received in its
    Jonathan> entirety, or dropped in its entireity?  Sure, doesn't that
    Jonathan> go without saying? 

  Yes, but my impression is that KAME takes what bytes fit.

    Jonathan> truncation of a message. If socket-buffer limits cause partial
    Jonathan> ACQUIREs to be passed up by th kernel, that's just broken.
    Jonathan> (Tho' I still suspect something in my private tree may be
    Jonathan> responsible for that one).

  Okay. I was surprised to hear that it did that as well, but prepared
to believe you.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@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

iQCVAwUBQKy1AIqHRg3pndX9AQFAEQP/bNXwVXgHkYtHItLN2ZvELYKHx7Nupiur
3kPYMEXMM4OexML+R7MDl+ldqsWt5zP+NadkBwKtfYch1JaL9O/jUHIQ10JRMwh7
rhKuF0W9jJq6udaYl5cMUGBcq3kYirCeN2a5vD6yuTCIeLC85fZTETnJ2JKfS6x4
XenZm2EV0YY=
=Ac7X
-----END PGP SIGNATURE-----