Subject: [tsvwg] L4S interaction with tunnel anti-replay

From: "Black, David" <[email-masked]>
Date: Wed, 16 Feb 2022 22:33:46 +0000

This is a follow-up to the discussion of tunnel anti-reply during the meeting earlier today.  This topic is the first bullet on the second slide that I used for L4S at IETF 111 (https://datatracker.ietf.org/meeting/111/materials/slides-111-tsvwg-sessb-31-a-l4s-issues-00 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/111/materials/slides-111-tsvwg-sessb-31-a-l4s-issues-00__;!!LpKI!zVBRipbLjaAbYig1ZebG8gLPYfURQ9_feiG5u8XtqBrgoEcpPeRPs3Di5te1z0pk$>):

* Creates DoS (Denial-of-Service) vulnerability in some tunnels
* Attacker advances replay protection window by sending low-latency traffic
* Conventional traffic arrives after window has advanced, gets discarded

As was suggested in the meeting, Section 6.2 of the ecn-l4s-id draft (https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-24#section-6.2) appears to cover this area well (in my opinion).

I have a few suggestions.

[A] This text at the end of the first paragraph:

   The specifications

   of IPsec AH [RFC4302<https://datatracker.ietf.org/doc/html/rfc4302>] and ESP [RFC4303<https://datatracker.ietf.org/doc/html/rfc4303>] suggest that an implementer

   scales the size of the anti-replay window with interface speed, and

   the current draft of DTLS 1.3 [I-D.ietf-tls-dtls13<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-24#ref-I-D.ietf-tls-dtls13>] says "The

   receiver SHOULD pick a window large enough to handle any plausible

   reordering, which depends on the data rate."  However, in practice,

   the size of a VPN's anti-replay window is not always scaled

   appropriately.

ought to be accompanied by an observation that mixing L4S and Classic packets in the same VPN
tunnel is likely to require a larger scale anti-replay window because that configuration introduces
additional potential/plausible re-ordering.

[B] This last resort measure would benefit from some clarification:

OLD

      -  configure the tunnel ingress not to propagate ECN to the outer,

         which would lose the benefits of L4S and Classic ECN over the

         VPN.

NEW

      -  configure the tunnel ingress not to propagate ECN to the outer

         IP header, i.e., set the ECN field to Not-ECT in all outer IP

         headers, which would give up any benefits of L4S differentiation

         from Classic ECN over the VPN.

[C] Somewhere, but not in section 6.2 (perhaps in section 7), there ought to be an if-all-else-fails
statement to the effect that if things go seriously awry, cease/disable experimental usage of L4s.

Thanks, --David

David L. Black, Sr. Distinguished Engineer, Technology & Standards
Infrastructure Solutions Group, Dell Technologies
mobile +1 978-394-7754 [email-masked]<mailto:[email-masked]>