addrblock Plugin

Purpose

The addrblock plugin for libcharon implements authorization of the remote subnets against the IPAddrBlocks extension as standardized in RFC 3779 that are contained in the peer’s X.509 certificate.

If necessary and possible, the remote subnets proposed by the peer are automatically narrowed to the subnets defined in the IPAddrBlocks extension.

The plugin is disabled by default and can be enabled with the ./configure option

--enable-addrblock

Behavior

The pki tool supports the issuing of both X.509 CA and End-Entity certificates with address blocks using the argument

--addrblock <address block>

X.509 End-Entity Certificate with IPAddrBlocks Extension

subject:  "C=CH, O=strongSwan Project, OU=RFC3779, CN=moon.strongswan.org"
issuer:   "C=CH, O=strongSwan Project, OU=RFC3779, CN=strongSwan RFC3779 Root CA"
validity:  not before Oct 03 08:00:38 2021, ok
           not after  Oct 03 08:00:38 2029, ok (expires in 2906 days)
serial:    01
altNames:  moon.strongswan.org
flags:
CRL URIs:  http://crl.strongswan.org/strongswan_rfc3779.crl
addresses: 10.1.0.0/16, 192.168.0.1/32, fec0::1/128, fec1::/16
authkeyId: 5a:74:31:f9:0b:6d:1a:cb:30:95:f0:1d:8c:73:78:ec:19:db:53:e2
subjkeyId: 6c:6c:13:79:d9:4e:bc:03:98:33:fd:e3:e3:61:75:9d:6b:44:28:3e
pubkey:    RSA 3072 bits, has private key
keyid:     a0:46:53:a2:b8:30:56:43:2e:e2:35:05:c5:f6:74:84:15:c0:4a:7e
subjkey:   6c:6c:13:79:d9:4e:bc:03:98:33:fd:e3:e3:61:75:9d:6b:44:28:3e

The peer moon.strongswan.org is allowed to use the IPv4 addresses 10.1.0.0/16 and 192.168.0.1/32 as well as the IPv6 addresses fec0::1/128 and fec1::/16.

X.509 CA Certificate with IPAddrBlocks Extension

subject:  "C=CH, O=strongSwan Project, OU=RFC3779, CN=strongSwan RFC3779 Root CA"
issuer:   "C=CH, O=strongSwan Project, OU=RFC3779, CN=strongSwan RFC3779 Root CA"
validity:  not before Oct 03 08:00:38 2021, ok
           not after  Oct 04 08:00:38 2031, ok (expires in 3637 days)
serial:    4c:c1:5c:87:8f:fc:5b:5f
flags:     CA CRLSign self-signed
addresses: 10.1.0.0..10.2.255.255, 10.3.0.1..10.3.3.232, 192.168.0.0/24,
           fec0::..fec2:ffff:ffff:ffff:ffff:ffff:ffff:ffff
subjkeyId: 5a:74:31:f9:0b:6d:1a:cb:30:95:f0:1d:8c:73:78:ec:19:db:53:e2
pubkey:    RSA 3072 bits
keyid:     3d:45:b0:ad:ee:99:c5:51:11:8d:31:d5:e5:53:0f:cc:1e:ac:99:28
subjkey:   5a:74:31:f9:0b:6d:1a:cb:30:95:f0:1d:8c:73:78:ec:19:db:53:e2

In order for an End-Entity certificate to be valid, all the IP address blocks defined in its IPAddrBlocks extension must be fully contained in the IP address blocks as defined by the IPAddrBlocks extension of the issuing CA’s certificate:

  • 10.1.0.0/16 contained in 10.1.0.0..10.2.255.255: ok

  • 192.168.0.1/32 contained in 192.168.0.0/24: ok

  • fec0::1/128 contained in fec0::..fec2:ffff:ffff:ffff:ffff:ffff:ffff:ffff: ok

  • fec1::/16 contained in fec0::..fec2:ffff:ffff:ffff:ffff:ffff:ffff:ffff: ok

Configuration

The addrblock plugin is configured using the following options in the charon.plugins.addrblock section of strongswan.conf:

Key Default Description

depth

-1

How deep towards the root CA to validate issuer cert IPAddrblock extensions (since version 5.9.6).

RFC 3779 requires that all addrblocks claimed by a certificate must be contained in the IPAddrblock extension of the issuer certificate, up to the root CA. The default depth setting of -1 enforces this.

In practice, third party (root) CAs may not contain the extension, making the IPAddrblock extension unusable under such CAs. By limiting the validation depth, only a certain level of issuer certificates are validated for proper IPAddrblock extensions: A depth of 0 does not check any issuer certificate extensions, a depth of 1 only the direct issuer of the end entity certificate is checkend, and so on.

strict

yes

If set to yes, a subject certificate without an IPAddrblock extension is rejected if the issuer certificate posesses an IPAddrblock extension extension. If set to no, subject certificates issued without the IPAddrblock extension are accepted without any traffic selector checks and no policy is enforced by the plugin.

Example

The VPN peer sun doesn’t know the IPv4 subnet behind the VPN peer moon nor its IPv4 host address:

connections {
   host {
      local {
         auth = pubkey
         certs = sunCert.pem
         id = sun.strongswan.org
      }
      remote {
         auth = pubkey
         id = moon.strongswan.org
      }
      children {
         net {
            local_ts  = 10.2.0.0/16
         }
      }
   }
}

Peer moon initiates an IPsec connection to peer sun and establishes both a host CHILD SA as well as a net CHILD SA

15[IKE] checking certificate-based traffic selector constraints [RFC 3779]
15[IKE]   TS 192.168.0.1/32 is contained in address block constraint 192.168.0.1/32 (subset 192.168.0.1/32)
15[IKE] CHILD_SA host{1} established with SPIs c74e3018_i c6d3f865_o and TS 192.168.0.2/32 === 192.168.0.1/32

Because moon uses the IPv4 host address as defined in the certificate the host CHILD SA` succeeds.

16[IKE] checking certificate-based traffic selector constraints [RFC 3779]
16[IKE]   TS 10.0.0.0/14 is contained in address block constraint 10.1.0.0/16 (subset 10.1.0.0/16)
16[IKE] CHILD_SA net{2} established with SPIs ca758282_i c83f2e49_o and TS 10.2.0.0/16 === 10.1.0.0/16

The peer proposes a much larger subnet 10.0.0.0/14 but it is automatically narrowed by sun to the subnet 10.1.0.0/16 defined in the certificate.

In another connection attempt moon proposes a 10.5.0.0/16 network not covered by the IPaddrBlock extension of the moon certificate

16[IKE] checking certificate-based traffic selector constraints [RFC 3779]
16[IKE]   TS 10.5.0.0/16 is not contained in any address block constraint
16[IKE] no acceptable traffic selectors found
16[IKE] failed to establish CHILD_SA, keeping IKE_SA

so the establishment of the CHILD SA fails.

topology
Figure 1. strongSwan example showing the use of the addrblock plugin