Re: linux-ipsec: socket to kernel issues

-----BEGIN PGP SIGNED MESSAGE----- To understand your ideas better I will try to comment on them and you might possibly explain some more where I seem to be wrong.

William Allen Simpson writes:
> I noticed earlier messages specifying IP source and ports. My view is
IP source and ports are just used as one criteria to base SA/SPI usage on. There is no functional difference in assiging a SA/SPI to a socket or using IP Source and ports for SA/SPI selection.

> As I've mentioned elsewhere, in my variant of Karn code, we start from
I seem to grasp your meaning now. I was a bit confused by the term Security Association since I think of an SA only as (destination address, spi and security protocol). So basically the 'bi-lateral Security Association' could be identified with a Photuris exchange and will also expire once the Photuris exchange expires? What about SAs/SPis which outlive the exchange ?

> I was suggesting that we could store (a pointer to a pointer to) the SA
So the kernel has another data structure, something like 'a SA/SPI conglomeration' which holds the different SPIs and to which a socket could have a pointer. Each SA/SPI strucuture would point back to that conglomeration? When you receive a packet which can be IP Sec processed, you pass down the incoming SA/SPI to the socket level and could check if there exists a conglomeration and let the socket point to it, if not. This would also require passing an additional parameter since incoming IP Sec is processed before the packet is passed to the protocol level.

> I think this is a lot cleaner design than looking things up later in
The SPI parameter would be zero

 for all sockets which have no associated SA/SPI conglomeration,

 for packets which have no associated socket:

• in-kernel generated packets: ICMP, ...
• packets which are passed on because we act as a gateway: VPN,...

At least the latter case seems to require a radix/routing table lookup. My experience with the OpenBSD code, basing the SA/SPI choice on routing tables, is that it is easy to implement in a fashion which requires minimal changes to the rest of the code. The benefit is quite a lot of flexibility.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

How did you implement host based SA/SPI choice? Via a conglomeration which does not get destroyed when an associated socket is killed? Using reference counters?

> And remember, in this mutually hostile user scenario, as soon as the
This should also be handled by the Replay Prevention Field.

Greetings
 Niels

• --
• - PHYSnet Rechnerverbund PGP V2.6 Public key via finger or key server Niels Provos Universitaet Hamburg WWW: http://www.physnet.uni-hamburg.de/provos/ Jungiusstrasse 9 E-Mail: provos@wserver.physnet.uni-hamburg.de Germany 20355 Hamburg Tel.: +49 40 4123-2404 Fax: -6571

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEUAwUBNV1gHjZ8FqYKL4flAQG3ywf3W9syndwBSgyMO6a6UsLW7NcCazuf0KoF 4/+vN3eOVk4mAgaA74lOWJw9KWSCERpKM3+kGrIVSW3xJwT6VVDooiWEI9rRVTda u0Cltp/UqOw9665PJQgZzWW+hlGRlymMRSmvwSTkKS60lKIbmdxAFHWUQJKbDRJc ggDMHNUcfzQw9oVUqhQjJ4+io6zA/M/t25m/uCAerO3rA9T4/s1B3WAAXhmVccSR tGf6FSZzl0CBArrwlG9AkaUTHt91Mf8lMI1O93xDgsMa0Y3yKcMniUjnDU8uYwvC oYvXNARsmOERcOIP3IMRVQWyuIJqXHiavhrtHWsq4k+PjcZzFD6N =CVmY
-----END PGP SIGNATURE----- Received on Sat May 16 06:55:56 1998