48 - subtopic: Security

[gwhiteCL]

Protection of the NQB PHB from malicious traffic has been a topic of discussion in #48. The recommended implementation option in the draft is to implement a traffic protection mechanism that can identify and deal with malicious traffic. The fact that this mechanism is only a recommendation and not mandatory is cause for concern for @dlb237.

In the WG discussions, it was pointed out that NQB is a best effort service, no more susceptible to abuse than other best effort services, and that mechanisms similar to traffic protection are not mandated for other best effort services (e.g. the Default PHB). It was also discussed that the PHB is primarily applicable to Access Network connections, where the PHB instance would be carrying traffic sourced/destined to a single customer, and thus the damage would be limited to impacting that customer only. It has also been discussed that some network environments may have other means (e.g. traffic conditioning / selective re-marking) to prevent malicious traffic from being marked NQB, and thus would have no use for traffic protection as a security mechanism. It was further commented that making traffic protection mandatory seems like it creates a barrier to deployment, and we shouldn't do it until we have actual evidence that it is needed.

The proposed resolution to this is the following:

1. We delete the words in section 10: but recognizes that other options might be more desirable in certain situations. so that the recommendation to implement traffic protection isn't watered down.
2. We modify the paragraph in 5.2 that discusses situations where traffic protection is potentially not needed, to instead frame it such that the decision by an implementer to not implement traffic protection might limit the deployment/usage of their NQB PHB implementation to a smaller set of use cases, and it would put the onus on the operator to monitor usage and take remediations manually rather than automatically dealing with misbehaving traffic. In this, we include language to more fully describe the implications of ignoring the recommendation to implement traffic protection.
3. We add a mandatory requirement that NQB PHB implementations provide statistics that can be used by the network operator to detect whether abuse is occurring (e.g. packet and drop counters). This requirement would ensure that operators who configure the NQB PHB have the ability to track the amount of packet drop that is occurring due to traffic overrunning the shallow buffer, and then take action if they feel as though the PHB is causing more issues than it is solving in their environment. Those actions could include disabling the PHB, identifying and dealing with the sources of malicious traffic directly, enabling traffic protection if it is available, or pursuing a feature request with the equipment manufacturer to add a traffic protection function if it isn't currently available.

If the above does not resolve the issue in your eyes, please provide proposed text that does solve the issue.

To avoid confusion for those trying to work this issue, please keep this thread limited to the security topic discussed above.

[dlb237]

Have sent draft of proposed wording changes to Greg. Revised version will be posted after he's had a chance to review the proposed changes.

Thanks, --David

[gwhiteCL]

Resolution of this issue is:

1. §5 PHB Requirements

Add text along the lines of:

To prevent propagation of degradation of service for NQB traffic, network equipment that supports this PHB and handles traffic for multiple users (e.g., subscribers) SHOULD support provisioning of bandwidth and related forwarding resources on a per-user (e.g., subscriber) basis and SHOULD support enforcement of the resulting per-user limits on both NQB and QB traffic for each user. Provisioning methodology as well as decisions on whether and how to enforce the resulting limits may vary by network operator.

Rationale: Based on mailing list discussion, limits scope of possible damage, especially when traffic protection is not supported.

Note: the exact text and placement within the draft is TBD.

2. §4.5 The NQB DSCP and Tunnels - last paragraph

Replace the paragraph with: As is discussed in [RFC2983], tunnel protocols that are sensitive to reordering (such as IPSec [RFC4301] or L2TP [RFC2661]) can result in undesirable interactions if multiple DSCP PHBs are signaled for traffic within a tunnel instance. This is true for tunnels containing a mix of QB and NQB traffic as well. Additionally, since networks supporting the NQB PHB could implement a traffic protection mechanism (see Section 5.2) and/or responses to NQB buffer overrun that result in out-of-order delivery for traffic marked with the NQB DSCP, even tunnels solely containing NQB traffic could have issues if they are sensitive to reordering and the outer header retains the NQB DSCP. As a result, the use of a reordering-sensitive tunnel protocol to carry NQB traffic, or a mix of QB and NQB traffic, necessitates that the outer tunnel header be re-marked with a non-NQB DSCP (e.g. Default), in which case the “pipe” model is preferable because it preserves the marking differentiation at tunnel decapsulation.

3. §10. Security Considerations

   If a Queue-Building microflow were to mismark its packets as NQB, it would be unlikely to receive a benefit by doing so, and it would usually experience a degradation. The nature of the degradation would depend on the specifics of the PHB OLD implementation (and on the presence or absence of a traffic protection function), NEW implementation, including response to NQB buffer overflow (and on the presence or absence of a traffic protection function), END but could include excessive packet loss, excessive latency variation and/or excessive out-of-order delivery. If a Non-Queue-Building microflow was to fail to mark its packets as NQB, it could suffer the latency and loss typical of sharing a queue with capacity seeking traffic.

Rationale: Add NQB buffer overflow response as another source of degradation.

4. §10. Security Considerations -

   The recommendations on traffic protection mechanisms in this document presume that some type of "flow" state be maintained in order to differentiate between microflows that are causing queuing delay and those that aren't. Since this flow state is likely finite, this opens up the possibility of flow-state exhaustion attacks. While this document requires that traffic protection mechanisms be designed with this possibility in mind, the outcomes of flow-state exhaustion would depend on the implementation.

After above text, add a new paragraph:

If traffic protection is not implemented or is not able to prevent to prevent queue formation in the NQB shallow buffer, the limited size of that buffer will cause a growing queue to overrun that buffer, resulting in negative effects (e.g., reforwarding as Default, discarding) that potentially impact multiple NQB-marked microflows, independent of whether each affected microflow contributed to queue formation. As discussed elsewhere in this draft, those negative effects serve to discourage misuse and abuse of NQB by QB traffic, but the negative side effects on NQB traffic that is using NQB (and the associated shallow buffer) as intended make it vital to limit the effects of shallow buffer overrun via per-user provisioning limits that prevent queue overrun effects from affecting other users (see section 3.4).

Rationale: Include queue formation in security discussion. Potential side effects of buffer overrun on legitimate NQB traffic are nasty.

[gwhiteCL]

On item 1 above: I added the following paragraph in Section 5.1 (Primary Requirements).

To prevent propagation of degradation of service for NQB traffic caused by potential mis-marking of QB traffic, network equipment that supports this PHB and handles traffic for multiple users (e.g., subscribers) SHOULD support provisioning of bandwidth and related forwarding resources on a per-user (e.g., subscriber) basis and SHOULD support enforcement of the resulting per-user limits on the aggregate of NQB and QB traffic for each user. This functionality is commonly available in the class of network equipment for which this PHB is primarily applicable (see Section 3.4).
Provisioning methodology as well as decisions on whether and how to enforce the resulting limits may vary by network operator.

[gwhiteCL]

Note, for item 4, the commits (c5397f4 and fd87934) softened the usage of the phrase "make it vital to limit" to "motivates limiting".

[gwhiteCL]

marking as closed.