One document matched: draft-trammell-plus-statefulness-00.txt
Network Working Group M. Kuehlewind
Internet-Draft B. Trammell
Intended status: Informational ETH Zurich
Expires: April 22, 2017 J. Hildebrand
October 19, 2016
Transport-Independent Path Layer State Management
draft-trammell-plus-statefulness-00
Abstract
This document describes a simple state machine for stateful network
devices on a path between two endpoints to associate state with
traffic traversing them on a per-flow basis, as well as abstract
signaling mechanisms for driving the state machine. This state
machine is intended to replace the de-facto use of the TCP state
machine or incomplete forms thereof by stateful network devices in a
transport-independent way, while still allowing for fast state
timeout of non-established or undesirable flows.
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 22, 2017.
Copyright Notice
Copyright (c) 2016 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
Kuehlewind, et al. Expires April 22, 2017 [Page 1]
Internet-Draft PLUS Statefulness October 2016
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Uniflow States . . . . . . . . . . . . . . . . . . . . . 5
3.2. Biflow States . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Additional States and Actions . . . . . . . . . . . . . . 6
4. Abstract Signaling Mechanisms . . . . . . . . . . . . . . . . 6
4.1. Flow Identification . . . . . . . . . . . . . . . . . . . 7
4.2. Association Signaling . . . . . . . . . . . . . . . . . . 7
4.3. Stop Signaling . . . . . . . . . . . . . . . . . . . . . 8
4.4. Timeout Exposure . . . . . . . . . . . . . . . . . . . . 9
5. Signal mappings for transport protocols . . . . . . . . . . . 9
5.1. Signal mapping for TCP . . . . . . . . . . . . . . . . . 9
5.2. Signal mapping for QUIC . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The boundary between the network and transport layers was originally
defined to be that between information used (and potentially
modified) hop-by-hop, and that used end-to-end. End-to-end
information in the transport layer is associated with state at the
endpoints, but processing of network-layer information was assumed to
be stateless.
The widespread deployment of stateful middleboxes in the Internet,
such as network address and port translators (NAPT), firewalls that
model the TCP state machine to distinguish packets belonging from
desirable flows from backscatter and random attack traffic, and
devices which keep per-flow state for reporting and monitoring
purposes (e.g. IPFIX [RFC7011] Metering Processes), has broken this
assumption, and made it more difficult to deploy non-TCP transport
protocols in the Internet.
Kuehlewind, et al. Expires April 22, 2017 [Page 2]
Internet-Draft PLUS Statefulness October 2016
The deployment of new transport protocols encapsulated in UDP with
encrypted transport headers (such as QUIC
[I-D.hamilton-quic-transport-protocol]) will present a challenge to
the operation of these devices, and their ubquity likewise threatens
to impair the deployability of these protocols. There are two main
causes for this problem: first, stateful devices often use an
internal model of the TCP state machine to determine when TCP flows
start and end, allowing them to manage state for these flows; for UDP
flows, they must rely on timeouts. These timeouts are generally
short relative to those for TCP [IMC-GATEWAYS], requiring UDP-
encapsulated transports either to generate unproductive keepalive
traffic for long-lived sessions, or to tolerate connectivity problems
and the necessity of reconnection due to loss of on-path state.
This document presents a solution to this problem by defining a state
machine that is transport independent to be implemented at per-flow
state-keeping middleboxes as a replacement for incomplete TCP state
modeling. Middleboxes implementing this state machine using signals
from a common UDP encapsulation layer can have equivalent necessary
state information to that provided by TCP, reducing the friction
between middleboxes and these new transport protocols.
2. Terminology
In this document, the term "flow" is defined to be compatible with
the definition given in [RFC7011]: A flow is defined as a set of
packets passing a device on the network during a certain time
interval. All packets belonging to a particular Flow have a set of
common properties. Each property is defined as the result of
applying a function to the values of:
1. one or more network layer header fields (e.g., destination IP
address) or transport layer header fields (e.g., destination port
number) that the device has access to;
2. one or more characteristics of the packet itself (e.g., number of
MPLS labels, etc.);
3. one or more of the fields derived from packet treatment at the
device (e.g., next-hop IP address, the output interface, etc.).
A packet is defined as belonging to a flow if it completely satisfies
all the defined properties of the flow.
A bidirectional flow or biflow is defined as compatible with
[RFC5103], by joining the "forward direction" flow with the "reverse
direction" flow, derived by reversing the direction of directional
fields (ports and IP addresses). Biflows are only relevant at
Kuehlewind, et al. Expires April 22, 2017 [Page 3]
Internet-Draft PLUS Statefulness October 2016
devices positioned so as to see all the packets in both directions of
the biflow, generally on the endpoint side of the service demarcation
point for either endpoint as defined in the reference path given in
[RFC7398].
3. State Machine
The transport-independent state machine for on-path devices is shown
in Figure 1. It relies on four states, three configurable timeouts,
and a set of signals defined in Section 4. The states are defined as
follows:
o zero: there is no state for a given flow at the device
o uniflow: a packet has been seen in one direction; state will be
kept at the device until it is explicitly cancelled or until
timeout t1 elapses without a packet.
o biflow: a packet has been seen in one direction and an indication
that that the receiving endpoint wishes to continue the
association has been seen in the opposite direction; state will be
kept at the device until it is explicitly canceled or until
timeout t2 elapses without a packet.
o closing: an established biflow is shutting down due to an explicit
close indication; state will be kept at the device until timeout
t3 elapses.
The three timeouts are defined as follows:
o t1 is the unidirectional idle timeout. It can be considered
equivalent to the idle timeout for transport protocols where the
device has no information about session start and end (e.g. most
UDP protocols).
o t2 is the bidirectional idle timeout. It can be considered
equivalent to the timeout for transport protocols where the device
has information about session start and end (e.g. TCP).
o t3 is the closing timeout: how long the device will account
additional packets to a flow after observing a stop signal, and is
generally applied to ensuring a reordered stop signal doesn't
create a new flow.
Selection of timeouts is a configuration and implementation detail,
but generally t3 <= t1 < t2.
Kuehlewind, et al. Expires April 22, 2017 [Page 4]
Internet-Draft PLUS Statefulness October 2016
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
' '
' +----+ p(s->d) +-----+ '
' / \---------->/ \----+ ' UNIFLOW
' ( zero ) ( uniflow ) p(s->d) ' ONLY
' \ /<----------\ /<---+ ' STATES
' +----+ t1 +-----+ '
'_ _ _ ^_^ _ _ _ _ _ _ _ _ | _ _ _ _ _ _ _'
t3 | \ | association
| \__________ v
+-----+ t2 \ +----+
/ \ \/ \----+
( closing )<--------( biflow ) p(s<->d)
\ / stop \ /<---+
+-----+ +----+
Figure 1: Transport-Independent State Machine for Stateful On-Path
Devices
3.1. Uniflow States
Every packet received by a device keeping per-flow state must
associate that packet with a flow (see Section 4.1). When a device
receives a packet associated with a flow it has not state forward,
and it is configured to forward the packet instead of dropping it, it
moves that flow from the zero state into the uniflow state and starts
a timer t1. It resets this timer for any additional packet it
forwards in the same direction as long as the flow remains in the
uniflow state. When timer t1 expires on a flow in the uniflow state,
the device drops state for the flow and performs any processing
associated with doing so: tearing down NAT bindings, closing
associated firewall pinholes, exporting flow information, and so on.
The device may also drop state on a stop signal, if observed.
Some devices will only see one side of a communication, e.g. if they
are placed in a portion of a network with asymmetric routing. These
devices use only the zero and uniflow states (as marked in Figure 1.)
In addition, true uniflows - protocols which are solely
unidirectional (e.g. some applications over UDP) - will also use only
the uniflow-only states. In either case, current devices generally
don't associate much state with observed uniflows flows, and timeout
is generally sufficient to expire this state.
Kuehlewind, et al. Expires April 22, 2017 [Page 5]
Internet-Draft PLUS Statefulness October 2016
3.2. Biflow States
A uniflow transitions to the biflow state when the device observes an
association signal. An association signal consists of a packet sent
in the opposite direction from the uniflow packet(s), with certain
properties as defined in Section 4.2. After transitioning to the
biflow state, the device starts a timer t2. It resets this timer for
any packet it forwards in either direction. The biflow state
represents a fully established bidirectional communication. When
timer t2 expires, the device assumes that the flow has shut down
without signaling as such, and drops state for the flow, performing
any associated processing. When a stop signal is observed in either
direction, the flow transitions to the closing state.
When a flow enters the closing state, it starts a timer t3. While
the stop signal should be the last packet on a flow, the t3 timer
ensures that reordered packets after the stop signal will be
accounted to the flow. When this timer expires, the device drops
state for the flow, performing any associated processing.
3.3. Additional States and Actions
This document is concerned only with states and transitions common to
transport- and function- independent state maintenance. Devices may
augment the transitions in this state diagram depending on their
function. For example, a firewall that decides based on some
information beyond the signals used by this state machine to shut
down a flow may transition it directly to a blacklist state on
shutdown. Or, a firewall may fail to forward additional packets in
the uniflow state until an association signal is observed.
4. Abstract Signaling Mechanisms
The state machine in Section 3 requires three signals: a new flow
signal (the first packet observed in a flow in the zero state), an
association signal (allowing a device to verify that an endpoint
wishes a bidirectional communication to be established or to
continue), and a stop signal (noting that an endpoint wishes to stop
a bidirectional communication). Additional related signals may also
be useful, depending on the function a device provides. There are a
few different ways to implement these signals; here, we explore the
properties of some potential implementations.
We assume the following general requirements for these signals;
parallel to those given in [draft-trammell-plus-abstract-mech]:
o At least the endpoints can verify the integrity of the signals
exposed, and shut down a transport association when that
Kuehlewind, et al. Expires April 22, 2017 [Page 6]
Internet-Draft PLUS Statefulness October 2016
verification fails, in order to reduce the incentive for on-path
devices to attempt to spoof these signals.
o Endpoints and devices on path can probabilistically verify that a
originator of a signal is on-path.
4.1. Flow Identification
In order to keep per-flow state, each device using this state machine
must have a function it can apply to each packet to be able to
extract common properties to identify the flow it is associated with.
In general, the set of properties used for flow identification on
presently deployed devices includes the source and destination IP
address, the source and destination transport layer port number, the
transport protocol number. The differentiated services field
[RFC2474] may also be included in the set of properties defining a
flow, since it may indicate different forwarding treatment.
However, other protocols may use additional bits in their own headers
for flow identification. In any case, a protocol implementing
signaling for this state machine must specify the function used for
flow identification.
4.2. Association Signaling
An association signal indicates that endpoint that received the first
packet seen by the device is interested in continuing conversation
with the sending endpoint. This signal is roughly an in-band
analogue to consent signaling in ICE [RFC7675] that is carried to
every device along the path.
Transport-independent, path-verifiable association signaling can be
implemented using a association token generated by one endpoint,
present on each packet sent in the flow by that endpoint, and a
response token, derived from the association token using a well-
known, defined function, present on each packet sent in the flow by
the opposite endpoint. We can assume a transport association has an
initiator and a responder; under this assumption, the association
token is chosen by the initiator, and the response token generated by
the responder.
Any packet sent by the responder with a valid response token, and
without a stop signal (see Section 4.3), can then be taken to be a
association signal to continue a bidirectional communication. Note
that, since it relies on a widely-known function, this mechanism does
allow on-path devices to forge association signaling in a way that
downstream on-path devices cannot detect. However, in the presence
of end-to-end signal integrity verification, this forgery will be
Kuehlewind, et al. Expires April 22, 2017 [Page 7]
Internet-Draft PLUS Statefulness October 2016
detected by the endpoint, which MUST terminate the association on a
forged association signal; the flow at the duped on-path device will
transition from biflow to closing within a single packet. This
reduces any attack against the association signaling mechanism to the
disruption of a connection, which on-path devices can do in any case
by simply refusing to forward packets.
Association tokens MUST be chosen by initiators to be hard to guess;
otherwise, off-path devices can spoof association and response
signals. Cryptographic random number generators suffice here. In
choosing the number of bits for an association token, there is a
tradeoff between per-packet overhead and state overhead at on-path
devices, and assurance that an association token is hard to guess.
This tradeoff must be evaluated at protocol design time.
There are a few considerations in choosing a function (or functions)
to generate the response token from the association token, and to
verify a response token given an association token. The simplest
such function is the identity function: the response token is simply
the association token. Simple two-way functions (e.g. one's
complement of the association token) provide additional assurance of
implementation of the protocol, and cannot be accidentally triggered
by simple reflection of unknown bits in a packet. One- way functions
(e.g. truncated SHA-2 hash of the association token) additionally
allow on-path recognition of initiator and responder from the middle
of a flow.
In any case, a concrete implementation of association signaling must
choose a single function, or mechanism for unambiguously choosing
one, at both endpoints as well as along the path.
4.3. Stop Signaling
A stop signal is directly carried or otherwise encoded in the
protocol header to indicate that a flow is ending, whether normally
or abnormally, and that state associated with the flow should be torn
down. Upon decoding a stop signal, a device on path should move the
flow from uniflow state to null, or from biflow state to closing.
Transports should send a stop signal only on the last packet sent in
a bidirectional flow. The closing timeout t3 is intended to ensure
that any packets reordered in delivery are accounted to the flow
before state for it is dropped.
We assume the encoding of a stop signal into a packet header, as with
all other signals, is integrity protected end-to-end. Stop signals,
as association signals, be forged by one on-path device to dupe other
devices into moving flows into the closing state. However, state
Kuehlewind, et al. Expires April 22, 2017 [Page 8]
Internet-Draft PLUS Statefulness October 2016
will be re-established by the continuing flow (and resulting
association signals) after the closing timeout, and an endpoint
receiving a spoofed stop signal could enter a fast re-establishment
phase of the upper layer transport protocol to minimize disruption,
further reducing the incentive to attackers to spoof stop signals.
4.4. Timeout Exposure
Since one of the goals of these mechanisms is to reduce the amount of
non- productive keepalive traffic required for UDP-encapsulated
transport protocols, they MAY be deployed together with a path-to-
receiver signal with feedback as defined in
[draft-trammell-plus-abstract-mech] asking for timeouts t1, t2, and
t3 for a given flow.
5. Signal mappings for transport protocols
We now show how this state machine can be driven by signals available
in TCP and QUIC.
5.1. Signal mapping for TCP
A mapping of TCP flags to transitions in to the state machine in
Section 3 shows how devices currently using a model of the TCP state
machine can be converted to use this state machine.
Simply speaking, an ACK flag [RFC0793] in the absence of the FIN or
RST flags, and an in-window acknowledgment number, is synonymous with
the association signal, while the RST or final FIN flags are stop
signals. For a typical TCP flow:
1. The initial SYN places the flow into uniflow state,
2. The SYN-ACK sent in reply acts as a association signal and places
the flow into biflow state,
3. Any RST moves the flow into closing state, or
4. The final FIN-ACK (not the first half-close FIN) moves the flow
into closing state.
Note that since any valid ACK acts as an association signal, this
mapping allows flows to transition to the biflow state even if the
initial SYN-ACK is not observed. However, generating a stop signal
from FIN does require additional TCP state modeling to prevent moving
into the closing state on a half-close.
Kuehlewind, et al. Expires April 22, 2017 [Page 9]
Internet-Draft PLUS Statefulness October 2016
Note that the association and stop signals derived from the TCP
header are not integrity protected, and an association signal based
on in-window ACK is not particularly resistant to off-path attacks;
the state machine is therefore more susceptible to manipulation when
used with vanilla TCP as when with a transport protocol providing
full integrity protection for its headers end-to-end.
5.2. Signal mapping for QUIC
QUIC [I-D.hamilton-quic-transport-protocol] as presently defined
lacks only a stop signal to be able to drive this state machine.
QUIC's 64-bit connection ID suffices as an association and response
token as in Section 4.2; the response token function is identity.
QUIC's cryptographic protocol, to be based on TLS
[I-D.thomson-quic-tls], will provide the necessary integrity
protection to drive the state machine.
Any number of designs could be chosen to add a stop signal compatible
with the definition in Section 4.3 to QUIC. One is particularly
promising, however. We note that the Public Reset facility described
in section 8 of [I-D.hamilton-quic-transport-protocol] very nearly
meets the criteria; it would need to be expanded to expose normal
termination as well as abnormal termination, and to provide for
endpoint detection of inauthentic termination signals.
6. IANA Considerations
This document has no actions for IANA.
7. Security Considerations
This document defines a state machine for transport-independent state
management on middleboxes, using in-band signaling, to replace the
commonly- implemented current practice of incomplete TCP state
modeling on these devices. It defines new signals for state
management. While these signals can be spoofed by any device on path
that observes traffic in both directions, we presume the presence of
end-to-end integrity protection of these signals provided by the
upper-layer transport driving them. This allows such spoofing to be
detected and countered by endpoints, reducing the threat from on-path
devices to connection disruption, which such devices are trivially
placed to perform in any case.
8. Acknowledgments
Thanks to Christian Huitema for discussions leading to this document.
Kuehlewind, et al. Expires April 22, 2017 [Page 10]
Internet-Draft PLUS Statefulness October 2016
This work is partially supported by the European Commission under
Horizon 2020 grant agreement no. 688421 Measurement and Architecture
for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat
for Education, Research, and Innovation under contract no. 15.0268.
This support does not imply endorsement.
9. References
9.1. Normative References
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export
Using IP Flow Information Export (IPFIX)", RFC 5103,
DOI 10.17487/RFC5103, January 2008,
<http://www.rfc-editor.org/info/rfc5103>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<http://www.rfc-editor.org/info/rfc7011>.
[RFC7398] Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A Reference Path and Measurement Points for
Large-Scale Measurement of Broadband Performance",
RFC 7398, DOI 10.17487/RFC7398, February 2015,
<http://www.rfc-editor.org/info/rfc7398>.
9.2. Informative References
[draft-trammell-plus-abstract-mech]
Trammell, B., "Abstract Mechanisms for a Cooperative Path
Layer under Endpoint Control", September 2016.
[I-D.hamilton-quic-transport-protocol]
Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC:
A UDP-Based Multiplexed and Secure Transport", draft-
hamilton-quic-transport-protocol-00 (work in progress),
July 2016.
[I-D.thomson-quic-tls]
Thomson, M. and R. Hamilton, "Porting QUIC to Transport
Layer Security (TLS)", draft-thomson-quic-tls-00 (work in
progress), March 2016.
[IMC-GATEWAYS]
Hatonen, S., Nyrhinen, A., Eggert, L., Strowes, S.,
Sarolahti, P., and M. Kojo, "An experimental study of home
gateway characteristics (Proc. ACM IMC 2010)", n.d..
Kuehlewind, et al. Expires April 22, 2017 [Page 11]
Internet-Draft PLUS Statefulness October 2016
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.
[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
Thomson, "Session Traversal Utilities for NAT (STUN) Usage
for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
October 2015, <http://www.rfc-editor.org/info/rfc7675>.
Authors' Addresses
Mirja Kuehlewind
ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Email: mirja.kuehlewind@tik.ee.ethz.ch
Brian Trammell
ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Email: ietf@trammell.ch
Joe Hildebrand
Email: hildjj@cursive.net
Kuehlewind, et al. Expires April 22, 2017 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 04:30:32 |