summaryrefslogtreecommitdiffstats
path: root/net/core/neighbour.c
diff options
context:
space:
mode:
authorPaul Moore <paul.moore@hp.com>2007-12-21 14:59:08 -0800
committerDavid S. Miller <davem@davemloft.net>2008-01-28 15:00:02 -0800
commite1af9f270b69a3ad1dcbabb404dd1f40a96f43f5 (patch)
tree8dc77b5c842a517d0d19bba835897846f77ec647 /net/core/neighbour.c
parentafeb14b49098ba7a51c96e083a4105a0301f94c4 (diff)
downloadop-kernel-dev-e1af9f270b69a3ad1dcbabb404dd1f40a96f43f5.zip
op-kernel-dev-e1af9f270b69a3ad1dcbabb404dd1f40a96f43f5.tar.gz
[XFRM]: Drop packets when replay counter would overflow
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@hp.com> Acked-by: James Morris <jmorris@namei.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/core/neighbour.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud