Opened 3 years ago

Last modified 3 years ago

#26 new defect

Admission control / untrusted marking

Reported by: wes@… Owned by: draft-ietf-tsvwg-l4s-arch@…
Priority: major Milestone: L4S Suite - WGLC Preparation
Component: l4s-arch Version:
Severity: - Keywords:


There is a question about how admission control for L4S ID traffic should be performed. How can the L4S ID be trusted? What are the implications?

This was raised at IETF 105 by Jake Holland.

Change History (2)

comment:1 Changed 3 years ago by ietf@…

This issue has already already addressed at length in the drafts and on the mailing list, with two main alternative approaches having been designed and implemented:

The aims are different.

  • Disabling ECN on overload aims to ensure that the L4S ECN marking provides no extra benefit (relative to not using ECN) for hosts that are unresponsive. Of course there was already a benefit to being unresponsive prior to L4S. The aim here is to ensure that L4S, particularly the priority scheduler in draft-ietf-tsvwg-aqm-dualq-coupled, does not make matters any worse.
  • Queue protection aims to protect the low latency of the L4S service from flows that use the the L4S ECN identifier but are not careful to avoid building a queue.

The former has been evaluated extensively. The reference is provided at the end of section 4.1.3 linked above, and it has been presented at the IETF, without any criticism resulting.

The latter has been and is continuing to be evaluated by CableLabs?, but the evaluations are not yet published.

I am not sure what to do with this issue. Trusting the ID is indeed a valid concern, which is why the above approaches were developed. But unless something is articulated that hasn't been solved (but needs to be), I don't think keeping this issue open will be useful.

A certain amount of desk study on security is always useful, but ultimately attacks don't get invented until there's something worth attacking. L4S is experimental, because deployment is ultimately necessary to really put it through its paces, including on security.

comment:2 Changed 3 years ago by jholland@…

There was a criticism posted, I believe. Myself and Luca each raised related points on the list that I don't think were addressed, outlining a plausible and important scenario that was unexamined by the referenced paper and outlining why it remains a problem:

[edit] further description of the same issue was expanded slightly here:

I don't remember seeing any test results that tried to examine the issue.

Last edited 3 years ago by jholland@… (previous) (diff)
Note: See TracTickets for help on using tickets.