[PATCH 2/2] XFRM: Drop packets when replay counter would overflow
David Miller
davem at davemloft.net
Fri Dec 21 22:59:16 UTC 2007
From: Paul Moore <paul.moore at hp.com>
Date: Fri, 21 Dec 2007 09:15:00 -0500
> According to RFC4303, section 3.3.3 we need to drop outgoing packets which
> cause the replay counter to overflow:
>
> 3.3.3. Sequence Number Generation
>
> The sender's counter is initialized to 0 when an SA is established.
> The sender increments the sequence number (or ESN) counter for this
> SA and inserts the low-order 32 bits of the value into the Sequence
> Number field. Thus, the first packet sent using a given SA will
> contain a sequence number of 1.
>
> If anti-replay is enabled (the default), the sender checks to ensure
> that the counter has not cycled before inserting the new value in the
> Sequence Number field. In other words, the sender MUST NOT send a
> packet on an SA if doing so would cause the sequence number to cycle.
> An attempt to transmit a packet that would result in sequence number
> overflow is an auditable event. The audit log entry for this event
> SHOULD include the SPI value, current date/time, Source Address,
> Destination Address, and (in IPv6) the cleartext Flow ID.
>
> Signed-off-by: Paul Moore <paul.moore at hp.com>
Applied.
More information about the Linux-audit
mailing list