[tsvwg] Re: NQB draft WGLC - incentives, security and traffic protection

["Black, David" <[e-mail]>]

Going back to this review, this is my view of where the concerns raised by the review stand (original review is below):

-- Incentives

There's been a lot of inconclusive email discussion, which has led to three related proposed issue resolutions: 46<https://github.com/gwhiteCL/NQBdraft/issues/46>, 47<https://github.com/gwhiteCL/NQBdraft/issues/47>, and 48<https://github.com/gwhiteCL/NQBdraft/issues/48>.  I'm not satisfied with the proposed resolutions.

At a high-level, I think there are three options:

  1.  Traffic protection is mandatory to implement.
  2.  Detailed queue configuration specifics that ensure that QB traffic stays out of the NQB queue.
  3.  Remove most or all of the discussion of incentives for QB traffic to stay out of the NQB queue.

Based on discussion, I currently lean towards c), in significant part because some degree of flexibility in how to configure new functionality to prevent/deter practical problems seems like a very good idea.  In addition, tolerating some modest amount of QB traffic in the NQB queue isn't necessarily inconsistent with the low(er) latency intentions for that queue.

-- Security

In contrast, progress has been made here, much as it may be hard to discern from all the emails.

Jason and Greg have identified a couple of classes of network equipment where traffic protection is not necessary wrt security concerns because the abuser can only do damage to themselves:

  *   Single-user network equipment where interference among flows is not a concern.
  *   ISP access network equipment that supports per-user/device/flow provisioning and enforces the resulting limits on traffic.
It should be fine to specify traffic protection as "SHOULD implement" (for other reasons) for those two classes of network equipment, and likely more classes to be identified.  Credit where credit is due to Jason and Greg for suggesting these.

OTOH, existing WiFi is still a problem area - the review comments on that topic appear to have been largely ignored.  In the absence of traffic protection (in the AP or elsewhere along the path), I don't know what to suggest.

Thanks, --David

From: Black, David <[e-mail]>
Sent: Sunday, June 9, 2024 9:43 PM
To: tsvwg IETF list <[e-mail]>
Cc: Black, David <[e-mail]>
Subject: NQB draft WGLC - incentives, security and traffic protection

Gorry asked me to be sure to review the NQB draft during WGLC.  This message is devoted to the primary set of issues that I found concerning incentives, security, and traffic protection.

-- Incentives

I like the overall approach of providing incentives for appropriate classification traffic as Default vs. NQB.  Unfortunately, I think the current draft falls short of providing a sufficient incentives framework.

This sentence in section 3.2 summarizes the goal of the incentives framework. "The PHB is also designed to minimize any incentives for a sender to mismark its traffic, since neither higher priority nor reserved bandwidth are being offered."  That sentence has at least two problems:

[A] The incentives are not minimized because lower latency is clearly being offered to NQB traffic, which provides an incentive for traffic mismarking.  Section 4.1 identifies traffic protection as the primary disincentive for mismarking queue-building traffic as NQB: "The consideration as to whether an application chooses to mark its traffic as NQB involves the risk of being subjected to a traffic protection algorithm (see Section 5.2) if it contributes to the formation of a queue in a node that supports the PHB."

[B]The statement that "neither higher priority nor reserved bandwidth are being offered" appears to be incorrect for NQB use of UP 5 by contrast to UP 0 in existing WiFi networks (section 7.3.1).  That statement would be closer to correct if all of the recommendations in Section 7.3.1 were followed, but this sentence in 7.3.1 strikes me as seriously unrealistic: "In order to preserve the incentives principle for NQB, Wi-Fi systems SHOULD be configured such that the EDCA parameters for the Video Access Category match those of the Best Effort Access Category." In the (common) presence of a lot of video traffic, I question whether operators or home users are actually going to do that to the potential detriment of video traffic.

-- Security

Section 5 states: "Malicious behavior is not necessarily based on rational self-interest, so incentive alignment is not a sufficient defense, but the large majority of users do not act out of malice. Protection against malicious attacks (and accidents) is addressed in Section 5.2 and summarized in Section 10."

An important implication is that traffic protection is *the* countermeasure to malicious use, which is confirmed by section 10: "To preserve low latency performance for NQB traffic, networks that support the NQB PHB will need to ensure that mechanisms are in place to prevent malicious traffic marked with the NQB DSCP from causing excessive queue delays. Section 5.2 recommends the implementation of a traffic protection mechanism to achieve this goal but recognizes that other options might be more desirable in certain situations."

To begin with, the words "might be more desirable" need to be removed from this draft and saved for possible use to update to section 9 of RFC 6919<https://datatracker.ietf.org/doc/html/rfc6919#section-9> (please take note of the 1 April publication date of RFC 6919).  More importantly, the usually IETF requirement for crucial security countermeasures such as this (traffic protection) is that they be mandatory to implement so that they are available for use if/as needed.

-- Traffic Protection

Both the incentive framework and security of NQB have a fundamental dependency on traffic protection - absent "certain situations", neither works without traffic protections.  Nonetheless, the requirement for traffic protection in the second paragraph of Section 5.2 is a SHOULD: "... network elements that support the NQB PHB SHOULD support a "traffic protection" function ...".  That's completely inadequate - based on incentives framework and security considerations, the appropriate requirement is "... network elements that support the NQB PHB MUST support and SHOULD use a "traffic protection" function ..." .

Turning to "certain situations" - these would initially be exceptions to "SHOULD use" and perhaps equipment that is only used in such exceptional situations could be an exception to "MUST support".  Unfortunately, the paragraph in Section 5.2 on these exceptional situations is a serious hand-wave: "There are some situations where traffic protection is potentially not necessary. One example could be a network element designed for use in controlled environments (e.g., enterprise LAN) where a network administrator is expected to manage the usage of DSCPs. Another example could be highly aggregated links (links designed to carry a large number of simultaneous microflows), where individual microflow burstiness is averaged out and thus is unlikely to cause much actual delay."  That's nowhere near good enough.

For "SHOULD use", quoting from RFC 2119's definition of "SHOULD": "... there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." The "full implications" that "must be understood and carefully weighed" in this case are the presence of incentives to mismark and the absence of protection against malicious use.  Omission of these concerns is a major flaw in the Section 5.2 paragraph on exceptional situations.  OTOH, there will be certainly be some situations in which network operators have effective controls outside of the NQB forwarding implementation that prevent mismarking and malicious use, and it would be good to describe at least one such situation - an extreme example would be an air-gapped network with complete controls on application deployment and network traffic origination, including traffic marking..

Exceptions to "MUST support" are a taller order, although one possibility could be implementations that are only usable in networks that have "valid reasons to ignore" the "SHOULD use" could be one possibility - in essence the implementer has to be certain that mismarking and malicious use are impossible in networks that use her implementation.  In order to agree to any text describing exceptions to "MUST support", I want to first understand the specific network examples that motivate the exception(s), including their mechanisms for prevention of mismarking and malicious use, since traffic protection will not be available for those purposes.

My understanding is that the DOCSIS-based cable modem implementations of NQB do include traffic protection - if that's correct, then they are not affected by the discussion in this message.

Thanks, --David

David L. Black, Sr. Distinguished Engineer, Technology & Standards
Infrastructure Solutions Group, Dell Technologies
mobile [phone] [e-mail]<mailto:[e-mail]>