< draft-ietf-dnsop-session-signal-18.txt   draft-ietf-dnsop-session-signal-19.txt >
DNSOP Working Group R. Bellis DNSOP Working Group R. Bellis
Internet-Draft ISC Internet-Draft ISC
Updates: 1035, 7766 (if approved) S. Cheshire Updates: 1035, 7766 (if approved) S. Cheshire
Intended status: Standards Track Apple Inc. Intended status: Standards Track Apple Inc.
Expires: April 26, 2019 J. Dickinson Expires: June 7, 2019 J. Dickinson
S. Dickinson S. Dickinson
Sinodun Sinodun
T. Lemon T. Lemon
Nibbhaya Consulting Nibbhaya Consulting
T. Pusateri T. Pusateri
Unaffiliated Unaffiliated
October 23, 2018 December 04, 2018
DNS Stateful Operations DNS Stateful Operations
draft-ietf-dnsop-session-signal-18 draft-ietf-dnsop-session-signal-19
Abstract Abstract
This document defines a new DNS OPCODE for DNS Stateful Operations This document defines a new DNS OPCODE for DNS Stateful Operations
(DSO). DSO messages communicate operations within persistent (DSO). DSO messages communicate operations within persistent
stateful sessions, using type-length-value (TLV) syntax. Three TLVs stateful sessions, using type-length-value (TLV) syntax. Three TLVs
are defined that manage session timeouts, termination, and encryption are defined that manage session timeouts, termination, and encryption
padding, and a framework is defined for extensions to enable new padding, and a framework is defined for extensions to enable new
stateful operations. This document updates RFC 1035 by adding a new stateful operations. This document updates RFC 1035 by adding a new
DNS header opcode which has different message semantics, and a new DNS header opcode which has different message semantics, and a new
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2019. This Internet-Draft will expire on June 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 7, line 16 skipping to change at page 7, line 16
message, a DNS response, or a DSO response. message, a DNS response, or a DSO response.
service instance: a specific instance of server software running on service instance: a specific instance of server software running on
a specific host (Section 9.1). a specific host (Section 9.1).
long-lived operation: a long-lived operation is an outstanding long-lived operation: a long-lived operation is an outstanding
operation on a DSO session where either the client or server, operation on a DSO session where either the client or server,
acting as initiator, has requested that the responder send new acting as initiator, has requested that the responder send new
information regarding the request, as it becomes available. information regarding the request, as it becomes available.
Early Data: A TCP SYN packet (TCP Fast Open) containing a TLS 1.3 Early Data: Early Data: A TLS 1.3 handshake containing early data
initial handshake containing early data that begins a DSO session that begins a DSO session ([RFC8446] section 2.3). TCP Fast Open
([RFC8446] section 2.3). TCP Fast Open is only permitted when is only permitted when using TLS.
using TLS encapsulation: a TCP SYN message that does not use TLS
encapsulation but contains data is not permitted.
DNS message: any DNS message, including DNS queries, response, DNS message: any DNS message, including DNS queries, response,
updates, DSO messages, etc. updates, DSO messages, etc.
DNS request message: any DNS message where the QR bit is 0. DNS request message: any DNS message where the QR bit is 0.
DNS response message: any DNS message where the QR bit is 1. DNS response message: any DNS message where the QR bit is 1.
DSO message: a DSO request message, DSO unidirectional message, or a DSO message: a DSO request message, DSO unidirectional message, or a
DSO response to a DSO request message. If the QR bit is 1 in a DSO response to a DSO request message. If the QR bit is 1 in a
skipping to change at page 13, line 6 skipping to change at page 13, line 6
a DSO request message, such as a DSO Keepalive request message a DSO request message, such as a DSO Keepalive request message
(Section 7.1), and receiving a response, with matching MESSAGE ID, (Section 7.1), and receiving a response, with matching MESSAGE ID,
and RCODE set to NOERROR (0), indicating that the DSO request was and RCODE set to NOERROR (0), indicating that the DSO request was
successful. successful.
Some DSO messages are permitted as early data (Section 11.1). Others Some DSO messages are permitted as early data (Section 11.1). Others
are not. Unidirectional messages are never permitted as early data are not. Unidirectional messages are never permitted as early data
unless an implicit session exists. unless an implicit session exists.
If a server receives a DSO message in early data whose primary TLV is If a server receives a DSO message in early data whose primary TLV is
not permitted to appear in early data, the server MUST forcible abort not permitted to appear in early data, the server MUST forcibly abort
the connection. If a client receives a DSO message in early data, the connection. If a client receives a DSO message in early data,
and there is no implicit DSO session, the client MUST forcibly abort and there is no implicit DSO session, the client MUST forcibly abort
the connection. If a server or client receives a TCP Fast Open the connection. This can only be enforced on TLS connections;
message that is not a TLS 1.3 0-RTT initial handshake, it MUST therefore, servers MUST NOT enable TFO when listening for a
forcibly abort the connection. connection that does not require TLS.
5.1.1. Session Establishment Failure 5.1.1. Session Establishment Failure
If the response RCODE is set to NOTIMP (4), or in practise any value If the response RCODE is set to NOTIMP (4), or in practise any value
other than NOERROR (0) or DSOTYPENI (defined below), then the client other than NOERROR (0) or DSOTYPENI (defined below), then the client
MUST assume that the server does not implement DSO at all. In this MUST assume that the server does not implement DSO at all. In this
case the client is permitted to continue sending DNS messages on that case the client is permitted to continue sending DNS messages on that
connection, but the client MUST NOT issue further DSO messages on connection, but the client MUST NOT issue further DSO messages on
that connection. that connection.
skipping to change at page 36, line 23 skipping to change at page 36, line 23
By default it is RECOMMENDED that clients request, and servers grant, By default it is RECOMMENDED that clients request, and servers grant,
a keepalive interval of 60 minutes. This keepalive interval provides a keepalive interval of 60 minutes. This keepalive interval provides
for reasonably timely detection if a client abruptly disconnects for reasonably timely detection if a client abruptly disconnects
without cleanly closing the session, and is sufficient to maintain without cleanly closing the session, and is sufficient to maintain
state in firewalls and NAT gateways that follow the IETF recommended state in firewalls and NAT gateways that follow the IETF recommended
Best Current Practice that the "established connection idle-timeout" Best Current Practice that the "established connection idle-timeout"
used by middleboxes be at least 2 hours 4 minutes [RFC5382] used by middleboxes be at least 2 hours 4 minutes [RFC5382]
[RFC7857]. [RFC7857].
Note that the lower the keepalive interval value, the higher the load Note that the lower the keepalive interval value, the higher the load
on client and server. For example, a (hypothetical and unrealistic) on client and server. Moreover for a keep-alive value that is
keepalive interval value of 100 ms would result in a continuous smaller than the time needed for the transport to retransmit, a
stream of ten messages per second or more, in both directions, to single packet loss would cause a server to overzealously abort the
keep the DSO Session alive. And, in this extreme example, a single connect. For example, a (hypothetical and unrealistic) keepalive
packet loss and retransmission over a long path could introduce a interval value of 100 ms would result in a continuous stream of ten
momentary pause in the stream of messages of over 200 ms, long enough messages per second or more (if allowed by the current congestion
to cause the server to overzealously abort the connection. control window), in both directions, to keep the DSO Session alive.
And, in this extreme example, a single retransmission over a path
with, e.g., 100ms RTT would introduce a momentary pause in the stream
of messages, long enough to cause the server to abort the connection.
Because of this concern, the server MUST NOT send a DSO Keepalive Because of this concern, the server MUST NOT send a DSO Keepalive
message (either a response to a client-initiated request, or a message (either a response to a client-initiated request, or a
server-initiated message) with a keepalive interval value less than server-initiated message) with a keepalive interval value less than
ten seconds. If a client receives a DSO Keepalive message specifying ten seconds. If a client receives a DSO Keepalive message specifying
a keepalive interval value less than ten seconds this is a fatal a keepalive interval value less than ten seconds this is a fatal
error and the client MUST forcibly abort the connection immediately. error and the client MUST forcibly abort the connection immediately.
A keepalive interval value of 0xFFFFFFFF represents "infinity" and A keepalive interval value of 0xFFFFFFFF represents "infinity" and
informs the client that it should generate no DSO keepalive traffic. informs the client that it should generate no DSO keepalive traffic.
skipping to change at page 61, line 33 skipping to change at page 61, line 33
number of DSO sessions established and can also close existing DSO number of DSO sessions established and can also close existing DSO
sessions as needed, denial of service or resource exhaustion should sessions as needed, denial of service or resource exhaustion should
not be a concern. not be a concern.
11.1. TLS 0-RTT Considerations 11.1. TLS 0-RTT Considerations
DSO permits zero round-trip operation using TCP Fast Open [RFC7413] DSO permits zero round-trip operation using TCP Fast Open [RFC7413]
with TLS 1.3 [RFC8446] 0-RTT to reduce or eliminate round trips in with TLS 1.3 [RFC8446] 0-RTT to reduce or eliminate round trips in
session establishment. TCP Fast Open is only permitted in session establishment. TCP Fast Open is only permitted in
combination with TLS 0-RTT. In the rest of this section we refer to combination with TLS 0-RTT. In the rest of this section we refer to
TLS 1.3 early data in a TLS 0-RTT initial handshake message that is TLS 1.3 early data in a TLS 0-RTT initial handshake message, whether
included in a TCP Fast Open packet as "early data." or not it is included in a TCP Fast Open packet, as "early data."
A DSO message may or may not be permitted to be sent as early data. A DSO message may or may not be permitted to be sent as early data.
The definition for each TLV that can be used as a primary TLV is The definition for each TLV that can be used as a primary TLV is
required to state whether or not that TLV is permitted as early data. required to state whether or not that TLV is permitted as early data.
Only response-requiring messages are ever permitted as early data, Only response-requiring messages are ever permitted as early data,
and only clients are permitted to send any DSO message as early data, and only clients are permitted to send any DSO message as early data,
unless there is an implicit session (see Section 5.1). unless there is an implicit session (see Section 5.1).
For DSO messages that are permitted as early data, a client MAY For DSO messages that are permitted as early data, a client MAY
include one or more such messages as early data without having to include one or more such messages as early data without having to
skipping to change at page 63, line 48 skipping to change at page 63, line 48
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-dnsop-no-response-issue] [I-D.ietf-dnsop-no-response-issue]
Andrews, M. and R. Bellis, "A Common Operational Problem Andrews, M. and R. Bellis, "A Common Operational Problem
in DNS Servers - Failure To Respond.", draft-ietf-dnsop- in DNS Servers - Failure To Respond.", draft-ietf-dnsop-
no-response-issue-11 (work in progress), July 2018. no-response-issue-12 (work in progress), November 2018.
[I-D.ietf-dnssd-mdns-relay] [I-D.ietf-dnssd-mdns-relay]
Lemon, T. and S. Cheshire, "Multicast DNS Discovery Lemon, T. and S. Cheshire, "Multicast DNS Discovery
Relay", draft-ietf-dnssd-mdns-relay-01 (work in progress), Relay", draft-ietf-dnssd-mdns-relay-01 (work in progress),
July 2018. July 2018.
[I-D.ietf-dnssd-push] [I-D.ietf-dnssd-push]
Pusateri, T. and S. Cheshire, "DNS Push Notifications", Pusateri, T. and S. Cheshire, "DNS Push Notifications",
draft-ietf-dnssd-push-15 (work in progress), September draft-ietf-dnssd-push-16 (work in progress), November
2018. 2018.
[I-D.ietf-doh-dns-over-https] [I-D.ietf-doh-dns-over-https]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", draft-ietf-doh-dns-over-https-14 (work in (DoH)", draft-ietf-doh-dns-over-https-14 (work in
progress), August 2018. progress), August 2018.
[I-D.ietf-dprive-padding-policy] [I-D.ietf-dprive-padding-policy]
Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf-
dprive-padding-policy-06 (work in progress), July 2018. dprive-padding-policy-06 (work in progress), July 2018.
 End of changes. 11 change blocks. 
24 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/