summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8558.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8558.txt')
-rw-r--r--doc/rfc/rfc8558.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc8558.txt b/doc/rfc/rfc8558.txt
new file mode 100644
index 0000000..2f10d8a
--- /dev/null
+++ b/doc/rfc/rfc8558.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB) T. Hardie, Ed.
+Request for Comments: 8558 April 2019
+Category: Informational
+ISSN: 2070-1721
+
+
+ Transport Protocol Path Signals
+
+Abstract
+
+ This document discusses the nature of signals seen by on-path
+ elements examining transport protocols, contrasting implicit and
+ explicit signals. For example, TCP's state machine uses a series of
+ well-known messages that are exchanged in the clear. Because these
+ are visible to network elements on the path between the two nodes
+ setting up the transport connection, they are often used as signals
+ by those network elements. In transports that do not exchange these
+ messages in the clear, on-path network elements lack those signals.
+ Often, the removal of those signals is intended by those moving the
+ messages to confidential channels. Where the endpoints desire that
+ network elements along the path receive these signals, this document
+ recommends explicit signals be used.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Architecture Board (IAB)
+ and represents information that the IAB has deemed valuable to
+ provide for permanent record. It represents the consensus of the
+ Internet Architecture Board (IAB). Documents approved for
+ publication by the IAB are not candidates for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8558.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie Informational [Page 1]
+
+RFC 8558 Transport Protocol Path Signals April 2019
+
+
+Copyright Notice
+
+ Copyright (c) 2019 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
+ (https://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.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Signal Types Inferred ...........................................4
+ 2.1. Session Establishment ......................................4
+ 2.1.1. Session Identity ....................................4
+ 2.1.2. Routability and Intent ..............................4
+ 2.1.3. Flow Stability ......................................5
+ 2.1.4. Resource Requirements ...............................5
+ 2.2. Network Measurement ........................................5
+ 2.2.1. Path Latency ........................................5
+ 2.2.2. Path Reliability and Consistency ....................5
+ 3. Options .........................................................5
+ 3.1. Do Not Restore These Signals ...............................6
+ 3.2. Replace These with Network-Layer Signals ...................6
+ 3.3. Replace These with Per-Transport Signals ...................6
+ 3.4. Create a Set of Signals Common to Multiple Transports ......6
+ 4. Recommendation ..................................................7
+ 5. IANA Considerations .............................................8
+ 6. Security Considerations .........................................8
+ 7. Informative References ..........................................9
+ IAB Members at the Time of Approval ...............................10
+ Acknowledgements ..................................................10
+ Author's Address ..................................................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie Informational [Page 2]
+
+RFC 8558 Transport Protocol Path Signals April 2019
+
+
+1. Introduction
+
+ This document discusses the nature of signals seen by on-path
+ elements examining transport protocols, contrasting implicit and
+ explicit signals. For example, TCP's state machine uses a series of
+ well-known messages that are exchanged in the clear. Because these
+ are visible to network elements on the path between the two nodes
+ setting up the transport connection, they are often used as signals
+ by those network elements. While the architecture of the Internet
+ may be best realized by end-to-end protocols [RFC1958], there are
+ cases such as the use of Network Address Translators [RFC3234] where
+ some functions are commonly provided by on-path network elements. In
+ transports that do not exchange these messages in the clear, on-path
+ network elements lack those signals. Often, the removal of those
+ signals is intended by those moving the messages to confidential
+ channels. Where the endpoints desire that network elements along the
+ path receive these signals, this document recommends explicit signals
+ be used.
+
+ The interpretation of TCP [RFC0793] by on-path elements is an example
+ of implicit signal usage. It uses cleartext handshake messages to
+ establish, maintain, and close connections. While these are
+ primarily intended to create state between two communicating nodes,
+ these handshake messages are visible to network elements along the
+ path between them. It is common for certain network elements to
+ treat the exchanged messages as signals that relate to their own
+ functions.
+
+ A firewall may, for example, create a rule that allows traffic from a
+ specific host and port to enter its network when the connection was
+ initiated by a host already within the network. It may subsequently
+ remove that rule when the communication has ceased. In the context
+ of TCP handshake, it sets up the pinhole rule on seeing the initial
+ TCP SYN acknowledgement and then removes it upon seeing a RST or FIN
+ and ACK exchange. Note that in this case, it does nothing to rewrite
+ any portion of the TCP packet; it simply enables a return path that
+ would otherwise have been blocked.
+
+ When a transport encrypts the fields it uses for state mechanics,
+ these signals are no longer accessible to path elements. The
+ behavior of path elements will then depend on which signal is not
+ available, on the default behavior configured by the path element
+ administrator, and by the security posture of the network as a whole.
+
+
+
+
+
+
+
+
+Hardie Informational [Page 3]
+
+RFC 8558 Transport Protocol Path Signals April 2019
+
+
+2. Signal Types Inferred
+
+ The following list of signals that may be inferred from transport
+ state messages includes those that may be exchanged during session
+ establishment and those that derive from the ongoing flow.
+
+ Some of these signals are derived from the direct examination of
+ packet sequences, such as using a sequence number gap pattern to
+ infer network reliability; others are derived from association, such
+ as inferring network latency by timing a flow's packet inter-arrival
+ times.
+
+ This list is not exhaustive, and it is not the full set of effects
+ due to encrypting data and metadata in flight. Note as well that
+ because these are derived from inference, they do not include any
+ path signals that would not be relevant to the endpoint state
+ machines; indeed, an inference-based system cannot send such signals.
+
+2.1. Session Establishment
+
+ One of the most basic inferences made by examination of transport
+ state is that a packet will be part of an ongoing flow; that is, an
+ established session will continue until messages are received that
+ terminate it. Path elements may then make subsidiary inferences
+ related to the session.
+
+2.1.1. Session Identity
+
+ Path elements that track session establishment will typically create
+ a session identity for the flow, commonly using a tuple of the
+ visible information in the packet headers. This is then used to
+ associate other information with the flow.
+
+2.1.2. Routability and Intent
+
+ A second common inference that session establishment provides is that
+ the communicating pair of hosts can each reach each other and are
+ interested in continuing communication. The firewall example given
+ above is a consequence of that inference; because the internal host
+ initiates the connection, it is presumed to want to receive return
+ traffic. That, in turn, justifies the pinhole.
+
+ Some other on-path elements assume that a host that asked to
+ communicate with a remote address has authorized receiving incoming
+ communications from any other host (e.g., Endpoint-Independent
+ Mapping or Endpoint-Independent Filtering [RFC7857]). This is, for
+ example, the default behavior in Network Address and Protocol
+ Translation from IPv6 Clients to IPv4 Servers (NAT64).
+
+
+
+Hardie Informational [Page 4]
+
+RFC 8558 Transport Protocol Path Signals April 2019
+
+
+2.1.3. Flow Stability
+
+ Some on-path devices that are responsible for load-sharing or load-
+ balancing may be instructed to preserve the same path for a given
+ flow rather than dispatching packets belonging to the same flow on
+ multiple paths as this may cause packets in the flow to be delivered
+ out of order.
+
+2.1.4. Resource Requirements
+
+ An additional common inference is that network resources will be
+ required for the session. These may be requirements within the
+ network element itself, such as table entry space for a firewall or
+ NAT; they may also be communicated by the network element to other
+ systems. For networks that use resource reservations, this might
+ result in reservation of radio air time, energy, or network capacity.
+
+2.2. Network Measurement
+
+ Some network elements will also observe transport messages to engage
+ in measurement of the paths that are used by flows on their network.
+ The list of measurements below is illustrative, not exhaustive.
+
+2.2.1. Path Latency
+
+ There are several ways in which a network element may measure path
+ latency using transport messages, but two common ones are examining
+ exposed timestamps and associating sequence numbers with a local
+ timer. These measurements are necessarily limited to measuring only
+ the portion of the path between the system that assigned the
+ timestamp or sequence number and the network element.
+
+2.2.2. Path Reliability and Consistency
+
+ A network element may also measure the reliability of a particular
+ path by examining sessions that expose sequence numbers;
+ retransmissions and gaps are then associated with the path segments
+ on which they might have occurred.
+
+3. Options
+
+ The set of options below are alternatives that optimize very
+ different things. Though it comes to a preliminary conclusion, this
+ document intends to foster a discussion of those trade-offs, and any
+ discussion of them must be understood as preliminary.
+
+
+
+
+
+
+Hardie Informational [Page 5]
+
+RFC 8558 Transport Protocol Path Signals April 2019
+
+
+3.1. Do Not Restore These Signals
+
+ It is possible, of course, to do nothing. The transport messages
+ were not necessarily intended for consumption by on-path network
+ elements, and encrypting them so they are not visible may be taken by
+ some as a benefit. Each network element would then treat packets
+ without these visible elements according to its own defaults. While
+ our experience of that is not extensive, one consequence has been
+ that state tables for flows of this type are generally not kept as
+ long as those for which sessions are identifiable. The result is
+ that heartbeat traffic must be maintained to keep any bindings (e.g.,
+ NAT or firewall) from early expiry. When those bindings are not
+ kept, methods like a QUIC connection-id [QUIC] may be necessary to
+ allow load balancers or other systems to continue to maintain a
+ flow's path to the appropriate peer.
+
+3.2. Replace These with Network-Layer Signals
+
+ It would be possible to replace these implicit signals with explicit
+ signals at the network layer. Though IPv4 has relatively few
+ facilities for this, IPv6 hop-by-hop headers [RFC7045] might suit
+ this purpose. Further examination of the deployability of these
+ headers may be required.
+
+3.3. Replace These with Per-Transport Signals
+
+ It is possible to replace these implicit signals with signals that
+ are tailored to specific transports, just as the initial signals are
+ derived primarily from TCP. There is a risk here that the first
+ transport that develops these will be reused for many purposes
+ outside its stated purpose, simply because it traverses NATs and
+ firewalls better than other traffic. If done with an explicit intent
+ to reuse the elements of the solution in other transports, the risk
+ of ossification might be slightly lower.
+
+3.4. Create a Set of Signals Common to Multiple Transports
+
+ Several proposals use UDP [RFC0768] as a demux layer, onto which new
+ transport semantics are layered. For those transports, it may be
+ possible to build a common signaling mechanism and set of signals,
+ such as that proposed in "Transport-Independent Path Layer State
+ Management" [PLUS].
+
+ This may be taken as a variant of the reuse of common elements
+ mentioned in the section above, but it has a greater chance of
+ avoiding the ossification of the solution into the first moving
+ protocol.
+
+
+
+
+Hardie Informational [Page 6]
+
+RFC 8558 Transport Protocol Path Signals April 2019
+
+
+4. Recommendation
+
+ The IAB urges protocol designers to design for confidential operation
+ by default. We strongly encourage developers to include encryption
+ in their implementations and to make them encrypted by default. We
+ similarly encourage network and service operators to deploy
+ encryption where it is not yet deployed, and we urge firewall policy
+ administrators to permit encrypted traffic. One of the consequences
+ of the change will be the loss of implicit signals.
+
+ Fundamentally, this document recommends that implicit signals should
+ be avoided and that an implicit signal should be replaced with an
+ explicit signal only when the signal's originator intends that it be
+ used by the network elements on the path. For many flows, this may
+ result in the signal being absent but allows it to be present when
+ needed.
+
+ Discussion of the appropriate mechanism(s) for these signals is
+ continuing, but at a minimum, any method should aim to adhere to
+ these basic principles:
+
+ o The portion of protocol signaling that is intended for end-system
+ state machines should be protected by confidentiality and
+ integrity protection such that it is only available to those end
+ systems.
+
+ o Anything exposed to the path should be done with the intent that
+ it be used by the network elements on the path. This information
+ should be integrity protected, so that end systems can detect if
+ path elements have made changes in flight.
+
+ o Signals exposed to the path should be decoupled from signals that
+ drive the protocol state machines in endpoints. This avoids
+ creating opportunities for additional inference.
+
+ o Intermediate path elements should not add visible signals that
+ identify the user, origin node, or origin network [RFC8164]. Note
+ that if integrity protection is provided as suggested above, any
+ signals added by intermediate path elements will be clearly
+ distinguishable from those added by endpoints, as they will not be
+ within the integrity-protected portion of the packet.
+
+ The IAB notes that methods for allowing on-path actors to verify
+ integrity protection are not available unless those actors have
+ shared keys with the end systems or share a common set of trust
+ points. As a result, integrity protection can generally be reliably
+ applied by and verified only by endpoints.
+
+
+
+
+Hardie Informational [Page 7]
+
+RFC 8558 Transport Protocol Path Signals April 2019
+
+
+ Verifying the authenticity of signals generated by on-path actors is
+ similarly difficult. Endpoints that consume signals generated by
+ on-path actors, particularly where those signals are unauthenticated,
+ need to fully consider the implications of doing so. Managing the
+ authentication of on-path signals is an area of active research, and
+ defining or recommending methods for it is outside the scope of this
+ document.
+
+5. IANA Considerations
+
+ This document has no IANA actions.
+
+6. Security Considerations
+
+ Path-visible signals allow network elements along the path to act
+ based on the signaled information, whether the signal is implicit or
+ explicit. If the network element is controlled by an attacker, those
+ actions can include dropping, delaying, or mishandling the
+ constituent packets of a flow. An attacker may also characterize the
+ flow or attempt to fingerprint the communicating nodes based on the
+ pattern of signals.
+
+ Note that actions that do not benefit the flow or the network may be
+ perceived as an attack even if they are conducted by a responsible
+ network element. Designing a system that minimizes the ability to
+ act on signals at all by removing as many signals as possible may
+ reduce this possibility. This approach also comes with risks,
+ principally that the actions will continue to take place on an
+ arbitrary set of flows.
+
+ Addition of visible signals to the path also increases the
+ information available to an observer and may, when the information
+ can be linked to a node or user, reduce the privacy of the user.
+
+ When signals from endpoints to the path are independent from the
+ signals used by endpoints to manage the flow's state mechanics, they
+ may be falsified by an endpoint without affecting the peer's
+ understanding of the flow's state. For encrypted flows, this
+ divergence is not detectable by on-path devices. The intent of this
+ practice may be to garner improved treatment from the network or to
+ avoid strictures. Protocol designers should be cautious when
+ introducing explicit signals to consider how falsified signals would
+ impact protocol operation and deployment. Similarly, operators
+ should be cautious in deployments to be sure that default operation
+ without these signals does not encourage gaming the system by
+ providing false signals.
+
+
+
+
+
+Hardie Informational [Page 8]
+
+RFC 8558 Transport Protocol Path Signals April 2019
+
+
+7. Informative References
+
+ [PLUS] Kuehlewind, M., Trammell, B., and J. Hildebrand,
+ "Transport-Independent Path Layer State Management", Work
+ in Progress, draft-trammell-plus-statefulness-04, November
+ 2017.
+
+ [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
+ Multiplexed and Secure Transport", Work in Progress,
+ draft-ietf-quic-transport-19, March 2019.
+
+ [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ DOI 10.17487/RFC0768, August 1980,
+ <https://www.rfc-editor.org/info/rfc768>.
+
+ [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, DOI 10.17487/RFC0793, September 1981,
+ <https://www.rfc-editor.org/info/rfc793>.
+
+ [RFC1958] Carpenter, B., Ed., "Architectural Principles of the
+ Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
+ <https://www.rfc-editor.org/info/rfc1958>.
+
+ [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
+ Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
+ <https://www.rfc-editor.org/info/rfc3234>.
+
+ [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
+ of IPv6 Extension Headers", RFC 7045,
+ DOI 10.17487/RFC7045, December 2013,
+ <https://www.rfc-editor.org/info/rfc7045>.
+
+ [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar,
+ S., and K. Naito, "Updates to Network Address Translation
+ (NAT) Behavioral Requirements", BCP 127, RFC 7857,
+ DOI 10.17487/RFC7857, April 2016,
+ <https://www.rfc-editor.org/info/rfc7857>.
+
+ [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for
+ HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017,
+ <https://www.rfc-editor.org/info/rfc8164>.
+
+
+
+
+
+
+
+
+
+
+Hardie Informational [Page 9]
+
+RFC 8558 Transport Protocol Path Signals April 2019
+
+
+IAB Members at the Time of Approval
+
+ Jari Arkko
+ Alissa Cooper
+ Ted Hardie
+ Christian Huitema
+ Gabriel Montenegro
+ Erik Nordmark
+ Mark Nottingham
+ Melinda Shore
+ Robert Sparks
+ Jeff Tantsura
+ Martin Thomson
+ Brian Trammell
+ Suzanne Woolf
+
+Acknowledgements
+
+ In addition to the editor listed in the header, this document
+ incorporates contributions from Brian Trammell, Mirja Kuehlewind,
+ Martin Thomson, Aaron Falk, Mohamed Boucadair, and Joe Hildebrand.
+ These ideas were also discussed at the PLUS BoF, sponsored by Spencer
+ Dawkins. The ideas around the use of IPv6 hop-by-hop headers as a
+ network-layer signal benefited from discussions with Tom Herbert.
+ The description of UDP as a demuxing protocol comes from Stuart
+ Cheshire. Mark Smith, Kazuho Oku, Stephen Farrell, and Eliot Lear
+ provided valuable comments on earlier draft versions of this
+ document.
+
+ All errors are those of the editor.
+
+Author's Address
+
+ Ted Hardie (editor)
+
+ Email: ted.ietf@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie Informational [Page 10]
+