Save latest ESP sequence number even if replay protection isn't in use

Save latest ESP sequence number even if replay protection isn't in use

In the current source, incoming ESP sequence numbers
(vpninfo->esp_in[vpinfo->current_esp_in].seq) are not actually tracked at
all unless replay protection is in use.

At the time of a rekey, old_esp_maxseq is *set based on the current value of
the incoming seq* at the time of the switchover:

    if (new_keys) {
        vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;

And then esp.c rejects packets with the old incoming SPI, unless seqp < old_esp_maxseq:

    } else if (pkt->esp.spi == old_esp->spi &&
               ntohl(pkt->esp.seq) + esp->seq < vpninfo->old_esp_maxseq) {
            vpn_progress(vpninfo, PRG_TRACE,
                         _("Consider SPI 0x%x, seq %u against outgoing ESP setup\n"),
                         (unsigned)ntohl(old_esp->spi), (unsigned)ntohl(pkt->esp.seq));
            if (decrypt_esp_packet(vpninfo, old_esp, pkt))
                    continue;

This code is supposed to allow a smooth handover from the old incoming SPI
to the new one after a rekey, so that in-flight packets from the old SPI
aren't totally dropped, but also aren't allowed to continue forever.

This patch tracks the latest sequence number even if ESP replay protection
isn't in use -- however inadvisable that may be -- allowing the handover to
work correctly.

This patch also improves the confusing trace message shown when a packet
from the old SPI is received.

[dwmw2: Just call verify_packet_seqno() every time, and let it return an
        artificial 'success' when replay protection is turned off. Also
        add changelog entry.]

Signed-off-by: Daniel Lenski <dlenski@gmail.com>
Signed-off-by: David Woodhouse <dwmw2@infradead.org>