idnits 2.17.1 draft-iab-path-signals-01.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 (September 25, 2018) is 2011 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-14 -- 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 September 25, 2018 4 Intended status: Informational 5 Expires: March 29, 2019 7 Path Signals 8 draft-iab-path-signals-01 10 Abstract 12 This document discusses the nature of signals seen by on-path 13 elements, contrasting implicit and explicit signals. For example, 14 TCP's state mechanics uses a series of well-known messages that are 15 exchanged in the clear. Because these are visible to network 16 elements on the path between the two nodes setting up the transport 17 connection, they are often used as signals by those network elements. 18 In transports that do not exchange these messages in the clear, on- 19 path network elements lack those signals. This document recommends 20 that explict signals be used by transports which encrypt their state 21 mechanics. It also recommends that a signal be exposed to the path 22 only when the signal's originator intends that it be used by the 23 network elements on the path. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 29, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Signals Type Inferred . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Session Establishment . . . . . . . . . . . . . . . . . . 4 63 3.1.1. Session Identity . . . . . . . . . . . . . . . . . . 4 64 3.1.2. Routability and Consent . . . . . . . . . . . . . . . 4 65 3.1.3. Flow Stability . . . . . . . . . . . . . . . . . . . 4 66 3.1.4. Resource Requirements . . . . . . . . . . . . . . . . 5 67 3.2. Network Measurement . . . . . . . . . . . . . . . . . . . 5 68 3.2.1. Path Latency . . . . . . . . . . . . . . . . . . . . 5 69 3.2.2. Path Reliability and Consistency . . . . . . . . . . 5 70 4. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. Do Not Restore These Signals . . . . . . . . . . . . . . 5 72 4.2. Replace These With Network Layer Signals . . . . . . . . 6 73 4.3. Replace These With Per-Transport Signals . . . . . . . . 6 74 4.4. Create a Set of Signals Common to Multiple Transports . . 6 75 5. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 6 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 81 9.2. Informative References . . . . . . . . . . . . . . . . . 8 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 2. Introduction 92 This document discusses the nature of signals seen by on-path 93 elements, contrasting implicit and explicit signals. For example, 94 TCP's state mechanics uses a series of well-known messages that are 95 exchanged in the clear. Because these are visible to network 96 elements on the path between the two nodes setting up the transport 97 connection, they are often used as signals by those network elements. 98 While the architecture of the Internet may be best realized by end- 99 to-end protocols[RFC1958], there are cases such as the use of Network 100 Address Translators[RFC3234] where some functions are commonly 101 provided by on-path network elements. In transports that do not 102 exchange these messages in the clear, on-path network elements lack 103 those signals. This document recommends that explicit signals be 104 used by transports which encrypt their state mechanics. It also 105 recommends that a signal be exposed to the path only when the 106 signal's originator intends that it be used by the network elements 107 on the path. 109 The interpretation of TCP [RFC0793] by on-path elements is an example 110 of implicit signal usage. It uses cleartext handshake messages to 111 establish, maintain, and close connections. While these are 112 primarily intended to create state between two communicating nodes, 113 these handshake messages are visible to network elements along the 114 path between them. It is common for certain network elements to 115 treat the exchanged messages as signals which relate to their own 116 functions. 118 A firewall may, for example, create a rule that allows traffic from a 119 specific host and port to enter its network when the connection was 120 initiated by a host already within the network. It may subsequently 121 remove that rule when the communication has ceased. In the context 122 of TCP handshake, it sets up the pinhole rule on seeing the initial 123 TCP SYN acknowledgement and then removes it upon seeing a RST or FIN 124 & ACK exchange. Note that in this case it does nothing to re-write 125 any portion of the TCP packet; it simply enables a return path that 126 would otherwise have been blocked. 128 When a transport encrypts the fields it uses for state mechanics, 129 these signals are no longer accessible to path elements. The 130 behavior of path elements will then depend on which signal is not 131 available, on the default behavior configured by the path element 132 administrator, and by the security posture of the network as a whole. 134 3. Signals Type Inferred 136 The following list of signals which may be inferred from transport 137 state messages includes those which may be exchanged during sessions 138 establishment and those which derive from the ongoing flow. 140 Some of these signals are derived from the direct examination of 141 packet trains, such as using a sequence number gap pattern to infer 142 network reliability; others are derived from association, such as 143 inferring network latency by timing a flow's packet inter-arrival 144 times. 146 This list is not exhaustive, and it is not the full set of effects 147 due to encrypting data and metadata in flight. Note as well that 148 because these are derived from inference, they do not include any 149 path signals which would not be relevant to the end point state 150 machines; indeed, an inference-based system cannot send such signals. 152 3.1. Session Establishment 154 One of the most basic inferences made by examination of transport 155 state is that a packet will be part of an ongoing flow; that is, an 156 established session will continue until messages are received that 157 terminate it. Path elements may then make subsidiary inferences 158 related to the session. 160 3.1.1. Session Identity 162 Path elements that track session establishment will typically create 163 a session identity for the flow, commonly using a tuple of the 164 visible information in the packet headers. This is then used to 165 associate other information with the flow. 167 3.1.2. Routability and Consent 169 A second common inference that session establishment provides is that 170 the communicating pair of hosts can each reach each other and are 171 interested in continuing communication. The firewall example given 172 above is a consequence of the inference of consent; because the 173 internal host initiates the connection, it is presumed to consent to 174 return traffic. That, in turn justifies the pinhole. 176 Some other on-path elements ( assume that a host which asked to 177 communicate with a remote address consents to establish incoming 178 communications from any other host (Endpoint-Independent Mapping/ 179 Endpoint-Independent Filtering). This is, for example, the default 180 behavior in NAT64. 182 3.1.3. Flow Stability 184 Some on-path devices that are responsible for load-sharing or load- 185 balancing may be instructed to preserve the same path for a given 186 flow, rather than dispatching packets belonging to the some flow on 187 multiple paths as this may cause packets in the flow to be delivered 188 out of order.. 190 3.1.4. Resource Requirements 192 An additional common inference is that network resources will be 193 required for the session. These may be requirements within the 194 network element itself, such as table entry space for a firewall or 195 NAT; they may also be communicated by the network element to other 196 systems. For networks which use resource reservations, this might 197 result in reservation of radio air time, energy, or network capacity. 199 3.2. Network Measurement 201 Some network elements will also observe transport messages to engage 202 in measurement of the paths which are used by flows on their network. 203 The list of measurements below is illustrative, not exhaustive. 205 3.2.1. Path Latency 207 There are several ways in which a network element may measure path 208 latency using transport messages, but two common ones are examining 209 exposed timestamps and associating sequence numbers with a local 210 timer. These measurements are necessarily limited to measuring only 211 the portion of the path between the system which assigned the 212 timestamp or sequence number and the network element. 214 3.2.2. Path Reliability and Consistency 216 A network element may also measure the reliability of a particular 217 path by examining sessions which expose sequence numbers; 218 retransmissions and gaps are then associated with the path segments 219 on which they might have occurred. 221 4. Options 223 The set of options below are alternatives which optimize very 224 different things. Though it comes to a preliminary conclusion, this 225 draft intends to foster a discussion of those tradeoffs and any 226 discussion of them must be understood as preliminary. 228 4.1. Do Not Restore These Signals 230 It is possible, of course, to do nothing. The transport messages 231 were not necessarily intended for consumption by on-path network 232 elements and encrypting them so they are not visible may be taken by 233 some as a benefit. Each network element would then treat packets 234 without these visible elements according to its own defaults. While 235 our experience of that is not extensive, one consequence has been 236 that state tables for flows of this type are generally not kept as 237 long as those for which sessions are identifiable. The result is 238 that heartbeat traffic must be maintained to keep any bindings (e.g. 239 NAT or firewall) from early expiry. When those bindings are not 240 kept, methods like QUIC's connection-id [QUIC] may be necessary to 241 allow load balancers or other systems to continue to maintain a 242 flow's path to the appropriate peer. 244 4.2. Replace These With Network Layer Signals 246 It would be possible to replace these implicit signals with explicit 247 signals at the network layer. Though IPv4 has relatively few 248 facilities for this, IPv6 hop-by-hop headers [RFC7045] might suit 249 this purpose. Further examination of the deployability of these 250 headers may be required. 252 4.3. Replace These With Per-Transport Signals 254 It is possible to replace these implicit signals with signals that 255 are tailored to specific transports, just as the initial signals are 256 derived primarily from TCP. There is a risk here that the first 257 transport which develops these will be reused for many purposes 258 outside its stated purpose, simply because it traverses NATs and 259 firewalls better than other traffic. If done with an explicit intent 260 to re-use the elements of the solution in other transports, the risk 261 of ossification might be slightly lower. 263 4.4. Create a Set of Signals Common to Multiple Transports 265 Several proposals use UDP [RFC0768] as a demux layer, onto which new 266 transport semantics are layered. For those transports, it may be 267 possible to build a common signalling mechanism and set of signals, 268 such as that proposed in "Transport-Independent Path Layer State 269 Management" [PLUS]. 271 This may be taken as a variant of the re-use of common elements 272 mentioned in the section above, but it has a greater chance of 273 avoiding the ossification of the solution into the first moving 274 protocol. 276 5. Recommendation 278 The IAB urges protocol designers to design for confidential operation 279 by default. We strongly encourage developers to include encryption 280 in their implementations, and to make them encrypted by default. We 281 similarly encourage network and service operators to deploy 282 encryption where it is not yet deployed, and we urge firewall policy 283 administrators to permit encrypted traffic. One of the consequences 284 of the change will be the loss of implicit signals. 286 Fundamentally, this paper recommends that implicit signals should be 287 replaced with explicit signals, but that a signal should be exposed 288 to the path only when the signal's originator intends that it be used 289 by the network elements on the path. For many flows, that may result 290 in signal being absent, but it allows them to be present when needed. 292 Discussion of the appropriate mechanism(s) for these signals is 293 continuing but, at minimum, any method should aim to adhere to these 294 basic principles: 296 o The portion of protocol signaling that is intended for end system 297 state machines should be protected by confidentiality and 298 integrity protection such that it is only available to those end 299 systems. 301 o Anything exposed to the path should be done with the intent that 302 it be used by the network elements on the path. This information 303 should be integrity protected. 305 o Signals exposed to the path should be decoupled from signals that 306 drive the protocol state machines in endpoints. This avoids 307 creating opportunities for additional inference. 309 o Intermediate path elements should not add visible signals which 310 identify the user, origin node, or origin network [RFC8164]. 312 6. IANA Considerations 314 This document contains no requests for IANA. 316 7. Security Considerations 318 Path-visible signals allow network elements along the path to act 319 based on the signaled information, whether the signal is implicit or 320 explicit. If the network element is controlled by an attacker, those 321 actions can include dropping, delaying, or mishandling the 322 constituent packets of a flow. It may also characterize the flow or 323 attempt to fingerprint the communicating nodes based on the pattern 324 of signals. 326 Note that actions that do not benefit the flow or the network may be 327 perceived as an attack even if they are conducted by a responsible 328 network element. Designing a system that minimizes the ability to 329 act on signals at all by removing as many signals as possible may 330 reduce this possibility. This approach also comes with risks, 331 principally that the actions will continue to take place on an 332 arbitrary set of flows. 334 Addition of visible signals to the path also increases the 335 information available to an observer and may, when the information 336 can be linked to a node or user, reduce the privacy of the user. 338 When signals from end points to the path are independent from the 339 signals used by endpoints to manage the flow's state mechanics, they 340 may be falsified by an endpoint without affecting the peer's 341 understanding of the flow's state. For encrypted flows, this 342 divergence is not detectable by on-path devices. The intent of this 343 practice may be to garner improved treatment from the network or to 344 avoid strictures. Protocol designers should be cautious when 345 introducing explicit signals to consider how falsified signals would 346 impact protocol operation and deployment. Similarly, operators 347 should be cautious in deployments to be sure that default operation 348 without these signals does not encourage gaming the system by 349 providing false signals. 351 8. Acknowledgements 353 In addition to the editor listed above, this document incorporates 354 contributions from Brian Trammell, Mirja Kuehlewind, Martin Thomson, 355 Aaron Falk, Mohamed Boucadair and Joe Hildebrand. These ideas were 356 also discussed at the PLUS BoF, sponsored by Spencer Dawkins. The 357 ideas around the use of IPv6 hop-by-hop headers as a network layer 358 signal benefited from discussions with Tom Herbert. The description 359 of UDP as a demuxing protocol comes from Stuart Cheshire. Mark Smith 360 and Kazuho Oku provided valuable comments on earlier versions of this 361 draft. 363 All errors are those of the editor. 365 9. References 367 9.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, 371 DOI 10.17487/RFC2119, March 1997, 372 . 374 9.2. Informative References 376 [PLUS] Kuehlewind, M., Trammell, B., and J. Hildebrand, 377 "Transport-Independent Path Layer State Management", 378 draft-trammell-plus-statefulness-04 (work in progress), 379 November 2017. 381 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 382 and Secure Transport", draft-ietf-quic-transport-14 (work 383 in progress), August 2018. 385 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 386 DOI 10.17487/RFC0768, August 1980, 387 . 389 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 390 RFC 793, DOI 10.17487/RFC0793, September 1981, 391 . 393 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 394 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 395 . 397 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 398 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 399 . 401 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 402 of IPv6 Extension Headers", RFC 7045, 403 DOI 10.17487/RFC7045, December 2013, 404 . 406 [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for 407 HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, 408 . 410 Author's Address 412 Ted Hardie (editor) 414 Email: ted.ietf@gmail.com