Itojun, thanks for this invaluable information. And I should also thank you for doing all this good work with KAME and on FreeBSD. I have been with FreeBSD since it was called 386BSD 0.0new :-) and from what I see you Japanese have done the best job of making our beloved system widely popular. In no language are so many books about FreeBSD published than in Japanese. This is really good. Jun-ichiro itojun Hagino wrote: > apache code from apache project (like stock 1.3.11) supports IPv4 only. > > there are IPv6 patches for 1.3.11, from ftp.kame.net for example. > however, for IPv6 support, we made certain changes to internal > data structures. it is required because of IP address size differences > for example (4 byte field -> 16 byte field). > > mod_perl assumes internal data structures present in normal IPv4-only > apache. so, mod_perl cannot coexist with IPv6 patch. Gee, this sounds like a lot of work that still needs to be done. From my little porting of netpipe I found that AF independent re-programming isn't that easy. What can be done to facilitate this conversion? I guess the best thing would be to educate the maintainers of these tools what needs to be done. > >But I have done some more comparison, an SSH tunnel that hops from > >localhost:5250->SSH[aurora->prometeus]->localhost:5251 is with > >3des-cbc almost as fast as IPsec with 3des-cbc (SSH about 5-10% > >slower.) But using the blowfish-cbc cipher the outcome inverts! > >IPsec with blowfish compares terrible against the SSH tunnel (IPsec > >about 20% slower.) Something must be wrong with the blowfish > >implementation used in KAME or the SSH blowfish cheats. But, > >I also found the RC5 is performing best among the strong ciphers > >(even better than 1DES, especially at higher transfer buffer sizes.) > > blowfish performance drawback is due to some implementation > inefficiency in the past in KAME side. freebsd 4.1 code uses KAME code > prior to the update. you may want to check KAME PR 229 on KAME PR > database, accessible via www.kame.net, for details. This is amazing. I have barely found the problem and you have already fixed it. Good job! > > >Would always use RC5, but unfortunately if you set up IPsec tunnels > >to CISCO routers, you are bound to 1DES, isn't it true? > > I can't speak for cisco. do they do IPsec IPv6 yet? Yes they do IPsec. Not sure about IPv6 yet. > >I did not quite understand the setkey function. I tried to use > >ipcomp but could not get it to work (always complains about the > >-C deflate option that I choose.) What I wanted to try is to > >increase throughput by compression before encryption. I have > >calculated that theoretically it should improve throughput, since > >the compression leaves less data to choke on for the encryption. > >But I can't test it with IPsec. Is that possible at all to use > >ipcomp/deflate before ESP-ing? > > that is possible. after setting up enough SAs, you can setup policy > for ip compression, like: > spdadd ::1 :: any -P out ipsec ipcomp/transport//use esp/transport//use; however I could not even get the parameters configured. I tried this: add 123.45.67.89 123.45.67.79 ipcomp 1000 -C deflate; and I get an error message on the "-C deflate" (illegal argument). The problem is that setkey is not very friendly with giving advice on what exactly is wrong. So I had to look up the sources to understand that one can combine -E and -A in an esp but not -C. But if I have an example, it'll be all I need. Ah, by the way, what are these security parameter indices about? Is this just a made-up number that isn't referred to anywhere? Is this still actually used? I also wonder whether this split between SA and SP is really useful. I mean, I'm not criticising, I'm probably just missing a piece of information. I find myself repeating a lot of stuff in spdadd that I already said in add. > the tricky thing is that, ipcomp kicks in only when we can compress > the packet - for short packets ipcomp will not be useful and will > not come into effect. this sounds like a wise idea. > >How come racoon is not part of the FreeBSD release in usr.sbin? > >I found it in ports. Is something wrong with it that it can't be > >trusted yet? > > because it is still under development and we expect to have tons > of improvements, and config syntax changes. with freebsd 4.1, racoon > is supplied as a "ports". Aha. Sounds good. I wonder about some things. 1) how can one link racoon / IKE up with a public key infrastructure? 2) might IKE and other IPsec things like secure DNS actually be an *alternative* to today's X.509 (ugh) based PKIs? 3) can racoon/IKE be used for user-level authentication instead of just system level? If so, how might it be linked up with personal keys in files, password prompts (callbacks?), or smartcard readers? 4) what would happen if someone is using IPsec+IKE for web browsing, would every URL reference start an IKE negotiation every time? That would be a heavy performance hit (remember, SSL is known to suffer from the extreme burden of the RSA or DSA cryptography on the CPUs. And SSL/HTTPS has devised a solution to hold connections beyond a single URL reference. Can IKE do something similar? 5) With SSL/HTTPS the standard solution today is to use a cluster of machines just to do the SSL and forward the requests to the final web server. Could one do something similar with IKE? Like run racoon remotely on a replicated cluster rather than on every IPsec-machine? Many questions indeed. Thank you for being so responsive. -Gunther
begin:vcard n:Schadow;Gunther tel;fax:+1 317 630 6962 tel;home:+1 317 816 0516 tel;work:+1 317 630 7960 x-mozilla-html:FALSE url:http://aurora.rg.iupui.edu org:Regenstrief Institute for Health Care adr:;;1050 Wishard Blvd;Indianapolis;Indiana;46202;USA version:2.1 email;internet:[EMAIL PROTECTED] title:M.D., Medical Information Scientist note;quoted-printable:Al oppinions expressed in this message are my own and do =0D=0Anot necessarily represent those of the Regenstrief Institute. fn:Gunther Schadow end:vcard
