idnits 2.17.1 draft-wagner-conex-audit-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 8, 2016) is 2939 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5681' is defined on line 389, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Wagner 3 Internet-Draft University of Stuttgart 4 Intended status: Informational M. Kuehlewind 5 Expires: October 10, 2016 ETH Zurich 6 April 8, 2016 8 Auditing of Congestion Exposure (ConEx) signals 9 draft-wagner-conex-audit-02 11 Abstract 13 Congestion Exposure (ConEx) is a mechanism by which senders inform 14 the network about the congestion encountered by previous packets on 15 the same flow. Reliable auditing is necessary to provide a strong 16 incentive to declare ConEx information honestly. This document 17 defines how the signals are handled by an audit and lists 18 requirements for an audit implementation. This document does not 19 mandate a particular design but identifies state and functions that 20 any auditor element must provide to fulfill the requirements stated 21 in [draft-ietf-conex-abstract-mech]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 10, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Meaning of the Re-Echo Signals . . . . . . . . . . . . . 2 59 1.2. Meaning of Credit Signal . . . . . . . . . . . . . . . . 3 60 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Audit Implementation . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Placing an Audit Element . . . . . . . . . . . . . . . . 4 63 2.2. Per Flow State . . . . . . . . . . . . . . . . . . . . . 4 64 2.3. Penalty Criteria . . . . . . . . . . . . . . . . . . . . 6 65 2.4. Appropriately Penalizing Misbehaving Flows . . . . . . . 7 66 2.5. Audit start for existing connections . . . . . . . . . . 7 67 2.6. Handling Loss of ConEx-marked Packets . . . . . . . . . . 8 68 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 6.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 In order to make ConEx information useful, reliable auditing is 79 necessary to provide a strong incentive to declare ConEx information 80 honestly. However, there is always a delay between congestion events 81 and the respective ConEx signal at the audit. In 82 [draft-ietf-conex-abstract-mech] it is proposed to use credit signals 83 sent in advance to cover potential congestion in the next feedback 84 delay duration. 86 The ConEx signal is based on loss or Explicit Congestion Notification 87 (ECN) marks [RFC3168] as a congestion indication. Following 88 [draft-ietf-conex-abstract-mech] (Section 4.4), ConEx signaling has 89 to encode ConEx capability, Re-Echo-Loss (L), Re-Echo-ECN (E) and 90 credit (C). 92 1.1. Meaning of the Re-Echo Signals 94 By the Re-Echo-Loss signal a sender exposes to the network that this 95 transport has experienced loss very recently. By the Re-Echo-ECN 96 signal a sender exposes to the network that this transport has 97 experienced an ECN-CE mark very recently. For the audit this means, 98 that if it detects a loss or an ECN-CE mark for a ConEx-enabled flow, 99 for a compliant sender the corresponding Re-Echo-Loss or Re-Echo-ECN 100 signals must be observed in the near future. 102 1.2. Meaning of Credit Signal 104 The Credit signal represents potential for congestion. A ConEx- 105 enabled sender should signal sufficient credit in advance to any 106 congestion event. If a congestion event occurs, a corresponding 107 amount of credit is consumed. If the sender intends to take the same 108 risk again, it just must replace this consumed credit as non-consumed 109 credit does not expire. 111 1.3. Definitions 113 Congestion signal 114 The occurrence of a packet loss or ECN-CE mark. We do not consider 115 other signs such as increased delay as congestion signals. 117 Congestion event 118 One or more congestion signals within one RTT. For today's 119 congestion control algorithms all these signals trigger just one 120 reaction regardless of their number. 122 Connection 123 A connection between transport layer endpoints that allows 124 bidirectional signalling, e.g. a TCP connection. 126 Flow 127 The flow of packets of a connection in one direction. Therefore for 128 a flow sender and receiver are well defined. With regard to ConEx 129 auditing, only one flow of any observed connection is audited, see 130 Section 2.1. 132 2. Audit Implementation 134 An audit element shall be a shadow device, i.e. its presence should 135 not be detectable for well-behaving senders. The objective of an 136 audit is to verify that senders signal the ConEx information 137 correctly and to penalize cheaters. For this, the audit element has 138 to maintain state for any active ConEx-enabled flow. It may maintain 139 appropriate timers to remove flows that have been idle for too long. 140 Flows can be audited independently, there are no dependencies. There 141 are two aspects the auditor has to check for each flow: 143 o if the congestion reported using the ConEx mechanism matches the 144 congestion actually observed by the receivers and 146 o if sufficient credit marks have been sent to signal the congestion 147 risk in advance. 149 The audit penalizes a flow if it fails either of these two criteria. 151 This document does not mandate a particular design but identifies 152 state and functions that any auditor element must provide to fulfill 153 the requirements stated in [draft-ietf-conex-abstract-mech]. 155 2.1. Placing an Audit Element 157 An audit element should be placed so that it can observe all 158 congestion signals of audited flows. If both congestion signals, ECN 159 and loss, are detected directly, all auditing should take place 160 beyond any potential source of congestion, i.e. any potential 161 bottleneck, towards the receiver of that flow. In that case it must 162 be placed beyond any potential multi path routing in order to be able 163 to identify all packet losses. For unencrypted TCP and maybe other 164 protocols, losses can be easily detected indirectly by monitoring the 165 sender's retransmissions, making loss auditing simple and reliable at 166 the same time. Such ConEx-loss audit function must be placed close 167 to the sender before any bottleneck where retransmissions might get 168 lost. Therefore it might make sense to have ConEx-loss auditing and 169 ConEx-ECN auditing separated. Nevertheless, this applies for certain 170 deployment scenarios only. Therefore we describe a combined loss and 171 ECN ConEx auditor in the following which must be placed close to the 172 receiver, beyond any potential bottleneck. 174 2.2. Per Flow State 176 ConEx auditing must be performed per incoming ConEx-enabled flow, so 177 all monitoring, assessment and penalizing is per flow. 179 An audit maintains state for each active connection that is updated 180 on every packet of that flow. Such state entry is created when the 181 first packet of an unknown flow is observed. It is deleted when 182 either the corresponding connection is closed conforming to its 183 transport layer protocol or a timeout expired. This timeout should 184 be chosen to keep false negatives low, i.e. avoiding timing out still 185 active flows. In contrast, false positives, recognizing two flows as 186 one, are expected typically being a smaller issue since in most cases 187 the sender is the same host and either complies to the protocol or 188 not. We recommend setting this timeout to 60 seconds, a value also 189 common e.g. in NAT middle boxes. 191 An audit should maintain an RTT_MAX estimation per flow. This value 192 should be as close to the maximum RTT observed by the sender as 193 possible. RTT_MAX must not be chosen smaller than the RTT observed 194 by the sender. 195 An audit maintains the following variables per flow: 197 o ECN-CE counter (ECN-CE codepoint set) 198 When an ECN-CE-marked packet is observed, the counter is increased 199 by the number of IP payload bytes. 201 o Loss counter (to be detected by the audit element, see also 202 Section 5.5 in [draft-ietf-conex-abstract-mech]) 203 When a loss is observed, the counter is increased by the number of 204 IP payload bytes. 206 o Re-Echo-ECN counter (ConEx signal E) 207 When Re-Echo-ECN-marked packet is seen, the counter is increased 208 by the number of IP payload bytes. 210 o Re-Echo-Loss counter (ConEx signal L) 211 When Re-Echo-Loss-marked packet is seen, the counter is increased 212 by the number of IP payload bytes. 214 o Credit state 215 Whenever a ConEx-marked packet (Re-Echo-Loss or Re-Echo-ECN) is 216 seen and Credit state is greater than zero, the counter is 217 decreased by the number of IP payload bytes. When a Credit-marked 218 packet is seen, the counter is increased by the number of IP 219 payload bytes. 220 Please note that the meaning of the Credit variable differs from 221 the other variables: While all other variables are life-time 222 counters for the flow and thus grow monotonously, the credit 223 buffer just reflects the current signaled credit. It shrinks and 224 grows as congestion is experienced and credit is sent. 226 o RTT_MAX 228 o is_in_penalty_state 230 o p, an EWMA of the congestion rate (loss and/or ECN-CE marks) 232 o x, an EWMA of the rate of Re-Echo-Loss and/or Re-Echo-ECN marks. 233 If a packet carries both flags, it must be counted twice. 235 o current drop probability 237 If the flow is part of a bidirectional connection, an auditor may use 238 information from the return flow in order to define RTT_MAX and to 239 detect packet losses. 241 2.3. Penalty Criteria 243 Generally, a connection is judged on three criteria, one concerning 244 exposure of loss, one on exposure of ECN-based congestion signaling 245 and one on announcing potential congestion by credit. A flow is 246 considered misbehaving if at least one of the three conditions is 247 met. 249 A connection is assumed behaving abusive if 251 o the Credit state is zero, 253 o losses observed in the last 2x RTT_MAX period are not exposed by 254 Re-Echo-Loss signals, and 256 o ECN-CE signals received in the last 2x RTT_MAX period are not 257 exposed by Re-Echo-Loss signals. 259 The first criterion should be checked each time a packet of that flow 260 towards the destination is observed. If Credit state is zero, 261 is_in_penalty_state is set to true, else set to false. 263 The other two criteria shall be checked periodically based on 264 timeouts. The timeout t must be equal or bigger than 2x RTT_MAX. 265 There are n timers used and n should be equal or bigger than 2. To 266 do the check, an audit element must store n snapshots of the ECN-CE 267 and loss counter. When the timeout fires, the oldest set of values 268 is compared with the current values of Re-echo-Loss and Re-Echo-ECN, 269 respectively. If the saved loss counter is greater than the current 270 Re-Echo-Loss counter, or saved ECN-CE counter is greater than the 271 current Re-Echo-ECN counter, is_in_penalty_state is set to true, else 272 set to false. 274 A flow may have not enough data at a time where it needs to send 275 ConEx markings and by this fall into misbehaving state 276 (is_in_penalty_state is true) during a phase of inactivity. If the 277 sender then restarts sending packets carrying markings for all failed 278 criteria, the sender is assumed being well-behaving (in dubio pro 279 reo). Therefore the auditor shall not drop packets which carry all 280 required flags, but use the normal penalty on all others. 282 For example, if credit is zero and the losses experienced in the 283 2xRTT_MAX period are not compensated by sufficient Re-Echo-Loss 284 signals, packets carrying both the C and the L flag will not be 285 subject of the penalty function. Nevertheless, packets carrying only 286 the C-flag or only the L-flag will. 288 2.4. Appropriately Penalizing Misbehaving Flows 290 If a flow is detected to misbehave, the audit must start penalizing 291 immediately. The only actually possible penalty is dropping packets 292 (with a certain probability). In order to not incentivize senders to 293 simply start new flows when detecting being penalized by an audit 294 element, the penalty of a misbehaving flow should be proportional to 295 the misbehavior. 297 Please note that we require the sender to make sure that any ConEx 298 mark will reach the receiver, so it is responsible for timely 299 retransmission of any lost ConEx signal. 301 The actual drop rate must provide a tangible disadvantage to the 302 sender but should not make the connection unusable. An auditor 303 should aim at forwarding not more packets than would have been 304 successfully sent with the exposed congestion rate. Since the 305 congestion rate may vary over time, the auditor should use an 306 exponentially-weighted moving average (EWMA) for each flow to define 307 the congestion rate p. An auditor should also maintain a EWMA for 308 the rate of ConEx-signals (Re-Echo-Loss and Re-Echo-ECN) x. 310 TODO: what are appropriate weighting factors alpha in EWMA? 312 Assume the packet rate is r and congestion rate is p, but only p-x 313 congestion is signaled by the sender using ConEx (c < p). The audit 314 should aim at giving the flow just a rate of r*(x/p). In other 315 words, it should drop (p-x)/p of the traffic, so its drop probability 316 should be (p-x)/p. Therefore the audit just keeps updated x and p, 317 and derives the drop probability as (p-x)/p. 319 2.5. Audit start for existing connections 321 An audit may be started with zero state information on existing 322 flows, e.g. due to (re-)started audit or re-routing of flows. As 323 credits will have been sent in advance of congestion events, it is 324 possible that no valid credit state is available at the audit when a 325 congestion event occurs. An audit implementation should take this 326 into account by ignoring the first criterion for some time. We 327 recommend starting to take credit into account after one minute. 329 TODO: is this the right way? this should be enough for the first 330 congestion epoch, but disregards credit build up in slow start. Or 331 give some credit on Credit for the start? how much? 333 2.6. Handling Loss of ConEx-marked Packets 335 ConEx-marked packets will be sent just after the sender noticed a 336 congestion signal, so often this sender will just have reduced its 337 sending rate. Thus the loss probability for ConEx-marked packets is 338 expected to be lower than for the average flow. Nevertheless, ConEx- 339 marked packets can be lost. The sender should re-send the ConEx- 340 signal. This induces additional delay for that ConEx-signal but this 341 is taken into account by using 2xRTT_MAX as threshold for penalties. 342 By that false positives of the auditor misbehavior detection are 343 avoided. Only if two ConEx-marked packets are lost in subsequent 344 RTTs, the auditor will penalize a flow of a well-behaving sender. To 345 avoid even these rare cases at least for long-lasting connections, 346 the audit may use the fraction of lost packets of that connection to 347 allow for the same fraction of loss for each ConEx-mark (E, L and C) 348 for a time longer than 2xRTT_MAX. Nevertheless, the rare event of 349 loss of ConEx-marked packets will often cause the audit to penalize 350 the flow for one RTT. We deem this price being acceptable for the 351 clean and robust auditor design made possible by making the sender 352 responsible for successful delivery of ConEx signals. 354 3. Acknowledgements 356 We would like to thank Bob Briscoe for his input (based on research 357 work of his PhD thesis). 359 4. Security Considerations 361 Here known / identified attacks will be discussed. Bob Briscoe's 362 dissertation provides good material here. big TODO. 364 5. IANA Considerations 366 This document has no IANA considerations. 368 6. References 370 6.1. Normative References 372 [draft-ietf-conex-abstract-mech] 373 Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 374 Concepts and Abstract Mechanism", draft-ietf-conex- 375 abstract-mech-08 (work in progress), October 2013. 377 [draft-ietf-conex-destopt] 378 Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6 379 Destination Option for ConEx", draft-ietf-conex-destopt-05 380 (work in progress), March 2013. 382 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 383 of Explicit Congestion Notification (ECN) to IP", 384 RFC 3168, DOI 10.17487/RFC3168, September 2001, 385 . 387 6.2. Informative References 389 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 390 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 391 . 393 Authors' Addresses 395 David Wagner 396 University of Stuttgart 397 Pfaffenwaldring 47 398 70569 Stuttgart 399 Germany 401 Email: david.wagner@ikr.uni-stuttgart.de 403 Mirja Kuehlewind 404 ETH Zurich 405 Gloriastrasse 35 406 8092 Zurich 407 Switzerland 409 Email: mirja.kuehlewind@tik.ee.ethz.ch