idnits 2.17.1 draft-bellis-dnsop-session-signal-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 : ---------------------------------------------------------------------------- ** 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 21, 2016) is 2828 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 22, 2017 Apple Inc. 6 J. Dickinson 7 S. Dickinson 8 Sinodun 9 A. Mankin 10 Salesforce 11 T. Pusateri 12 Unaffiliated 13 July 21, 2016 15 DNS Session Signaling 16 draft-bellis-dnsop-session-signal-01 18 Abstract 20 The Extension Mechanisms for DNS (EDNS(0)) [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 22, 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 . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Message Handling . . . . . . . . . . . . . . . . . . . . 4 65 3.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Mandatory TLVs . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Session Management Support TLVs . . . . . . . . . . . . . 6 68 4.1.1. "Not Implemented" . . . . . . . . . . . . . . . . . . 6 69 4.2. Session Management TLVs . . . . . . . . . . . . . . . . . 6 70 4.2.1. Start Session . . . . . . . . . . . . . . . . . . . . 6 71 4.2.2. Terminate Session . . . . . . . . . . . . . . . . . . 6 72 4.2.3. Idle Timeout . . . . . . . . . . . . . . . . . . . . 7 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 5.1. DNS Session Signaling Opcode Registration . . . . . . . . 8 75 5.2. DNS Session Signaling Type Codes Registry . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 8.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly 86 defined to only have "per-message" semantics. This document defines 87 a new Session Signaling OpCode used to carry persistent "per-session" 88 type-length-values (TLVs), and defines an initial set of TLVs used to 89 manage session timeouts and termination. 91 A further issue with EDNS(0) is that there is no standard mechanism 92 for a client to be able to tell whether a server has processed or 93 otherwise acted upon the individual options contained with an OPT RR. 94 The Session Signaling OpCode therefore requires an explicit response 95 to each request message. 97 It should be noted that the message format (see Section 3.1) does not 98 conform to the standard DNS packet format. 100 2. Terminology 102 The terms "initiator" and "responder" correspond respectively to the 103 initial sender and subsequent receiver of a Session Signaling TLV, 104 regardless of which was the "client" and "server" in the usual DNS 105 sense. The term "sender" may apply to either an initiator or 106 responder. 108 The term "session" in the context of this document means the exchange 109 of DNS messages over a single connection using an end-to-end 110 transport protocol where: 112 o connections can be long-lived 114 o either end of the connection may initiate requests 116 o message delivery order is guaranteed 118 o it is guaranteed that the same two endpoints are in communication 119 for the entire lifetime of the session. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Protocol Details 127 Session Signaling messages MUST only be carried in protocols and in 128 environments where a session may be established according to the 129 definition above. Standard DNS over TCP [RFC1035], and DNS over TLS 130 [RFC7858] are appropriate protocols. DNS over plain UDP is not 131 appropriate since it fails on both the bi-directional initiation 132 requirement and the message order delivery requirement. 134 Session Signaling messages relate only to the specific session in 135 which they are being carried. Where a middle box (e.g. a DNS proxy, 136 forwarder, or session multiplexer) is in the path the message MUST 137 NOT be blindly forwarded in either direction by that middle box. 138 This does not preclude the use of these messages in the presence of a 139 NAT box that rewrites Layer 3 or Layer 4 headers but otherwise 140 maintains the effect of a single session. 142 A server MUST NOT initiate Session Signaling messages until a client- 143 initiated Session Signaling message is received first. This 144 requirement is to ensure that the client does not observe unsolicited 145 inbound messages until it has indicated its ability to handle them. 147 Session Signaling support is therefore said to be confirmed from the 148 client's point of view after the first session signaling TLV has been 149 sent by that client and subsequently successfully acknowledged by the 150 server. 152 Use of Session Signaling by a client should be taken as an implicit 153 request for a long-lived session. 155 3.1. Message Format 157 A message containing a Session Signaling OpCode does not conform to 158 the usual DNS message format. The 4 octet header format from 159 [RFC1035] is however preserved, since that includes the message ID 160 and OpCode and RCODE fields, and the QR bit that differentiates 161 requests from responses. 163 Each message MUST contain only a single TLV. 165 1 1 1 1 1 1 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 167 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 168 | MESSAGE ID | 169 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 170 |QR | OpCode | Z | RCODE | 171 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 172 | | 173 / TLV-DATA / 174 / / 175 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 177 The MESSAGE ID, QR, OpCode and RCODE fields have their usual meaning 178 as defined in [RFC1035]. 180 The Z bits are currently unused, and SHOULD be set to zero (0) in 181 requests and responses unless re-defined in a later specification. 183 3.2. Message Handling 185 Both clients and servers may unilaterally send Session Signaling 186 messages at any point in the lifetime of a session and are therefore 187 considered to be the initiator with respect to that message. The 188 initiator MUST set the value of the QR bit in the DNS header to zero 189 (0), and the responder MUST set it to one (1). 191 Every Session Signaling request message MUST elicit a response (which 192 MUST have the same ID in the DNS message header as in the request). 194 In order to preserve the correct sequence of state, Session Signaling 195 requests MUST NOT be processed out of order. 197 << RB: should the presence of a SS message create a "sequencing 198 point", such that all pending responses must be answered? >> 200 The RCODE value in a response uses a subset of the standard (non- 201 extended) RCODE values from the IANA DNS RCODEs registry, interpreted 202 as follows: 204 +------+----------+---------------------------------+ 205 | Code | Mnemonic | Description | 206 +------+----------+---------------------------------+ 207 | 0 | NOERROR | TLV processed successfully | 208 | | | | 209 | 1 | FORMERR | TLV format error | 210 | | | | 211 | 4 | NOTIMP | Session Signaling not supported | 212 | | | | 213 | 5 | REFUSED | TLV declined for policy reasons | 214 +------+----------+---------------------------------+ 216 3.3. TLV Format 218 1 1 1 1 1 1 219 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 220 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 221 | SESSION-TYPE | 222 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 223 | SESSION-LENGTH | 224 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 225 | | 226 / SESSION-DATA / 227 / / 228 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 230 SESSION-TYPE: A 16 bit field in network order giving the type of the 231 current Session Signaling TLV per the IANA DNS Session Signaling 232 Type Codes Registry. 234 SESSION-LENGTH: A 16 bit field in network order giving the size in 235 octets of SESSION-DATA. 237 SESSION-DATA: Type-code specific. 239 4. Mandatory TLVs 241 4.1. Session Management Support TLVs 243 4.1.1. "Not Implemented" 245 Since the "NOTIMP" RCODE is required to indicate lack of support for 246 the Session Signaling OpCode itself, the "Not Implemented" TLV (0) 247 MUST be returned in response to a TLV that is not implemented by the 248 responder. 250 This TLV has no SESSION-DATA. 252 4.2. Session Management TLVs 254 4.2.1. Start Session 256 The Start Session TLV (1) SHOULD be used by a client to indicate 257 support for Session Signaling. It MUST NOT be initiated by a server. 259 It is not required that this TLV be used in every session - any valid 260 client-initiated TLV will suffice to initiate Session Signaling 261 support. The intention of this TLV is to provide a suitable "No-Op" 262 TLV to permit Session Signaling support to be negotiated without 263 carrying any other information. 265 This TLV has no SESSION-DATA. 267 << RB: this could perhaps also be used as a real "no-op" message to 268 provide application-level keep-alive pings >> 270 4.2.2. Terminate Session 272 The Terminate Session TLV (2) MAY be sent by a server to request that 273 the client terminate the session. It MUST NOT be initiated by a 274 client. 276 The client SHOULD terminate the session as soon as possible, but MAY 277 wait for any inflight queries to be answered. It MUST NOT initiate 278 any new requests over the existing session. 280 The SESSION-DATA is as follows: 282 1 1 1 1 1 1 283 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 284 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 285 | RECONNECT DELAY | 286 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 288 RECONNECT DELAY: a time value, specified as a 16 bit word in network 289 order in units of 100 milliseconds, within which the client MUST 290 NOT establish a new session to the current server. 292 The RECOMMENDED value is 10 seconds. << RB: text required here about 293 default values for load balancers, etc >> 295 4.2.3. Idle Timeout 297 The Idle Timeout TLV (3) has similar intent to the EDNS TCP Keepalive 298 Option [RFC7828]. It is used by a server to tell the client how long 299 it may leave the current session idle for. a client. The definition 300 of an idle session is as specified in [RFC7766]. 302 Messages generate by the client have no SESSION-DATA (whether in 303 requests or responses). A client-initiated Idle Timeout TLV allows 304 the client to request the current timeout value, whereas a server- 305 initiated request allows the server to unilaterally update the 306 current timeout value. 308 Messages generated by the server contain SESSION-DATA as follows: 310 1 1 1 1 1 1 311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 312 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 313 | IDLE TIMEOUT | 314 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 316 IDLE TIMEOUT: the idle timeout for the current session, specified as 317 a 16 bit word in network order in units of 100 milliseconds. 319 The client SHOULD terminate the current session if it remains idle 320 for longer than the specified timeout (and MAY of course terminate 321 the session earlier). The server MAY unilaterally terminate the 322 connection at any time, but SHOULD allow the client to keep the 323 connection open if further messages are received before the idle 324 timeout expires. 326 A client / server pair that supports Session Signaling MUST NOT use 327 the EDNS TCP KeepAlive option within any message once bi-directional 328 Session Signaling support has been confirmed. 330 5. IANA Considerations 331 5.1. DNS Session Signaling Opcode Registration 333 IANA are directed to assign the value TBD for the Session Signaling 334 OpCode in the DNS OpCodes Registry. 336 5.2. DNS Session Signaling Type Codes Registry 338 IANA are directed to create the DNS Session Signaling Type Codes 339 Registry, with initial values as follows: 341 +-----------+--------------------------------+----------+-----------+ 342 | Type | Name | Status | Reference | 343 +-----------+--------------------------------+----------+-----------+ 344 | 0 | Not implemented | | RFC-TBD1 | 345 | | | | | 346 | 1 | Start Session | Standard | RFC-TBD1 | 347 | | | | | 348 | 2 | Terminate Session | Standard | RFC-TBD1 | 349 | | | | | 350 | 3 | Idle Timeout | Standard | RFC-TBD1 | 351 | | | | | 352 | 4 - 63 | Unassigned, reserved for | | | 353 | | session management TLVs | | | 354 | | | | | 355 | 64 - | Unassigned | | | 356 | 63487 | | | | 357 | | | | | 358 | 63488 - | Reserved for local / | | | 359 | 64511 | experimental use | | | 360 | | | | | 361 | 64512 - | Reserved for future expansion | | | 362 | 65535 | | | | 363 +-----------+--------------------------------+----------+-----------+ 365 Registration of additional Session Signaling Type Codes requires 366 Expert Review. << RB: definition of process required? >> 368 6. Security Considerations 370 If this mechanism is to be used with DNS over TLS, then these 371 messages are subject to the same constraints as any other DNS over 372 TLS messages and MUST NOT be sent in the clear before the TLS session 373 is established. 375 7. Acknowledgements 377 TBW 379 8. References 381 8.1. Normative References 383 [RFC1035] Mockapetris, P., "Domain names - implementation and 384 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 385 November 1987, . 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 389 RFC2119, March 1997, 390 . 392 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 393 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 394 RFC6891, April 2013, 395 . 397 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 398 D. Wessels, "DNS Transport over TCP - Implementation 399 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 400 . 402 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 403 edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/ 404 RFC7828, April 2016, 405 . 407 8.2. Informative References 409 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 410 and P. Hoffman, "Specification for DNS over Transport 411 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 412 2016, . 414 Authors' Addresses 415 Ray Bellis 416 Internet Systems Consortium, Inc. 417 950 Charter Street 418 Redwood City CA 94063 419 USA 421 Phone: +1 650 423 1200 422 Email: ray@isc.org 424 Stuart Cheshire 425 Apple Inc. 426 1 Infinite Loop 427 Cupertino CA 95014 428 USA 430 Phone: +1 408 974 3207 431 Email: cheshire@apple.com 433 John Dickinson 434 Sinodun Internet Technologies 435 Magadalen Centre 436 Oxford Science Park 437 Oxford OX4 4GA 438 United Kingdom 440 Email: jad@sinodun.com 442 Sara Dickinson 443 Sinodun Internet Technologies 444 Magadalen Centre 445 Oxford Science Park 446 Oxford OX4 4GA 447 United Kingdom 449 Email: sara@sinodun.com 451 Allison Mankin 452 Salesforce 454 Email: allison.mankin@gmail.com 455 Tom Pusateri 456 Unaffiliated 458 Phone: +1 843 473 7394 459 Email: pusateri@bangj.com