Transport Protocol Path Signals
RFC 8558
Document | Type |
RFC - Informational
(April 2019; Errata)
Was draft-iab-path-signals (iab)
|
|
---|---|---|---|
Author | Ted Hardie | ||
Last updated | 2019-06-06 | ||
Replaces | draft-hardie-path-signals | ||
Stream | IAB | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | IAB state | Published RFC | |
Consensus Boilerplate | Yes | ||
RFC Editor Note | (None) |
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 thoseShow full document text