[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    [IPsec] RFC 4303 ESN and replay protection entanglement
From:       Tero Kivinen <kivinen () iki ! fi>
Date:       2024-01-09 14:53:15
Message-ID: 26013.24027.408270.509935 () fireball ! acr ! fi
[Download RAW message or body]

Paul Wouters writes:
> In RFC 4303 Section 3.3.3 states:
> 
>     Note: If a receiver chooses to not enable anti-replay for an SA, then
>     the receiver SHOULD NOT negotiate ESN in an SA management protocol.
>     Use of ESN creates a need for the receiver to manage the anti-replay
>     window (in order to determine the correct value for the high-order
>     bits of the ESN, which are employed in the ICV computation), which is
>     generally contrary to the notion of disabling anti-replay for an SA.

This is SHOULD, not a MUST. You do have good reason to do ESN even
with anti-replay turned off if your link speeds are that fast, so
simply negotiate ESN, and implement your window code in such way that
it can keep track of ESN window even when the anti-replay is turned
off. 

I agree that this advise is bad, as ESN is enabled by the sender, but
anti-replay is property of the receiver, thus there is no way of
sender to know whether other end enables or disables the anti-replay.
-- 
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic