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

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

Magnus,

Thanks for the prompt explanation.

> My intention was to state that the same approach of addressing the issue for L4S
> ECN as for DSCP appear to be appropriate. However, to me that appears to mean
> that L4S would document the issue and point to similar approaches of handling or
> mitigation like for DSCP. To my understanding, the better approach of using two
> SAs after L4S aware subflow classifier in tunnel ingress, alternatively to
> downgrade the pipe segment the tunnel represents to not enable L4S treatment and
> recover the L4S on egress from the inner ECN markings. But, it does imply that
> tunnel implementations have some work to do. I recognize that guard DSCP would
> simplify that process to likely just a configuration change for implementation
> already capable of using sets of DSCP to SA mappings.

I generally agree with the above paragraph.  The crucial takeaway from my vantage
point is that IPsec has addressed this problem for Diffserv DSCPs.  FWIW,  the RFC 2983
text that I wrote likely contributed to the RFC 4301 provisions that address this problem,
so this is a familiar area.

I do hope that there will be no further attempts to argue that Diffserv interaction with
IPsec anti-replay is an unaddressed problem.

Thanks, --David

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

On Tue, 2021-05-18 at 14:01 +0000, Black, David wrote:
> 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?

Okay, I must have expressed myself poorly. That you should arrive at the above
interpretation was definitely not my intention. 

My intention was to state that the same approach of addressing the issue for L4S
ECN as for DSCP appear to be appropriate. However, to me that appear to mean
that L4S would document the issue and point to similar approaches of handling or
mitiagation like for DSCP. To my undestanding, the better approach of using two
SAs after L4S aware subflow classifyier in tunnel ingress, alternatively to
downgrade the pipe segment the tunnel represents to not enable L4S treatment and
recover the L4S on egress from the inner ECN markings. But, it does imply that
tunnel implementations have some work to do. I recognize that guard DSCP would
simplify that process to likely just a configuration change for implementation
already capable of using sets of DSCP to SA mappings. 

I think a third way of dealing with this issue is adaptive scaling of the replay
protection window in the egress side of the tunnels. This maybe anyway is needed
based on the increase bandwidth, the changes in what lower layers are and how
they behave and on what level they preserve order. 

I think the core of my thinking is that this type of tunnels that has the
properties that I expressed are going to be impacted by any change in forwarding
behaviors that impacts packet priority or path when being forwarded through the
network. L4S do redefine in some sense what the flow selectors are when
forwarding packets. This, has to no surprise some cross area impact. The WG have
been discussing these impacts and there cost and severity for a while now. I
think describing this one and its handling appear fairly straightforward. So I
suggest that we continue on writing up the issue and its handling. The severity
and impact discussion can go on in parallel. I do want to arrive at the point
where the L4S related specifications are in good enough state that we can
actually see where the IETF wide consensus on this really stands. 

Cheers

Magnus


> 
> 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
> 
>