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

[Magnus Westerlund <[e-mail]>]

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