Transport Protocol Path Signals
RFC 8558
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
Show full document text