<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<?rfc authorship='yes' ?>
<rfc category="info" docName="draft-wing-dprive-profile-and-msg-flows-01"
     ipr="trust200902">
  <front>
    <title abbrev="DPRIVE TLS/DTLS Message Flows">DPRIVE TLS/DTLS Message
    Flows</title>

    <author fullname="Dan Wing" initials="D." surname="Wing">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>California</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <date />

    <workgroup>DPRIVE Working Group</workgroup>

    <abstract>
      <t>Message flows for DNS-over-TLS and DNS-over-DTLS are discussed and
      compared.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The DPRIVE working group has two active documents that provide DNS
      confidentiality, DNS over DTLS <xref
      target="I-D.ietf-dprive-dnsodtls"></xref> and DNS over TLS <xref
      target="I-D.ietf-dprive-dns-over-tls"></xref>.</t>

      <t>This document shows message flows for those two documents. Also shown
      is how <xref target="RFC7413">TCP Fast Open (TFO)</xref> eliminates a
      round-trip, which is especially helpful for DNS communication.</t>
    </section>

    <section title="Server state lost">
      <t>This section shows message flows after server state is lost, such as
      due to routing change (communicating to a different server, unbeknownst
      to the client) or due to server losing state (crash or software
      upgrade).</t>

      <section title="TLS">
        <t>With TLS, the client is immediately informed of server state loss
        with a TCP RST, as shown in the diagram below. This costs one round
        trip, and this round trip is unavoidable. This is a TCP RST, and is
        not authenticated. After the RST, a new TCP connection and TLS state
        are established.</t>

        <figure anchor="fig_server_state_loss_tls"
                title="Server State Loss, TLS">
          <artwork align="center"><![CDATA[
client                                                    server
   |                                                         |
   |<-----------------DPRIVE communications----------------->|
   |                                                         |
   |                         ...                             |
   |                                                         |
   |                                                  (state lost)
   |                                                         |
   |-DNS-over-TLS------------------------------------------->|
   |<------TCP RST-------------------------------------------|
   |--TCP SYN----------------------------------------------->|
   |<-TCP SYNACK---------------------------------------------|
   |--TCP ACK, TLS ClientHello w/Resumption ---------------->|
   |<-TLS ServerHello, ChangeCipherSpec, Finished -----------|
   |--TLS ChangeCipherSpec, Finished, DNS query------------->|
   |<-DNS response-------------------------------------------|
   |                                                         |
]]></artwork>
        </figure>
      </section>

      <section title="DTLS ">
        <t>With DTLS, the client is immediately informed of the server state
        loss with a DTLS Alert, as shown in the diagram below. This DTLS Alert
        is not authenticated. This message costs one round trip, but can be
        avoided if the client anticipates this server state loss and consumes
        additional packet overhead, as discussed below <xref
        target="fig_server_state_loss_dtls"></xref>.</t>

        <figure anchor="fig_server_state_loss_dtls"
                title="Server State Loss, DTLS">
          <artwork align="center"><![CDATA[
 client                                          server
    |                                               |              
    |<-----------DPRIVE communications------------->|
    |                                               |
    |                   ...                         |
    |                                               |
    |                                        (state lost)
    |                                               |
 1. |-----------DPRIVE query----------------------->|
 2. |<----------DTLS Alert--------------------------|
 3. |-DLTS ClientHello w/resumption---------------->|
    |                   ...                         |
]]></artwork>
        </figure>

        <t>An optimization of the above flow is possible, if the client
        believes the server is likely to have lost state, such as if the most
        recent DPRIVE communications was a long time ago (exact value of "long
        time" is debatable). In that situation, the client can send a DTLS
        handshake with TLS resumption -- effectively, it sends the DTLS
        handshake identical to packet (3) of <xref
        target="fig_server_state_loss_dtls"></xref> (avoiding packets 1 and
        2). This packet is larger, though, as it contains the TLS session
        resumption information. Thus, it is a trade-off of a larger message
        versus a (possible) round trip savings. This message flow is shown
        below.</t>

        <figure anchor="fig_server_state_loss_dtls_false"
                title="Server State Loss, DTLS False Start">
          <artwork align="center"><![CDATA[
client                                              server
   |                                                   |              
   |<----------DPRIVE communications------------------>|
   |                                                   |
   |                   ...                             |
   |                                                   |
   |                                             (state lost)
   |                                                   |
   |--DTLS ClientHello w/resumption ------------------>|
   |<-DTLS ServerHello, ChangeCipherSpec, Finished-----|
   |--DTLS ChangeCipherSpec, Finished, DNS query------>|
   |<-DNS response-------------------------------------|
   |                   ...                             |  
]]></artwork>
        </figure>
      </section>

      <section title="TLS 1.3">
        <t>Session resumption via identifiers and tickets is obsolete in
        TLS1.3 <xref target="I-D.ietf-tls-tls13"></xref>. Both methods are
        replaced by a pre-shared key (PSK) mode. A PSK is established on a
        previous connection after the handshake is completed, and can then be
        presented by the client on the next visit.</t>

        <t><figure anchor="fig-session_resumption" title="Session resumption">
            <artwork align="center"><![CDATA[
client                                                    server
   |                                                                        |
   |<-----------------DPRIVE communications-------------------------------->|
   |                                                                        |
   |                         ...                                            |
   |                                                                        |
   |                                                                     (state lost)
   |                                                                        |
   |-DNS-over-TLS---------------------------------------------------------->|
   |<------TCP RST----------------------------------------------------------|
   |--TCP SYN-------------------------------------------------------------->|
   |<-TCP SYNACK------------------------------------------------------------|
   |--TCP ACK, TLS ClientHello+key_share+pre_shared_key-------------------->|
   |<-TLS ServerHello+pre_shared_key, EncryptedExtensions, Finished --------|
   |--TLS Finished--------------------------------------------------------->|
   |<-DNS response----------------------------------------------------------|
   |                                                                        |
]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="TCP Fast Open">
      <t>If the client and server TCP stacks both support <xref
      target="RFC7413">TCP Fast Open (TFO)</xref>, the TCP 3-way handshake can
      be done without a round trip, as shown below. Currently, TFO is
      supported in Linux 3.7 (TCP client and server), iOS 9, and OS X
      10.11.</t>

      <t><figure anchor="fig_server_state_loss_tls_fastopen"
          title="Server State Loss, TLS with TCP FastOpen">
          <artwork align="center"><![CDATA[
client                                                         server
   |                                                              |
   |<-------------------DPRIVE communications-------------------->|
   |                                                              |
   |                         ...                                  |
   |                                                              |
   |                                                     (state lost)
   |                                                              |
   |-DNS-over-TLS------------------------------------------------>|
   |<------TCP RST------------------------------------------------|
   |--TCP SYN, TLS ClientHello w/Resumption --------------------->|
   |<-TCP SYNACK, TLS ServerHello, ChangeCipherSpec, Finished-----|
   |--TLS ChangeCipherSpec, Finished, DNS query------------------>|
   |<-DNS response------------------------------------------------|
]]></artwork>
        </figure></t>
    </section>

    <section title="Probing for Server State Loss">
      <t>In between normal DNS traffic while the communication to the DNS
      server is quiescent, the DNS client may want to probe the server to
      ensure it has maintained cryptographic state. Such probes can also keep
      alive firewall or NAT bindings. This probing reduces the frequency of
      needing a new handshake when a DNS query needs to be resolved, improving
      the user experience at the cost of bandwidth and processing time;
      cellular devices could even send the probes while in power-save state
      <xref target="I-D.isomaki-rtcweb-mobile"></xref>.</t>

      <t>If the server has lost state, a DTLS (or TLS) handshake needs to be
      initiated with the server.</t>

      <section title="DTLS">
        <t>A <xref target="RFC6520">DTLS heartbeat</xref> verifies the server
        still has DTLS state by returning a DTLS message. If the server has
        lost state, it returns a DTLS Alert.</t>
      </section>

      <section title="TLS">
        <t>TLS runs over TCP, so a simple probe is a 0-length TCP packet (a
        "window probe"). This verifies the TCP connection is still working,
        which is also sufficient to prove the server has retained TLS state,
        because if the server loses TLS state it abandons the TCP connection.
        If the server has lost state, a TCP RST is returned immediately.</t>
      </section>
    </section>

    <section title="NAT or Firewall Pinhole Closed">
      <t>A NAT or Firewall, on the path between the DPRIVE client and DPRIVE
      server, lose state -- either due to timing out the pinhole, exhausting
      its resources (and needing to prematurely close the pinhole), or
      crashing. This differs from the server losing state.</t>

      <section title="DTLS">
        <t>With DTLS, the NAT or firewall will create a new mapping when it
        sees the new UDP packet. With a NAT, depending on its load (of other
        traffic) and its implmentation that mapping might be assigned to the
        same UDP port and IP address as the previous mapping, a different UDP
        port, and/or a different source IP address. The situation where the
        same mapping occurs is shown below.</t>

        <figure anchor="fig_server_state_loss_dtls_firewall_same"
                title="NAT/Firewall State Loss, DTLS">
          <artwork align="center"><![CDATA[
 client            NAT or firewall                server
    |                     |                         |              
    |<-----------DPRIVE communications------------->|
    |                     |                         |
    |                (state loss)                   |
    |                     |                         |
    |-----------DPRIVE query----------------------->|
    |        (new state created in NAT/firewall)    |
    |                     |                         |
    |<----------DPRIVE response---------------------|
    |                   ...                         |
]]></artwork>
        </figure>

        <t>A different mapping can cause the server to reject the
        communication (DTLS Alert) cause the server to reject the
        communication (DTLS Alert) if the server was sensative to the client's
        source address or source port, consuming a round trip. This is shown
        below.</t>

        <figure anchor="fig_server_state_loss_dtls_firewall_changed"
                title="NAT/Firewall State Loss, DTLS, changed mapping">
          <artwork align="center"><![CDATA[
 client            NAT or firewall                server
    |                     |                         |              
    |<-----------DPRIVE communications------------->|
    |                     |                         |
    |                (state loss)                   |
    |                     |                         |
    |-----------DPRIVE query----------------------->|
    |        (new state created in NAT/firewall)    |
    |                     |                         |
    |<----------DTLS Alert--------------------------| 
    |                     |                         |
    |-DLTS ClientHello w/resumption---------------->|
    |                     |                         |
    |<----------DPRIVE response---------------------|
    |                    ...                        |
]]></artwork>
        </figure>
      </section>

      <section title="TLS">
        <t>With a TCP connection when the NAT or firewall has lost state and
        sees a TCP packet without the SYN bit set, there are several possible
        reactions by the NAT or firewall: <list style="symbols">
            <t>send TCP RST, spoofing the source IP address of the original
            packet's destination address. This is shown in the following
            figure.</t>

            <t>create state. A firewall is unlikely to create state when it
            sees an in-progress TCP packet, but some NATs may create state.
            However, if the NAT creates state for a different source TCP port
            than the previous connection, the server will reject the TCP
            packet as shown in <xref
            target="fig_server_state_loss_tls_fastopen"></xref>.</t>
          </list></t>

        <figure anchor="fig_server_state_loss_tls_firewall_tcp_fast_open"
                title="NAT/Firewall State Loss, TLS with TCP FastOpen">
          <artwork align="center"><![CDATA[
 client            NAT or firewall                             server
    |                     |                                        |
    |<-----------DPRIVE communications---------------------------->|
    |                     |                                        |
    |                (state loss)                                  |
    |                     |                                        |
    |----DPRIVE query---->X                                        |
    |        (no state exists for TCP flow)                        |
    |                     |                                        |
    |<---TCP RST----------|                                        |
    |                     |                                        |
  (client does            |                                        |
  TLS re-establishment with TCP FastOpen)                          |
    |                     |                                        |
    |--TCP SYN, TLS ClientHello w/Resumption --------------------->|
    |<-TCP SYNACK, TLS ServerHello, ChangeCipherSpec, Finished-----|
    |--TLS ChangeCipherSpec, Finished, DNS query------------------>|
    |<-DNS response------------------------------------------------|
    |                     |                          |
]]></artwork>
        </figure>

        <figure anchor="fig_server_state_loss_tls_firewall"
                title="NAT/Firewall State Loss, TLS">
          <artwork align="center"><![CDATA[
 client            NAT or firewall                server
    |                     |                          |              
    |<-----------DPRIVE communications-------------->|
    |                     |                          |
    |                (state loss)                    |
    |                     |                          |
    |----DPRIVE query---->X                          |
    |        (no state exists for TCP flow)          |
    |                     |                          |
    |<---TCP RST----------|                          |
    |                     |                          |
  (client does normal     |                          |
  TLS re-establishment)   |                          |
    |                     |                          |
    |--TCP SYN-------------------------------------->|
    |<-TCP SYNACK------------------------------------|
    |--TCP ACK, TLS ClientHello w/Resumption ------->|
    |<-TLS ServerHello, ChangeCipherSpec, Finished --|
    |--TLS ChangeCipherSpec, Finished, DNS query---->|
    |<-DNS response----------------------------------|
    |                     |                          |
]]></artwork>
        </figure>
      </section>
    </section>

    <section title="IANA Considerations">
      <t>None.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>Authors would like to thank Allison Mankin for comments and
      review.</t>
    </section>

    <!--
   <section title="Acknowledgements">
    </section>
-->
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.I-D.ietf-dprive-dnsodtls"?>

      <?rfc include="reference.I-D.ietf-dprive-dns-over-tls"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.7413"?>

      <?rfc include="reference.RFC.6520"?>

      <?rfc include="reference.I-D.ietf-tls-tls13"?>

      <?rfc include="reference.I-D.isomaki-rtcweb-mobile"?>
    </references>
  </back>
</rfc>
