Babel Routing Protocol over Datagram Transport Layer Security
draft-ietf-babel-dtls-10

[Ballot comment]
[[ comments ]]

[ section 5 ]

* The first sentence of the 3rd paragraphs reads to me like "while DTLS
  provides protection against replay attacks an attacker can still mount
  a replay attack".

  I don't have any constructive proposal to change this, but if it tickles
  something in your mind that might be more clear to those not super
  knowledgeable about DTLS, I'm sure that'll be great.

[Ballot comment]
Reading the shorter document before the longer one, so I may be missing some important context here.

This was pretty easy to read, so nice work.  A number of editorial comments and suggestions follow:

Section 2:

* "... sent over to both unicast ..." -- s/over to both/over both/, right?

Section 2.1:

* "... intervals, to avoid ..." -- remove the comma

* "Nodes SHOULD drop packets that have been reordered ..." -- Why would an implementer not do this?  (i.e., why is it only a SHOULD?)

Section 2.2:

* "... from the Magic byte ..." -- s/Magic/magic/

Section 2.3:

* Please expand/explain "TLV" on first use.

* Just an aesthetic suggestion: In this sentence...

  Since Babel over DTLS only protects unicast packets, implementors may
  implement Babel over DTLS by modifying an implementation of Babel
  without DTLS support, and replacing any TLV previously sent over
  multicast with a separate TLV sent over unicast for each neighbour.

...you use "implementors", "implement", and "implementation".  Maybe this?

  Since Babel over DTLS only protects unicast packets, implementors may
  provide Babel over DTLS by using a variant of Babel
  without DTLS support, and replacing any TLV previously sent over
  multicast with a separate TLV sent over unicast for each neighbour.

Section 2.5:

* Why is the stuff in the first paragraph only SHOULD/RECOMMENDED?  (The answer may lie in the second paragraph, but I'm uncertain.)

* I suggest that Section 5 should make a backward reference to this section since it talks about mitigation of an attack.

Section 2.6:

* "A node MAY allow configuration options to allow ..." -- change one of those "allow"s to "permit"

[Ballot comment]
This is very well written draft. Nits:

-
- Please update the DTLS-CID reference; I see that even the current draft is going to expire on 23 April.

[Ballot comment]
This is very well written draft. Nits:

- In section 2.1, could we change "nodes could use DTLS connection identifiers" to a MAY?
- Please update the DTLS-CID reference; I see that even the current draft is going to expire on 23 April.

[Ballot discuss]
I support Roman's Discuss point (1) (and basically cover the same as his
(2) below).

Let's have a discussion about (DTLS) identity.
Section 2.1 says that we use mutual authentication and that
implementations "MUST support authenticating peers against a local store
of credentials"; also that "if a node receives a new DTLS connection
from a neighbour to whom it already has a connection, the node MUST NOT
discard the older connection until it has completed the handshake of the
new one and validated the identity of the peer".  But how does this
authentication occur, and what constitutes the identity of the peer.  We
will frequently have (D)TLS consumers cite RFC 6125 and say that (e.g.)
DNS-ID or SRV-ID must match the name obtained in some fashion.  But for
Babel, we are authenticating routers -- router identity is usually in
the form of just an IP address on a loopback interface!  Are we expected
to get certificates that certify IP addresses as identity, or use some
sort of PSK or password-based TLS authentication?  (The last two are not
really compatible with the "MUST send a CertificateRequest", BTW.)  Raw
public keys?  I think we can give a more clear picture of how to build a
secure system.

Relatedly, once DTLS authenticates an identity, what level of
authorization checks are performed?  Are we still in a single
authorization domain, where any router that authenticates as being part
of a given domain is implictily authorized to be a babel peer and convey
any and all routing information?

We should also give some guidance on ciphers and algorithms where we
discuss the DTLS details (BCP 195 is probably the safest bet here, even
if it's a little in need of an update).

[Ballot comment]
Section 1.2

  The protocol described in this document protects Babel packets with
  DTLS.  As such, it inherits the features offered by DTLS, notably
  authentication, integrity, replay protection, confidentiality and
  asymmetric keying.  It is therefore expected to be applicable in a

replay protection is not an inherent feature of DTLS, so I suggest
"optional replay protection" to emphasize that an implementation of
babel may need to explicitly configure it.

  There exists another mechanism for securing Babel, namely Babel HMAC
  authentication [BABEL-HMAC].  HMAC only offers basic features, namely
  authentication, integrity and replay protection with a small number
  of symmetric keys.  A comparison of Babel security mechanisms and

Even the authentication is limited, as it is group authentication, not
true per-entity authentication.

Section 2.1

  information last longer.  If a node receives a new DTLS connection
  from a neighbour to whom it already has a connection, the node MUST
  NOT discard the older connection until it has completed the handshake
  of the new one and validated the identity of the peer.

(Does the validated identity of the peer have to match the one from the
previous handshake?)

Section 2.3

I agree with the RtgDir reviewer that unprotected (multicast) Hellos are
at risk of tampering by an attacker, who could drop them or modify the
seqno/interval, for DoS purposes.
I see the text about use of multicast Hellos for discovery and the
acknowledgment that an out-of-band neighbor discovery mechanism may be
available.  Are there any such discovery mechanism under development?
Regardless, I think we should consider mandating/suggesting (to some
strength; maybe SHOULD is enough) the use of protected unicast Hellos
instead of just stating that nodes can either rely on multicast or send
protected unicast Hellos.  When unicast (protected) Hellos are in use,
even tampering with multicast Hellos will not be enough to cause a DoS
attack, since a node must be detected as down on both unicast and
multicast to be considered gone.  (Of course, a sufficiently powerful
attacker can still just drop all traffic and cause DoS.)

Section 2.4

  Note that receiving an unprotected packet can still be used to
  discover new neighbours, even when all TLVs in that packet are
  silently ignored.

Is this going to cause a lot of spurious DTLS handshake attempts if we
ever end up with a babel-dtls implementation adjacent to a
classic-babel-only implementation?  Is there any rate limiting on that?

Section 2.5

Do we want to talk about the potential consequences of an attacker
arbitrarily delaying valid content (to justify the need for a timeout)?

Section 2.6

  A node MAY allow configuration options to allow unprotected Babel on
  some interfaces but not others; this effectively gives nodes on that
  interface the same access as authenticated nodes, and SHOULD NOT be
  done unless that interface has a mechanism to authenticate nodes at a
  lower layer (e.g., IPsec).

I'm unhappy that this SHOULD NOT is not a MUST NOT, but cannot quite
justify making it a Discuss-level point.

Section 3

  IP, UDP and DTLS.  Nodes MUST NOT send Babel packets larger than the
  attached interface's MTU adjusted for known lower-layer headers (at
  least UDP and IP) or 512 octets, whichever is larger, but not
  exceeding 2^16 - 1 adjusted for lower-layer headers.  Every Babel
  speaker MUST be able to receive packets that are as large as any

Aren't these requirements just duplicating what's in 6126bis?  We
probably don't need to repeat the normative language, at least, even if
there's a desire to repeat the content.

  Note that distinct DTLS connections can use different ciphers, which
  can have different amounts of overhead per packet.  Therefore, the

nit: I think the intention here was "per-packet overhead", though the
statement is true as currently written (due to variable length padding
for block ciphers).

Section 5

The RFC 7525 ref is probably better spelled as BCP 195, and arguably
moved earlier in the text (i.e., where I mentioned it previously).

  A malicious client might attempt to perform a high number of DTLS
  handshakes with a server.  As the clients are not uniquely identified
  by the protocol and can be obfuscated with IPv6 temporary addresses,
  a server needs to mitigate the impact of such an attack.  Such

nit: they're not uniquely identified by the protocol *until the
handshake completes* -- our requirement for mutual authentication will
cause all valid clients to be identified.  However, the DoS risk does
not require the client to let the handshake complete, so the core
statement here remains valid.  It may also be worth mentioning
"Slowloris"-style attacks that keep handshake state active for as long
as possible to increase resource consumption.

Section 6.2

DTLS-CID needs to be normative if it is a MAY-level feature.  (See
https://www6.ietf.org/iesg/statement/normative-informative.html .)

RFC 7525 (i.e., BCP 195) definitely needs to be normative, as a
MUST-level requirement!

[Ballot discuss]
(1) Section 1. These are different than the ones listed in Section 6 of draft-ietf-babel-rfc6126bis and Section 1 of draft-ietf-babel-dtls.  As DTLS and HMAC are mitigations for attacks in draft-ietf-babel-rfc6126bis, they really should be harmonized.

(2) Section 2.1.  Per “Implementations MUST support authenticating peers against a local store of credentials”, what does that credentialing look like?  Is it certificates, PSK, etc?  What validation procedure is being used for this authentication?

[Ballot comment]
(3) Abstract.  Per “Babel does not contain any means … [to] protect messages”, be more precise in the definition of protect (i.e., integrity and confidentiality)

(4) Section 1.2.  Per “A comparison of Babel security mechanisms and their applicability can be found in [RFC6126bis]”, where in draft-ietf-babel-rfc6126bis does this comparison occur.  The references to HMAC and TLS are in a single paragraph in in Section 6/Security Considerations which roughly reiterate the one sentence statements written here.

(5) Section 2.1.  Per “When a node receives a new DTLS connection, it MUST verify that the source IP address is an IPv6 link-local address …”, what happens if IPv4 is in use?

(6) Section 2.1. Per “Nodes MUST only negotiate DTLS version 1.2 or higher”, this is stricter than RFC7525 cited in the Security Consideration later in the draft.  That’s fine, but please reiterate that in Section 5.

(7) Section 2.6  Suggest being clearer that this is a deployment not an implementation issue. 
s/Implementations MAY implement both Babel over DTLS and unprotected Babel./
/A node MAY run both Babel over DTLS and unprotected Babel./ 

(8) Section 2.6, Per “However, accepting unprotected Babel packets … loses the security properties of Babel over DTLS”.  This seems misleading.  The security properties of “Babel over DTLS” as a protocol are stated in Section 1.2.  In this section there is discussion of the security properties of the node (and the resulting neighbor table).  These are different.  The issue seems to be that a node is building a neighbor table with updates from sources which need to be trusted to different degrees.

(9) Section 5.  Per “Confidential interaction between two Babel peers requires Datagram Transport Layer Security (DTLS) with a cipher suite offering  confidentiality protection.  The guidance given in [RFC7525] MUST be followed to avoid attacks on DTLS.”, the first sentence is true, but incomplete, in that we’d also want cipher suites with a strong key exchange algorithm, etc.  Section 4.2 of RFC7525, which is cited as a MUST, provides a list of recommended ciphers suites.  Do we need this first sentence?

(10) Editorial
-- Section 2.1.  Expand “IHU” on first use

-- Section 3.  Nit. s/ciphers/ciphersuites/

[Ballot discuss]
Unfortunately I need to discuss the port request again.

First of all I would like to comment on the shepherd write-up which says:
"The document requires only the allocation of a port number for Babel
over DTLS. Having such a second port for the secured version of a
protocol is a fairly common practice. This is shown in the IANA
Considerations section."
This is not correct. Having a second port for the secured version of a protocol WAS common practice. However RFC6335 say now
"The use of separate
  service name or port number assignments for secure and insecure
  variants of the same service is to be avoided in order to discourage
  the deployment of insecure services."

Anyway, in this case I understand that a different port is desired because unencrypted HELLO messages are still received over the default babel port. However, it is not clear to me why a fixed/default port is needed. The neighbour needs to be discovered in some why, no matter what, before a DTLS connection can be established and this discovery procedure could indicate a dynamic port number that the peer is listening on for babel over DTLS. E.g. the multicast HELLO could have a new TLV with this port information. Please clarify why this option is not suitable! Thanks!

[Ballot comment]
Thank you for the work put into this document. I have only two COMMENTs.

Regards,

-éric

== COMMENTS ==

-- Section 1.2 --

The text refers to the security consideration of RFC6121bis for an extended comparison of HMAC & DTLS except that there is no additional information in RFC 6121bis.

-- Section 2.1 --

It is a little unclear to me whether a mix of DTLS and non-DTLS Babel nodes can exist on the same layer-2 network. I guess no (as implied later) but a clear sentence would help.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-babel-dtls-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about the IANA Considerations section of this document.

We understand that, upon approval of this document, there is a single action which we must complete.

In the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers

the following port number will be registered as follows:

Service Name: babel-dtls
Port Number: TBD
Description: Babel Routing Protocol over DTLS
Assignee: David Schinazi
Contact: David Schinazi
Reference: [RFC to be]

IANA notes the authors have suggested port 6699 for this registration.

IANA Question: Should the assignee be the IESG  and the contact be the IETF Chair ? Please see RFC 6335, Section 8.1.1

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-07-04):

From: The IESG
To: IETF-Announce
CC: babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com, draft-ietf-babel-dtls@ietf.org, martin.vigoureux@nokia.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Babel Routing Protocol over Datagram Transport Layer Security) to Proposed Standard


The IESG has received a request from the Babel routing protocol WG (babel) to
consider the following document: - 'Babel Routing Protocol over Datagram
Transport Layer Security'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-07-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Babel Routing Protocol does not contain any means to authenticate
  neighbours or protect messages sent between them.  This document
  specifies a mechanism to ensure these properties, using Datagram
  Transport Layer Security (DTLS).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO for draft-ietf-babel-dtls-07.txt
--------------------------------------

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard. Title page indicates Standards Track. This document
standardizes the securing of Babel with DTLS.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

  Technical Summary:

The Babel Routing Protocol does not contain any means to authenticate
neighbours or protect messages sent between them.  This documents
specifies a mechanism to ensure these properties, using Datagram
Transport Layer Security (DTLS).

  Working Group Summary:

There was a clear consensus in favor of the document. There was no
opposition except for one participant who changed to support.

  Document Quality:

The document is of good quality and has had a reasonable variety of
reviews with comments resolved to the satisfaction of the reviewers.

  Personnel:
    Document Shepherd: Donald Eastlake
    Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed
    by the Document Shepherd. If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

The document Shepherd's review is here:
https://mailarchive.ietf.org/arch/msg/babel/AzjslHG1bVLksmXMs62gLDqeN_M

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

An early security review took place. See
https://mailarchive.ietf.org/arch/msg/babel/1i3PTpCYZ5uXgNxIsWR8Ken3Tnw
An early routing review took place. See
https://mailarchive.ietf.org/arch/msg/babel/cKA2BYaRP08UPgPSeIWp7K-ci6A

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area
    Director and/or the IESG should be aware of?

No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.

Yes, see:
https://mailarchive.ietf.org/arch/msg/babel/CcIbTcuyYI7GdJfGvYg7S3CxddQ
https://mailarchive.ietf.org/arch/msg/babel/XacfODvwa5WHp7VG5tTCgV3AL28
https://mailarchive.ietf.org/arch/msg/babel/071D6tjivX4agtaUzFGlmxL0DT8

(8) Has an IPR disclosure been filed that references this document?
    If so, summarize any WG discussion and conclusion regarding the
    IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?

There is a good consensus of active participants in the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist). Boilerplate checks are not enough;
    this check needs to be thorough.

No nits.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

No such formal review required.

(13) Have all references within this document been identified as
    either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
    for advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their
    completion?

There is a normative reference to draft-ietf-babel-rfc6126bis but that
draft is in WG Last Call and expected to advance shortly.

(15) Are there downward normative references (see RFC 3967)?

There are no down-refs.

(16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction?

The front page indicates that this document Updates rfc6126bis. This
is an arguable point.

(17) Describe the Document Shepherd's review of the IANA
    considerations section, especially with regard to its consistency
    with the body of the document. Confirm that all protocol
    extensions that the document makes are associated with the
    appropriate reservations in IANA registries. Confirm that any
    referenced IANA registries have been clearly identified.

The document requires only the allocation of a port number for Babel
over DTLS. Having such a second port for the secured version of a
protocol is a fairly common practice. This is shown in the IANA
Considerations section.

(18) List any new IANA registries that require Expert Review for
    future allocations.

No new registries created.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

No automated checks required.

PROTO for draft-ietf-babel-dtls-07.txt
--------------------------------------

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)?

Proposed Standard. Title page indicates Standards Track. This document
standardizes the securing of Babel with DTLS.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the
    following sections:

  Technical Summary:

The Babel Routing Protocol does not contain any means to authenticate
neighbours or protect messages sent between them.  This documents
specifies a mechanism to ensure these properties, using Datagram
Transport Layer Security (DTLS).

  Working Group Summary:

There was a clear consensus in favor of the document. There was no
opposition except for one participant who changed to support.

  Document Quality:

The document is of good quality and has had a reasonable variety of
reviews with comments resolved to the satisfaction of the reviewers.

  Personnel:
    Document Shepherd: Donald Eastlake
    Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed
    by the Document Shepherd. If this version of the document is not
    ready for publication, please explain why the document is being
    forwarded to the IESG.

The document Shepherd's review is here:
https://mailarchive.ietf.org/arch/msg/babel/AzjslHG1bVLksmXMs62gLDqeN_M

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the
    review that took place.

An early security review took place. See
https://mailarchive.ietf.org/arch/msg/babel/1i3PTpCYZ5uXgNxIsWR8Ken3Tnw
An early routing review took place. See
https://mailarchive.ietf.org/arch/msg/babel/cKA2BYaRP08UPgPSeIWp7K-ci6A

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area
    Director and/or the IESG should be aware of?

No special concerns.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.

Yes, see:
https://mailarchive.ietf.org/arch/msg/babel/CcIbTcuyYI7GdJfGvYg7S3CxddQ
https://mailarchive.ietf.org/arch/msg/babel/XacfODvwa5WHp7VG5tTCgV3AL28
https://mailarchive.ietf.org/arch/msg/babel/071D6tjivX4agtaUzFGlmxL0DT8

(8) Has an IPR disclosure been filed that references this document?
    If so, summarize any WG discussion and conclusion regarding the
    IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?

There is a good consensus of active participants in the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
    document. (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist). Boilerplate checks are not enough;
    this check needs to be thorough.

No nits.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type
    reviews.

No such formal review required.

(13) Have all references within this document been identified as
    either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
    for advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their
    completion?

There is a normative reference to draft-ietf-babel-rfc6126bis but that
draft is in WG Last Call and expected to advance shortly.

(15) Are there downward normative references (see RFC 3967)?

There are no down-refs.

(16) Will publication of this document change the status of any
    existing RFCs? Are those RFCs listed on the title page header,
    listed in the abstract, and discussed in the introduction?

The front page indicates that this document Updates rfc6126bis. This
is an arguable point.

(17) Describe the Document Shepherd's review of the IANA
    considerations section, especially with regard to its consistency
    with the body of the document. Confirm that all protocol
    extensions that the document makes are associated with the
    appropriate reservations in IANA registries. Confirm that any
    referenced IANA registries have been clearly identified.

The document requires only the allocation of a port number for Babel
over DTLS. Having such a second port for the secured version of a
protocol is a fairly common practice. This is shown in the IANA
Considerations section.

(18) List any new IANA registries that require Expert Review for
    future allocations.

No new registries created.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

No automated checks required.

Request for Early review by RTGDIR is assigned to Tony Przygiendaquot; semantics.  While
  EDNS(0) has been used to signal at least one session-related
  parameter (edns-tcp-keepalive EDNS(0) Option [RFC7828]), the result
  is less than optimal due to the restrictions imposed by the EDNS(0)
  semantics and the lack of server-initiated signaling.  For example, a
  server cannot arbitrarily instruct a client to close a connection
  because the server can only send EDNS(0) options in responses to
  queries that contained EDNS(0) options.

  This document defines a new DNS OPCODE for DNS Stateful Operations
  (DSO) with a value of 6.  DSO messages are used to communicate
  operations within persistent stateful sessions, expressed using Type
  Length Value (TLV) syntax.  This document defines an initial set of
  three TLVs used to manage session timeouts, termination, and
  encryption padding.

  All three TLVs defined here are mandatory for all implementations of
  DSO.  Further TLVs may be defined in additional specifications.

  DSO messages may or may not be acknowledged.  Whether a DSO message
  is to be acknowledged (a DSO request message) or is not to be
  acknowledged (a DSO unidirectional message) is specified in the
  definition of that particular DSO message type.  The MESSAGE ID is
  nonzero for DSO request messages, and zero for DSO unidirectional
  messages.  Messages are pipelined and responses may appear out of
  order when multiple requests are being processed concurrently.

  The format for DSO messages (Section 5.4) differs somewhat from the
  traditional DNS message format used for standard queries and
  responses.  The standard twelve-byte header is used, but the four
  count fields (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) are set to zero,
  and accordingly their corresponding sections are not present.

Bellis, et al.              Standards Track                    [Page 4]
RFC 8490                DNS Stateful Operations              March 2019

  The actual data pertaining to DNS Stateful Operations (expressed in
  TLV syntax) is appended to the end of the DNS message header.  Just
  as in traditional DNS-over-TCP [RFC1035] [RFC7766], the stream
  protocol carrying DSO messages (which are just another kind of DNS
  message) frames them by putting a 16-bit message length at the start.
  The length of the DSO message is therefore determined from that
  length rather than from any of the DNS header counts.

  When displayed using packet analyzer tools that have not been updated
  to recognize the DSO format, this will result in the DSO data being
  displayed as unknown extra data after the end of the DNS message.

  This new format has distinct advantages over an RR-based format
  because it is more explicit and more compact.  Each TLV definition is
  specific to its use case and, as a result, contains no redundant or
  overloaded fields.  Importantly, it completely avoids conflating DNS
  Stateful Operations in any way with normal DNS operations or with
  existing EDNS(0)-based functionality.  A goal of this approach is to
  avoid the operational issues that have befallen EDNS(0), particularly
  relating to middlebox behavior (see sections discussing EDNS(0), and
  problems caused by firewalls and load balancers, in the recent work
  describing causes of DNS failures [Fail]).

  With EDNS(0), multiple options may be packed into a single OPT
  pseudo-RR, and there is no generalized mechanism for a client to be
  able to tell whether a server has processed or otherwise acted upon
  each individual option within the combined OPT pseudo-RR.  The
  specifications for each individual option need to define how each
  different option is to be acknowledged, if necessary.

  In contrast to EDNS(0), with DSO there is no compelling motivation to
  pack multiple operations into a single message for efficiency
  reasons, because DSO always operates using a connection-oriented
  transport protocol.  Each DSO operation is communicated in its own
  separate DNS message, and the transport protocol can take care of
  packing several DNS messages into a single IP packet if appropriate.
  For example, TCP can pack multiple small DNS messages into a single
  TCP segment.  This simplification allows for clearer semantics.  Each
  DSO request message communicates just one primary operation, and the
  RCODE in the corresponding response message indicates the success or
  failure of that operation.

Bellis, et al.              Standards Track                    [Page 5]
RFC 8490                DNS Stateful Operations              March 2019

2.  Requirements Language

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
  "OPTIONAL" in this document are to be interpreted as described in
  BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
  capitals, as shown here.

3.  Terminology

  DSO:  DNS Stateful Operations.

  connection:  a bidirectional byte (or message) stream, where the
      bytes (or messages) are delivered reliably and in order, such as
      provided by using DNS-over-TCP [RFC1035] [RFC7766] or DNS-over-TLS
      [RFC7858].

  session:  the unqualified term "session" in the context of this
      document refers to a persistent network connection between two
      endpoints that allows for the exchange of DNS messages over a
      connection where either end of the connection can send messages to
      the other end.  (The term has no relationship to the "session
      layer" of the OSI "seven-layer model".)

  DSO Session:  a session established between two endpoints that
      acknowledge persistent DNS state via the exchange of DSO messages
      over the connection.  This is distinct from a DNS-over-TCP session
      as described in the previous specification for DNS-over-TCP
      [RFC7766].

  close gracefully:  a normal session shutdown where the client closes
      the TCP connection to the server using a graceful close such that
      no data is lost (e.g., using TCP FIN; see Section 5.3).

  forcibly abort:  a session shutdown as a result of a fatal error
      where the TCP connection is unilaterally aborted without regard
      for data loss (e.g., using TCP RST; see Section 5.3).

  server:  the software with a listening socket, awaiting incoming
      connection requests, in the usual DNS sense.

  client:  the software that initiates a connection to the server's
      listening socket, in the usual DNS sense.

  initiator:  the software that sends a DSO request message or a DSO
      unidirectional message during a DSO Session.  Either a client or
      server can be an initiator.

Bellis, et al.              Standards Track                    [Page 6]
RFC 8490                DNS Stateful Operations              March 2019

  responder:  the software that receives a DSO request message or a DSO
      unidirectional message during a DSO Session.  Either a client or a
      server can be a responder.

  sender:  the software that is sending a DNS message, a DSO message, a
      DNS response, or a DSO response.

  receiver:  the software that is receiving a DNS message, a DSO
      message, a DNS response, or a DSO response.

  service instance:  a specific instance of server software running on
      a specific host (Section 9.1).

  long-lived operation:  an outstanding operation on a DSO Session
      where either the client or server, acting as initiator, has
      requested that the responder send new information regarding the
      request, as it becomes available.

  early data:  a TLS 1.3 handshake containing data on the first flight
      that begins a DSO Session (Section 2.3 of the TLS 1.3
      specification [RFC8446]).  TCP Fast Open [RFC7413] is only
      permitted when using TLS.

  DNS message:  any DNS message, including DNS queries, responses,
      updates, DSO messages, etc.

  DNS request message:  any DNS message where the QR bit is 0.

  DNS response message:  any DNS message where the QR bit is 1.

  DSO message:  a DSO request message, DSO unidirectional message, or
      DSO response to a DSO request message.  If the QR bit is 1 in a
      DSO message, it is a DSO response message.  If the QR bit is 0 in
      a DSO message, it is a DSO request message or DSO unidirectional
      message, as determined by the specification of its Primary TLV.

  DSO response message:  a response to a DSO request message.

  DSO request message:  a DSO message that requires a response.

  DSO unidirectional message:  a DSO message that does not require and
      cannot induce a response.

  Primary TLV:  the first TLV in a DSO request message or DSO
      unidirectional message; this determines the nature of the
      operation being performed.

Bellis, et al.              Standards Track                    [Page 7]
RFC 8490                DNS Stateful Operations              March 2019

  Additional TLV:  any TLVs that follow the Primary TLV in a DSO
      request message or DSO unidirectional message.

  Response Primary TLV:  in a DSO response, any TLVs with the same DSO-
      TYPE as the Primary TLV from the corresponding DSO request
      message.  If present, any Response Primary TLV(s) MUST appear
      first in the DSO response message, before any Response Additional
      TLVs.

  Response Additional TLV:  any TLVs in a DSO response that follow the
      (optional) Response Primary TLV(s).

  inactivity timer:  the time since the most recent non-keepalive DNS
      message was sent or received (see Section 6.4).

  keepalive timer:  the time since the most recent DNS message was sent
      or received (see Section 6.5).

  session timeouts:  the inactivity timer and the keepalive timer.

  inactivity timeout:  the maximum value that the inactivity timer can
      have before the connection is gracefully closed.

  keepalive interval:  the maximum value that the keepalive timer can
      have before the client is required to send a keepalive (see
      Section 7.1).

  resetting a timer:  setting the timer value to zero and restarting
      the timer.

  clearing a timer:  setting the timer value to zero but not restarting
      the timer.

Bellis, et al.              Standards Track                    [Page 8]
RFC 8490                DNS Stateful Operations              March 2019

4.  Applicability

  DNS Stateful Operations are applicable to several known use cases and
  are only applicable on transports that are capable of supporting a
  DSO Session.

4.1.  Use Cases

  Several use cases for DNS Stateful Operations are described below.

4.1.1.  Session Management

  In one use case, establishing session parameters such as server-
  defined timeouts is of great use in the general management of
  persistent connections.  For example, using DSO Sessions for stub-to-
  recursive DNS-over-TLS [RFC7858] is more flexible for both the client
  and the server than attempting to manage sessions using just the
  edns-tcp-keepalive EDNS(0) Option [RFC7828].  The simple set of TLVs
  defined in this document is sufficient to greatly enhance connection
  management for this use case.

4.1.2.  Long-Lived Subscriptions

  In another use case, DNS-based Service Discovery (DNS-SD) [RFC6763]
  has evolved into a naturally session-based mechanism where, for
  example, long-lived subscriptions lend themselves to 'push'
  mechanisms as opposed to polling.  Long-lived stateful connections
  and server-initiated messages align with this use case [Push].

  A general use case is that DNS traffic is often bursty, but session
  establishment can be expensive.  One challenge with long-lived
  connections is sustaining sufficient traffic to maintain NAT and
  firewall state.  To mitigate this issue, this document introduces a
  new concept for the DNS -- DSO "keepalive traffic".  This traffic
  carries no DNS data and is not considered 'activity' in the classic
  DNS sense, but it serves to maintain state in middleboxes and to
  assure the client and server that they still have connectivity to
  each other.

Bellis, et al.              Standards Track                    [Page 9]
RFC 8490                DNS Stateful Operations              March 2019

4.2.  Applicable Transports

  DNS Stateful Operations are applicable in cases where it is useful to
  maintain an open session between a DNS client and server, where the
  transport allows such a session to be maintained, and where the
  transport guarantees in-order delivery of messages on which DSO
  depends.  Two specific transports that meet the requirements to
  support DNS Stateful Operations are DNS-over-TCP [RFC1035] [RFC7766]
  and DNS-over-TLS [RFC7858].

  Note that in the case of DNS-over-TLS, there is no mechanism for
  upgrading from DNS-over-TCP to DNS-over-TLS mid-connection (see
  Section 7 of the DNS-over-TLS specification [RFC7858]).  A connection
  is either DNS-over-TCP from the start, or DNS-over-TLS from the
  start.

  DNS Stateful Operations are not applicable for transports that cannot
  support clean session semantics or that do not guarantee in-order
  delivery.  While in principle such a transport could be constructed
  over UDP, the current specification of DNS-over-UDP [RFC1035] does
  not provide in-order delivery or session semantics and hence cannot
  be used.  Similarly, DNS-over-HTTP [RFC8484] cannot be used because
  HTTP has its own mechanism for managing sessions, which is
  incompatible with the mechanism specified here.

  Only DNS-over-TCP and DNS-over-TLS are currently defined for use with
  DNS Stateful Operations.  Other transports may be added in the future
  if they meet the requirements set out in the first paragraph of this
  section.

Bellis, et al.              Standards Track                  [Page 10]
RFC 8490                DNS Stateful Operations              March 2019

5.  Protocol Details

  The overall flow of DNS Stateful Operations goes through a series of
  phases:

  Connection Establishment:  A client establishes a connection to a
      server (Section 4.2).

  Connected but Sessionless:  A connection exists, but a DSO Session
      has not been established.  DNS messages can be sent from the
      client to server, and DNS responses can be sent from the server to
      the client.  In this state, a client that wishes to use DSO can
      attempt to establish a DSO Session (Section 5.1).  Standard DNS-
      over-TCP inactivity timeout handling is in effect [RFC7766] (see
      Section 7.1.2 of this document).

  DSO Session Establishment in Progress:  A client has sent a DSO
      request within the last 30 seconds, but has not yet received a DSO
      response for that request.  In this phase, the client may send
      more DSO requests and more DNS requests, but MUST NOT send DSO
      unidirectional messages (Section 5.1).

  DSO Session Establishment Timeout:  A client has sent a DSO request,
      and after 30 seconds has still received no DSO response for that
      request.  This means that the server is now in an indeterminate
      state.  The client forcibly aborts the connection.  The client MAY
      reconnect without using DSO, if appropriate.

  DSO Session Establishment Failed:  A client has sent a DSO request,
      and received a corresponding DSO response with a nonzero RCODE.
      This means that the attempt to establish the DSO Session did not
      succeed.  At this point, the client is permitted to continue
      operating without a DSO Session (Connected but Sessionless) but
      does not send further DSO messages (Section 5.1).

  DSO Session Established:  A client has sent a DSO request, and
      received a corresponding DSO response with RCODE set to NOERROR
      (0).  A DSO Session has now been successfully established.  Both
      client and server may send DSO messages and DNS messages; both may
      send replies in response to messages they receive (Section 5.2).
      The inactivity timer (Section 6.4) is active; the keepalive timer
      (Section 6.5) is active.  Standard DNS-over-TCP inactivity timeout
      handling is no longer in effect [RFC7766] (see Section 7.1.2 of
      this document).

Bellis, et al.              Standards Track                  [Page 11]
RFC 8490                DNS Stateful Operations              March 2019

  Server Shutdown:  The server has decided to gracefully terminate the
      session and has sent the client a Retry Delay message
      (Section 6.6.1).  There may still be unprocessed messages from the
      client; the server will ignore these.  The server will not send
      any further messages to the client (Section 6.6.1.1).

  Client Shutdown:  The client has decided to disconnect, either
      because it no longer needs service, the connection is inactive
      (Section 6.4.1), or because the server sent it a Retry Delay
      message (Section 6.6.1).  The client closes the connection
      gracefully (Section 5.3).

  Reconnect:  The client disconnected as a result of a server shutdown.
      The client either waits for the server-specified Retry Delay to
      expire (Section 6.6.3) or else contacts a different server
      instance.  If the client no longer needs service, it does not
      reconnect.

  Forcibly Abort:  The client or server detected a protocol error, and
      further communication would have undefined behavior.  The client
      or server forcibly aborts the connection (Section 5.3).

  Abort Reconnect Wait:  The client has forcibly aborted the connection
      but still needs service.  Or, the server forcibly aborted the
      connection, but the client still needs service.  The client either
      connects to a different service instance (Section 9.1) or waits to
      reconnect (Section 6.6.3.1).

5.1.  DSO Session Establishment

  In order for a session to be established between a client and a
  server, the client must first establish a connection to the server
  using an applicable transport (see Section 4.2).

  In some environments, it may be known in advance by external means
  that both client and server support DSO, and in these cases either
  client or server may initiate DSO messages at any time.  In this
  case, the session is established as soon as the connection is
  established; this is referred to as implicit DSO Session
  establishment.

  However, in the typical case a server will not know in advance
  whether a client supports DSO, so in general, unless it is known in
  advance by other means that a client does support DSO, a server MUST
  NOT initiate DSO request messages or DSO unidirectional messages
  until a DSO Session has been mutually established by at least one
  successful DSO request/response exchange initiated by the client, as

Bellis, et al.              Standards Track                  [Page 12]
RFC 8490                DNS Stateful Operations              March 2019

  described below.  This is referred to as explicit DSO Session
  establishment.

  Until a DSO Session has been implicitly or explicitly established, a
  client MUST NOT initiate DSO unidirectional messages.

  A DSO Session is established over a connection by the client sending
  a DSO request message, such as a DSO Keepalive request message
  (Section 7.1), and receiving a response with a matching MESSAGE ID,
  and RCODE set to NOERROR (0), indicating that the DSO request was
  successful.

  Some DSO messages are permitted as early data (Section 11.1).  Others
  are not.  Unidirectional messages are never permitted as early data,
  unless an implicit DSO Session exists.

  If a server receives a DSO message in early data whose Primary TLV is
  not permitted to appear in early data, the server MUST forcibly abort
  the connection.  If a client receives a DSO message in early data,
  and there is no implicit DSO Session, the client MUST forcibly abort
  the connection.  This can only be enforced on TLS connections;
  therefore, servers MUST NOT enable TCP Fast Open (TFO) when listening
  for a connection that does not require TLS.

5.1.1.  DSO Session Establishment Failure

  If the response RCODE is set to NOTIMP (4), or in practice any value
  other than NOERROR (0) or DSOTYPENI (defined below), then the client
  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 connection but MUST NOT issue further DSO messages on that
  connection.

  If the RCODE in the response is set to DSOTYPENI ("DSO-TYPE Not
  Implemented"; RCODE 11), this indicates that the server does support
  DSO but does not implement the DSO-TYPE of the Primary TLV in this
  DSO request message.  A server implementing DSO MUST NOT return
  DSOTYPENI for a DSO Keepalive request message because the Keepalive
  TLV is mandatory to implement.  But in the future, if a client
  attempts to establish a DSO Session using a response-requiring DSO
  request message using some newly-defined DSO-TYPE that the server
  does not understand, that would result in a DSOTYPENI response.  If
  the server returns DSOTYPENI, then a DSO Session is not considered
  established.  The client is, however, permitted to continue sending
  DNS messages on the connection, including other DSO messages such as
  the DSO Keepalive, which may result in a successful NOERROR response,
  yielding the establishment of a DSO Session.

Bellis, et al.              Standards Track                  [Page 13]
RFC 8490                DNS Stateful Operations              March 2019

  When a DSO message is received by an existing DNS server that doesn't
  recognize the DSO OPCODE, two other possible outcomes exist: the
  server might send no response to the DSO message, or the server might
  drop the connection.

  If the server sends no response to the DSO message, the client SHOULD
  wait 30 seconds, after which time the server will be assumed not to
  support DSO.  If the server doesn&