idnits 2.17.1 draft-hardie-path-signals-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 30, 2017) is 2332 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-07 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardie, Ed. 3 Internet-Draft November 30, 2017 4 Intended status: Informational 5 Expires: June 3, 2018 7 Path signals 8 draft-hardie-path-signals-02 10 Abstract 12 TCP's state mechanics uses a series of well-known messages that are 13 exchanged in the clear. Because these are visible to network 14 elements on the path between the two nodes setting up the transport 15 connection, they are often used as signals by those network elements. 16 In transports that do not exchange these messages in the clear, on- 17 path network elements lack those signals. This document discusses 18 the nature of the signals as they are seen by on-path elements and 19 reflects on best practices for transports which encrypt their state 20 mechanics. 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 https://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 3, 2018. 39 Copyright Notice 41 Copyright (c) 2017 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 (https://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Signals Type Inferred . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Session establishment . . . . . . . . . . . . . . . . . . 3 60 3.1.1. Session identity . . . . . . . . . . . . . . . . . . 3 61 3.1.2. Routability and Consent . . . . . . . . . . . . . . . 4 62 3.1.3. Resource Requirements . . . . . . . . . . . . . . . . 4 63 3.2. Network Measurement . . . . . . . . . . . . . . . . . . . 4 64 3.2.1. Path Latency . . . . . . . . . . . . . . . . . . . . 4 65 3.2.2. Path reliability and consistency . . . . . . . . . . 4 66 4. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Do not restore these signals . . . . . . . . . . . . . . 5 68 4.2. Replace these with network layer signals . . . . . . . . 5 69 4.3. Replace these with per-transport signals . . . . . . . . 5 70 4.4. Create a set of signals common to multiple transports . . 5 71 5. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 9.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Introduction 88 TCP [RFC0793] uses handshake messages to establish, maintain, and 89 close connections. While these are primarily intended to create 90 state between two communicating nodes, these handshake messages are 91 visible to network elements along the path between them. It has been 92 common over time for certain network elements to treat the exchanged 93 messages as signals which related to their own functions. 95 A firewall may, for example, create a rule that allows traffic from a 96 specific host and port to enter its network when the connection was 97 initiated by a host already within the network. It may subsequently 98 remove that rule when the communication has ceased. In the context 99 of TCP handshake, it sets up the pinhole rule on seeing the initial 100 TCP SYN acknowledged and then removes it upon seeing a RST or FIN & 101 ACK exchange. Note that in this case it does nothing to re-write any 102 portion of the TCP packet; it simply enables a return path that would 103 otherwise have been blocked. 105 When a transport encrypts the headers it uses for state mechanics, 106 the signal path elements inferred from examination is no longer 107 available. Their behavior in its absence will depend on which signal 108 is not available, on the default behavior configured by the path 109 element administrator, and by the security posture of the network as 110 a whole. 112 3. Signals Type Inferred 114 The following list of signals which may be inferred from transport 115 state messages includes those which may be exchanged during sessions 116 establishment and those which derive from the ongoing flow. Some of 117 these signals are derived from the direct examination of packet 118 trains, such as using a sequence number gap pattern to infer network 119 reliability; others are derived from association, such as inferring 120 network latency by timing a flow's packet inter-arrival times. This 121 list is not exhaustive, and it is not the full set of effects due to 122 encrypting data and metadata in flight. Note as well that because 123 these are derived from inferenece, they do not include any path 124 signals which would not be relevant to the end point state machines; 125 indeed, an inference-based system cannot send such signals. 127 3.1. Session establishment 129 One of the most basic inferences made by examination of transport 130 state is that a packet will be part of an ongoing flow; that is, an 131 established session will continue until messages are received that 132 terminate it. Path elements may then make subsidiary inferences 133 related to the session. 135 3.1.1. Session identity 137 Path elements that track session establishment will typically create 138 a session identify for the flow, commonly using a tuple of the 139 visible information in the packet headers. This is then used to 140 associate other information with the 142 3.1.2. Routability and Consent 144 A second common inference is that the session establishment provides 145 is that the communicating pair of hosts can each reach each other and 146 are interested in continuing communication. The firewall example 147 given above is a consequence of the inference of consent; because the 148 internal host initiates the connection, it is presumed to consent to 149 return traffic. That, in turn justifies the pinhole. 151 3.1.3. Resource Requirements 153 An additional common inference is that network resources will be 154 required for the session. These may be requirements within the 155 network element itself, such as table entry space for a firewall or 156 NAT; they may also be communicated by the network element to other 157 systems. For networks which use resource reservations, this might 158 result in reservation of radio air time, energy, or network capacity. 160 3.2. Network Measurement 162 Some network elements will also use transport messages to engage in 163 measurement of the paths which are used by flows on their network. 164 The list of measurements below is illustrative, not exhaustive. 166 3.2.1. Path Latency 168 There are several ways in which a network element may measure path 169 latency using transport messages, but two common ones are examining 170 exposed timestamps and associating sequence numbers with a local 171 timer. These measurements are necessarily limited to measuring only 172 the portion of the path between the system which assigned the 173 timestamp or sequence number and the network element. 175 3.2.2. Path reliability and consistency 177 A network element may also measure the reliability of a particular 178 path by examining sessions which expose sequence numbers; 179 retransmissions and gaps are then associated with the path segments 180 on which they might have occurred. 182 4. Options 184 The set of options below are alternatives which optimize very 185 different things. Though it comes to a preliminary conclusion, this 186 draft intends to foster a discussion of those tradeoffs and any 187 discussion of them must be understood as preliminary. 189 4.1. Do not restore these signals 191 It is possible, of course, to do nothing. The transport messages 192 were not necessarily intended for consumption by on-path network 193 elements and encrypting them so they are not visible may be taken by 194 some as a benefit. Each network element would then treat packets 195 without these visible elements according to its own defaults. While 196 our experience of that is not extensive, one consequence has been 197 that state tables for flows of this type are generally not kept as 198 long as those for which sessions are identifiable. The result is 199 that heartbeat traffic must be maintained to keep any bindings (e.g. 200 NAT or firewall) from early expiry. When those bindings are not 201 kept, methods like QUIC's connection-id [I-D.ietf-quic-transport] may 202 be necessary to allow load blancers or other systems to continue to 203 maintain a flow's path to the appropriate peer. 205 4.2. Replace these with network layer signals 207 It would be possible to replace these implicit signals with explicit 208 signals at the network layer. Though IPv4 has relatively few 209 facilities for this, IPv6 hop-by-hop headers [RFC7045] might suit 210 this purpose. Further examination of the deployability of these 211 headers may be required. 213 4.3. Replace these with per-transport signals 215 It is possible to replace these implicit signals with signals that 216 are tailored to specific transports, just as the initial signals are 217 derived primarily from TCP. There is a risk here that the first 218 transport which develops these will be reused for many purposes 219 outside its stated purpose, simply because it traverses NATs and 220 firewalls better than other traffic. If done with an explicit intent 221 to re-use the elements of the solution in other transports, the risk 222 of ossification might be slightly lower. 224 4.4. Create a set of signals common to multiple transports 226 Several proposals use UDP[RFC0768] as a demux layer, onto which new 227 transport semantics are layered. For those transports, it may be 228 possible to build a common signalling mechanism and set of signals, 229 such as that proposed in "Transport-Independent Path Layer State 230 Management" [I-D.trammell-plus-statefulness]. 232 This may be taken as a variant of the re-use of common elements 233 mentioned in the section above, but it has a greater chance of 234 avoiding the ossification of the solution into the first moving 235 protocol. 237 5. Recommendation 239 Fundamentally, this paper recommends that implicit signals should be 240 replaced with explicit signals, but that a signal should be exposed 241 to the path only when the signal's originator intends that it be used 242 by the network elements on the path. For many flows, that may result 243 in signal being absent, but it allows them to be present when needed. 245 Discussion of the appropriate mechanism(s) for these signals is 246 continuing but, at minimum, any method should meet the principles set 247 out in the security considerations below. 249 6. IANA Considerations 251 This document contains no requests for IANA. 253 7. Security Considerations 255 Path-visible signals allow network elements along the path to act 256 based on the signaled information, whether the signal is implicit or 257 explicit. If the network element is controlled by an attacker, those 258 actions can include dropping, delaying, or mishandling the 259 constituent packets of a flow. It may also characterize the flow or 260 attempt to fingerprint the communicating nodes based on the pattern 261 of signals. 263 Note that actions that do not benefit the flow or the network may be 264 perceived as an attack even if they are conducted by a responsible 265 network element. Designing a system that minimizes the ability to 266 act on signals at all by removing as many signals as possible may 267 reduce this possibility. This approach also comes with risks, 268 principally that the actions will continue to take place on an 269 arbitrary set of flows. 271 Addition of visible signals to the path also increases the 272 information available to an observer and may, when the information 273 can be linked to a node or user, reduce the privacy of the user. 275 This document recommends three basic principles: 277 o Cryptographic contexts should be available on any flow, derived 278 from ubiquitous end-system cryptographic capabilities. That 279 context should cover the portion of protocol signaling that is 280 inteded for end system state machines. 282 o Anything exposed to the path should be done with the intent that 283 it be used by the network elements on the path. 285 o Intermediate path elements should not add visible signals which 286 identify the user, origin node, or origin network [RFC8164]. 288 8. Acknowledgements 290 In addition to the editor listed above, this document incorporates 291 contributions from Brian Trammel, Mirja Kuehlwind, and Joe 292 Hildebrand. These ideas were also discussed at the PLUS BoF, 293 sponsored by Spencer Dawkins. The ideas around the use of IPv6 hop- 294 by-hop headers as a network layer signal benefited from discussions 295 with Tom Herbert. The description of UDP as a demuxing protocol 296 comes from Stuart Cheshire. 298 All errors are those of the editor. 300 9. References 302 9.1. Normative References 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, 306 DOI 10.17487/RFC2119, March 1997, 307 . 309 9.2. Informative References 311 [I-D.ietf-quic-transport] 312 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 313 and Secure Transport", draft-ietf-quic-transport-07 (work 314 in progress), October 2017. 316 [I-D.trammell-plus-statefulness] 317 Kuehlewind, M., Trammell, B., and J. Hildebrand, 318 "Transport-Independent Path Layer State Management", 319 draft-trammell-plus-statefulness-04 (work in progress), 320 November 2017. 322 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 323 DOI 10.17487/RFC0768, August 1980, 324 . 326 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 327 RFC 793, DOI 10.17487/RFC0793, September 1981, 328 . 330 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 331 of IPv6 Extension Headers", RFC 7045, 332 DOI 10.17487/RFC7045, December 2013, 333 . 335 [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for 336 HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, 337 . 339 Author's Address 341 Ted Hardie (editor) 343 Email: ted.ietf@gmail.com