Auditing of Congestion Exposure (ConEx) signals
draft-wagner-conex-audit-00

Abstract

Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. In order to make ConEx information useful, reliable auditing is necessary to provide a strong incentive to declare ConEx information honestly. However, there is always a delay between congestion events and the respective ConEx signal at the audit. In order to also provide a signal for risking congestion in the future, in [draft-ietf-conex-abstract-mech] it is proposed to use credit signals sent in advance. This document defines how the signals are interpreted by an audit and lists requirements for an audit implementation. It also discusses the security of the proposed system and lists potential attacks on it.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 24, 2014.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Abstract meaning of credit
• 1.2. Definitions
• 2. Audit implementation
• 2.1. Placing an audit element
• 2.2. Per flow state
• 2.3. Assessing flow behavior
• 2.4. Penalizing misbehaving flows
• 2.5. Audit start for existing connections
• 2.6. Handling Loss of ConEx-marked Packets
• 3. Open issues
• 4. Security Considerations
• 5. IANA Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

In order to make ConEx information useful, reliable auditing is necessary to provide a strong incentive to declare ConEx information honestly. However, there is always a delay between congestion events and the respective ConEx signal at the audit. To avoid state and complex Round-Trip Time (RTT) estimations at the audit, in [draft-ietf-conex-abstract-mech] it is proposed to use credit signals sent in advance to cover potential congestion in the next feedback delay duration.

The ConEx signal is based on loss or Explicit Congestion Notification (ECN) marks [RFC3168] as a congestion indication. Following [draft-ietf-conex-abstract-mech] (Section 4.4), ConEx signaling has to encode ConEx capability, Re-Echo-Loss (L), Re-Echo-ECN (E) and credit (C).

1.1. Abstract meaning of credit

Credit represents risk for congestion. A ConEx-enabled sender should signal sufficient credit in advance to any congestion occurences. If a congestion event occurs, a corresponding amount of credit is consumed. If the sender intends to take the same risk again, it only must replace this consumed credit as non-consumed credit does not expire.

1.2. Definitions

Congestion occurrence
The occurrence of a signal congestion signal, which today corresponds to a packet loss or ECN-CE mark.

Congestion event
One or more congestion occurrences that happen within one RTT and therefore are perceived as one congestion event by today's congestion control algorithms.

Connection
A connection between transport layer endpoints that allows bidirectional signalling, e.g. a TCP connection.

Flow
The flow of packets of a connection in one direction. Therefore for a flow sender and receiver are well defined. With regard to ConEx auditing, only one flow of any observed connection is audited, see Section 2.1.

2. Audit implementation

The objectives of an audit are to verify that the congestion reported using the ConEx mechanism matches the congestion actually observed by the receivers and to penalize cheaters.

2.1. Placing an audit element

An audit element should be placed so that it can surveil all congestion signals of audited flows. This means it should be placed beyond any potential source of congestion, i.e. any potential bottleneck, towards the receiver of that flow.

2.2. Per flow state

ConEx auditing is performed per incoming flow, so all monitoring, assessment and penalizing is per flow.

An audit maintains state for each active connection that is updated on every packet seen on up- or downstream of that connection. Such entry is created when the first packet of an unknown connection is observed. It is deleted when the connection either is closed conforming to its transport layer protocol or a timeout expired. This timeout should be chosen to keep false negatives low, i.e. avoiding timing out still active flows. In contrast, false positives, recognizing two flows as one, are expected typically being a smaller issue since in most cases the sender is the same host.
An audit should maintain an RTT_MAX estimation per flow to avoid false positives for flows with smaller RTT as well as false negatives This value should be as close to the RTT observed by the sender as possible. The audit should avoid choosing RTT_MAX lower than the RTT observed by the sender.
An audit maintains five counters per flow

• ECN-CE (ECN codepoint set)
• Loss (to be detected by the audit)
• Re-Echo-ECN (ConEx signal E)
• Re-Echo-Loss (ConEx signal L)
• Credit (ConEx signal C)

Whenever a ConEx-marked packet (Re-Echo-Loss or Re-Echo-ECN) is seen, the respective counter is increased. When a loss is detected or a ECN-CE-marked packet is observed, the respective counter and also the credit counter are decreased. An audit may use information from the return flow in order to define RTT_MAX and to detect packet losses.

2.3. Assessing flow behavior

Generally, a connection is judged on three criteria, one concerning exposure of loss, one on exposure of ECN and one on announcing congestion risk by credit. A connection is assumed behaving abusive if Section 2.6.
If a flow is considered misbehaving based on at least one of the three conditions. An audit may count the number of detected misbehaviors to .

• the credit counter is negative
• losses suffered from in the last RTT_MAX period are not exposed by Re-Echo-Loss signals
• ECN-CE signals received in the last RTT_MAX period are not exposed by Re-Echo-Loss signals

The first criterion should be checked each time a packet of that flow towards the destination is observed. Both criteria regarding the ConEx signals should be checked at distinct points of time only, so it is only necessary to store a limited number of old states. These criteria should at least be checked once in RTT_MAX. The audit may consider an estimation of loss of ConEx-marked packets in favor of the sender in its calculations, see Section

2.4. Penalizing misbehaving flows

If a flow is detected to misbehave, the audit must start penalizing immediately. The only actually possible penalty would be dropping packets (with a certain probability). The actual drop rate must provide a tangible disadvantage to the sender but should not render the connection unusable.

2.5. Audit start for existing connections

An audit may be started with zero state information on existing flows, e.g. due to (re-)started audit or re-routing of flows. As credits will have been sent in advance of congestion events, it is possible that no valid credit state is available at the audit when a congestion event occurs. An audit implementation should take this into account when defining drop probabilities for misbehaving flows.

2.6. Handling Loss of ConEx-marked Packets

ConEx-marked packets will be sent just after the sender noticed a congestion occurence, so often this sender will just have reduced its sending rate. Thus the loss probability for ConEx-marked packets is expected to be lower than for the average flow. Nevertheless, ConEx-marked packets can be lost. For long-lasting connections, the audit may use the fraction of lost packets of that connection to allow for the same fraction of loss for each ConEx-mark (E, L and C). Nevertheless, often loss of ConEx-marked packets will cause the audit to penalize the flow. The sender may guess audit intervention when it detects significant increase in packet loss and re-sent ConEx-marks. The audit may try to detect such behavior and decide to abort a penalty phase.

3. Open issues

Todo

4. Security Considerations

Here known / identified attacks will be discussed. Bob Briscoe's dissertation provides good material here. big TODO.

5. IANA Considerations

This document has no IANA considerations.

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses