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

[Jonathan Morton <[e-mail]>]

> On 18 May, 2021, at 2:51 am, Bob Briscoe <[e-mail]> wrote:
> 
>> 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. 

The easy way out of this, for tunnel-mode SAs, is to maintain the same DSCP on all outer headers belonging to the same SA.  This permits it to establish fewer SAs between a host pair (typically 1) than the number of DSCPs that might theoretically be encountered (always 64).  Since middleboxes on the tunnel path will only see the outer header, they won't then reorder packets based purely on the DSCP, and no systematic DoS attack against the replay window can be mounted via the DSCP field.

I'd appreciate data on whether IPsec implementations take this approach in practice.

L4S does not have recourse to this approach, because the ECT(1) codepoint is the only identifier informing middleboxes that high-fidelty CE marking is expected rather than RFC-3168 marking.  The only thing that *could* safely be done here is to revert the ECN field to Not-ECT on tunnelled L4S packets.  That seems like rather a retrograde step, and the vulnerability would still exist with respect to non-participating users who are still using an existing RFC-3168 compliant VPN, that preserves the ECN field of the inner packet on the outer header.

 - Jonathan Morton