Re: VIA C7 hardware AES support in IPSEC(ctl)
On Thu, 2006-06-22 at 20:04 +0200, Hans-Joerg Hoexer wrote: we are. It would be great if you could explain us a little more about this? BTW thanks for the great tool ipsecctl is! Ciao -- Massimo.run();
Re: Crypto acceleration (was: Re: VIA C7 hardware AES support in IPSEC(ctl))
yes, the card needs to support all algorithms, crypto_newsession() does this: /* * The algorithm we use here is pretty stupid; just use the * first driver that supports all the algorithms we need. Do * a double-pass over all the drivers, ignoring software ones * at first, to deal with cases of drivers that register after * the software one(s) --- e.g., PCMCIA crypto cards. * * XXX We need more smarts here (in real life too, but that's * XXX another story altogether). */ -m
Re: Crypto acceleration (was: Re: VIA C7 hardware AES support in IPSEC(ctl))
On Fri, 2006-06-23 at 10:00 +0200, Markus Friedl wrote: yes, the card needs to support all algorithms, crypto_newsession() does this: /* * The algorithm we use here is pretty stupid; just use the * first driver that supports all the algorithms we need. Do * a double-pass over all the drivers, ignoring software ones * at first, to deal with cases of drivers that register after * the software one(s) --- e.g., PCMCIA crypto cards. * * XXX We need more smarts here (in real life too, but that's * XXX another story altogether). */ -m I was looking at this a while ago for an old setup which is still alive for test pourpose and needed attention just for this particular case. Thanks Christian and Markus for pointing this out. Regards. -- Massimo.run();
Re: VIA C7 hardware AES support in IPSEC(ctl)
On Wed, 2006-06-21 at 17:49 +0200, Bihlmaier Andreas wrote: Sorry, for that but I thought it wouldn't matter: I dont mean to offend you, but... i think test environment matter. All hosts are in the same network and can talk directly to each other, but for unsecure protocols (NFS, HTTP) I run a VPN between them. host1 router host2 10.0.0.1 10.0.0.254 10.0.0.8// Real IP // VPN 10.2.0.1 10.2.0.254 10.2.0.8// alias used for VPN +-+ host1---+ | | Switch +--- router host2---+ | +-+ Again you don't specify which host is what so i'm guessing here. Which is the C7? What the others box are? I use iperf -w 256k for testing purposes. The speed between hosts/router using their real IPs (-B 10.0.0.*) is about 70-80 Mb/s. ~22 Mb/s between host1 and host2 using their VPN IPs. BTW i don't think you should spit on 22 Mb/s IPSec for a 500/600EURO box. For the records I got the same IPSec performance with C3 1GHz on rl(4) boxes. Sustained. -- Massimo.run();
Re: VIA C7 hardware AES support in IPSEC(ctl)
On Thu, Jun 22, 2006 at 04:03:58PM +0200, Massimo Lusetti wrote: On Wed, 2006-06-21 at 17:49 +0200, Bihlmaier Andreas wrote: Sorry, for that but I thought it wouldn't matter: I dont mean to offend you, but... i think test environment matter. All hosts are in the same network and can talk directly to each other, but for unsecure protocols (NFS, HTTP) I run a VPN between them. host1 router host2 10.0.0.110.0.0.254 10.0.0.8// Real IP // VPN 10.2.0.110.2.0.254 10.2.0.8// alias used for VPN +-+ host1---+ | | Switch +--- router host2---+ | +-+ Again you don't specify which host is what so i'm guessing here. Which is the C7? the router. What the others box are? fast enough (amd64 3200+ and i386 athlon xp 2500+). I use iperf -w 256k for testing purposes. The speed between hosts/router using their real IPs (-B 10.0.0.*) is about 70-80 Mb/s. ~22 Mb/s between host1 and host2 using their VPN IPs. BTW i don't think you should spit on 22 Mb/s IPSec for a 500/600EURO box. My problem with the speed is that compared to the performance I get out of openssl (by USERcrypto) the IPSEC (in kernel) performance is terrible. AFAIK right now it doesn't even make use of the crypto hardware because I can get the same throughput with a comparable fast CPU (without crypto hardware). The box was 200 Euros + RAM + Dual NIC, thus would be a _DREAM_ of an IPSEC box (and it only uses ~30W of power). Also see this quote: With OpenBSD version 3.4, the kernel now exploits the C7's blindingly fast AES hardware in IPSec http://www.viaarena.com/default.aspx?PageID=5ArticleID=451P=4printer=true Sure it is marketing, but I think it SHOULD work... For the records I got the same IPSec performance with C3 1GHz on rl(4) boxes. Sustained. -- Massimo.run(); Is it really using the crypto hardware? ahb
Re: VIA C7 hardware AES support in IPSEC(ctl)
Bihlmaier Andreas wrote: My problem with the speed is that compared to the performance I get out of openssl (by USERcrypto) the IPSEC (in kernel) performance is terrible. AFAIK right now it doesn't even make use of the crypto hardware because I can get the same throughput with a comparable fast CPU (without crypto hardware). This explained on http://www.openbsd.org/crypto.html VIA C3 CPUs with a step 8 or later Nehemiah core contains an AES implementation accessible via simple instructions. As of 3.4 the kernel supports them to be used in an IPsec context and exported by /dev/crypto. As of 3.5 performances have been greatly improved and OpenSSL now uses the new instruction directly when available without the need to enter the kernel, resulting in vastly improved speed (AES-128 measured at 780MByte/sec) for applications using OpenSSL to perform AES encryption. As I say earlier, the hardware is working, but the performance bottleneck is elsewhere (presumably kernel crypto framework). Cheers, Dries
Re: VIA C7 hardware AES support in IPSEC(ctl)
Dries Schellekens wrote: As I say earlier, the hardware is working, but the performance bottleneck is elsewhere (presumably kernel crypto framework). Sam Leffler of FreeBSD did some work in improving the performance of the OpenBSD kernel crypto framework: http://www.usenix.org/event/bsdcon03/tech/leffler_crypto/leffler_crypto.pdf Cheers, Dries
Re: VIA C7 hardware AES support in IPSEC(ctl)
On Thu, Jun 22, 2006 at 05:08:07PM +0200, Dries Schellekens wrote: Bihlmaier Andreas wrote: My problem with the speed is that compared to the performance I get out of openssl (by USERcrypto) the IPSEC (in kernel) performance is terrible. AFAIK right now it doesn't even make use of the crypto hardware because I can get the same throughput with a comparable fast CPU (without crypto hardware). This explained on http://www.openbsd.org/crypto.html VIA C3 CPUs with a step 8 or later Nehemiah core contains an AES implementation accessible via simple instructions. As of 3.4 the kernel supports them to be used in an IPsec context and exported by /dev/crypto. As of 3.5 performances have been greatly improved and OpenSSL now uses the new instruction directly when available without the need to enter the kernel, resulting in vastly improved speed (AES-128 measured at 780MByte/sec) for applications using OpenSSL to perform AES encryption. As I say earlier, the hardware is working, but the performance bottleneck is elsewhere (presumably kernel crypto framework). Cheers, Dries I'm sorry, I didn't get it the first time, but I get it know :) This is what I was seeking for, an answer. Now I have to greatly improve my C skills in search for a solution ;) ahb
Re: VIA C7 hardware AES support in IPSEC(ctl)
Bihlmaier Andreas wrote: As I say earlier, the hardware is working, but the performance bottleneck is elsewhere (presumably kernel crypto framework). I'm sorry, I didn't get it the first time, but I get it know :) This is what I was seeking for, an answer. Now I have to greatly improve my C skills in search for a solution ;) You could use the ssh tunneling support to create a vpn. Then all crypto is processed using the OpenSSL and thus bypassing the kernel crypto framework. Cheers, Dries
Re: VIA C7 hardware AES support in IPSEC(ctl)
On Thu, Jun 22, 2006 at 10:22:08AM -0700, Joe wrote: Dries Schellekens wrote: Bihlmaier Andreas wrote: As I say earlier, the hardware is working, but the performance bottleneck is elsewhere (presumably kernel crypto framework). I'm interested in purchasing one of these boards for my vpns. The numbers aren't too bad, but is anyone working on a fix? I don't want to we are.
Re: VIA C7 hardware AES support in IPSEC(ctl)
On Thu, Jun 22, 2006 at 06:30:27PM +0200, Dries Schellekens wrote: Bihlmaier Andreas wrote: As I say earlier, the hardware is working, but the performance bottleneck is elsewhere (presumably kernel crypto framework). I'm sorry, I didn't get it the first time, but I get it know :) This is what I was seeking for, an answer. Now I have to greatly improve my C skills in search for a solution ;) You could use the ssh tunneling support to create a vpn. Then all crypto is processed using the OpenSSL and thus bypassing the kernel crypto framework. Cheers, Dries Complexity of the setup and this keeps me from following your advice: Since a SSH-based setup entails a fair amount of overhead, it may be more suited to temporary setups, such as for wireless VPNs. More permanent VPNs are better provided by tools such as ipsecctl(8) and isakmpd(8). - ssh(1) And the other point is, there is a bug/problem and (again a quote): The only good bug is a dead bug! - Starship Troopers As always thanks for help/clues/advice/suggestions ahb
Crypto acceleration (was: Re: VIA C7 hardware AES support in IPSEC(ctl))
Bihlmaier Andreas [EMAIL PROTECTED] wrote: Since I have no glue at all how IPSEC goes about looking for crypto accelerator hardware and making use of it, I'm kind of stuck. Because everything I have found so far by google and archives was that it should just work. Not directly applicable to Andreas's problem, but doubting questions whether a provided crypto accelerator is actually used keep coming up, and I just became aware of an extra twist to this: My hifn (a Soekris vpn1401) didn't appear to be used for IPsec either. When I had ssh traffic terminating at that machine, there were plenty of hifn0 interrupts, but when it only served as an IPsec gateway there were none. Strange. So I took another look at the crypto algorithms employed. ipsecctl(8) defaults to AES and SHA2-256. The Hifn 7955 supports AES, of course, and ... no SHA2. You'd imagine the crypto accelerator would still be used for AES with the SHA2-256 hash added in software, but apparently this is not the case. I switched the IPsec setup to AES/SHA1 and now the hardware acceleration is used, as the respective interrupt rate and overall lower CPU usage convincingly demonstrate. -- Christian naddy Weisgerber [EMAIL PROTECTED]
Re: VIA C7 hardware AES support in IPSEC(ctl)
Bihlmaier Andreas wrote: ## openssl speed aes-128-cbc type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 17311.15k18319.00k18569.35k18893.09k 18765.02k ## openssl speed aes-256-cbc type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 13658.21k14272.24k14446.41k14594.65k 14587.05k This is AES running in software. ## openssl speed -evp aes-128-cbc type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 50807.21k 181629.43k 493014.94k 823907.91k 1029947.70k ## openssl speed -evp aes-256-cbc type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 50317.60k 179579.03k 426484.45k 655755.44k 777427.43k This is AES running on the VIA hardware accelerator. Just compare AES-128 on 8192 bytes: 18765.02k vs 1029947.70k That is more than 50 times quicker. Cheers, Dries
Re: VIA C7 hardware AES support in IPSEC(ctl)
On Wed, Jun 21, 2006 at 09:18:14AM +0200, Dries Schellekens wrote: Bihlmaier Andreas wrote: ## openssl speed aes-128-cbc type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 17311.15k18319.00k18569.35k18893.09k 18765.02k ## openssl speed aes-256-cbc type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 13658.21k14272.24k14446.41k14594.65k 14587.05k This is AES running in software. ## openssl speed -evp aes-128-cbc type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 50807.21k 181629.43k 493014.94k 823907.91k 1029947.70k ## openssl speed -evp aes-256-cbc type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 50317.60k 179579.03k 426484.45k 655755.44k 777427.43k This is AES running on the VIA hardware accelerator. Just compare AES-128 on 8192 bytes: 18765.02k vs 1029947.70k That is more than 50 times quicker. I dont mean to offend you, but ... Doh, I know that and these are VERY nice figures, BUT my problem is that I have to slow (== no acceleration) speed in IPSEC. I thought that OPenBSD would just make use of it (again in IPSEC) if it detects it. Regards, ahb
Re: VIA C7 hardware AES support in IPSEC(ctl)
Bihlmaier Andreas wrote: I dont mean to offend you, but ... Doh, I know that and these are VERY nice figures, BUT my problem is that I have to slow (== no acceleration) speed in IPSEC. I thought that OPenBSD would just make use of it (again in IPSEC) if it detects it. IPSEC always uses the kernel crypto API. So it *is* being used. The performance bottle neck is somewhere else: the kernel crypto interface itself, the network interface, ... Cheers, Dries
Re: VIA C7 hardware AES support in IPSEC(ctl)
On Wed, 2006-06-21 at 13:48 +0200, Bihlmaier Andreas wrote: I dont mean to offend you, but ... Doh, I know that and these are VERY nice figures, BUT my problem is that I have to slow (== no acceleration) speed in IPSEC. I thought that OPenBSD would just make use of it (again in IPSEC) if it detects it. You haven't specified the network setup and how did you conduced the tests. -- Massimo.run();
Re: VIA C7 hardware AES support in IPSEC(ctl)
On Wed, Jun 21, 2006 at 02:24:18PM +0200, Massimo Lusetti wrote: On Wed, 2006-06-21 at 13:48 +0200, Bihlmaier Andreas wrote: I dont mean to offend you, but ... Doh, I know that and these are VERY nice figures, BUT my problem is that I have to slow (== no acceleration) speed in IPSEC. I thought that OPenBSD would just make use of it (again in IPSEC) if it detects it. You haven't specified the network setup and how did you conduced the tests. Sorry, for that but I thought it wouldn't matter: All hosts are in the same network and can talk directly to each other, but for unsecure protocols (NFS, HTTP) I run a VPN between them. host1 router host2 10.0.0.110.0.0.254 10.0.0.8// Real IP // VPN 10.2.0.110.2.0.254 10.2.0.8// alias used for VPN +-+ host1---+ | | Switch +--- router host2---+ | +-+ I use iperf -w 256k for testing purposes. The speed between hosts/router using their real IPs (-B 10.0.0.*) is about 70-80 Mb/s. ~22 Mb/s between host1 and host2 using their VPN IPs. Hope this made some stuff more clear. Thanks everyone for helping, I hope this can be fixed. ahb
Re: VIA C7 hardware AES support in IPSEC(ctl)
Bihlmaier Andreas wrote: I use iperf -w 256k for testing purposes. The speed between hosts/router using their real IPs (-B 10.0.0.*) is about 70-80 Mb/s. ~22 Mb/s between host1 and host2 using their VPN IPs. Hope this made some stuff more clear. Thanks everyone for helping, I hope this can be fixed. What speed do you get when using ssh/sftp? You can disable the userland support of the hardware accelerator using sysctl kern.usercrypto=0 to see if it makes a big difference. Cheers, Dries
Re: VIA C7 hardware AES support in IPSEC(ctl)
On Wed, Jun 21, 2006 at 06:49:09PM +0200, Dries Schellekens wrote: Bihlmaier Andreas wrote: I use iperf -w 256k for testing purposes. The speed between hosts/router using their real IPs (-B 10.0.0.*) is about 70-80 Mb/s. ~22 Mb/s between host1 and host2 using their VPN IPs. Hope this made some stuff more clear. Thanks everyone for helping, I hope this can be fixed. What speed do you get when using ssh/sftp? direct scp (without vpn): 100% 86MB 6.6MB/s 00:13 via vpn: 100% 86MB 2.9MB/s 00:30 You can disable the userland support of the hardware accelerator using sysctl kern.usercrypto=0 to see if it makes a big difference. Well, it does make a huge difference for openssl speed, but none for IPSEC: kern.usercrypto=0 aes-128-cbc 16509.92k18243.74k18760.55k18931.63k 18977.59k kern.usercrypto=1 aes-128-cbc 51475.06k 184199.05k 497290.91k 831042.14k 1033285.89k Regards, ahb
Re: VIA C7 hardware AES support in IPSEC(ctl)
On Wed, Jun 21, 2006 at 06:49:09PM +0200, Dries Schellekens wrote: Bihlmaier Andreas wrote: I use iperf -w 256k for testing purposes. The speed between hosts/router using their real IPs (-B 10.0.0.*) is about 70-80 Mb/s. ~22 Mb/s between host1 and host2 using their VPN IPs. Hope this made some stuff more clear. Thanks everyone for helping, I hope this can be fixed. I found a post in misc@ form 2005 about somebody having a similar problem with IPSEC and VIA hardware acceleration: http://marc.theaimsgroup.com/?l=openbsd-miscm=112275803416870w=2 Could somebody official _PLEASE_ state if it is supposed to work, or isn't? If it should there is a bug, if it doesn't that is bad, but at least it would give me a definite ANSWER. Sorry for bugging (with bugs), ahb
