idnits 2.17.1 draft-trammell-plus-statefulness-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 (December 22, 2016) is 2676 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.hardie-path-signals' is defined on line 687, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-hardie-path-signals-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-00 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kuehlewind 3 Internet-Draft B. Trammell 4 Intended status: Informational ETH Zurich 5 Expires: June 25, 2017 J. Hildebrand 6 December 22, 2016 8 Transport-Independent Path Layer State Management 9 draft-trammell-plus-statefulness-02 11 Abstract 13 This document describes a simple state machine for stateful network 14 devices on a path between two endpoints to associate state with 15 traffic traversing them on a per-flow basis, as well as abstract 16 signaling mechanisms for driving the state machine. This state 17 machine is intended to replace the de-facto use of the TCP state 18 machine or incomplete forms thereof by stateful network devices in a 19 transport-independent way, while still allowing for fast state 20 timeout of non-established or undesirable flows. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 25, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Uniflow States . . . . . . . . . . . . . . . . . . . . . 7 60 3.2. Biflow States . . . . . . . . . . . . . . . . . . . . . . 7 61 3.3. Additional States and Actions . . . . . . . . . . . . . . 8 62 4. Abstract Signaling Mechanisms . . . . . . . . . . . . . . . . 8 63 4.1. Flow Identification . . . . . . . . . . . . . . . . . . . 9 64 4.2. Association and Confirmation Signaling . . . . . . . . . 9 65 4.3. Bidirectional Stop Signaling . . . . . . . . . . . . . . 11 66 4.3.1. Authenticated Stop Signaling . . . . . . . . . . . . 11 67 4.4. Separate Utility . . . . . . . . . . . . . . . . . . . . 12 68 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 69 5.1. Middlebox Deployment . . . . . . . . . . . . . . . . . . 12 70 5.2. Endpoint Deployment . . . . . . . . . . . . . . . . . . . 13 71 6. Signal mappings for transport protocols . . . . . . . . . . . 13 72 6.1. Signal mapping for TCP . . . . . . . . . . . . . . . . . 13 73 6.2. Signal mapping for QUIC . . . . . . . . . . . . . . . . . 14 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 79 10.2. Informative References . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 The boundary between the network and transport layers was originally 85 defined to be that between information used (and potentially 86 modified) hop-by-hop, and that used end-to-end. End-to-end 87 information in the transport layer is associated with state at the 88 endpoints, but processing of network-layer information was assumed to 89 be stateless. 91 The widespread deployment of stateful middleboxes in the Internet, 92 such as network address and port translators (NAPT), firewalls that 93 model the TCP state machine to distinguish packets belonging from 94 desirable flows from backscatter and random attack traffic, and 95 devices which keep per-flow state for reporting and monitoring 96 purposes (e.g. IPFIX [RFC7011] Metering Processes), has broken this 97 assumption, and made it more difficult to deploy non-TCP transport 98 protocols in the Internet. 100 The deployment of new transport protocols encapsulated in UDP with 101 encrypted transport headers (such as QUIC [I-D.ietf-quic-transport]) 102 will present a challenge to the operation of these devices, and their 103 ubquity likewise threatens to impair the deployability of these 104 protocols. There are two main causes for this problem: first, 105 stateful devices often use an internal model of the TCP state machine 106 to determine when TCP flows start and end, allowing them to manage 107 state for these flows; for UDP flows, they must rely on timeouts. 108 These timeouts are generally short relative to those for TCP 109 [IMC-GATEWAYS], requiring UDP- encapsulated transports either to 110 generate unproductive keepalive traffic for long-lived sessions, or 111 to tolerate connectivity problems and the necessity of reconnection 112 due to loss of on-path state. 114 This document presents an abstract solution to this problem by 115 defining a transport-independent state machine to be implemented at 116 per-flow state- keeping middleboxes as a replacement for incomplete 117 TCP state modeling. A key concept behind this approach is that 118 encryption of transport protocol headers allows a transport protocol 119 to separate its wire image - what it looks like to devices on path - 120 from its internal semantics. We advocate the creation of a minimal 121 wire image for these protocols that exposes enough information to 122 drive the state machine presented. Present and future evolution of 123 encrypted transport protocols can then happen behind this wire image, 124 and Middleboxes implementing this state machine can use signals from 125 a UDP encapsulation common to a set of encrypted transport protocols 126 can have equivalent state information to that provided by TCP, 127 reducing the friction between deployed middleboxes and these new 128 transport protocols. 130 2. Terminology 132 In this document, the term "flow" is defined to be compatible with 133 the definition given in [RFC7011]: A flow is defined as a set of 134 packets passing a device on the network during a certain time 135 interval. All packets belonging to a particular Flow have a set of 136 common properties. Each property is defined as the result of 137 applying a function to the values of: 139 1. one or more network layer header fields (e.g., destination IP 140 address) or transport layer header fields (e.g., destination port 141 number) that the device has access to; 143 2. one or more characteristics of the packet itself (e.g., number of 144 MPLS labels, etc.); 146 3. one or more of the fields derived from packet treatment at the 147 device (e.g., next-hop IP address, the output interface, etc.). 149 A packet is defined as belonging to a flow if it completely satisfies 150 all the defined properties of the flow. 152 A bidirectional flow or biflow is defined as compatible with 153 [RFC5103], by joining the "forward direction" flow with the "reverse 154 direction" flow, derived by reversing the direction of directional 155 fields (ports and IP addresses). Biflows are only relevant at 156 devices positioned so as to see all the packets in both directions of 157 the biflow, generally on the endpoint side of the service demarcation 158 point for either endpoint as defined in the reference path given in 159 [RFC7398]. 161 3. State Machine 163 A transport-independent state machine for on-path devices is shown in 164 Figure 1. It was designed to have the following properties: 166 o A device on path that can see traffic in both directions between 167 two endpoints knows that each side of an association wishes that 168 association to continue. This allows firewalls to delegate policy 169 decisions about accepting or continuing an association to the 170 servers they protect. 172 o A device on path that can see traffic in both directions between 173 two endpoints knows that each device can receive traffic at the 174 source address it provides. This allows firewalls to provide 175 protection against trivially spoofed packets. 177 Both of these properties hold with current firewalls and network 178 address translation devices observing the flags and sequence/ 179 acknowledgment numbers exposed by TCP. 181 It relies on six states, three configurable timeouts, and a set of 182 signals defined in Section 4. The states are defined as follows: 184 o zero: there is no state for a given flow at the device 186 o uniflow: at least one packet has been seen in one direction 188 o associating: at least one packet has been seen in one direction, 189 and an indication that the receiving endpoint wishes to continue 190 the association has been seen in the other direction. 192 o associated: a flow in associating state has further demonstrated 193 that the initial sender can receive packets at its given source 194 address. 196 o half-close: one side of a connection has sent an explicit stop 197 signal, waiting for confirmation 199 o closing: stop signal confirmed, association is closing. 201 We refer to the zero and uniflow states as "uniflow states", as they 202 are relevant both for truly unidirectional flows, as well as in 203 situations where an on-path device can see only one side of a 204 communication. We refer to the remaining four states as "biflow 205 states", as they are only applicable to true bidirectional flows, 206 where the on-path device can see both sides of the communication. 208 `- - - - - - - - - - - - - - - - - - - - - - - - - - - -' 209 ` +============+ a->b +============+ ' 210 ` / \--------->/ \<-+ ' 211 +--->( zero ) ( uniflow ) | a->b ' 212 ^ ` \ /<---------\ /--+ ' 213 | ` +============+ TO_IDLE +============+ ' 214 | `- - - - - - - - - - or - | association - - - - -' 215 | stop signal V signal 216 | +============+ 217 | TO_IDLE / \ 218 +<-----------------------( associating ) 219 | \ / 220 | +============+ 221 | | confirmation 222 | V signal 223 | +============+ 224 | TO_ASSOCIATED / \<-+ 225 +<-----------------------( associated ) | any packet 226 | \ /--+ 227 | +============+ 228 | | stop 229 | V signal 230 | +============+ 231 | TO_ASSOCIATED / \<-+ 232 +<-----------------( half-close ) | any packet 233 | \ /--+ 234 | +============+ 235 | | stop confirmation 236 | V signal 237 | +============+ 238 | TO_CLOSING / \ 239 +------------( closing ) 240 \ / 241 +============+ 243 Figure 1: Transport-Independent State Machine for Stateful On-Path 244 Devices 246 The three timeouts are defined as follows: 248 o TO_IDLE, the unidirectional idle timeout, can be considered 249 equivalent to the idle timeout for transport protocols where the 250 device has no information about session start and end (e.g. most 251 UDP protocols). 253 o TO_ASSOCIATED, the bidirectional idle timeout, can be considered 254 equivalent to the timeout for transport protocols where the device 255 has information about session start and end (e.g. TCP). 257 o TO_CLOSING is the closing timeout: how long the device will 258 account additional packets to a flow after confirming a close 259 signal, ensuring a reordered close signal doesn't create a new 260 flow. 262 Selection of timeouts is a configuration and implementation detail, 263 but generally TO_CLOSING <= TO_IDLE << TO_ASSOCIATED; see 264 [IMC-GATEWAYS]. 266 3.1. Uniflow States 268 Every packet received by a device keeping per-flow state must 269 associate that packet with a flow (see Section 4.1). When a device 270 receives a packet associated with a flow it has no state for, and it 271 is configured to forward the packet instead of dropping it, it moves 272 that flow from the zero state into the uniflow state and starts a 273 timer TO_IDLE. It resets this timer for any additional packet it 274 forwards in the same direction as long as the flow remains in the 275 uniflow state. When timer TO_IDLE expires on a flow in the uniflow 276 state, the device drops state for the flow and performs any 277 processing associated with doing so: tearing down NAT bindings, 278 closing associated firewall pinholes, exporting flow information, and 279 so on. The device may also drop state on a stop signal, if observed. 281 Some devices will only see one side of a communication, e.g. if they 282 are placed in a portion of a network with asymmetric routing. These 283 devices use only the zero and uniflow states (as marked in Figure 1.) 284 In addition, true uniflows - protocols which are solely 285 unidirectional (e.g. some applications over UDP) - will also use only 286 the uniflow-only states. In either case, current devices generally 287 don't associate much state with observed uniflows, and an idle 288 timeout is generally sufficient to expire this state. 290 3.2. Biflow States 292 A uniflow transitions to the associating state when the device 293 observes an association signal, and further to the associated state 294 when the device observes a subsequent confirmation signal; see 295 Section 4.2 for details. If the flow has not transitioned to from 296 the associating to the associated state after TO_IDLE, the device 297 drops state for the flow. 299 After transitioning to the associated state, the device starts a 300 timer TO_ASSOCIATED. It resets this timer for any packet it forwards 301 in either direction. The associated state represents a fully 302 established bidirectional communication. When timer TO_ASSOCIATED 303 expires, the device assumes that the flow has shut down without 304 signaling as such, and drops state for the flow, performing any 305 associated processing. When a bidirectional stop signal (see 306 Section 4.3) is confirmed, the flow transitions to the closing state. 308 When a flow enters the closing state, it starts a timer TO_CLOSING. 309 While the stop signal should be the last packet on a flow, the 310 TO_CLOSING timer ensures that reordered packets after the stop signal 311 will be accounted to the flow. When this timer expires, the device 312 drops state for the flow, performing any associated processing. 314 3.3. Additional States and Actions 316 This document is concerned only with states and transitions common to 317 transport- and function- independent state maintenance. Devices may 318 augment the transitions in this state diagram depending on their 319 function. For example, a firewall that decides based on some 320 information beyond the signals used by this state machine to shut 321 down a flow may transition it directly to a blacklist state on 322 shutdown. Or, a firewall may fail to forward additional packets in 323 the uniflow state until an association signal is observed. 325 4. Abstract Signaling Mechanisms 327 The state machine in Section 3 requires four signals: a new flow 328 signal, the first packet observed in a flow in the zero state; an 329 association signal, allowing a device to verify that an endpoint 330 wishes a bidirectional communication to be established or to 331 continue; a confirmation signal, allowing a device to confirm that 332 the initiator of a flow is reachable at its purported source address; 333 and a stop signal, noting that an endpoint wishes to stop a 334 bidirectional communication. Additional related signals may also be 335 useful, depending on the function a device provides. There are a few 336 different ways to implement these signals; here, we explore the 337 properties of some potential implementations. 339 We assume the following general requirements for these signals; 340 parallel to those given in [draft-trammell-plus-abstract-mech]: 342 o At least the endpoints can verify the integrity of the signals 343 exposed, and shut down a transport association when that 344 verification fails, in order to reduce the incentive for on-path 345 devices to attempt to spoof these signals. 347 o Endpoints and devices on path can probabilistically verify that a 348 originator of a signal is on-path. 350 4.1. Flow Identification 352 In order to keep per-flow state, each device using this state machine 353 must have a function it can apply to each packet to be able to 354 extract common properties to identify the flow it is associated with. 355 In general, the set of properties used for flow identification on 356 presently deployed devices includes the source and destination IP 357 address, the source and destination transport layer port number, the 358 transport protocol number. The differentiated services field 359 [RFC2474] may also be included in the set of properties defining a 360 flow, since it may indicate different forwarding treatment. 362 However, other protocols may use additional bits in their own headers 363 for flow identification. In any case, a protocol implementing 364 signaling for this state machine must specify the function used for 365 flow identification. 367 4.2. Association and Confirmation Signaling 369 An association signal indicates that the endpoint that received the 370 first packet seen by the device has indeed seen that packet, and is 371 interested in continuing conversation with the sending endpoint. 372 This signal is roughly an in-band analogue to consent signaling in 373 ICE [RFC7675] that is carried to every device along the path. 375 A confirmation signal indicates that the endpoint that sent the first 376 packet seen by the device is reachable at its purported source 377 address, and is necessary to prevent spoofed or reflected packets 378 from driving the state machine into the associated state. It is 379 roughly equivalent to the final ACK in the TCP three-way handshake. 381 These two signals are related to each other, in that association 382 requires the receiving endpoint of the first packet to prove it has 383 seen that packet (or a subsequent packet), and to acknowledge it 384 wants to continue the association; while confirmation requires the 385 sending endpoint to prove it has seen the association token. 387 Transport-independent, path-verifiable association and confirmation 388 signaling can be implemented using three values carried in the packet 389 headers: an association token, a confirmation nonce, and an echo 390 token. 392 The association token is a cryptographically random value generated 393 by the endpoint initiating a connection, and is carried on packets in 394 the uniflow state. When a receiving endpoint wishes to send an 395 association signal, it generates an echo token from the association 396 token using a well-known, defined function (e.g. a truncated SHA-256 397 hash), and generates a cryptographically random confirmation nonce. 399 The initiating endpoint sends a confirmation signal on the next 400 packet it sends after receiving the confirmation nonce, by applying a 401 function to the echo token and the confirmation nonce, and sending 402 the result as a new association token. 404 Devices on path verify that the echo token corresponds to a 405 previously seen association token to recognize an association signal, 406 and recognize that an association token corresponds to a previously 407 seen echo token and confirmation nonce to recognize an association 408 signal. 410 These signals could be exposed on only first few packets of a 411 connection (those corresponding to the cryptographic and/or transport 412 state handshakes in the overlying protocols). In this case, an on- 413 path device would need to observe the start of the flow to establish 414 state. They could also be present on every packet in the flow, 415 allowing state to be re-established even in the middle of a flow with 416 longer idle periods than the TO_ESTABLISHED timeout value. In this 417 case, the series of exposed association tokens, echo tokens, and 418 confirmation nonces can be observed to derive a running round-trip 419 time estimate for the flow. 421 If the association token and confirmation nonce are predictable, off- 422 path devices can spoof association and confirmation signals. In 423 choosing the number of bits for an association token, there is a 424 tradeoff between per-packet overhead and state overhead at on-path 425 devices, and assurance that an association token is hard to guess. 426 This tradeoff must be evaluated at protocol design time. 428 There are a few considerations in choosing a function (or functions) 429 to generate the echo token from the association token, to verify an 430 echo token given an association token, and to derive a next 431 association token from the echo token and confirmation nonce. The 432 functions could be extremely simple (e.g., identity for the echo 433 token and addition for the nonce) for ease of implementation even in 434 extremely constrained environments. Using one-way functions (e.g., 435 truncated SHA-256 hash to derive echo token from association token; 436 XOR followed by truncated SHA-256 hash to derive association token 437 from echo token and confirmation nonce) requires slightly more work 438 from on-path devices, but the primitives will be available at any 439 endpoint using an encrypted transport protocol. In any case, a 440 concrete implementation of association and confirmation signaling 441 must choose a set of functions, or mechanism for unambiguously 442 choosing one, at both endpoints as well as along the path. 444 4.3. Bidirectional Stop Signaling 446 The transport-independent state machine uses bidirectional stop 447 signaling to tear down state. This requires a stop signal to be 448 observed in one direction, and a stop confirmation signal to be 449 observed in the other, to complete closing an association. 451 A stop signal is directly carried or otherwise encoded in the 452 protocol header to indicate that a flow is ending, whether normally 453 or abnormally, and that state associated with the flow should be torn 454 down. Upon decoding a stop signal, a device on path should move the 455 flow from uniflow state to zero, or from associated state to half- 456 close state, to wait for a confirmation signal in the other 457 direction. While in half-close state, state will be maintained until 458 a timer set to TO_ASSOCIATED expires, with any packet forwarded in 459 either direction reseting the timer. 461 A stop confirmation signal is directly carried or otherwise encoded 462 in the protocol header to indicate that the endpoint receiving the 463 stop signal confirms that the stop signal is valid. The stop 464 confirmation signal contains some assurance that the far endpoint has 465 seen the stop signal. When a stop confirmation signal is observed in 466 the opposite direction from the stop signal, a device on path should 467 move the flow from half-close state to closing state. The flow will 468 then remain in closing state until a timer set to TO_CLOSING has 469 expired, after which state for the flow will be dropped. The closing 470 timeout TO_CLOSING is intended to ensure that any packets reordered 471 in delivery are accounted to the flow before state for it is dropped. 473 We assume the encoding of stop and stop confirmation signals into a 474 packet header, as with all other signals, is integrity protected end- 475 to-end. Stop signals, as association signals, could be forged by one 476 on-path device. However, unless a stop confirmation signal that can 477 be associated with the stop signal is observed in the other 478 direction, the flow remains in half-close state, during which state 479 is maintained and packets continue to be forwarded in both 480 directions. So this attack is of limited utility unless an attacker 481 controls two on-path devices on either side of a target device to 482 spoof both stop and corresponding stop confirmation signals. 484 4.3.1. Authenticated Stop Signaling 486 Additionally, the stop and stop confirmation signals could be 487 designed to authenticate themselves. Each endpoint could reveal a 488 stop hash during the initial association, which is the result of a 489 chosen cryptographic hash function applied to a stop token which that 490 endpoint keeps secret. An endpoint wishing to end the association 491 then reveals the stop token, which can be verified both by the far 492 endpoint and devices on path which have cached the stop hash to be 493 authentic. A stop confirmation signal additionally contains 494 information derived from the initiating stop signal's stop token, as 495 further assurance that the stop token was observed by the far 496 endpoint. 498 4.4. Separate Utility 500 Although all of these signals are required to drive the state machine 501 described by this document, note that association/confirmation and 502 bidirectional stop signaling have separate utility. A transport 503 protocol may expose the end of a flow without any proof of 504 association or confirmation of return routability of the initiator. 505 Alternately, the transport protocol could rely on short timeouts to 506 clean up stale state on path, while exposing continuous association 507 and confirmation signals to quickly reestablish state. 509 5. Deployment Considerations 511 The state machine defined in this document is most useful when 512 implemented in a single instantiation (wire format for signals, and 513 selection of functions for deriving values to be exposed and 514 verified) by multiple transport protocols. It is intended for use 515 with protocols that encrypt their transport- layer headers, and that 516 are encapsulated within UDP, as is the case with QUIC 517 [I-D.ietf-quic-transport]. Definition of that instantiation is out 518 of scope for the present revision of this document. 520 The following subsections discuss incentives for deployment of this 521 state machine both at middleboxes and at endpoints. 523 5.1. Middlebox Deployment 525 The state machine defined herein is designed to replace TCP state- 526 tracking for firewalls and NAT devices. When encrypted transport 527 protocols encapsulated in UDP adopt a set of signals and a wire 528 format for those signals to drive this state machine, these 529 middleboxes could continue using TCP-like logic to handle those UDP 530 flows. Recognizing the wire format used by those signals would allow 531 these middleboxes to distinguish "UDP with an encrypted transport" 532 from undifferentiated UDP, and to treat the former case more like 533 TCP, providing longer timeouts for established flows, as well as 534 stateful defense against spoofed or reflected garbage traffic. 536 5.2. Endpoint Deployment 538 An encrypted, UDP-encapsulated transport protocol has two primary 539 incentives to expose these signals. First, allowing firewalls on 540 networks that generally block UDP (about 3-5% of Internet-connected 541 networks, depending on the study) to distinguish "UDP with an 542 encrypted transport" traffic from other UDP traffic may result in 543 less blocking of that traffic. Second, the difference between the 544 timeouts TO_IDLE and TO_ASSOCIATED, as well as the continuous state 545 establishment possible with some instantiations of the association 546 and confirmation signals, would allow these transport protocols to 547 send less unproductive keepalive traffic for long-lived, sparse 548 flows. 550 While both of these advantages require middleboxes on path to 551 recognize and use the signals driving this state machine, we note 552 that content providers driving the deployment of this protocols are 553 also operators of their own content provision networks, and that many 554 of the benefits of encrypted- encapsulated transport firewalls will 555 accrue to them, giving these content providers incentives to deploy 556 both endpoints and middleboxes. 558 6. Signal mappings for transport protocols 560 We now show how this state machine can be driven by signals available 561 in TCP and QUIC. 563 6.1. Signal mapping for TCP 565 A mapping of TCP flags to transitions in to the state machine in 566 Section 3 shows how devices currently using a model of the TCP state 567 machine can be converted to use this state machine. 569 TCP [RFC0793] provides start-of-flow association only. A packet with 570 the SYN and ACK flags set in the absence of the FIN or RST flags, and 571 an in-window acknowledgment number, is synonymous with the 572 association signal. A packet with the ACK flag set in the absence of 573 the FIN or RST flags after an initial SYN, and an in-window 574 acknowledgment number, is synonymous with the confirmation signal. 575 For a typical TCP flow: 577 1. The initial SYN places the flow into uniflow state, 579 2. The SYN-ACK sent in reply acts as a association signal and places 580 the flow into associating state, 582 3. The ACK sent in reply acts as a confirmation signal and places 583 the flow into associated state, 585 4. The final FIN is a stop signal, and 587 5. the ACK of the final FIN is a stop confirmation signal, moving 588 the flow into closing state. 590 Note that abormally closed flows (with RST) do not provide stop 591 confirmation, and are therefore not provided for by this state 592 machine. Due to TCP's support for half-closed flows, additional 593 state modeling is necessary to extract a stop signal from the final 594 FIN. 596 Note also that the association and stop signals derived from the TCP 597 header are not integrity protected, and association and confirmation 598 signals based on in-window ACK are not particularly resistant to off- 599 path attacks [IMC-TCP]. The state machine is therefore more 600 susceptible to manipulation when used with vanilla TCP as when with a 601 transport protocol providing full integrity protection for its 602 headers end-to-end. 604 6.2. Signal mapping for QUIC 606 QUIC [I-D.ietf-quic-transport] is a moving target; however, signals 607 for driving this state machine are fundamentally compatible with the 608 protocol's design and could easily be added to the protocol 609 specification. 611 Specifically, as of this writing, QUIC's 64-bit connection ID, 612 together with integrity protection of the connection ID provided by 613 QUIC's cryptographic protocol [I-D.ietf-quic-tls], could be used as 614 an association and echo token as in Section 4.2. A mechanism 615 equivalent to the confirmation nonce is presently missing and would 616 have to be added. Note that adding monotonically increasing, 617 initially-random packet serial numbers, as well as echo of the last 618 packet serial number seen, to the QUIC packet header, would provide 619 an equivalent mechanism, allowing a confirmation signal to be derived 620 from the echo of a previously seen association signal's serial 621 number. 623 The addition of a public reset signal that would act as a stop signal 624 as in Section 4.3 is presently under discussion on the QUIC mailing 625 list; one proposal for self-authenticating public reset inspired the 626 addition of Section 4.3.1 to this document. 628 7. IANA Considerations 630 This document has no actions for IANA. 632 8. Security Considerations 634 This document defines a state machine for transport-independent state 635 management on middleboxes, using in-band signaling, to replace the 636 commonly- implemented current practice of incomplete TCP state 637 modeling on these devices. It defines new signals for state 638 management. While these signals can be spoofed by any device on path 639 that observes traffic in both directions, we presume the presence of 640 end-to-end integrity protection of these signals provided by the 641 upper-layer transport driving them. This allows such spoofing to be 642 detected and countered by endpoints, reducing the threat from on-path 643 devices to connection disruption, which such devices are trivially 644 placed to perform in any case. 646 9. Acknowledgments 648 Thanks to Christian Huitema for discussions leading to this document, 649 and to Andrew Yourtchenko for the feedback. The mechanism for using 650 a revealed value to prove ownership of a stop token was inspired by 651 Eric Rescorla's suggestion to use a fundamentally identical mechanism 652 for the QUIC public reset. 654 This work is partially supported by the European Commission under 655 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 656 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 657 for Education, Research, and Innovation under contract no. 15.0268. 658 This support does not imply endorsement. 660 10. References 662 10.1. Normative References 664 [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export 665 Using IP Flow Information Export (IPFIX)", RFC 5103, 666 DOI 10.17487/RFC5103, January 2008, 667 . 669 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 670 "Specification of the IP Flow Information Export (IPFIX) 671 Protocol for the Exchange of Flow Information", STD 77, 672 RFC 7011, DOI 10.17487/RFC7011, September 2013, 673 . 675 [RFC7398] Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 676 A. Morton, "A Reference Path and Measurement Points for 677 Large-Scale Measurement of Broadband Performance", 678 RFC 7398, DOI 10.17487/RFC7398, February 2015, 679 . 681 10.2. Informative References 683 [draft-trammell-plus-abstract-mech] 684 Trammell, B., "Abstract Mechanisms for a Cooperative Path 685 Layer under Endpoint Control", September 2016. 687 [I-D.hardie-path-signals] 688 Hardie, T., "Path signals", draft-hardie-path-signals-00 689 (work in progress), October 2016. 691 [I-D.ietf-quic-tls] 692 Thomson, M. and (. (Unknown), "Using Transport Layer 693 Security (TLS) to Secure QUIC", draft-ietf-quic-tls-00 694 (work in progress), November 2016. 696 [I-D.ietf-quic-transport] 697 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 698 and Secure Transport", draft-ietf-quic-transport-00 (work 699 in progress), November 2016. 701 [IMC-GATEWAYS] 702 Hatonen, S., Nyrhinen, A., Eggert, L., Strowes, S., 703 Sarolahti, P., and M. Kojo, "An experimental study of home 704 gateway characteristics (Proc. ACM IMC 2010)", October 705 2010. 707 [IMC-TCP] Luckie, M., Beverly, R., Wu, T., Allman, M., and k. 708 claffy, "Resilience of Deployed TCP to Blind Attacks. 709 (Proc. ACM IMC 2015)", October 2015. 711 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 712 RFC 793, DOI 10.17487/RFC0793, September 1981, 713 . 715 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 716 "Definition of the Differentiated Services Field (DS 717 Field) in the IPv4 and IPv6 Headers", RFC 2474, 718 DOI 10.17487/RFC2474, December 1998, 719 . 721 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 722 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 723 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 724 October 2015, . 726 Authors' Addresses 728 Mirja Kuehlewind 729 ETH Zurich 730 Gloriastrasse 35 731 8092 Zurich 732 Switzerland 734 Email: mirja.kuehlewind@tik.ee.ethz.ch 736 Brian Trammell 737 ETH Zurich 738 Gloriastrasse 35 739 8092 Zurich 740 Switzerland 742 Email: ietf@trammell.ch 744 Joe Hildebrand 746 Email: hildjj@cursive.net