hey, this is IPv6 list, not IPsec list...
>> 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.
the best solution is to integrate IPv6 support into mainline apache
code.
we tried to convince apache guys to integrate IPv6 patch into
1.3 branch, however, they try to avoid new functionality for
1.3 branch. i'm trying to find some time to make an IPv6 patch
to 2.0, haven't done it 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.
try upgrading to 4.1.
>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?
/usr/share/doc/IPv6/IMPLEMENTATION, or something similar talks about it.
if you don't find it in the above path, try
http://www.kame.net/dev/cvsweb.cgi/kame/IMPLEMENTATION.
>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 separation of SA and SP is very important. even if you want to
negotiate keys (SAs) on the fly with IKE, you don't want to lose
your policy (SP). actually, we obeyed what is described in RFC240x
IPsec.
>Aha. Sounds good. I wonder about some things.
>1) how can one link racoon / IKE up with a public key infrastructure?
go read the document. you can use x509 certificates to authenticate
yourself to the peer (or vice versa).
>2) might IKE and other IPsec things like secure DNS actually be an
> *alternative* to today's X.509 (ugh) based PKIs?
there are proposals to carry certs on DNS payload, we need to
look at those deeper.
>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?
not really, at least for kame code.
>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?
IKE sets up keys (SAs) based on IP addresses. you can reuse IPsec SAs
as long as you contact the same IP address. so effectively,
you will have at most the same number of IKE exchanges than HTTPS
authentications.
>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?
IPsec documentation talks about "bump-in-the-wire" in the spec,
not sure if it is relevant but it is the closest one.
kame code doesn't do that right now.
itojun
---------------------------------------------------------------------
The IPv6 Users Mailing List
Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
