idnits 2.17.1 draft-bellis-dnsop-session-signal-00.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 6, 2016) is 2822 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 7, 2017 Apple Inc. 6 J. Dickinson 7 Sinodun 8 A. Mankin 9 T. Pusateri 10 Unaffiliated 11 July 6, 2016 13 DNS Session Signaling 14 draft-bellis-dnsop-session-signal-00 16 Abstract 18 The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly 19 defined to only have "per-message" semantics. This document defines 20 a new Session Signaling OpCode used to carry persistent "per-session" 21 type-length-values (TLVs), and defines an initial set of TLVs used to 22 handle feature negotiation and to manage session timeouts and 23 termination. 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 http://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 January 7, 2017. 42 Copyright Notice 44 Copyright (c) 2016 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 (http://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Message Format . . . . . . . . . . . . . . . . . . . . . 3 63 3.2. Message Handling . . . . . . . . . . . . . . . . . . . . 4 64 3.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Mandatory TLVs . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Feature Negotiation . . . . . . . . . . . . . . . . . . . 5 67 4.1.1. TypeCode Support . . . . . . . . . . . . . . . . . . 5 68 4.2. Layer 4 Connection Management TLVs . . . . . . . . . . . 6 69 4.2.1. Terminate . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2.2. Idle Timeout . . . . . . . . . . . . . . . . . . . . 6 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 5.1. DNS Session Signaling OpCode Registration . . . . . . . . 7 73 5.2. DNS Session Signaling Status Codes Registry . . . . . . . 7 74 5.3. DNS Session Signaling Type Codes Registry . . . . . . . . 7 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 The Extension Mechanisms for DNS (EDNS(0)) [RFC6891] is explicitly 83 defined to only have "per-message" semantics. This document defines 84 a new Session Signaling OpCode used to carry persistent "per-session" 85 type-length-values (TLVs), and defines an initial set of TLVs used to 86 handle feature negotiation and to manage session timeouts and 87 termination. 89 A further issue with EDNS(0) is that there is no standard mechanism 90 for a client to be able to tell whether a server has processed or 91 otherwise acted upon the individual options contained with an OPT RR. 92 The Session Signaling Opcode therefore requires an explicit response 93 to each TLV within a request. 95 The message format (see Section 3.1) does not completely conform to 96 the standard DNS packet format but is designed such that existing DNS 97 protocol parsers should be able to read the packet header and then 98 simply ignore the extra data that appears thereafter. 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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Protocol Details 114 Session Signaling messages MUST only be carried in protocols and in 115 environments that can guarantee that the same two endpoints are in 116 communication for the entire lifetime of the session. 118 Session Signaling messages relate only to the specific session in 119 which they are being carried. Where a middle box (e.g. a DNS proxy, 120 forwarder, or session multiplexer) is in the path the message MUST 121 NOT be blindly forwarded in either direction by that middle box. 122 This does not preclude the use of these messages in the presence of a 123 NAT box that rewrites Layer 3 or Layer 4 headers but otherwise 124 maintains the effect of a single session. 126 << RB: OSI Layer 5 session analog? This is obviously intended for 127 TCP "sessions" which aren't distinct from Layer 4, but is this also 128 applicable to DNS-o-DTLS, or DNS over UDP with an EDNS cookie - I 129 think probably "yes" for the former, but "no" for the latter. I'm 130 wondering whether "session" is even the right term to be using 131 here >> 133 3.1. Message Format 135 A message containing a Session Signaling Opcode does not conform to 136 the usual DNS message format. The 12 octet header format from 137 [RFC1035] is preserved, but the four section count fields (QDCOUNT, 138 ANCOUNT, NSCOUNT and ARCOUNT) MUST all be set to zero. 140 A list of TLVs are used in place of the usual sections, and MUST 141 appear immediately after the 12 octet header. The total size of the 142 TLVs is calculated from the value of the standard two octet framing 143 word minus the 12 octets of the DNS header. 145 3.2. Message Handling 147 Both clients and servers may unilaterally send Session Signaling 148 messages at any point in the lifetime of a session and are therefore 149 considered to be the initiator with respect to that message. The 150 initiator MUST set the value of the QR bit in the DNS header to zero 151 (0), and the responder MUST set it to one (1). 153 Every Session Signaling request message MUST elicit a response (which 154 MUST have the same ID in the DNS message header as in the request) 155 and every TLV contained within the request requires a corresponding 156 TLV in the response. 158 In order to preserve the correct sequence of state, Session Signaling 159 requests MUST NOT be processed out of order. Similarly the TLVs in a 160 message MUST be processed in the order in which they are contained in 161 the message, and the order of the TLVs in the response MUST 162 correspond with the order of the TLVs in the request. 164 << RB: should the presence of a SS message create a "sequencing 165 point", such that all pending responses must be answered? >> 167 3.3. TLV Format 169 1 1 1 1 1 1 170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 171 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 172 |SESSION-STATUS | SESSION-TYPE | 173 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 174 | SESSION-LENGTH | 175 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 176 | | 177 / SESSION-DATA / 178 / / 179 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 181 SESSION-STATUS: A 4 bit field used in a response to indicate the 182 success (or otherwise) of an operation, as defined in the DNS 183 Session Signaling Status Codes Registry. It SHOULD contain 184 "NOERROR" (0) in a request message but the responder MUST NOT 185 reject the request if it does not. 187 SESSION-TYPE: A 12 bit field in network order giving the type of the 188 current Session Signaling TLV per the IANA DNS Session Signaling 189 Type Codes Registry. 191 SESSION-LENGTH: A 16 bit field in network order giving the size in 192 octets of SESSION-DATA. 194 SESSION-DATA: Type-code specific. The SESSION-DATA field MUST be 195 NUL padded to an even number of octets such that each Session 196 Signaling TLV is aligned on a two octet boundary relative to the 197 start of the first Session Signaling TLV. Padding octets MUST NOT 198 be included in the calculation of SESSION-LENGTH but MUST be 199 included in the calculation of the overall message length. 201 << RB: the padding is specified such that client code can read the 202 type and length fields directly from an aligned uint16_t array (with 203 byte swapping) >> 205 4. Mandatory TLVs 207 4.1. Feature Negotiation 209 4.1.1. TypeCode Support 211 The TypeCode Support TLV (1) is used to allow a client and server to 212 exchange information about which Session Signaling Type Codes they 213 support. 215 The SESSION-DATA contains a list of the Session Signaling Type Codes 216 supported by the sender. 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 | TYPE CODEs | 222 / ... / 223 / / 224 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 226 TYPE CODEs: A list of 16 bit words in network order comprising the 227 complete list of Session Signaling Type Codes supported by the 228 sender. Since a Session Signaling Type Code is in reality only a 229 12 bit value, the four most significant bits of each word MUST be 230 zero. The number of TYPE CODEs can be calculated from the total 231 length of the TLV. 233 An initiator MAY send its own list of supported Session Signaling 234 Type Codes in a TypeCode Support TLV, and if sent they MUST be 235 complete. Otherwise the SESSION-DATA MUST be empty. In either case 236 the responder MUST respond with its complete list of supported Type 237 Codes. 239 4.2. Layer 4 Connection Management TLVs 241 4.2.1. Terminate 243 The Terminate TLV (64) MAY be sent by a server to request that the 244 client terminate the session, and when sent MUST be the only TLV 245 present. It MUST NOT be requested by a client. 247 The client SHOULD terminate the session as soon as possible, but MAY 248 wait for any inflight queries to be answered. It MUST NOT initiate 249 any new queries over the existing session, nor send any further TLVs 250 other than its response to the Terminate request. 252 << RB: dns-sd push has a "reconnect delay" option but I think it's of 253 questionable value since in an anycast or load-balancing architecture 254 there's no way for the client to know which instance sent the option 255 nor control which server instance the next connection will go to. 256 This would IMHO be better controlled directly at the TCP layer. >> 258 4.2.2. Idle Timeout 260 The Idle Timeout TLV (65) has similar semantics to the EDNS TCP 261 Keepalive Option [RFC7828]. It is used by a server to tell the 262 client how long it may leave the current session idle for. 264 The SESSION-DATA is as follows: 266 1 1 1 1 1 1 267 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 268 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 269 | IDLE TIMEOUT | 270 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 272 IDLE TIMEOUT: the idle timeout for the current session, specified as 273 a 16 bit word in network order in units of 100 milliseconds. 275 It is NOT an error for this TLV and the similar EDNS option to appear 276 within the same session. The client SHOULD pay attention to the most 277 recently received value, regardless of which method was used to send 278 it. 280 The client SHOULD terminate the current session if it remains idle 281 for longer than the specified timeout (and MAY of course terminate 282 the session earlier). The server MAY unilaterally terminate the 283 connection at any time, but SHOULD allow the client to keep the 284 connection open if further messages are received before the idle 285 timeout expires. 287 << RB: this assumes that the EDNS OPT RR is added at the final stage 288 of message processing, and therefore not affected by out-of-order 289 processing - c.f. comment above about sequencing points >> 291 5. IANA Considerations 293 5.1. DNS Session Signaling OpCode Registration 295 IANA are directed to assign the value TBD for the Session Signaling 296 OpCode in the DNS OpCodes Registry. 298 5.2. DNS Session Signaling Status Codes Registry 300 IANA are directed to create the DNS Session Signaling Status Codes 301 Registry, with initial values as follows: 303 +------+----------+---------------------------------+-----------+ 304 | Code | Mnemonic | Description | Reference | 305 +------+----------+---------------------------------+-----------+ 306 | 0 | NOERROR | TLV processed successfully | RFC-TBD1 | 307 | | | | | 308 | 4 | NOTIMP | TLV not implemented | RFC-TBD1 | 309 | | | | | 310 | 5 | REFUSED | TLV declined for policy reasons | RFC-TBD1 | 311 +------+----------+---------------------------------+-----------+ 313 Registration of additional Session Signaling Status Codes requires 314 Standards Action. 316 5.3. DNS Session Signaling Type Codes Registry 318 IANA are directed to create the DNS Session Signaling Type Codes 319 Registry, with initial values as follows: 321 +----------+---------------------------------+----------+-----------+ 322 | Type | Name | Status | Reference | 323 +----------+---------------------------------+----------+-----------+ 324 | 0 | Reserved | | RFC-TBD1 | 325 | | | | | 326 | 1 | TypeCode Support | Standard | RFC-TBD1 | 327 | | | | | 328 | 2 - 63 | Unassigned, reserved for | | | 329 | | feature negotiation TLVs | | | 330 | | | | | 331 | 64 | Terminate | Standard | RFC-TBD1 | 332 | | | | | 333 | 65 | Idle Timeout | Standard | RFC-TBD1 | 334 | | | | | 335 | 66 - 127 | Unassigned, reserved for | | | 336 | | session management TLVs | | | 337 | | | | | 338 | 127 - | Unassigned | | | 339 | 3965 | | | | 340 | | | | | 341 | 3968 - | Reserved for local / | | | 342 | 4031 | experimental use | | | 343 | | | | | 344 | 4032 - | Reserved for future expansion | | | 345 | 4095 | | | | 346 +----------+---------------------------------+----------+-----------+ 348 Registration of additional Session Signaling Type Codes requires 349 Expert Review. << RB: definition of process required? >> 351 6. Security Considerations 353 The authors are not aware of any specific security considerations 354 introduced by this specification at this time. 356 7. Acknowledgements 358 TBW 360 8. Normative References 362 [RFC1035] Mockapetris, P., "Domain names - implementation and 363 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 364 November 1987, . 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 368 RFC2119, March 1997, 369 . 371 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 372 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 373 RFC6891, April 2013, 374 . 376 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 377 edns-tcp-keepalive EDNS0 Option", RFC 7828, DOI 10.17487/ 378 RFC7828, April 2016, 379 . 381 Authors' Addresses 383 Ray Bellis 384 Internet Systems Consortium, Inc. 385 950 Charter Street 386 Redwood City CA 94063 387 USA 389 Phone: +1 650 423 1200 390 Email: ray@isc.org 392 Stuart Cheshire 393 Apple Inc. 394 1 Infinite Loop 395 Cupertino CA 95014 396 USA 398 Phone: +1 408 974 3207 399 Email: cheshire@apple.com 401 John Dickinson 402 Sinodun Internet Technologies 403 Magadalen Centre 404 Oxford Science Park 405 Oxford OX4 4GA 406 United Kingdom 407 Allison Mankin 408 Unaffiliated 410 Email: allison.mankin@gmail.com 412 Tom Pusateri 413 Unaffiliated 415 Phone: +1 843 473 7394 416 Email: pusateri@bangj.com