ietf-svn-bot
commented
5 years ago @ietf@bobbriscoe.net commented
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:
-
Switching from ECN to loss on overload, see draft-ietf-tsvwg-aqm-dualq-coupled#section-4.1.3 and Appendix A.2.
-
Queue protection, see draft-briscoe-docsis-q-protection as well as the Security Considerations sections of the L4S architecture.
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.
owner:draft-ietf-tsvwg-l4s-arch@ietf.orgtype_defect| by wes@mti-systems.comThere 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.
Issue migrated from trac:26 at 2022-01-31 12:35:52 +0000