KAME IPsec vs Fast IPsec

[Jason Thorpe]

What's the status of Fast IPsec being a completely replacement for
KAME IPsec? If it has feature parity, is it time to dump KAME IPsec?

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Jason Thorpe
What's the status of Fast IPsec being a completely replacement for
KAME IPsec? If it has feature parity, is it time to dump KAME IPsec?

I believe there's one feature missing, which is support for
UDP-encapsulated ESP. I believe FreeBSD has in fact nonetheless
dumped the KAME code at this point.

I have been putting a lot of work into the opencrypto code used by
Fast IPsec and would like to see a lot of duplicative crypto and
IPsec code go. In a few cases (e.g. the iovec walking code in cgd,
which does not needlessly copy every request before encrypting it)
the code elsewhere in the tree is better than the opencrypto or
netipsec code, but as far as KAME IPsec itself I don't think that's
the case.

[Arnaud Degroote]

Post by Thor Lancelot Simon

Post by Jason Thorpe
What's the status of Fast IPsec being a completely replacement for
KAME IPsec? If it has feature parity, is it time to dump KAME IPsec?

I believe there's one feature missing, which is support for
UDP-encapsulated ESP. I believe FreeBSD has in fact nonetheless
dumped the KAME code at this point.

fast_ipsec(4) supports UDP-encapsulated ESP via IPSEC_NAT_T options
since June 2007.

There are still an issue between "ipv6 extension header" and fast_ipsec.
But it is probably the last difference with Kame IPSec (if you don't
count the fact that kame ipsec is probably better tested)

Take cares.

[Jason Thorpe]

What will it take to fix this last issue? I think it's time we had
just one ipsec in the tree.

Post by Arnaud Degroote

Post by Thor Lancelot Simon

Post by Jason Thorpe
What's the status of Fast IPsec being a completely replacement for
KAME IPsec? If it has feature parity, is it time to dump KAME IPsec?

I believe there's one feature missing, which is support for
UDP-encapsulated ESP. I believe FreeBSD has in fact nonetheless
dumped the KAME code at this point.

fast_ipsec(4) supports UDP-encapsulated ESP via IPSEC_NAT_T options
since June 2007.
There are still an issue between "ipv6 extension header" and
fast_ipsec.
But it is probably the last difference with Kame IPSec (if you don't
count the fact that kame ipsec is probably better tested)
Take cares.
--
Arnaud Degroote

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Keiichi SHIMA]

I want to know the plan of the extension header support in fast IPsec
too.

I'm working on Mobile IPv6 that uses extension header and IPsec same
time. The missing extension header support in one of the reason for
me that I cannot move from KAME IPsec to fast IPsec.

Regards,
---
Keiichi SHIMA

Post by Jason Thorpe
What will it take to fix this last issue? I think it's time we had
just one ipsec in the tree.

Post by Arnaud Degroote

Post by Thor Lancelot Simon

Post by Jason Thorpe
What's the status of Fast IPsec being a completely replacement for
KAME IPsec? If it has feature parity, is it time to dump KAME IPsec?

I believe there's one feature missing, which is support for
UDP-encapsulated ESP. I believe FreeBSD has in fact nonetheless
dumped the KAME code at this point.

fast_ipsec(4) supports UDP-encapsulated ESP via IPSEC_NAT_T options
since June 2007.
There are still an issue between "ipv6 extension header" and
fast_ipsec.
But it is probably the last difference with Kame IPSec (if you don't
count the fact that kame ipsec is probably better tested)
Take cares.
--
Arnaud Degroote

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Arnaud Degroote]

Post by Keiichi SHIMA
I want to know the plan of the extension header support in fast IPsec
too.
I'm working on Mobile IPv6 that uses extension header and IPsec same
time. The missing extension header support in one of the reason for
me that I cannot move from KAME IPsec to fast IPsec.

Itojun has added some patches in feb 2007 to better support extension
header. There are still some problems, particulary the hbh extensions is
not correctly computed with this code.

The problem comes from the strategy of fast_ipsec. We do something like
that :
- ip6_ouput begins to prepend headers and extension headers if
necessary
- ipsec6_process_packet is called
- when the fast_ipsec has finished its jobs, it reinjects the packet
in the stack using ip6_output with a NULL context for ip6_pkopts and
ip6_moptions (which is correct in "tunnel case", but not in the case of
"transport mode" where we still need to threat some extension headers)

Consequences : all the threatement about extension header after ipsec
processing is not done (in particular bhb extension).

I think that we need to split ip6_output in two functions, and save the
full context of ip6 processing along the ip6_ouput1 ->
ipsec6_process_packet -> ip6_output2 if we want to have a 100% correct
behaviour. But I fear that it can be a performance killer and we have to
deal with tons of informations to pass in the different context.

Moreover, I don't have anymore ipv6 connection so it is hard to test
(only virtual things on my virtual qemu network).