linux-ipsec: klips restructuring

-----BEGIN PGP SIGNED MESSAGE-----
In case it wasn't apparent from some of the information leaking from me to the list, I am in the process of trying to implement PF_KEY_v2 in FreeS/WAN's KLIPS (the kernel portion + manual keying utils).

The way it organises ESP transforms is to give separate parameters for authentication and encryption. Beyond two of each, this makes sense since it reduces the number of copies of almost identical code that need to be updated as new features and bugfixes end their way into the codebase.

The FreeS/WAN kernel code was originally set up with one transform per combination of authentication and encryption algorithms. There are now 11 transforms of which only 8 are usable when there are 3 usable authentication algorithms out of 4 and 3 usable encryption algorithms out of 4.

(Incidentally, one of each of the "usable" algorithms is 'null encryption' and 'null authentication', which will obviously never be used together.)

At the moment we have

        auth{none, md5-96, sha1-96}

and

        esp{none, des, 3des}

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

As we add ripemd160, des for authentication and rc5, idea, cast, blowfish, 3idea, rc4 for encryption the numbers of combinations of transforms would get a little out of hand with duplication leaving bugs to be fixed more than once. The permutations will give us 4 * 11 - - 1 = 43 transforms vs. 4 + 11 = 15 algorithms.

My point in all of this is to get some opinions on the best way to organise the transform switches. I am thinking of eliminating all the 'ipsec_ah*.c' and 'ipsec_esp*.c' source files and transferring all that code to various other parts of the existing structure.

I want to (actually, I already have) merge ipsec_ah.c and ipsec_esp.c into one file called ipsec_rcv.c. It also contains all the esp*_input() and ah*_input() functionality with switch() statements. I have already moved all the ah*_room() and esp*_room() functionality and want to move all the ah*_output() and esp*_output() functionality into the ipsec_tunnel_do_xmit() routine, or maybe one routine called from it. The ah*_print() and esp*_print() functionality could be put into ipsec_spi_get_info() routine or one routine called from it. The ah*_init() and esp*_init() fucntionality could be put into ipsec_netlink.c as could ah*_zeroize() and esp*_zeroize().

I have had a look at the OpenBSD code and am not really that crazy about the transform distinctions of old and new, ah and esp. Perhaps the existing structure could work with a bit more fine grain on the functions, reducing the amount of duplication of code. In particular, much of the contents of the *_input(), *_output, *_init is duplicated and prone to missing bugfixes and updates. The transform switches should at least be converted to algorithm switches which can be used in both AH and authenticated ESP in the case of the authentication algorithms.

        slainte mhath, RGB
- --

Richard Guy Briggs -- PGP key available                Auto-Free Ottawa! Canada
rgb at conscoop dot ottawa dot on dot ca                <
http://flora.org/afo/>
<
http://conscoop.ottawa.on.ca/>           FreeS/WAN:<
http://flora.org/freeswan>

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

iQCVAwUBNncuoN+sBuIhFagtAQFJoQP/VcinatpMNO+bopIMo9+q6ajEdbJSdXXu 27+AJHpJsaOt7ib28stwgfzS+Ixx3EjtUV/CLWwkjDNe7cyCchcWbWiQIS3p6zFL LZAGq3IoJ8h43hzNAKiL5bdBkc4u8lEt+9lNUaiyWEO0Be1DkUnMtHEdwoFO2Y2U rXB2P8spuow=
=gzPj
-----END PGP SIGNATURE-----
Received on Tue Dec 15 23:38:48 1998