I still think ipsec/l2tp with fragmentation support is a useful
fallback option in case the Windows IKEv2 connection fails because
of fragmentation problems.
Tested with Windows XP, 7 and 8.1.
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.
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.
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().
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.
Martin Willi