Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors David Wagner , Mirja Kühlewind
Last updated 2013-10-21
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wagner-conex-audit-00
ConEx Working Group                                            D. Wagner
Internet-Draft                                             M. Kuehlewind
Intended status: Informational                   University of Stuttgart
Expires: April 24, 2014                                 October 21, 2013

            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

Wagner & Kuehlewind      Expires April 24, 2014                 [Page 1]
Internet-Draft               ConEx Auditing                 October 2013

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

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

Wagner & Kuehlewind      Expires April 24, 2014                 [Page 2]
Internet-Draft               ConEx Auditing                 October 2013

   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

Wagner & Kuehlewind      Expires April 24, 2014                 [Page 3]
Internet-Draft               ConEx Auditing                 October 2013

   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

   o  ECN-CE (ECN codepoint set)

   o  Loss (to be detected by the audit)

   o  Re-Echo-ECN (ConEx signal E)

   o  Re-Echo-Loss (ConEx signal L)

   o  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

   o  the credit counter is negative

   o  losses suffered from in the last RTT_MAX period are not exposed by
      Re-Echo-Loss signals

   o  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

Wagner & Kuehlewind      Expires April 24, 2014                 [Page 4]
Internet-Draft               ConEx Auditing                 October 2013

   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 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 .

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.

Wagner & Kuehlewind      Expires April 24, 2014                 [Page 5]
Internet-Draft               ConEx Auditing                 October 2013

5.  IANA Considerations

   This document has no IANA considerations.

6.  References

6.1.  Normative References

   [draft-ietf-conex-abstract-mech]
              Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
              Concepts and Abstract Mechanism", draft-ietf-conex-
              abstract-mech-07 (work in progress), October 2012.

   [draft-ietf-conex-destopt]
              Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6
              Destination Option for ConEx", draft-ietf-conex-destopt-05
              (work in progress), March 2013.

6.2.  Informative References

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, September 2009.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP", RFC
              3168, September 2001.

Authors' Addresses

   David Wagner
   University of Stuttgart
   Pfaffenwaldring 47
   70569 Stuttgart
   Germany

   Email: david.wagner@ikr.uni-stuttgart.de

   Mirja Kuehlewind
   University of Stuttgart
   Pfaffenwaldring 47
   70569 Stuttgart
   Germany

   Email: mirja.kuehlewind@ikr.uni-stuttgart.de

Wagner & Kuehlewind      Expires April 24, 2014                 [Page 6]