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

[Sebastian Moeller <[e-mail]>]

Hi Bob,


> On May 18, 2021, at 01:51, Bob Briscoe <[e-mail]> wrote:
> 
> David,
> 
> On 11/05/2021 15:56, Black, David wrote:
>> This message is the explanation of the interaction of L4S and VPN anti-replay that I promised to send during the interim meeting yesterday.  I'm writing (explaining) as an individual, not as a WG chair.
>>  
>> This explanation is for IPsec VPNs, although it applies in principle to any VPN that propagates the ECN field to outer IP headers.
>>  
>> For IPsec, the primary RFCs involved are RFC 4301 (IPsec architecture, https://datatracker.ietf.org/doc/rfc4301/) and RFC 4303 (ESP – Encapsulating Security Payload, https://datatracker.ietf.org/doc/rfc4303/).  RFC 4302 (AH – Authentication Header, https://datatracker.ietf.org/doc/rfc4302/) was mentioned in discussion, but that RFC is not generally applicable to VPNs because AH does not encrypt its payload.  As a result, this explanation focuses on ESP anti-replay functionality, as specified in Section 3.4.3 of RFC 4303 (https://datatracker.ietf.org/doc/html/rfc4303#section-3.4.3).  This explanation also assumes a tunnel-mode IPsec VPN, where the outer IP header is applied and removed by the VPN sender and receiver.  Tunnel-mode is a common configuration, as it separates VPN IP addressing (in inner IP headers) from Internet IP addressing (in outer IP headers).
> 
> [BB] The reason I focused on AH is that replay attacks are a lot harder to mount when blind (i.e. when traffic is encrypted). But I accept that replay protection is normally used on encrypted VPNs, whether or not the replay protection is actually necessary. Then of course the ESP VPN is prone to this interaction. But AH exhibits the more difficult tradeoff, because it's more critical to keep replay protection enabled.

	[SM] Do you have references for cryptography papers supporting that view that replay protection is more important for AH than ESP? 

> 
>>  
>> Here's a simplified summary of how ESP anti-replay works:
>> 	• The VPN sender numbers each packet with a sequence number that is incremented for each packet.
>> 	• The VPN receiver uses a sliding sequence number window to scoreboard (track) which packets have been received and reject duplicates.
>> 		• There's a bit per packet within the window that indicates whether that packet has been received.
>> 		• The scoreboard is initialized with all bits cleared to '0'.  Setting a bit to '1' indicates that the corresponding packet has been received.
>> 	• Receipt of a packet whose sequence number is within the sliding window causes the VPN receiver to check the bit for that sequence number:
>> 		• If that bit is already set to '1', the packet is a duplicate and is discarded.
>> 		• If that bit is cleared to '0', that bit is set to '1' and the packet is processed and forwarded.
>> 	• Receipt of a packet whose sequence number is larger than the range covered by the sliding window causes the window to advance to include that sequence number (clearing new scoreboard bits to '0'), and then proceeds as above because the packet's sequence number is within the window after the advance.
>> 		• The packet sequence number is included in ESP crypto computations, so rogue packets injected by an attacker who does not know the relevant VPN key(s) are discarded without advancing the window.
>> 	• Receipt of a packet with a sequence number less than the range covered by the window always causes the packet to be discarded.
>> 	• Here's the entire paragraph on scoreboard window size (last paragraph in Section 3.4.3 of RFC 4303):
>>            A minimum window size of 32 packets MUST be supported when 32-bit
>>            sequence numbers are employed; a window size of 64 is preferred and
>>            SHOULD be employed as the default.  Another window size (larger than
>>            the minimum) MAY be chosen by the receiver.  (The receiver does NOT
>>            notify the sender of the window size.)  The receive window size
>>            should be increased for higher-speed environments, irrespective of
>>            assurance issues.  Values for minimum and recommended receive window
>>            sizes for very high-speed (e.g., multi-gigabit/second) devices are
>>            not specified by this standard.
>> 	• Prior discussion on this list indicates that the 32 and 64 window size values are present in some running code, at least as defaults.
>>  
>> L4S can exhibit undesirable interactions with ESP anti-replay based only on ECT(0) and ECT(1) in the outer headers as follows:
>> 	• Simultaneously send L4S flows (ECT(1) in ECN field) and Classic flows (ECT(0) in ECN field) through the same VPN.
>> 	• The VPN sender assigns in-order sequence numbers to the packets independent of which type of flow they belong to.
>> 	• The VPN sender propagates the ECN field in each packet to the outer IP header, as required by the tables in Sections 5.1.2.1 and 5.1.2.2 of RFC 4301.
>> 	• One or more network node bottlenecks between the VPN sender and receiver apply L4S treatment to the L4S ECT(1) packets, causing them to advance past some Classic ECT(0) packets.
>>  
>> At the VPN receiver, the received L4S packets drive advancing the sliding window to higher sequence numbers.  If the sequence numbers in the arriving L4S packets get ahead of the sequence numbers in the arriving Classic packets by the size of the sliding window or more, the arriving Classic packets are dropped *even though they are not duplicates* (!).
>>  
>> 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?

	[SM] Have a look at https://www.strongswan.org/testing/testresults/ikev2/net2net-psk-dscp/ which gives an example setup for Linux/strongswan exactly fr this use-case. So I woud say the implementation supports and documents that. Now, how many deployed instances actually use that (say compared to the number of instances that opted not to propagate DSCPs at encapsulation) I do not know.


> 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

	[SM] Well sure, because that is a policy decision each network deploying IPSEC has to make, Cisco has not way of knowing what people actually configured...

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

	[SM] The ipsec RFC talks about DSCP bypass and an explicit mapping table of inner DSCPs to outer DSCPs,... anybody taking DSCP propagation seriously will certainly figure out not to leak arbitrary DSCPs, if she/he already went to the effort to configure different SAs for some dscps, no?

> Seems unlikely that an implementer would have gone to all this trouble, rather than just using one SA, which is allowed by the SHOULD in the spec.
> It strikes me that this SHOULD in RFC4301 might be easy to say but infeasible to implement.

	[SM] Look at the strongswan example above, that does not seem to be witchcraft, but rather mundane iptables/nftables marking/filtering. I see no reason why this could not be extended for all 64 possible DSCPs if one really would like to prepare for all eventualities... but realsitically it shoukd suffice to cover those DSCPs the end network actually intends to use and simply re-mark the other ones sanely...

> On a host with an L4S CC enabled, a VPN would never need more than two SAs for the two types of ECN.

	[SM] Unless there is also DSCP based priority forwarding in polace along the path, like WiFi WMM, because dscp and L4S re-ordering are not mutually excusive along an arbitrary network path, no?

> So it would be more feasible to ensure that a VPN sets up two SAs in advance (for ECT1 or NotECT&ECT0). But that would require an L4S-specific patch to the VPN code. That would be do-able but probably only reasonable to expect it to be officially maintained in a VPN if L4S one day became standards track. And by then ECT0 might be on the decrease anyway.

	[SM] Yes that is one way to solve that, unfortunately this again requires bystanders to fix up L4S side-effects...

>>  
>> At least two incorrect assertions have been made about IPsec anti-replay in list discussion and/or in the interim meeting:
>> 	• The undesirable anti-replay interaction is neither specific to nor caused by L4S.
>> 		• That is incorrect because RFC 4301 has addressed the anti-replay interaction for Diffserv.  In contrast, L4S is new wrt RFC 4301.
> 
> [BB] Correct, RFC4301 doesn't ask for ECT1 to be in a separate SA 'cos (obviously) L4S didn't exist when 4301 was written.
> 
> But that first sentence ("RFC 4301 has addressed the anti-replay interaction for Diffserv") might not be the whole story, if the SHOULD is infeasible to implement (see above).

	[SM] While it would seem convenient for your argument, it seems that at least for strongswan there is evidence that the dscp replay issue got sufficient attention, that a reference configuration was created and added to the test suite. 

>> 
>> 	• The undesirable anti-replay interaction only occurs if CE marks are present in some of the packets involved.
>> 		• This is incorrect because ECT(0) and ECT(1) values in the ECN field suffice to create the problem, see above.
> 
> [BB] Correct (if ECT0 and ECT1 are in the same SA).

	[SM] Which they will be by default.

> I was thinking of the corner-case where the VPN ingress places ECT1 into a separate SA, but there are multiple bottlenecks between the two ends of the VPN as in the unlikely CE reordering problem with L4S discussed before:
> 1. VPN ingress
> 2. Classic ECN AQM
> 3. L4S DualQ AQM
> 4. VPN egress
> 
> If both AQMs are simultaneously bottlenecked (unusual) then, any ECT0 packets that the Classic AQM marks as CE will be classified into the L4S queue of the DualQ, along with the packets in the ECT1 SA. Then replay protection in the VPN egress could drop some Classic traffic.

	[SM] Yes, that seems to be correct, IMHO this is also quite problematic, but this will only trigger if (one) AQM (along the path) wants the classic traffic to slow down anyway, so is not as bad as the case with competing ECT(1) and ECT(0) traffic (as that will be quite normal for a long time, assuming L4S actually gains some traction).

>>  
>> I'll close by noting that if L4S flows carried a DSCP that differed from Classic flows, that would enable a "reduce to previous case" line of reasoning (yes, I used to be a mathematician) that reuses the IPsec provisions for Diffserv to address this anti-replay interaction with L4S.  That reuse won't prevent all reordering-caused anti-replay problems that could occur, but it would take advantage of existing/known techniques for dealing with them.
> 
> [BB] That would only make a difference if the VPN actually implemented separating DSCPs into separate SAs (which I questioned earlier).

	[SM] As above, for Linux xfrm/ipsec it is incumbent upon the party setting up an ipsec tunnel to implement the desired policies, but the cited example indicates IMHO that the separate SA modus can be expected to not exist in the real word, as convenient as that might be.

> It might be as feasible for the VPN to separate ECT1 into a separate SA, as discussed earlier.

	[SM] I am sure all operators of ipsec tunnels are going to absolutely adore L4S once they figure out that L4S is the root cause that they need to change all of their configurations...


Best Regards
	Sebastian

> 
> 
> 
> Bob
> 
>>  
>> Thanks for reading this far, --David
>>  
>> David L. Black, Sr. Distinguished Engineer, Technology & Standards
>> Infrastructure Solutions Group, Dell Technologies
>> mobile [phone] [e-mail]
>>  
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/