The IPv6 length field denotes the payload length after the 40 bytes header.
Fixes: 293515f95c ("libipsec: remove extra RFC4303 TFC padding appended to inner payload")
We assume that a responder is behind a static NAT (e.g. port forwarding)
and allow remote address updates in such situations.
The problem described in RFC 5996 is only an issue if the NAT mapping
can expire.
This allows accessing the guests with `virsh console <name>`.
Using a serial console would also be possible but our kernel configs
have no serial drivers enabled, CONFIG_VIRTIO_CONSOLE is enabled though.
So to avoid having to recompile the kernels let's do it this way, only
requires rebuilding the guest images.
References #729.
Any interval returned by the RADIUS server in the Access-Accept message
overrides the configured interval. But it might be useful if RADIUS is
only used for accounting.
The maximum for IKEv1 is already 255 due to the 8-bit fragment number.
With an overhead of 17 bytes (x64) per fragment and a default maximum
of 10000 bytes per packet the maximum memory required is 14 kB
for a fragmented message.
For instance, if a DPD exchange is initiated by the gateway when a
mobile client is roaming and it then gets a new IP address and sends
an address update via MOBIKE, the DPD retransmits would still be sent
to the old address and the SA would eventually get closed.
The message() hook on bus_t is now called exactly once before (plain) and
once after fragmenting (!plain), not twice for the complete message and again
for each individual fragment, as was the case in earlier iterations.
For inbound messages the hook is called once for each fragment (!plain)
and twice for the reassembled message.
The comment indicated this but it was always set anyway. All internal
commands are called via their absolute paths, so the script only uses PATH for
the uname command, but if that is not located in one of the configured
directories the script will fail.
Also, since the internal commands are called via their absolute paths there is
no need to add the directories to PATH.
At the time we reset an IKE_SA (e.g. when re-authenticating a not yet
established SA due to a roaming event) such tasks might already be queued
by one of the phase 1 tasks. If the SA is initiated again another task will
get queued by the phase 1 task. This results in e.g. multiple mode config
requests, which most gateways will have problems with.
The scenarios will work with new or old base images as long as the version
in use is included as product in the master data (src/libimcv/imv/data.sql).
The tkm scenarios recently failed due to a segmentation fault on my host
because I had an old build of the tkm library already built in the build
directory. Because the stamp file was not versioned the new release was
never checked out or built and charon-tkm was linked against the old
version causing a segmentation fault during key derivation.
This reverts commit 3293d14628.
The position of tasks in the queue does not actually determine the order
in which they are activated. Instead this is determined by the
statements in task_manager_v2_t.initiate().
This allows to (relatively) quickly (re-)build and install the current
or an arbitrary strongSwan source tree within the root image.
bindfs is used to bind mount the source directory using the regular user
and group (only works if sudo is used to run the script) so that newly
created files are not owned by root.
As with building the root image in general the guests must not be
running while executing this script. The guest images are automatically
rebuilt after the root image has been updated so configuration files and
other modifications in guests will be lost.
We don't expect a response with the same MID, but apparently some
devices (e.g. FRITZ!Box) do that for DPDs, while still treating the
response as a new exchange. By storing the last message block as IV
we can't decrypt the first block of such a response.
Fixes#661.
While the examples in RFC 2408 show proposal numbers starting at 1 and
increasing by one for each subsequent proposal this is not mandatory.
Actually, IKEv1 proposals may start at any number, the only requirement
is that the proposal numbers increase monotonically they don't have to
do so consecutively.
Most implementations follow the examples and start numbering at 1 (charon,
racoon, Shrew, Cisco, Windows XP, FRITZ!Box) but pluto was one of the
implementations that started with 0 and there might be others out there.
The previous assumption that implementations always start numbering proposals
at 0 caused problems with clients that start numbering with 1 and whose first
proposal consists of multiple protocols (e.g. ESP+IPComp).
Fixes#661.
This might not be the case if e.g. an address appeared but the old one
is still available but not actually usable. Without this the MOBIKE
task would eventually time out even though we might be able to switch
to a working address.
Because we only queue one MOBIKE task at a time, but destroy superfluous
ones only after we already increased the counter for pending MOBIKE updates,
we have to reduce the counter when such tasks are destroyed. Otherwise, the
queued task would assume another task is queued when it is running and
ignore any successful response.
Tobias Brunner