| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
RFC 4303 reserves the SPIs between 1 and 255 for future use. This also
avoids an overflow and a division by zero if spi_min is 0 and spi_max is
0xffffffff.
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #2252.
|
|
|
|
| |
Fixes #2172.
|
|
|
|
| |
Fixes #2118.
|
| |
|
|
|
|
|
|
| |
We already do this for the other kernel interfaces.
Fixes e1e88d5adde0 ("libipsec: Don't attempt deletion of any non-IPsec policies")
|
|
|
|
|
|
|
|
| |
An example are the fallback drop policies installed when updating SAs.
We ignore such policies in add_policy() so there is no point in attempting
to remove them. Since they use different priorities than regular policies
this did not result in policies getting deleted unintentionally but there
was an irritating log message on level 2 that indicated otherwise.
|
|
|
|
|
|
|
|
| |
Since we don't use the kernel-netlink plugin anymore and the headers
in the NDK are reasonably recent, we don't need this anymore (at least
when building the app).
Fixes #1172.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the nonce, the ESP key material is four bytes longer than needed for
the actual AES key. The crypto plugins, however, register their AES-CTR
implementations with the AES key length, so the lookup here failed.
For IKEv2 the key material is allocated after creating a crypter instance
with the negotiated AES key size. The length of the actual key material is
retrieved via get_key_size(), which adds the four bytes to the AES key length.
Fixes #1124.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This was useful for testing purposes of RADIUS accounting, but OS kernels
generally will use the latest SA, so we do the same.
|
|
|
|
|
|
| |
Real AEADs directly provide a suitable IV generator, but traditional crypters
do not. For some (stream) ciphers, we should use sequential IVs, for which
we pass an appropriate generator to the AEAD wrapper.
|
|
|
|
|
| |
Similar to other kernel interfaces, the libipsec backends uses the flag for
different purposes, and therefore should get separate flags.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The IPv6 length field denotes the payload length after the 40 bytes header.
Fixes: 293515f95cf5 ("libipsec: remove extra RFC4303 TFC padding appended to inner payload")
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
The salt, or often called implicit nonce, varies between AEAD algorithms and
their use in protocols. For IKE and ESP, GCM uses 4 bytes, while CCM uses
3 bytes. With TLS, however, AEAD mode uses 4 bytes for both GCM and CCM.
Our GCM backends currently support 4 bytes and CCM 3 bytes only. This is fine
until we go for CCM mode support in TLS, which requires 4 byte nonces.
|
| |
|
| |
|
| |
|
|
|
|
| |
This prevents duplicate sequential IVs in case of a HA failover.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
To prevent a client from sending a packet with a source address of a different
client, we require a policy bound via reqid to the decapsulating SA.
|
|
|
|
|
|
|
|
|
|
| |
The flag is required to convince libtool on Cygwin to build DLLs. But on
Windows these shared libraries can not have undefined symbols, so we have to
link them explicitly to the libraries they reference.
For plugins this is currently not done, so only the monolithic build is
supported. The plugin loader wouldn't be able to load DLLs anyway, as
it tries to load files that don't exist on Cygwin.
|
| |
|
|
|
|
| |
Closes #377.
|
|
|
|
|
|
| |
INCLUDES are now deprecated and throw warnings when using automake 1.13.
We now also differentiate AM_CPPFLAGS and AM_CFLAGS, where includes and
defines are passed to AM_CPPFLAGS only.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new flag gives the kernel-interface a hint how it should priorize the
use of newly installed SAs during rekeying.
Consider the following rekey procedure in IKEv2:
Initiator --- Responder
I1 -------CREATE-------> R1
I2 <------CREATE--------
-------DELETE-------> R2
I3 <------DELETE--------
SAs are always handled as pairs, the following happens at the SA level:
* Initiator starts the exchange at I1
* Responder installs new SA pair at R1
* Initiator installs new SA pair at I2
* Responder removes old SA pair at R2
* Initiator removes old SA pair at I3
This makes sure SAs get installed/removed overlapping during rekeying. However,
to avoid any packet loss, it is crucial that the new outbound SA gets
activated at the correct position:
* as exchange initiator, in I2
* as exchange responder, in R2
This should guarantee that we don't use the new outbound SA before the peer
could install its corresponding inbound SA.
The new parameter allows the kernel backend to install the new SA with
appropriate priorities, i.e. it should:
* as exchange inititator, have the new outbound SA installed with higher
priority than the old SA
* as exchange responder, have the new outbound SA installed with lower
priority than the old SA
While we could split up the SA installation at the responder, this approach
has another advantage: it allows the kernel backend to switch SAs based on
other criteria, for example when receiving traffic on the new inbound SA.
|