Re: [tsvwg] Gorry Fairhurst Individual thoughts on choosing whether/how to advance ECN work.

[Jonathan Morton <[e-mail]>]

> On 15 May, 2020, at 7:49 pm, Joseph Touch <[e-mail]> wrote:
> 
> I also haven’t quite seen a brief summary of the utility of these bits as a signal in either direction (endpoint to net; net to endpoint) given the assumption that “everybody lies”.
> 
> IMO, lying is part of why DSCPs are useful only where either redundantly validated on network ingress or inside managed networks.
> 
> So my questions - not really experiments (as per one of the options) are:
> 
> 	- assuming endpoints lie and/or network nodes lie (either by what they indicate or what they rewrite), are either of these options still safe?
> 
> 	- assuming everybody lies (as above), are either of these options still useful? (i.e., more than just safe)
> 
> If not - and partly based on Gorry’s observation above, my inclination is not to define these bits for such uses at all.

It's an important question, so thank you for raising it.  Ultimately the answer to such questions boils down to what incentives an actor may have to abuse the mechanisms controlled by each codepoint.

Taking the question of lying endpoints first, SCE is reasonably robust in that respect.  The normal case is that an SCE sender originates ECT(0), the same as normal ECN.  If it instead originates ECT(1) or CE, it is equivalent to pre-applying a congestion signal and removing the network's ability to give the transport information.  The sender could already ignore that information without giving an explicit signal of doing so, so the latter is not incentivised.  Meanwhile the receiver may choose to ignore the ECT(1) signal and not feed it back to the sender - which is what existing RFC-3168 receivers do anyway, and this is allowed for in SCE's design.  Or they might falsely generate such a signal, but that would reduce its own throughput, so that is not incentivised.  Other forms of lying are already possible with RFC-3168, which SCE does not exacerbate.

In the L4S system, a sender may falsely mark a low-latency transport with ECT(0), or a conventional transport with ECT(1), to drop it into the "wrong" queue and AQM treatment regime at the bottleneck.  I think the former case is the most damaging one, because it would result in other traffic being forced out of the way of the misbehaving sender, which thereby gains a throughput advantage under congested conditions.  This scenario should be familiar from the usual concern about Diffserv PHBs.  I offer no opinion about misbehaving receivers in this context.

If we now turn to the prospect of lying middleboxes, SCE again inherits much existing analysis from RFC-3168.  The new distinction between ECT(0) and ECT(1) is meaningful and carries congestion information, and middleboxes are currently supposed to preserve that distinction (a rule originally intended to support Nonce Sum, a proposed prophylactic against ECN misbehaviour that proved to be unnecessary).  SCE permits changing ECT(0) to ECT(1) in the network, but not the reverse.  The latter would erase congestion information; this is however backstopped by the continued use of CE at a higher level of congestion, so is relatively benign.  A DoS scenario could employ falsely marking with ECT(1), but this could also be done (with greater efficiency) by falsely marking CE, and ultimately the same sorts of mitigations would apply as in RFC-3168.

It's also difficult to see how an attacker could gain benefit from manipulating the ECN field at a middlebox in the L4S system, besides the obvious ploy of simulating the sender falsely setting ECT(0) on L4S traffic.  In part this is because the behaviour of a correctly functioning L4S system is already so fragile, that it is not necessary to do much to disrupt its behaviour.  In particular, one of the worst things a middlebox can do is to simply ignore the ECT(1) codepoint and treat both classes of traffic as indistinguishable; but that is precisely what existing RFC-3168 AQMs are permitted, even encouraged to do.  Recent developments in TCP Prague were intended to detect this case at the endpoints, but actually fail to do so reliably.

I hope that at least begins to answer your question.

 - Jonathan Morton