Hello,
I am working on setting up an IPsec network with two PowerQuicc 8349E devices.
I am using Strongswan for key negotiation. I have a test connection between two
devices running the 2.6.27.3 kernel. Everything works fine with
CONFIG_CRYPTO_DEV_TALITOS
unset. Strongswan configures the XFRM tunnels and I get ESP traffic flow
between my remote networks.
I wanted to enable the Talitos driver for hw entropy. If I rebuild
the kernel with
CONFIG_CRYPTO_DEV_TALITOS set to y, strongswan still successfully negotiates
an IPsec SA, but no traffic flows.
I have a very repeatable configuration (everything configured from
rc.local, etc).
Any ideas what is wrong? Any recommendations on places to start looking?
Also, is it correct that Talitos only accelerates AEAD connections, not ESP/AH
protocols so there will be no performance increase for me until Strongswan
adds rfc5282 support?
Attached is the output for my device. The output is the same with or
without the TALITOS driver (Except for the keys and the SPI values of course):
# ip xfrm state
src 192.168.1.1 dst 192.168.1.2
proto esp spi 0xcc0b06a6 reqid 1 mode tunnel
replay-window 32
auth hmac(sha256)
0xffab7c320d8375cad9633af7c67d923df47183296b9eb8a25fca5c8e5670e8ac
enc cbc(aes) 0x1e918673fd34a1dbb52480e8587f656790194727114cddfdc5f41d19972c1649
sel src 0.0.0.0/0 dst 0.0.0.0/0
src 192.168.1.2 dst 192.168.1.1
proto esp spi 0xc929ef13 reqid 1 mode tunnel
replay-window 32
auth hmac(sha256)
0x2330715271fb3cb23e35bce99ef21c60e4c6a81d684533c2be114e6d1e85197e
enc cbc(aes) 0x1cc443b036fcf1aeb4d6e25da46e07681b513ea489816c507b32f0f79e1cbbc2
sel src 0.0.0.0/0 dst 0.0.0.0/0
# ip xfrm policy
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
dir 4 priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
dir 3 priority 0
src 10.201.0.0/16 dst 192.168.2.0/24
dir out priority 2840
tmpl src 192.168.1.1 dst 192.168.1.2
proto esp reqid 1 mode tunnel
src 192.168.2.0/24 dst 10.201.0.0/16
dir in priority 2760
tmpl src 192.168.1.2 dst 192.168.1.1
proto esp reqid 1 mode tunnel
src 192.168.2.0/24 dst 10.201.0.0/16
dir fwd priority 2760
tmpl src 192.168.1.2 dst 192.168.1.1
proto esp reqid 1 mode tunnel
Thanks in advance for any help,
Barry
On Thu, 23 Oct 2008 16:12:22 -0700
"Barry G" <[email protected]> wrote:
> I wanted to enable the Talitos driver for hw entropy. If I rebuild
> the kernel with
> CONFIG_CRYPTO_DEV_TALITOS set to y, strongswan still successfully negotiates
> an IPsec SA, but no traffic flows.
does no traffic flow at all or is it all getting dropped?
> Also, is it correct that Talitos only accelerates AEAD connections, not ESP/AH
> protocols so there will be no performance increase for me until Strongswan
> adds rfc5282 support?
I'm not sure what you mean here; talitos supports aes-cbc but doesn't
support aes-ccm nor aes-gcm.
> auth hmac(sha256)
> 0xffab7c320d8375cad9633af7c67d923df47183296b9eb8a25fca5c8e5670e8ac
can you try hmac(sha1) until I get a decent setkey?
Kim
>> CONFIG_CRYPTO_DEV_TALITOS set to y, strongswan still successfully negotiates
>> an IPsec SA, but no traffic flows.
>
> does no traffic flow at all or is it all getting dropped?
Unencrypted traffic still flows fine. Sniffing traffic on the encrypted link,
I see the ISAKMP SA init, but no ESP traffic flows after the link is
established even though I have traffic that matches the policy happening.
The firewall is not dropping traffic, as all default filter chain
policies are ACCEPT and
I have no rules added.
Interesting enough, the counters for the INPUT, FORWARD, and OUTPUT chain
all still increase even though no traffic leaves the device on the
remote network pointing
interface.
It looks to me like the kernel gets the SA and still processes
packets, but doesn't actually let them leave box. The mangle and nat tables
are empty, so I don't know what would stop the packet that late in the flow.
>
>> Also, is it correct that Talitos only accelerates AEAD connections, not ESP/AH
>> protocols so there will be no performance increase for me until Strongswan
>> adds rfc5282 support?
>
> I'm not sure what you mean here; talitos supports aes-cbc but doesn't
> support aes-ccm nor aes-gcm.
The reason I ask is:
# cat /proc/crypto | grep -i talitos
driver : authenc-hmac-md5-cbc-3des-talitos
driver : authenc-hmac-md5-cbc-aes-talitos
driver : authenc-hmac-sha256-cbc-3des-talitos
driver : authenc-hmac-sha256-cbc-aes-talitos
driver : authenc-hmac-sha1-cbc-3des-talitos
driver : authenc-hmac-sha1-cbc-aes-talitos
All talitos drivers have the authenc prefix. The aes-cbc entry in my
crypto is:
name : cbc(aes)
driver : cbc(aes-generic)
module : kernel
priority : 100
refcnt : 1
type : blkcipher
blocksize : 16
min keysize : 16
max keysize : 32
ivsize : 16
geniv : <default>
Since its priority isn't 3000 and its driver isn't a talitos driver, I figure
it is software. Disabling the software AES driver in the kernel
results in an error
from strongswan when it tries to add the SA to the kernel.
> can you try hmac(sha1) until I get a decent setkey?
Certainly. I have reconfigured Strongswan to use AES-128 and SHA1:
# ip xfrm state
src 192.168.1.1 dst 192.168.1.2
proto esp spi 0xca44d182 reqid 1 mode tunnel
replay-window 32
auth hmac(sha1) 0x48eacafaaaeb134933642d83c44f2293c277810b
enc cbc(aes) 0x31f28f683a1e9774110abbafe462ac18
sel src 0.0.0.0/0 dst 0.0.0.0/0
src 192.168.1.2 dst 192.168.1.1
proto esp spi 0xc5240eb5 reqid 1 mode tunnel
replay-window 32
auth hmac(sha1) 0xbdf7f26e1ee7339f98dd12c35c85e4af3b671ebc
enc cbc(aes) 0x49ffa621e1baf7921857f4fe1a8003e4
sel src 0.0.0.0/0 dst 0.0.0.0/0
Moving to aes-128 and sha1 had no affect on the problem.
Unsetting CONFIG_CRYPTO_DEV_TALITOS gives me ESP traffic
and everything works as desired.
FYI, my network is 10.201.0./16--192.168.1.1/24==192.168.1.2/24--192.168.2.0/24
Thanks Kim!
Barry
On Wed, 29 Oct 2008 10:33:39 -0700
"Barry G" <[email protected]> wrote:
> >> Also, is it correct that Talitos only accelerates AEAD connections, not ESP/AH
> >> protocols so there will be no performance increase for me until Strongswan
> >> adds rfc5282 support?
> >
> > I'm not sure what you mean here; talitos supports aes-cbc but doesn't
> > support aes-ccm nor aes-gcm.
> The reason I ask is:
> # cat /proc/crypto | grep -i talitos
> driver : authenc-hmac-md5-cbc-3des-talitos
> driver : authenc-hmac-md5-cbc-aes-talitos
> driver : authenc-hmac-sha256-cbc-3des-talitos
> driver : authenc-hmac-sha256-cbc-aes-talitos
> driver : authenc-hmac-sha1-cbc-3des-talitos
> driver : authenc-hmac-sha1-cbc-aes-talitos
>
> All talitos drivers have the authenc prefix. The aes-cbc entry in my
> crypto is:
> name : cbc(aes)
> driver : cbc(aes-generic)
> module : kernel
> priority : 100
> refcnt : 1
> type : blkcipher
> blocksize : 16
> min keysize : 16
> max keysize : 32
> ivsize : 16
> geniv : <default>
>
> Since its priority isn't 3000 and its driver isn't a talitos driver, I figure
> it is software. Disabling the software AES driver in the kernel
> results in an error
> from strongswan when it tries to add the SA to the kernel.
Selecting talitos also selects CRYPTO_AUTHENC. Can you try sending
traffic with CRYPTO_DEV_TALITOS unset and CRYPTO_AUTHENC set if you
haven't already?
If Strongswan works with authenc and s/w crypto (talitos unset), and
the SEC is firing interrupts (grep talitos /proc/interrupts), can you
try with the latest cryptodev-2.6 git tree? There's an error reporting
fix for talitos there that may manifest any h/w the error may be
reporting, depending on the level of traffic.
Otherwise, if you still want to use Strongswan, you can keep talitos
entropy support by commenting out the crypto algorithm registration
section of talitos_probe().
hth,
Kim
Kim Phillips <[email protected]> wrote:
> On Thu, 23 Oct 2008 16:12:22 -0700
> "Barry G" <[email protected]> wrote:
>
>> Also, is it correct that Talitos only accelerates AEAD connections, not ESP/AH
>> protocols so there will be no performance increase for me until Strongswan
>> adds rfc5282 support?
No, AEAD is just a frame-work under which all existing algorithms
and new combined-mode algorithms are now used by IPsec. FWIW, the
fact that talitos has broken your IPsec shows you that it is being
used :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> Selecting talitos also selects CRYPTO_AUTHENC. Can you try sending
> traffic with CRYPTO_DEV_TALITOS unset and CRYPTO_AUTHENC set if you
> haven't already?
Certainly. I compiled a kernel with CRYPTO_AUTHENC set and
CRYPTO_DEV_TALITOS unset. This kernel works fine. Both
encrypted and unencrypted traffic flow properly.
> If Strongswan works with authenc and s/w crypto (talitos unset), and
> the SEC is firing interrupts (grep talitos /proc/interrupts), can you
> try with the latest cryptodev-2.6 git tree? There's an error reporting
> fix for talitos there that may manifest any h/w the error may be
> reporting, depending on the level of traffic.
Strongswan works with authenc enabled and talitos unset. I don't
know about the SEC iterrupt because talitos isn't mentioned in /proc/interrupts
(probably due to CRYPTO_DEV_TALITOS not being set).
I am cloning cryptodev-2.6 right now and will report on what it does.
>
> Otherwise, if you still want to use Strongswan, you can keep talitos
> entropy support by commenting out the crypto algorithm registration
> section of talitos_probe().
Yea. Now that I know I can get hw accel of aes-cbc, I would really like
to get talitos working happily.
Thanks,
Barry
> I am cloning cryptodev-2.6 right now and will report on what it does.
I cloned cryptdev-2.6 and have it running with talitos enabled on my devices.
I still have no ESP traffic, and dmesg shows no errors.
Something I did find that looks suspicious is talitos doesn't appear to be
firing interrupts.
# grep talitos /proc/interrupts
24: 0 IPIC Level talitos
What could cause this?
Herbert: Thanks for the clarification on authenc.
Thanks,
Barry
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Barry G
> I still have no ESP traffic, and dmesg shows no errors.
>
Hi Barry,
Are you using ikev1 or ikev2 with strongswan ?
I have a simple strongswan example which works with talitos aes256,
but it uses ikev1 (pluto).
> Something I did find that looks suspicious is talitos doesn't
> appear to be
> firing interrupts.
>
> # grep talitos /proc/interrupts
> 24: 0 IPIC Level talitos
>
> What could cause this?
>
My feeble attempt to use ikev2 shows this too.
Lee
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Nipper Lee-B04937
> Sent: Thursday, October 30, 2008 6:11 PM
>
> I have a simple strongswan example which works with talitos aes256,
> but it uses ikev1 (pluto).
>
Barry,
In case it provides any help, see below for ipsec.conf & ipsec.secrets
for a tiny strongswan example which works with talitos doing the
encryption/decryption.
I'm using kernel 2.6.27 on 8349E MDS, and strongswan version 4.2.8.
Lee
##################################################
# /etc/ipsec.conf:
version 2.0
config setup
plutodebug=dns
interfaces="ipsec0=eth1"
conn hometooffice
left=200.200.200.10
leftid="@home"
leftsubnet=192.168.1.0/24
right=200.200.200.20
rightid="@office"
rightsubnet=192.168.2.0/24
keyexchange=ikev1
pfs=yes
authby=secret
auto=add
esp=aes256-sha2_256
conn officetohome
left=200.200.200.20
leftid="@office"
leftsubnet=192.168.2.0/24
right=200.200.200.10
rightid="@home"
rightsubnet=192.168.1.0/24
keyexchange=ikev1
pfs=yes
authby=secret
auto=add
esp=aes256-sha2_256
##################################################
# /etc/ipsec.secrets:
# Format for psk: @self @peer PSK "secret"
@home @office: PSK "secret1"
> Are you using ikev1 or ikev2 with strongswan ?
>
I am trying IKEv2 right now (charon). I will try it when I get back to
my main computer with IKEv1.
>> # grep talitos /proc/interrupts
>> 24: 0 IPIC Level talitos
>>
>> What could cause this?
>>
>
> My feeble attempt to use ikev2 shows this too.
I guess its good to know I am not alone :-)
Thanks,
Barry
>>> # grep talitos /proc/interrupts
>>> 24: 0 IPIC Level talitos
>>>
>>> What could cause this?
>>>
Doh! After playing around for a few days, I figured it out:
>From the DTS File:
crypto@30000 {
...
interrupts = <0x11 0x8>;
...
};
Turns out SEC is Interrupt ID 11, which is 0xb or 11, but not 0x11. Not
sure how that got into there.
Changing the DTS file results in a firing interrupt and HW accelerated
crypto traffic.
For the record, both IKEv1 and IKEv2 traffic works fine. On my
test network between two 8347 devices we are getting ~44 Mbit throughput using
SHA256 and AES256. Switching to SHA1 and AES128 gives me ~ 49 Mbit throughput
(half duplex, iperf reported).
Thanks Herbert, Kim, Lee,
Barry