idnits 2.17.1 draft-bellis-dnsop-session-signal-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6891]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 28, 2016) is 2800 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-push-08 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group R. Bellis 3 Internet-Draft ISC 4 Intended status: Standards Track S. Cheshire 5 Expires: January 29, 2017 Apple Inc. 6 J. Dickinson 7 S. Dickinson 8 Sinodun 9 A. Mankin 10 Salesforce 11 T. Pusateri 12 Unaffiliated 13 July 28, 2016 15 DNS Session Signaling 16 draft-bellis-dnsop-session-signal-02 18 Abstract 20 The EDNS(0) Extension Mechanism for DNS [RFC6891] is explicitly 21 defined to only have "per-message" semantics. This document defines 22 a new Session Signaling Opcode used to carry persistent "per-session" 23 type-length-values (TLVs), and defines an initial set of TLVs used to 24 manage session timeouts and termination. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 29, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Session Lifecycle . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. Message Handling . . . . . . . . . . . . . . . . . . . . 6 66 3.4. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Mandatory TLVs . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. Session Management Support TLVs . . . . . . . . . . . . . 7 69 4.1.1. "Not Implemented" . . . . . . . . . . . . . . . . . . 8 70 4.2. Session Management TLVs . . . . . . . . . . . . . . . . . 8 71 4.2.1. Idle Timeout . . . . . . . . . . . . . . . . . . . . 8 72 4.2.2. Terminate Session . . . . . . . . . . . . . . . . . . 9 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 5.1. DNS Session Signaling Opcode Registration . . . . . . . . 10 75 5.2. DNS Session Signaling Type Codes Registry . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 The use of transports other than UDP for DNS is being increasingly 86 specified, for example, DNS-over-TCP [RFC7766], DNS-over-TLS 87 [RFC7858] and recent work on DNS Push Notifications 88 [I-D.ietf-dnssd-push]. Such transports frequently use persistent, 89 long-lived sessions and therefore when using them for transporting 90 DNS messages it is of benefit to have a mechanism that can establish 91 parameters associated with those sessions, such as timeouts. In such 92 situations it is also advantageous to support server initiated 93 messages. 95 The EDNS(0) Extension Mechanism for DNS [RFC6891] is explicitly 96 defined to only have "per-message" semantics. Whilst EDNS(0) has 97 been used to signal at least one session related parameter (the EDNS 98 TCP KeepAlive option [RFC7828]) the result is less than optimal due 99 to the restrictions imposed by the EDNS(0) semantics and the lack of 100 server initiated signalling. This document defines a new Session 101 Signaling Opcode used to carry persistent "per-session" type-length- 102 values (TLVs), and defines an initial set of TLVs used to manage 103 session timeouts and termination. 105 With EDNS(0), multiple options may be packed into a single OPT RR, 106 and there is no generalized mechanism for a client to be able to tell 107 whether a server has processed or otherwise acted upon each 108 individual option within the combined OPT RR. The specifications for 109 each individual option need to define how each different option is to 110 be acknowledged, if necessary. 112 With Session Signaling, in contrast, each Session Signaling operation 113 is communicated in its own separate DNS message, and the RCODE in the 114 response indicates the success or failure of that operation. 116 It should be noted that the message format for Session Signaling 117 operations (see Section 3.2) differs from the DNS packet format used 118 for standard queries and responses, in that it has a shorter header 119 (four octets instead of usual twelve octets). 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 128 The terms "initiator" and "responder" correspond respectively to the 129 initial sender and subsequent receiver of a Session Signaling TLV, 130 regardless of which was the "client" and "server" in the usual DNS 131 sense. 133 The term "sender" may apply to either an initiator or responder. 135 The term "session" in the context of this document means the exchange 136 of DNS messages using an end-to-end transport protocol where: 138 o The connection between client and server is persistent and 139 relatively long-lived (i.e. minutes or hours, rather than 140 seconds). 142 o Either end of the connection may initiate messages to the other 143 o Messages are delivered in order 145 3. Protocol Details 147 Session Signaling messages MUST only be carried in protocols and in 148 environments where a session may be established according to the 149 definition above. Standard DNS over TCP [RFC1035], and DNS over TLS 150 [RFC7858] are suitable protocols. DNS over plain UDP is not 151 appropriate since it fails on the requirement for in-order message 152 delivery, and, in the presence of NAT gateways and firewalls with 153 short UDP timeouts, it fails to provide a persistent bi-directional 154 communication channel unless an excessive amount of keepalive traffic 155 is used. 157 Session Signaling messages relate only to the specific session in 158 which they are being carried. Where a middle box (e.g. a DNS proxy, 159 forwarder, or session multiplexer) is in the path the message MUST 160 NOT be blindly forwarded in either direction by that middle box. 161 This does not preclude the use of these messages in the presence of a 162 NAT box that rewrites IP-layer or transport-layer headers but 163 otherwise maintains the effect of a single session. 165 A client MAY attempt to initiate Session Signaling messages at any 166 time on a connection; receiving a NOTIMP response in reply indicates 167 that the server does not implement Session Signaling, and the client 168 SHOULD NOT issue further Session Signaling messages on that 169 connection. 171 A server SHOULD NOT initiate Session Signaling messages until a 172 client-initiated Session Signaling message is received first, unless 173 in an environment where it is known in advance by other means that 174 both client and server support Session Signaling. This requirement 175 is to ensure that the clients that do not support Session Signaling 176 do not receive unsolicited inbound Session Signaling messages that 177 they would not know how to handle. 179 3.1. Session Lifecycle 181 A session begins when a client makes a new connection to a server. 183 The client may perform as many DNS operations as it wishes on the 184 newly created connection. Operations SHOULD be pipelined (i.e., the 185 client doesn't need wait for a reply before sending the next 186 message). The server MUST act on messages in the order they are 187 received, but responses to those messages MAY be sent out of order, 188 if appropriate. 190 When a server implementing this specification receives a new 191 connection from a client, it MUST begin by internally assigning an 192 initial idle timeout of 30 seconds to that connection. At both 193 servers and clients, the generation or reception of any complete DNS 194 message, including DNS requests, responses, updates, or Session 195 Signaling messages, resets the idle timer for that connection (see 196 [RFC7766]). 198 If, at any time during the life of the connection, half the idle- 199 timeout value (i.e., 15 seconds by default) elapses without any DNS 200 messages being sent or received on a connection, then the connection 201 is considered stale and the client MUST take action. When this 202 happens the client MUST either send at least one new message to reset 203 the idle timer - such as a Session Signaling Idle Timeout message 204 (see Section 4.2.1), or any other valid DNS message - or close the 205 connection. 207 If, at any time during the life of the connection, the full idle- 208 timeout value (i.e., 30 seconds by default) elapses without any DNS 209 messages being sent or received on a connection, then the connection 210 is considered delinquent and the server SHOULD forcibly terminate the 211 connection. For sessions over TCP (or over TLS-over-TCP), to avoid 212 the burden of having a connection in TIME-WAIT state, instead of 213 closing the connection gracefully with a TCP FIN the server SHOULD 214 abort the connection with a TCP RST. (In the Sockets API this is 215 achieved by setting the SO_LINGER option to zero before closing the 216 socket.) 218 If the client wishes to keep an idle connection open for longer than 219 the default duration without having to send traffic every 15 seconds, 220 then it uses the Session Signaling Idle Timeout message to request a 221 longer idle timeout (see Section 4.2.1). 223 A client is not required to wait until half of the idle-timeout value 224 before closing a connection. A client MAY close a connection at any 225 time, at the client's discretion, if it has no further need for the 226 connection at that time. 228 3.2. Message Format 230 A Session Signaling message begins with the first 4 octets of the 231 standard DNS message header [RFC1035], with the Opcode field set to 232 the Session Signaling Opcode. A Session Signaling message does not 233 contain the QDCOUNT, ANCOUNT, NSCOUNT and ARCOUNT fields fields used 234 in standard DNS queries and responses. This 4-octet header is 235 followed by a single Session Signaling TLV. 237 1 1 1 1 1 1 238 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 239 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 240 | MESSAGE ID | 241 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 242 |QR | Opcode | Z | RCODE | 243 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 244 | | 245 / TLV-DATA / 246 / / 247 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 249 The MESSAGE ID, QR, Opcode and RCODE fields have their usual meanings 250 [RFC1035]. 252 The Z bits are currently unused, and SHOULD be set to zero (0) in 253 requests and responses unless re-defined in a later specification. 255 3.3. Message Handling 257 On a connection between a client and server that support Session 258 Signaling, either end may unilaterally send Session Signaling 259 messages at any point in the lifetime of a session, and therefore 260 either client or server may be the initiator of a message. The 261 initiator MUST set the value of the QR bit in the DNS header to zero 262 (0), and the responder MUST set it to one (1). 264 <> 267 Every Session Signaling request message MUST elicit a response (which 268 MUST have the same ID in the DNS message header as in the request). 270 << RB: should the presence of a SS message create a "sequencing 271 point", such that all pending responses must be answered? SC: I do 272 not believe so. We can define an explicit SS "sequencing point" 273 opcode for this if necessary. >> 275 The RCODE value in a response uses a subset of the standard (non- 276 extended) RCODE values from the IANA DNS RCODEs registry, interpreted 277 as follows: 279 +------+----------+---------------------------------+ 280 | Code | Mnemonic | Description | 281 +------+----------+---------------------------------+ 282 | 0 | NOERROR | TLV processed successfully | 283 | | | | 284 | 1 | FORMERR | TLV format error | 285 | | | | 286 | 4 | NOTIMP | Session Signaling not supported | 287 | | | | 288 | 5 | REFUSED | TLV declined for policy reasons | 289 +------+----------+---------------------------------+ 291 3.4. TLV Format 293 1 1 1 1 1 1 294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 295 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 296 | SSOP-TYPE | 297 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 298 | SSOP-LENGTH | 299 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 300 | | 301 / SSOP-DATA / 302 / / 303 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 305 SSOP-TYPE: A 16 bit field in network order giving the type of the 306 current Session Signaling TLV per the IANA DNS Session Signaling 307 Type Codes Registry. 309 << SC: I changed SESSION-TYPE to SSOP-TYPE because to me SESSION-TYPE 310 read as "type of session" which it is not. It is Session Signaling 311 Operation Type, Session Signaling Operation Length, Session Signaling 312 Operation Data. >> 314 SSOP-LENGTH: A 16 bit field in network order giving the size in 315 octets of SSOP-DATA. 317 SSOP-DATA: Type-code specific. 319 4. Mandatory TLVs 321 4.1. Session Management Support TLVs 322 4.1.1. "Not Implemented" 324 Since the "NOTIMP" RCODE in the DNS message header is used to 325 indicate lack of support for the Session Signaling Opcode itself, a 326 different mechanism is used to indicate lack of support of a specific 327 SSOP-TYPE. If a server that supports Session Signaling receives a 328 Session Signaling query message (QR bit zero) with an SSOP-TYPE it 329 does not support, it returns a response message (QR bit one) 330 containing a single Session Signaling SSOP-NOTIMP TLV (0). The 331 MESSAGE ID in the message header serves to tell the client which of 332 its requests was not understood. 334 The SSOP-NOTIMP TLV has no SSOP-DATA. 336 4.2. Session Management TLVs 338 4.2.1. Idle Timeout 340 The Idle Timeout TLV (1) is be used by a client to reset a 341 connection's idle timer, and at the same time to request what the 342 idle timeout should be from this point forward in the connection. 344 The Idle Timeout TLV also MAY be initiated by a server, to 345 unilaterally inform the client of a new idle timeout this point 346 forward in this connection. 348 It is not required that the Idle Timeout TLV be used in every 349 session. While many Session Signaling operations (such as DNS Push 350 Notifications [I-D.ietf-dnssd-push]) will be used in conjunction with 351 a long-lived connection, this is not required, and in some cases the 352 default 30-second timeout may be perfectly appropriate. 354 The SSOP-DATA for the the Idle Timeout TLV is as follows: 356 1 1 1 1 1 1 357 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 358 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 359 | IDLE TIMEOUT | 360 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 362 IDLE TIMEOUT: the idle timeout for the current session, specified as 363 a 16 bit word in network order in units of 100 milliseconds. This 364 is the timeout at which the server will forcibly terminate the 365 connection with a TCP RST (or equivalent for other protocols); 366 after half this interval the client MUST take action to either 367 preserve the connection, or close it if it is no longer needed. 369 In a client-initiated Session Signaling Idle Timeout message, the 370 IDLE TIMEOUT contains the client's requested value for the idle 371 timeout. 373 In a server response to a client-initiated message, the IDLE TIMEOUT 374 contains the server's chosen value for the idle timeout, which the 375 client MUST respect. This is modeled after the DHCP protocol, where 376 the client requests a certain lease lifetime, but the server is the 377 ultimate authority for deciding what lease lifetime is actually 378 granted. 380 In a server-initiated Session Signaling Idle Timeout message, the 381 IDLE TIMEOUT unilaterally informs the client of the new idle timeout 382 this point forward in this connection. 384 In a client response to a server-initiated message, there is no SSOP- 385 DATA. SSOP-LENGTH is zero. 387 <> 389 The Idle Timeout TLV (3) has similar intent to the EDNS TCP Keepalive 390 Option [RFC7828]. A client/server pair that supports Session 391 Signaling MUST NOT use the EDNS TCP KeepAlive option within any 392 message once bi-directional Session Signaling support has been 393 confirmed. 395 << SC: And if client or server does use EDNS TCP Keepalive, then 396 other end should... close connection? Silently ignore? >> 398 4.2.2. Terminate Session 400 There may be rare cases where a server is overloaded and wishes to 401 shed load. If the server simply closes connections, the likely 402 behaviour of clients is to detect this as a network failure, and 403 reconnect. 405 To avoid this reconnection implosion, the server sends a Terminate 406 Session TLV (2) to inform the client of the overload situation. 407 After sending a Terminate Session TLV the server MUST NOT send any 408 further messages on the connection. 410 The Terminate Session TLV (2) MUST NOT be initiated by a client. 412 <> 414 Upon receipt of the Terminate Session TLV (2) the client MUST make 415 note of the reconnect delay for this server, and then immediately 416 close the connection. 418 The SSOP-DATA is as follows: 420 1 1 1 1 1 1 421 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 422 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 423 | RECONNECT DELAY | 424 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 426 RECONNECT DELAY: a time value, specified as a 16 bit word in network 427 order in units of 100 milliseconds, within which the client MUST 428 NOT establish a new session to the current server. 430 The RECOMMENDED value is 10 seconds. << RB: text required here about 431 default values for load balancers, etc >> 433 5. IANA Considerations 435 5.1. DNS Session Signaling Opcode Registration 437 IANA are directed to assign the value TBD for the Session Signaling 438 Opcode in the DNS OpCodes Registry. 440 5.2. DNS Session Signaling Type Codes Registry 442 IANA are directed to create the DNS Session Signaling Type Codes 443 Registry, with initial values as follows: 445 +-----------+--------------------------------+----------+-----------+ 446 | Type | Name | Status | Reference | 447 +-----------+--------------------------------+----------+-----------+ 448 | 0 | SSOP-NOTIMP | Standard | RFC-TBD1 | 449 | | | | | 450 | 1 | SSOP-Keepalive | Standard | RFC-TBD1 | 451 | | | | | 452 | 2 | SSOP-Terminate | Standard | RFC-TBD1 | 453 | | | | | 454 | 3 - 63 | Unassigned, reserved for | | | 455 | | session management TLVs | | | 456 | | | | | 457 | 64 - | Unassigned | | | 458 | 63487 | | | | 459 | | | | | 460 | 63488 - | Reserved for local / | | | 461 | 64511 | experimental use | | | 462 | | | | | 463 | 64512 - | Reserved for future expansion | | | 464 | 65535 | | | | 465 +-----------+--------------------------------+----------+-----------+ 467 Registration of additional Session Signaling Type Codes requires 468 Expert Review. << RB: definition of process required? >> 470 6. Security Considerations 472 If this mechanism is to be used with DNS over TLS, then these 473 messages are subject to the same constraints as any other DNS over 474 TLS messages and MUST NOT be sent in the clear before the TLS session 475 is established. 477 7. Acknowledgements 479 TBW 481 8. References 483 8.1. Normative References 485 [RFC1035] Mockapetris, P., "Domain names - implementation and 486 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 487 November 1987, . 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 491 RFC2119, March 1997, 492 . 494 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 495 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 496 RFC6891, April 2013, 497 . 499 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 500 D. Wessels, "DNS Transport over TCP - Implementation 501 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 502 . 504 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 505 edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/ 506 RFC7828, April 2016, 507 . 509 8.2. Informative References 511 [I-D.ietf-dnssd-push] 512 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 513 draft-ietf-dnssd-push-08 (work in progress), July 2016. 515 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 516 and P. Hoffman, "Specification for DNS over Transport 517 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 518 2016, . 520 Authors' Addresses 522 Ray Bellis 523 Internet Systems Consortium, Inc. 524 950 Charter Street 525 Redwood City CA 94063 526 USA 528 Phone: +1 650 423 1200 529 Email: ray@isc.org 531 Stuart Cheshire 532 Apple Inc. 533 1 Infinite Loop 534 Cupertino CA 95014 535 USA 537 Phone: +1 408 974 3207 538 Email: cheshire@apple.com 539 John Dickinson 540 Sinodun Internet Technologies 541 Magadalen Centre 542 Oxford Science Park 543 Oxford OX4 4GA 544 United Kingdom 546 Email: jad@sinodun.com 548 Sara Dickinson 549 Sinodun Internet Technologies 550 Magadalen Centre 551 Oxford Science Park 552 Oxford OX4 4GA 553 United Kingdom 555 Email: sara@sinodun.com 557 Allison Mankin 558 Salesforce 560 Email: allison.mankin@gmail.com 562 Tom Pusateri 563 Unaffiliated 565 Phone: +1 843 473 7394 566 Email: pusateri@bangj.com