• Daniel Lenski's avatar
    Save latest ESP sequence number even if replay protection isn't in use · 4daac3fa
    Daniel Lenski authored
    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))
    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: default avatarDaniel Lenski <dlenski@gmail.com>
    Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
openssl-esp.c 7.01 KB