Bug 76791 - Problem with esp sequence and anti-replay window logic.
Summary: Problem with esp sequence and anti-replay window logic.
Status: NEW
Alias: None
Product: Networking
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-23 07:22 UTC by Bhargav
Modified: 2014-05-23 07:22 UTC (History)
0 users

See Also:
Kernel Version: 2.6.34
Subsystem:
Regression: No
Bisected commit-id:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Bhargav 2014-05-23 07:22:47 UTC 
Hi,

As the esp sequence number is a 32 bit field in the ESP packet, the maximum sequence number could be 4294967295 [as 2^32 is 4294967296], then after the sender will send the esp sequence starting from 1 again.

Lets say a scenario, if there is a huge traffic continously and the esp sequence number reaches the maximum, and for the next packets the esp sequence will be 1. 
The highest sequence number received will be 4294967295.

But the anti-replay logic will check the difference of the highest sequence number  till that time and the sequence number of the received packet. In this case the difference  will be greater than the replay window size. There is a chance of dropping of packets.

Seems it is a bug. Do we have to fix the anti-replay window to cycle the highest sequence like the sender is doing for the esp sequence number?

Thanks,
Bhargav
Note You need to log in before you can comment on or make changes to this bug.