Usage

Before you begin

In this section, it is assumed that Virtual Accelerator has been properly installed and configured. See Getting Started for more details.

There is no runtime configuration for IPsec.

When using Linux - Fast Path Synchronization, the linux-fp-sync.sh startup script executes the following commands to enable IPsec offload to fast path for packets issued by the Linux stack, using filter rules:

# fptun-ipsec-ctrl start

The status can be checked with the following command:

# fptun-ipsec-ctrl status
table inet fptun {
     chain postrouting {
             rt ipsec exists counter pkts 0 bytes 0 queue num 20036
             oifkind "vti" counter pkts 0 bytes 0 queue num 20036
             oifkind "vti6" counter pkts 0 bytes 0 queue num 20036
             oifkind "xfrmi" counter pkts 0 bytes 0 queue num 20036
     }
}

By default, one queue is configured. It is possible to load balance traffic to several queues. One instance of fptun-nfqd runs per queue. This can be configured with the FPTUN_IPSEC_NB_QUEUE option. Note that the service must be stopped before updating this option.

Example

# fptun-ipsec.sh stop
Try to gently kill process fptun-nfqd-ipsec-qnum-20036
fptun-nfqd ipsec stopped
# ip --all netns exec fptun-ipsec-ctrl stop

netns: vrf0
# $EDITOR /etc/fptun-ipsec.env #set FPTUN_IPSEC_NB_QUEUE to 4
# fptun-ipsec.sh start
fptun-nfqd ipsec started
# ip --all netns exec fptun-ipsec-ctrl start 4

netns: vrf0
# fptun-ipsec-ctrl status
table inet fptun {
        chain ipsec-output-delegation {
                rt ipsec exists counter pkts 0 bytes 0 queue num 20036-20039
                oifkind "vti" counter pkts 0 bytes 0 queue num 20036-20039
                oifkind "vti6" counter pkts 0 bytes 0 queue num 20036-20039
                oifkind "xfrm" counter pkts 0 bytes 0 queue num 20036-20039
        }
}

You must add the netfilter rules to all VRF instances you create afterwards, typically by invoking the linux-fp-sync-vrf.sh script:

# vrfctl add 1 linux-fp-sync-vrf.sh

Configuration example

  1. Configure network interfaces

    # ip link set eth1 up
# ip link set eth3 up
# ip addr add 10.22.4.104/24 dev eth1
# ip addr add 10.23.4.104/24 dev eth3
# ip route add default via 10.23.4.204

  2. Configure SAs

    # ip xfrm state flush
# ip xfrm state add src 10.23.4.104 dst 10.23.4.204 proto esp spi 4096 \
  enc "cbc(aes)" 0xa69e295e5a7718450b9531cac8b73a5d \
  auth "hmac(sha1)" 0xde86d704f3227d67e59f1cdd659d3887f90690d8 \
  mode tunnel
# ip xfrm state add src 10.23.4.204 dst 10.23.4.104 proto esp spi 4352 \
  enc "cbc(aes)" 0x68f199b8d3f753a807385b3f8ab21a58 \
  auth "hmac(sha1)" 0x487bf1117963a795e1bf6f3a37c7289375679c7c \
  mode tunnel

  3. Configure SPs

    # ip xfrm policy flush
# ip xfrm policy add src 10.22.4.0/24 dst 10.24.4.10/24 dir out priority 2000 \
  tmpl src 10.23.4.104 dst 10.23.4.204 proto esp mode tunnel
# ip xfrm policy add src 10.24.4.0/24 dst 10.22.4.10/24 dir in  priority 2000 \
  tmpl src 10.23.4.204 dst 10.23.4.104 proto esp mode tunnel
# ip xfrm policy add src 10.24.4.0/24 dst 10.22.4.10/24 dir fwd priority 2000 \
  tmpl src 10.23.4.204 dst 10.23.4.104 proto esp mode tunnel

  4. Display SAs in the Linux kernel

    # ip xfrm state
src 10.23.4.204 dst 10.23.4.104
        proto esp spi 0x00001100 reqid 0 mode tunnel
        replay-window 0
        auth-trunc hmac(sha1) 0x487bf1117963a795e1bf6f3a37c7289375679c7c 96
        enc cbc(aes) 0x68f199b8d3f753a807385b3f8ab21a58
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
        sel src 0.0.0.0/0 dst 0.0.0.0/0
src 10.23.4.104 dst 10.23.4.204
        proto esp spi 0x00001000 reqid 0 mode tunnel
        replay-window 0
        auth-trunc hmac(sha1) 0xde86d704f3227d67e59f1cdd659d3887f90690d8 96
        enc cbc(aes) 0xa69e295e5a7718450b9531cac8b73a5d
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
        sel src 0.0.0.0/0 dst 0.0.0.0/0

  5. Display SPs in the Linux kernel

    # ip xfrm policy
src 10.24.4.0/24 dst 10.22.4.10/24
        dir fwd priority 2000
        tmpl src 10.23.4.204 dst 10.23.4.104
                proto esp reqid 0 mode tunnel
src 10.24.4.0/24 dst 10.22.4.10/24
        dir in priority 2000
        tmpl src 10.23.4.204 dst 10.23.4.104
                proto esp reqid 0 mode tunnel
src 10.22.4.0/24 dst 10.24.4.10/24
        dir out priority 2000
        tmpl src 10.23.4.104 dst 10.23.4.204
                proto esp reqid 0 mode tunnel

  6. Display SAs in the fast path

    # fp-cli

    <fp-0> ipsec4-sad all
SAD 2 SA.
1: 10.23.4.104 - 10.23.4.204 vr0 spi 0x1000 ESP tunnel
     counter 1 (genid 1)
     AES-CBC HMAC-SHA1
     key enc:a69e295e5a7718450b9531cac8b73a5d
     digest length: 12
     key auth:de86d704f3227d67e59f1cdd659d3887f90690d8
     sa_packets=0 sa_bytes=0 sa_auth_errors=0 sa_decrypt_errors=0
     sa_replay_errors=0 sa_selector_errors=0
     replay width=0 seq=0x0 - oseq=0x0
2: 10.23.4.204 - 10.23.4.104 vr0 spi 0x1100 ESP tunnel
     counter 1 (genid 2)
     AES-CBC HMAC-SHA1
     key enc:68f199b8d3f753a807385b3f8ab21a58
     digest length: 12
     key auth:487bf1117963a795e1bf6f3a37c7289375679c7c
     sa_packets=0 sa_bytes=0 sa_auth_errors=0 sa_decrypt_errors=0
     sa_replay_errors=0 sa_selector_errors=0
     replay width=0 seq=0x0 - oseq=0x0

  7. Display SPs in the fast path

    <fp-0> ipsec4-spd all
Inbound SPD: 1 rules
1: 10.24.4.0/24 10.22.4.10/24 proto any vr0 protect prio 2000
     ESP tunnel 10.23.4.204 - 10.23.4.104
     sp_packets=0 sp_bytes=0 sp_exceptions=0 sp_errors=0
Outbound SPD: 1 rules
1: 10.22.4.0/24 10.24.4.10/24 proto any vr0 protect prio 2000
     cached-SA 0 (genid 0)
     ESP tunnel 10.23.4.104 - 10.23.4.204
     sp_packets=0 sp_bytes=0 sp_exceptions=0 sp_errors=0

Displaying IPsec SPD trie thresholds

IPv4 unhashed SPs are stored in a linked list and may also be stored in an optimized lookup structure, the IPsec trie. The lookup through these policies is done either through the linked list or through the IPsec trie, depending on thresholds.

Synopsis

ipsec4-trie-threshold

Example

<fp-0> ipsec4-trie-threshold
IPsec output trie threshold: 49 2048
IPsec input trie threshold: 49 2048

Setting IPsec SPD trie thresholds

For a given direction (in or out), if the number of unhashed IPsec policies (nb) is between the 2 thresholds (min <= nb <= max), then the trie is built and used for SPD lookup.

If nb < min or nb > max, then the linked list is used for SPD lookup.

Synopsis

ipsec4-trie-threshold-set [in|out] <thresh min> [<thresh max>]
in or out

Direction of the SPs.

<thresh min>

Minimum unhashed policies to build and use the IPsec trie (0..4095).

<thresh max>

Maximum unhashed policies to build and use the IPsec trie (0..4095).

Example

<fp-0> ipsec4-trie-threshold-set 50 1500
IPsec output trie threshold: 50 1500
IPsec input trie threshold: 50 1500

Statistics

Displaying the SPD

Synopsis

ipsec4-spd [(all [(svti|xfrmi) <iface>])|raw]
No parameter

Only display the number of global SPs.

all

Display all global SPs registered in the fast path in order of priority.

svti <ifname>

Specific SVTI interface name.

xfrmi <ifname>

Specific XFRM interface name.

raw

Display all SPs registered in the fast path in the same order as in the internal table.

Examples

<fp-0> ipsec4-spd
Inbound SPD: 2 rules
Outbound SPD: 2 rules

<fp-0> ipsec4-spd all
SPD hash lookup min prefix lengths: local=0, remote=0
Inbound SPD: 2 rules
3: 10.24.4.119/32 10.22.4.118/32 proto 17 vr0 protect prio 2000
    link-vr0
    ESP tunnel 10.23.4.204 - 10.23.4.104 reqid=1
    sp_packets=4 sp_bytes=2112 sp_exceptions=0 sp_errors=0
2: 10.24.4.119/32 10.22.4.118/32 proto 6 vr0 protect prio 2000
    link-vr0
    ESP tunnel 10.23.4.204 - 10.23.4.104 reqid=2
    sp_packets=1 sp_bytes=40 sp_exceptions=0 sp_errors=0
Outbound SPD: 2 rules
3: 10.22.4.118/32 10.24.4.119/32 proto 17 vr0 protect prio 2000
    link-vr0 cached-SA 3 genid 17
    ESP tunnel 10.23.4.104 - 10.23.4.204 reqid=1
    sp_packets=6 sp_bytes=3168 sp_exceptions=1 sp_errors=1
2: 10.22.4.118/32 10.24.4.119/32 proto 6 vr0 protect prio 2000
    link-vr0 cached-SA 2 genid 20
    ESP tunnel 10.23.4.104 - 10.23.4.204 reqid=2
    sp_packets=1 sp_bytes=60 sp_exceptions=1 sp_errors=0

<fp-0> ipsec4-spd raw
SPD hash lookup min prefix lengths: local=0, remote=0
Inbound SPD: 2 total rules, 2 global rules
2: 10.24.4.119/32 10.22.4.118/32 proto 6 vr0 protect prio 2000
    link-vr0
    ESP tunnel 10.23.4.204 - 10.23.4.104 reqid=2
    sp_packets=1 sp_bytes=40 sp_exceptions=0 sp_errors=0
3: 10.24.4.119/32 10.22.4.118/32 proto 17 vr0 protect prio 2000
    link-vr0
    ESP tunnel 10.23.4.204 - 10.23.4.104 reqid=1
    sp_packets=4 sp_bytes=2112 sp_exceptions=0 sp_errors=0
Outbound SPD: 2 total rules, 2 global rules
2: 10.22.4.118/32 10.24.4.119/32 proto 6 vr0 protect prio 2000
    link-vr0 cached-SA 2 genid 20
    ESP tunnel 10.23.4.104 - 10.23.4.204 reqid=2
    sp_packets=1 sp_bytes=60 sp_exceptions=1 sp_errors=0
3: 10.22.4.118/32 10.24.4.119/32 proto 17 vr0 protect prio 2000
    link-vr0 cached-SA 3 genid 17
    ESP tunnel 10.23.4.104 - 10.23.4.204 reqid=1
    sp_packets=6 sp_bytes=3168 sp_exceptions=1 sp_errors=1

Displaying the SAD

Dump all SAs, or only a specific one.

Synopsis

ipsec4-sad [all] [(svti|xfrmi) IFNAME] [<src> <prefix> <dst> <prefix> <proto>]
No parameters

Only display the number of SAs present in the fast path table.

all

Display all SAs present in the fast path table.

svti <ifname>

Specific SVTI interface name.

xfrmi <ifname>

Specific XFRM interface name.

<src>

SA source ip address.

<prefix>

Length (in bits) of the source ip netmask prefix.

<dst>

SA destination ip address.

<prefix>

Length (in bits) of the destination ip netmask prefix.

<proto>

Select the AH or the ESP protocol.

Examples

<fp-0> ipsec4-sad
SAD 4 SA.

<fp-0> ipsec4-sad all
SAD 4 SA.
2: 10.23.4.104 - 10.23.4.204 vr0 spi 0xc55d891 ESP tunnel
    x-vr0 reqid=2 genid 20 cached-SP 0
    DES-CBC HMAC-MD5
    key enc:4efe5a2ab00d7273
    key auth:8ae2e379f5d9950f9e16c5b5cb95496e
    sa_packets=1 sa_bytes=60 sa_auth_errors=0 sa_decrypt_errors=0
    sa_replay_errors=0 sa_selector_errors=0
    replay check is on width=32 seq=0 bitmap=0x00000000 - oseq=1
3: 10.23.4.104 - 10.23.4.204 vr0 spi 0xe4dbd1 ESP tunnel
    x-vr0 reqid=1 genid 17 cached-SP 0
    DES-CBC HMAC-MD5
    key enc:d6ce2c08b3ed0340
    key auth:33da206f897fd17a214052eb07b403bc
    sa_packets=6 sa_bytes=3168 sa_auth_errors=0 sa_decrypt_errors=0
    sa_replay_errors=0 sa_selector_errors=0
    replay check is on width=32 seq=0 bitmap=0x00000000 - oseq=6
4: 10.23.4.204 - 10.23.4.104 vr0 spi 0x4d2eba4 ESP tunnel
    x-vr0 reqid=2 genid 19 cached-SP 2
    DES-CBC HMAC-MD5
    key enc:becc9cfbed4123cc
    key auth:40a6314fc26317d499389654b0ee670f
    sa_packets=1 sa_bytes=96 sa_auth_errors=0 sa_decrypt_errors=0
    sa_replay_errors=0 sa_selector_errors=0
    replay check is on width=32 seq=1 bitmap=0x00000001 - oseq=0
6: 10.23.4.204 - 10.23.4.104 vr0 spi 0x778e36c ESP tunnel
    x-vr0 reqid=1 genid 16 cached-SP 3
    DES-CBC HMAC-MD5
    key enc:c080b354f2f0d217
    key auth:efd3f0cbc5ade56761385eaa74bbbcb9
    sa_packets=4 sa_bytes=2336 sa_auth_errors=0 sa_decrypt_errors=0
    sa_replay_errors=0 sa_selector_errors=0
    replay check is on width=32 seq=4 bitmap=0x0000000f - oseq=0

Extended Sequence Number

Note

This feature needs the ESN and large anti-replay window static configuration iproute2 patch.

AH/ESP headers support extended, 64 bit sequence numbers to detect replay.

A single IPsec SA can transfer a maximum of 2^64 IPsec packets.

Example

  1. Create an SA with ESN support and a 128 packets replay window:

    $ ip xfrm state add src 2.1.0.1 dst 2.1.0.5 spi 0x00000220 proto esp reqid 22 mode tunnel \
enc aes cle1goldorakgoldorakcle1 auth sha1 cle1goldorakgoldcle1 flag esn replay-window 128

  2. Check that your configuration is correctly synchronized in the fast path:

    $ fp-cli

    <fp-0> ipsec4-sad all
SAD 1 SA.
1: 2.1.0.1 - 2.1.0.5 vr0 spi 0x220 ESP tunnel
  x-vr0 reqid=22 counter 1 cached-SP 0 (genid 1)
  cached-svti 0 (genid 0)
  AES-CBC HMAC-SHA1 esn
  key enc:636c6531676f6c646f72616b676f6c646f72616b636c6531
  digest length: 12
  key auth:636c6531676f6c646f72616b676f6c64636c6531
  sa_packets=0 sa_bytes=0 sa_auth_errors=0 sa_decrypt_errors=0
  sa_replay_errors=0 sa_selector_errors=0
  replay width=128 seq=0x0 - oseq=0x0
  00000000 00000000 00000000 00000000

See also

Dependencies

Large anti-replay window

Note

This feature needs the ESN and large anti-replay window static configuration iproute2 patch.

You can set the anti-replay window size between 32 and 4096 packets (maximum size allowed by the Linux kernel).

Example

  1. Create an SA with a 256 packets replay window:

    $ ip xfrm state add src 2.1.0.1 dst 2.1.0.5 spi 0x00000220 proto esp reqid 22 mode tunnel \
enc aes cle1goldorakgoldorakcle1 auth sha1 cle1goldorakgoldcle1 replay-window 256

  2. Check that your configuration is correctly synchronized in the fast path:

    $ fp-cli

    <fp-0> ipsec4-sad all
  SAD 1 SA.
  1: 2.1.0.1 - 2.1.0.5 vr0 spi 0x220 ESP tunnel
  x-vr0 reqid=22 counter 2 cached-SP 0 (genid 2)
  cached-svti 0 (genid 0)
  AES-CBC HMAC-SHA1
  key enc:636c6531676f6c646f72616b676f6c646f72616b636c6531
  digest length: 12
  key auth:636c6531676f6c646f72616b676f6c64636c6531
  sa_packets=0 sa_bytes=0 sa_auth_errors=0 sa_decrypt_errors=0
  sa_replay_errors=0 sa_selector_errors=0
  replay width=256 seq=0x0 - oseq=0x0
  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

See also

Dependencies

IPv4 in IPv6 IPsec tunnel example

We will encapsulate IPv4 packets in a static IPv6 IPsec tunnel.

  1. Create the inbound IPsec configuration:

    1. Create an IPv6 IPsec SA for IPv4 packets:

      $ ip xfrm state add src 3ffe:2:11::5 dst 3ffe:2:11::1 \
  proto esp spi 0x00000221 mode tunnel \
  enc aes cle1goldorakgoldorakcle1 auth sha1 cle1goldorakgoldcle1 \
  flag af-unspec

    2. Create an inbound IPv4 IPsec SP:

      $ ip xfrm policy add src 110.2.2.1/32 dst 100.2.2.1/32 dir in \
  tmpl src 3ffe:2:11::5 dst 3ffe:2:11::1 proto esp mode tunnel

    3. Create a forward IPv4 IPsec SP:

      $ ip xfrm policy add src 110.2.2.1/32 dst 100.2.2.1/32 dir fwd \
  tmpl src 3ffe:2:11::5 dst 3ffe:2:11::1 proto esp mode tunnel

  2. Create the outbound IPsec configuration:

    1. Create an IPv6 IPsec SA for IPv4 packets:

      $ ip xfrm state add src 3ffe:2:11::1 dst 3ffe:2:11::5 \
  proto esp spi 0x00000220 mode tunnel \
  enc aes cle1goldorakgoldorakcle2 auth sha1 cle1goldorakgoldcle2 \
  flag af-unspec

    2. Create an outbound IPv4 IPsec SP:

      $ ip xfrm policy add src 100.2.2.1/32 dst 110.2.2.1/32 dir out \
  tmpl src 3ffe:2:11::1 dst 3ffe:2:11::5 proto esp mode tunnel

  3. Check that your configuration is correctly synchronized in the fast path:

    1. Start fp-cli:

      $ fp-cli

    2. Display the SAs in the Fast Path IPsec IPv6 table:

      <fp-0> ipsec6-sad all
IPv6 SAD 2 SA.
1: 3ffe:2:11::5 - 3ffe:2:11::1 vr0 spi 0x221 ESP tunnel
  x-vr0 counter 1 genid 1 cached-SP: 0
  AES-CBC HMAC-SHA1
  key enc:636c6531676f6c646f72616b676f6c646f72616b636c6531
  digest length: 12
  key auth:636c6531676f6c646f72616b676f6c64636c6531
  sa_packets=0 sa_bytes=0 sa_auth_errors=0 sa_decrypt_errors=0
  sa_replay_errors=0 sa_selector_errors=0
  replay width=0 seq=0x0 - oseq=0x0
2: 3ffe:2:11::1 - 3ffe:2:11::5 vr0 spi 0x220 ESP tunnel
  x-vr0 counter 1 genid 2 cached-SP: 0
  AES-CBC HMAC-SHA1
  key enc:636c6531676f6c646f72616b676f6c646f72616b636c6532
  digest length: 12
  key auth:636c6531676f6c646f72616b676f6c64636c6532
  sa_packets=0 sa_bytes=0 sa_auth_errors=0 sa_decrypt_errors=0
  sa_replay_errors=0 sa_selector_errors=0
  replay width=0 seq=0x0 - oseq=0x0

    3. Display the SPs in the Fast Path IPsec IPv4 table:

      <fp-0> ipsec4-spd all
SPD hash lookup min prefix lengths: local=0, remote=0
Inbound SPD: 1 rules
1: 110.2.2.1/32 100.2.2.1/32 proto any vr0 protect prio 0
  link-vr0
  ESP tunnel 3ffe:2:11::5 - 3ffe:2:11::1
  sp_packets=0 sp_bytes=0 sp_exceptions=0 sp_errors=0
Outbound SPD: 1 rules
1: 100.2.2.1/32 110.2.2.1/32 proto any vr0 protect prio 0
  link-vr0 cached-SA 0 (genid 0)
  ESP tunnel 3ffe:2:11::1 - 3ffe:2:11::5
  sp_packets=0 sp_bytes=0 sp_exceptions=0 sp_errors=0

See also

To dynamically configure IPsec tunnels, see the Control Plane Security - IKEv1 and IKEv2 documentation.

RFC compliance for HMAC-SHA2 cryptographic algorithms

HMAC-SHA256 truncation length

The standard HMAC-SHA256 truncation length in IPsec is 128 bits.

However, by default, the Linux kernel sets the truncation length to 96 bits (HMAC-SHA256-96). The fast path ignores the truncation size configured in the Linux kernel and always assumes that it is 128 bits.

You can manually configure RFC compliant HMAC-SHA256 IPsec SAs via the following iproute2 command:

# ip xfrm state add src 10.23.4.104 dst 10.23.4.204 proto esp spi 5246 \
  enc "cbc(aes)" 0xa69e295e5a7718450b9531cac8b73a5d \
  auth-trunc "hmac(sha256)" \
  0x3dbce667c4c31fa24d88d9b7d64a16d415c78f469b0ae7f734803d2ec1bbe844 128

instead of:

# ip xfrm state add src 10.23.4.104 dst 10.23.4.204 proto esp spi 5246 \
  enc "cbc(aes)" 0xa69e295e5a7718450b9531cac8b73a5d \
  auth "hmac(sha256)" \
  0x3dbce667c4c31fa24d88d9b7d64a16d415c78f469b0ae7f734803d2ec1bbe844

See also

RFC 4868 Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec, section 2.6.

HMAC-SHA2 algorithms and IPv4 AH

The AH header ICV field may include explicit padding if required to ensure that the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6).

However, the Linux kernel always ensures that the AH header is a multiple of 64 bits, regardless of the IP version. If the output of the selected algorithm is 96 bits (e.g. HMAC-SHA1-96) or 192 bits (e.g. HMAC-SHA384-192), aligning the AH header on 32 or 64 bits is the same, but if the output of the selected algorithm is 128 bits (HMAC-SHA256-128) or 256 bits (HMAC-SHA512-256), Linux pads IPv4 AH headers although it MUST not.

The fast path always performs the padding as specified in the AH RFC.

You can manually configure RFC compliant IPsec IPv4 SAs by setting the flag align4, at least for HMAC-SHA256 and HMAC-SHA512 algorithms. However, a good practice is to always set this flag on IPsec IPv4 SAs, whatever the authentication algorithm.

Example

# ip xfrm state add src 10.23.4.104 dst 10.23.4.204 proto ah \
  spi 0x00127764 mode tunnel auth-trunc "hmac(sha256)" \
  0x8dcce7d80f7c8bb81e6a526b9d5d7ce2e7a474e3406c40953108b6d92b61cb77 128 \
  flag align4

See also

RFC 4302 IP Authentication Header, section 3.3.3.2.1.

IPsec NAT-T example

We will encapsulate the IPsec packet in a IPv4 UDP payload, and NAT will be done on the same device.

Example

  1. NAT configuration

    # iptables -t nat -A POSTROUTING -o ntfp2 -s 10.200.0.2/0 -j MASQUERADE

  2. Configure Control Plane Security - IKEv1 and IKEv2

    # cat /etc/ike/ipsec.conf
config setup

conn %default
    keyexchange=ikev2
    keyingtries=1
    mobike=no
    ikelifetime=57600s
    rekeymargin=5760s
    keylife=28800s

conn nat-t
    auto=route
    left=10.200.0.2
    right=10.125.0.1
    leftid=10.125.0.2
    rightid=10.125.0.1
    type=tunnel
    leftsubnet=10.200.0.0/24
    rightsubnet=10.100.0.0/24
    authby=psk
    ike=aes128-sha1-modp2048
    esp=aes128-sha1-modp2048

The IPsec IPv4 SAs and SPs are generated automatically by Control Plane Security - IKEv1 and IKEv2, see Control Plane Security - IKEv1 and IKEv2 documentation about how to dynamically configure IPsec tunnels.

  1. Display SPs in the Linux kernel

    # ip xfrm policy
src 10.100.0.0/24 dst 10.200.0.0/24
        dir fwd priority 287712
        tmpl src 10.125.0.1 dst 10.200.0.2
                proto esp reqid 1 mode tunnel
src 10.100.0.0/24 dst 10.200.0.0/24
        dir in priority 287712
        tmpl src 10.125.0.1 dst 10.200.0.2
                proto esp reqid 1 mode tunnel
src 10.200.0.0/24 dst 10.100.0.0/24
        dir out priority 287712
        tmpl src 10.200.0.2 dst 10.125.0.1
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0

  2. trigger IKE negotiations

  3. Display SAs in the Linux kernel

    # ip xfrm state
src 10.200.0.2 dst 10.125.0.1
        proto esp spi 0xcacf0d61 reqid 1 mode tunnel
        replay-window 0 flag af-unspec
        auth-trunc hmac(sha1) 0xe65464fd16c7b8d234bca701e9a52fd7c8ba1b57 96
        enc cbc(aes) 0xf1ffcdd8173204a1cde5ca0e55b123ce
        encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 10.125.0.1 dst 10.200.0.2
        proto esp spi 0xc5b51de0 reqid 1 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0xed1d8b8a30844365dbf9657041da76d725842cc3 96
        enc cbc(aes) 0xac1d42cb032259724a14f97441b309a3
        encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

  4. Check that the SAs is correctly synchronized in the fast path:

    1. Start fp-cli:

      # fp-cli

    2. Display the SAs in the Fast Path IPsec IPv4 table:

      <fp-0> ipsec4-sad all
SAD 2 SA.
2: 10.125.0.1 - 10.200.0.2 vr0 spi 0xc5b51de0 ESP tunnel
     reqid=1 counter 1 (genid 2)
     AES-CBC HMAC-SHA1
     key enc:ac1d42cb032259724a14f97441b309a3
     digest length: 12
     key auth:ed1d8b8a30844365dbf9657041da76d725842cc3
     NAT traversal: sport: 4500 dport: 4500
     sa_packets=0 sa_bytes=0 sa_auth_errors=0 sa_decrypt_errors=0
     sa_replay_errors=0 sa_selector_errors=0
     replay width=32 seq=0x0 - oseq=0x0
     00000000
3: 10.200.0.2 - 10.125.0.1 vr0 spi 0xcacf0d61 ESP tunnel
     reqid=1 counter 1 (genid 3)
     AES-CBC HMAC-SHA1
     key enc:f1ffcdd8173204a1cde5ca0e55b123ce
     digest length: 12
     key auth:e65464fd16c7b8d234bca701e9a52fd7c8ba1b57
     NAT traversal: sport: 4500 dport: 4500
     sa_packets=0 sa_bytes=0 sa_auth_errors=0 sa_decrypt_errors=0
     sa_replay_errors=0 sa_selector_errors=0
     replay width=0 seq=0x0 - oseq=0x0

AES-GCM and AES-GMAC cryptographic algorithms

AES-GCM and AES-GMAC are AEAD cryptographic algorithms. AES-GCM provides confidentiality and data origin authentication, while AES-GMAC only provides data origin authentication.

AES-GCM

The configuration parameters of the AES-GCM algorithm are:

  • the AES key (128, 192 or 256 bits)

  • the salt (32 bits), prepended to the packet IV to form a Nonce

  • the ICV length. Only the mandatory size of 128 bits is supported by the fast path IPsec implementation.

When configuring an SA via iproute2, the salt is appended to the AES key. Since AES-GCM provides both confidentiality and authentication, no additional authentication algorithm must be specified.

Example

  1. Create an ESP SA with algorithm AES-GCM and a 128-bit key, a 32-bit salt and 128-bit ICV:

    # ip xfrm state add src 10.23.4.104 dst 10.23.4.204 proto esp spi 4096 \
  aead "rfc4106(gcm(aes))" 0x531bf5714440d166757353f29511ca42146e8b0c 128 \
  mode tunnel

  2. Display the SA in the fast path:

    <fp-0> ipsec4-sad all
SAD 1 SA.
1: 10.23.4.104 - 10.23.4.204 vr0 spi 0x1000 ESP tunnel
     counter 1 (genid 1)
     AES-GCM
     key enc:531bf5714440d166757353f29511ca42
     nonce salt:146e8b0c
     digest length: 16
     sa_packets=0 sa_bytes=0 sa_auth_errors=0 sa_decrypt_errors=0
     sa_replay_errors=0 sa_selector_errors=0
     replay width=0 seq=0x0 - oseq=0x0

Warning

The fast path IPsec implementation only supports a full-length 128-bit ICV, the optional lengths of 64 or 96 bits are not supported. The fast path ignores the ICV length specified in Linux and will only send and accept IPsec packets protected by AES-GCM with a 128-bit ICV.

Note

If you use the multibuffer crypto library, AES-GCM is accelerated for 128 bit, 192 or 256 bit keys.

See also

RFC 4106 The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)

AES-GMAC

AES-GMAC is a special case of AES-GCM, designed to only provide data origin authentication, typically to implement authenticated ESP-null.

Like AES-GCM, the configuration parameters of the AES-GMAC algorithm are:

  • the AES key (128, 192 or 256 bits)

  • the salt (32 bits), prepended to the packet IV to form a Nonce

Only the full-length 128 bit ICV is authorized by the standard.

When configuring an SA via iproute2, the salt is appended to the AES key.

Example

  1. Create an ESP SA with algorithm AES-GMAC and a 128-bit key, a 32-bit salt and 128-bit ICV:

    # ip xfrm state add src 10.23.4.104 dst 10.23.4.204 proto esp spi 4097 \
  aead "rfc4543(gcm(aes))" 0x40d3a54c5ae9ee8f23f73729975a3db58eb5cdbb 128 \
  mode tunnel

  2. Display the SA in the fast path:

    <fp-0> ipsec4-sad all
SAD 1 SA.
1: 10.23.4.104 - 10.23.4.204 vr0 spi 0x1001 ESP tunnel
     counter 2 (genid 3)
     AES-GMAC
     key enc:40d3a54c5ae9ee8f23f73729975a3db5
     nonce salt:8eb5cdbb
     digest length: 16
     sa_packets=0 sa_bytes=0 sa_auth_errors=0 sa_decrypt_errors=0
     sa_replay_errors=0 sa_selector_errors=0
     replay width=0 seq=0x0 - oseq=0x0

Note

Linux only supports AES-GMAC for the ESP algorithm, not for the AH algorithm.

Note

If you use the multibuffer crypto library, AES-GMAC is accelerated for 128 bit, 192 or 256 bit keys.

See also

RFC 4543 The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH

Offload of cryptographic operations

Maximal throughput of a tunnel is limited. In order to increase this limit cryptographic operations are offloaded to idle fast path cores. Gain provided by this feature depends of the traffic model and the number of idle fast path cores. Typically the maximal throughput of a tunnel with IMIX traffic is double if a fast path core is available to do the cryptographic operations.

Details of the way to configure offloading of the cryptographic operations is detailed in FPN-SDK Cryptographic offloading

By default the crytographic offloading is done only for packets received from the tunnel. The cryptographic offloading for packets sent into the tunnel can be enabled through the cli but can impact packet ordering (especially if there are many flows aggregated in the tunnel) and cause issue with the anti-replay windows of the IPsec SA.

Providing options

To change the maximum number of IPsec tunnels, several runtime parameters must be changed. An IPsec tunnel has 2 IPsec SAs, 1 IPsec SP in and 1 IPsec SP out.

To change the value of a runtime parameter set FP_OPTIONS variable in fast-path.env:

FP_OPTIONS="--mod-opt=ipsec:option=<value>"

Example

FP_OPTIONS="--mod-opt=ipsec:--max-sa=4096"

The number of IPsec SPs (in and out) is specified by the max-sp parameter.

The number of IPsec SAs is specified by the max-sa parameter. This parameter must be at least the double of the max-sp parameter. Each SA uses a dedicated cryptographic session, and the maximum number of cryptographic sessions must be changed accordingly: the number of cryptographic sessions must be equal or greater than max-sa (see FPN-SDK cryptography option).

--max-sp

Maximum number of SPs

Default value

8192

Memory footprint per IPsec SP

1 KB

Range

0 .. 400K

--max-sa

Maximum number of SAs

Default value

8192

Memory footprint per SA

5 KB

This footprint takes into account 1 cryptographic session per SA.

Range

0 .. 400K

--sa-hash-order

Size order of IPv4 IPsec SAD hash table. Value automatically updated if --max-sa is changed.

Default value

16

Range

16 .. 20

--sp-hash-order

Size order of IPv4 IPsec SPD hash table. Value automatically updated if --max-sp is changed.

Default value

9

Range

8 .. 16

Note

See Fast Path Capabilities documentation for impact of the available memory on the default value of configurable capabilities