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

["Black, David" <[e-mail]>]

I'm sorry Magnus, but I'm going to be blunt.

For IPsec tunnels, there appears to be both "rough consensus" (RFC 4301) and "running code" (e.g., strongSwan VPN) to address this problem for DSCP-caused reordering.

The message below appears to regard both as irrelevant.  I don't understand why - would you please explain?

Thanks, --David

-----Original Message-----
From: Magnus Westerlund <[e-mail]> 
Sent: Tuesday, May 18, 2021 8:33 AM
To: [e-mail]; Black, David
Subject: Re: [tsvwg] L4S & VPN anti-replay interaction: Explanation

Hi,

I think I have read through all the relevant discussion of this issue. I have to
agree with Bob Briscoe that this is a general issue for tunneling protocols that
have several properties:

 - Any form of replay protection with a window shorter than produced reordering 
   (e.g. IPsec) or have a reordering restoring functionality (e.g. L2TP).
 - Marks through ECN and/or DSCP.
 - Aggregate multiple sub-flows

These tunnels will exhibit issues either resulting in packet loss (replay
protection) or additional delay (to cancel out the reordering) when the tunnel
flow are going through some type of queue that will cause reordering, i.e. when
sufficiently loaded to have any queue buildup to reorder around. 

Any forwarding impacting technologhy that would cause subflows to be subject to
improved performance compared to other flows will trip over this issue. That is
clear based on the significant discussion of this related to diffserv in IPsec
RFC 4301, and Section 4.1 in RFC 2983 (
https://datatracker.ietf.org/doc/html/rfc2983#section-4.1).

From my perspective we can't halt progress towards improved performance based on
this general problem. We should mitigate and inform about the issue. However, I
think part of the burden here long term will need to be put on the tunnels that
exhibit the above properties. They need to track development in network
technologies to stay current. It is clear that tunnels that handles this by
correctly classifying the subflows before aggregation and put them in tunnels
with same type of forwarding performance will not suffer. The alternative
solution is to avoid the mark through seperation and loose the potential benefit
if encountering a queue where differentation could have been done. But that
requires the pipe style handling on egress to correctly preserve the ECN
information for L4S, just as it does for DSCP field. And thirdly, if ones replay
protection is reasonably scaled with experienced jitter and tunnel throughput
rates this would also not be a significant issue. 

Thus my opinion is that in the L4S context we need to document this impact. Link
to solutions or mitigations that can be applied and potential push for updates
on important affected specifications, like IPsec. 

Cheers

Magnus Westerlund