Re: [tsvwg] L4S & VPN anti-replay interaction: Explanation

[Bob Briscoe <[e-mail]>]

David,

On 11/05/2021 15:56, Black, David wrote:
>
> This message is the explanation of the interaction of L4S and VPN 
> anti-replay that I promised to send during the interim meeting 
> yesterday.  I'm writing (explaining) as an individual, not as a WG chair.
>
> This explanation is for IPsec VPNs, although it applies in principle 
> to any VPN that propagates the ECN field to outer IP headers.
>
> For IPsec, the primary RFCs involved are RFC 4301 (IPsec architecture, 
> https://datatracker.ietf.org/doc/rfc4301/ 
> <https://datatracker.ietf.org/doc/rfc4301/>) and RFC 4303 (ESP – 
> Encapsulating Security Payload, 
> https://datatracker.ietf.org/doc/rfc4303/ 
> <https://datatracker.ietf.org/doc/rfc4303/>).  RFC 4302 (AH – 
> Authentication Header, https://datatracker.ietf.org/doc/rfc4302/ 
> <https://datatracker.ietf.org/doc/rfc4302/>) was mentioned in 
> discussion, but that RFC is not generally applicable to VPNs because 
> AH does not encrypt its payload. As a result, this explanation focuses 
> on ESP anti-replay functionality, as specified in Section 3.4.3 of RFC 
> 4303 (https://datatracker.ietf.org/doc/html/rfc4303#section-3.4.3 
> <https://datatracker.ietf.org/doc/html/rfc4303#section-3.4.3>). This 
> explanation also assumes a tunnel-mode IPsec VPN, where the outer IP 
> header is applied and removed by the VPN sender and receiver.  
> Tunnel-mode is a common configuration, as it separates VPN IP 
> addressing (in inner IP headers) from Internet IP addressing (in outer 
> IP headers).
>

[BB] The reason I focused on AH is that replay attacks are a lot harder 
to mount when blind (i.e. when traffic is encrypted). But I accept that 
replay protection is normally used on encrypted VPNs, whether or not the 
replay protection is actually necessary. Then of course the ESP VPN is 
prone to this interaction. But AH exhibits the more difficult tradeoff, 
because it's more critical to keep replay protection enabled.

> Here's a simplified summary of how ESP anti-replay works:
>
>   * The VPN sender numbers each packet with a sequence number that is
>     incremented for each packet.
>   * The VPN receiver uses a sliding sequence number window to
>     scoreboard (track) which packets have been received and reject
>     duplicates.
>       o There's a bit per packet within the window that indicates
>         whether that packet has been received.
>       o The scoreboard is initialized with all bits cleared to '0'.
>         Setting a bit to '1' indicates that the corresponding packet
>         has been received.
>   * Receipt of a packet whose sequence number is within the sliding
>     window causes the VPN receiver to check the bit for that sequence
>     number:
>       o If that bit is already set to '1', the packet is a duplicate
>         and is discarded.
>       o If that bit is cleared to '0', that bit is set to '1' and the
>         packet is processed and forwarded.
>   * Receipt of a packet whose sequence number is larger than the range
>     covered by the sliding window causes the window to advance to
>     include that sequence number (clearing new scoreboard bits to
>     '0'), and then proceeds as above because the packet's sequence
>     number is within the window after the advance.
>       o The packet sequence number is included in ESP crypto
>         computations, so rogue packets injected by an attacker who
>         does not know the relevant VPN key(s) are discarded without
>         advancing the window.
>   * Receipt of a packet with a sequence number less than the range
>     covered by the window always causes the packet to be discarded.
>   * Here's the entire paragraph on scoreboard window size (last
>     paragraph in Section 3.4.3 of RFC 4303):
>
>             A minimum window size of 32 packets MUST be supported when 32-bit
>             sequence numbers are employed; a window size of 64 is preferred and
>             SHOULD be employed as the default.  Another window size (larger than
>             the minimum) MAY be chosen by the receiver.  (The receiver does NOT
>             notify the sender of the window size.)  The receive window size
>             should be increased for higher-speed environments, irrespective of
>             assurance issues.  Values for minimum and recommended receive window
>             sizes for very high-speed (e.g., multi-gigabit/second) devices are
>             not specified by this standard.
>
>   * Prior discussion on this list indicates that the 32 and 64 window
>     size values are present in some running code, at least as defaults.
>
> L4S can exhibit undesirable interactions with ESP anti-replay based 
> only on ECT(0) and ECT(1) in the outer headers as follows:
>
>  1. Simultaneously send L4S flows (ECT(1) in ECN field) and Classic
>     flows (ECT(0) in ECN field) through the same VPN.
>  2. The VPN sender assigns in-order sequence numbers to the packets
>     independent of which type of flow they belong to.
>  3. The VPN sender propagates the ECN field in each packet to the
>     outer IP header, as required by the tables in Sections 5.1.2.1 and
>     5.1.2.2 of RFC 4301.
>  4. One or more network node bottlenecks between the VPN sender and
>     receiver apply L4S treatment to the L4S ECT(1) packets, causing
>     them to advance past some Classic ECT(0) packets.
>
> At the VPN receiver, the received L4S packets drive advancing the 
> sliding window to higher sequence numbers.  If the sequence numbers in 
> the arriving L4S packets get ahead of the sequence numbers in the 
> arriving Classic packets by the size of the sliding window or more, 
> the arriving Classic packets are dropped *even though they are not 
> duplicates* (!).
>
> The problem arises at step 1 – mixing L4S and non-L4S traffic in the 
> same VPN.  IPsec has addressed the analogous problem for Diffserv by 
> requiring (MUST) support of multiple VPN sessions (which IPsec calls 
> Security Associations, SAs) between the same endpoints, and strongly 
> recommending (SHOULD) that traffic in different Diffserv classes use 
> different SAs (RFC 4301, Section 4.1, paragraph spanning pp.13-14).
>

[BB] In the thread where Sebastian first pointed out this interaction, I 
asked if you knew how prevalent it is for IPsec implementations to 
follow that SHOULD. Indeed, are you aware of any implementations at all 
that follow it?

You might have noticed the Cisco troubleshooting guide I found about how 
to remedy Diffserv interacting with replay-protection, which implies 
that the different DSCPs do not always have separate SAs:
https://www.cisco.com/c/en/us/support/docs/ip/internet-key-exchange-ike/116858-problem-replay-00.html

It occurs to me that multiple application sessions can come and go 
within a VPN. So it might be some time after the set up of a VPN when an 
application is launched that starts to use different DSCPs within the 
VPN. The VPN would not have known this in advance, so then it would have 
to set up a new SA on the fly. Then it would have to either buffer or 
discard the new Diffserv packets while it did the new key exchange.

Seems unlikely that an implementer would have gone to all this trouble, 
rather than just using one SA, which is allowed by the SHOULD in the spec.
It strikes me that this SHOULD in RFC4301 might be easy to say but 
infeasible to implement.

On a host with an L4S CC enabled, a VPN would never need more than two 
SAs for the two types of ECN. So it would be more feasible to ensure 
that a VPN sets up two SAs in advance (for ECT1 or NotECT&ECT0). But 
that would require an L4S-specific patch to the VPN code. That would be 
do-able but probably only reasonable to expect it to be officially 
maintained in a VPN if L4S one day became standards track. And by then 
ECT0 might be on the decrease anyway.


> At least two incorrect assertions have been made about IPsec 
> anti-replay in list discussion and/or in the interim meeting:
>
>   * The undesirable anti-replay interaction is neither specific to nor
>     caused by L4S.
>       o That is incorrect because RFC 4301 has addressed the
>         anti-replay interaction for Diffserv.  In contrast, L4S is new
>         wrt RFC 4301.
>

[BB] Correct, RFC4301 doesn't ask for ECT1 to be in a separate SA 'cos 
(obviously) L4S didn't exist when 4301 was written.

But that first sentence ("RFC 4301 has addressed the anti-replay 
interaction for Diffserv") might not be the whole story, if the SHOULD 
is infeasible to implement (see above).

>      o
>
>
>   * The undesirable anti-replay interaction only occurs if CE marks
>     are present in some of the packets involved.
>       o This is incorrect because ECT(0) and ECT(1) values in the ECN
>         field suffice to create the problem, see above.
>

[BB] Correct (if ECT0 and ECT1 are in the same SA).

I was thinking of the corner-case where the VPN ingress places ECT1 into 
a separate SA, but there are multiple bottlenecks between the two ends 
of the VPN as in the unlikely CE reordering problem with L4S discussed 
before:
1. VPN ingress
2. Classic ECN AQM
3. L4S DualQ AQM
4. VPN egress

If both AQMs are simultaneously bottlenecked (unusual) then, any ECT0 
packets that the Classic AQM marks as CE will be classified into the L4S 
queue of the DualQ, along with the packets in the ECT1 SA. Then replay 
protection in the VPN egress could drop some Classic traffic.


> I'll close by noting that if L4S flows carried a DSCP that differed 
> from Classic flows, that would enable a "reduce to previous case" line 
> of reasoning (yes, I used to be a mathematician) that reuses the IPsec 
> provisions for Diffserv to address this anti-replay interaction with 
> L4S.  That reuse won't prevent all reordering-caused anti-replay 
> problems that could occur, but it would take advantage of 
> existing/known techniques for dealing with them.
>

[BB] That would only make a difference if the VPN actually implemented 
separating DSCPs into separate SAs (which I questioned earlier).
It might be as feasible for the VPN to separate ECT1 into a separate SA, 
as discussed earlier.



Bob

> Thanks for reading this far, --David
>
> *David L. Black, *Sr. Distinguished Engineer, Technology & Standards
>
> Infrastructure Solutions Group,*Dell Technologies*
>
> mobile [phone] [e-mail] <mailto:[e-mail]>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/