Subject: [DNSOP] I-D Action: draft-ietf-dnsop-edns-tcp-keepalive-02.txt

From: [email-masked]
Date: Fri, 03 Jul 2015 07:06:45 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : The edns-tcp-keepalive EDNS0 Option
        Authors         : Paul Wouters
                          Joe Abley
                          Sara Dickinson
                          Ray Bellis
	Filename        : draft-ietf-dnsop-edns-tcp-keepalive-02.txt
	Pages           : 12
	Date            : 2015-07-03

Abstract:
   DNS messages between clients and servers may be received over either
   UDP or TCP.  UDP transport involves keeping less state on a busy
   server, but can cause truncation and retries over TCP.  Additionally,
   UDP can be exploited for reflection attacks.  Using TCP would reduce
   retransmits and amplification.  However, clients commonly use TCP
   only for fallback and servers typically use idle timeouts on the
   order of seconds.

   This document defines an EDNS0 option ("edns-tcp-keepalive") that
   allows DNS servers to signal a variable idle timeout.  This
   signalling facilitates a better balance of UDP and TCP transport
   between individual clients and servers, reducing the impact of
   problems associated with UDP transport and allowing the state
   associated with TCP transport to be managed effectively with minimal
   impact on the DNS transaction time.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-tcp-keepalive-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ray Bellis <[email-masked]>
Date: Fri, 03 Jul 2015 15:26:14 +0100

> 	Filename        : draft-ietf-dnsop-edns-tcp-keepalive-02.txt

This update to the draft adds the support of two additional authors,
simplifies it somewhat and also including a connection-close signal.

A further change is the removal of the usage of the option over UDP
since the semantics of whether a UDP message can say anything about a
subsequent TCP message are unclear.

The authors request working group discussion on this point.

Ray

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 4 Jul 2015 11:06:31 -0400

All

I'm hoping to see some discussion on the mailing list on this, or we'll 
bring it up in Prague.

This draft has been languishing that was resolved with some discussion, 
and it's time to either move it along or shut it down.

tim

On 7/3/15 10:26 AM, Ray Bellis wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: P Vixie <[email-masked]>
Date: Sat, 04 Jul 2015 17:01:44 +0100

I'll have extensive comments, mostly positive, after the weekend. 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Petr Spacek <[email-masked]>
Date: Mon, 20 Jul 2015 10:49:41 +0200

Hello,

having been encouraged to do reviews with my newcomer's eyes, here are some
comments:

>From my perspective this is a reasonable step.

>> The authors request working group discussion on this point.

3.3.2. Sending Responses
Current text seems to allow servers to send tcp-keepalive option even if the
client did not explicitly request it. Is it intended? If it is the case it
would be nice to say it explicitly. Right now I do not if it is just omission
or a intentional violation of 6891 section 7.

3.4. TCP Session Management
typo: "RCF6891 states" ...

Since servers must be faithful to this specification even on a
persistent TCP connection it means that (following the initial
exchange of timeouts) a server may not be presented with the
opportunity to signal a change in the idle timeout associated with a
connection if the client does not send any further requests
containing EDNS0 OPT RRs.

This reference to RFC 6891 section 7 seems to contradict server behavior
mentioned earlier in section 3.3.2 of this draft.

Personally I think that this is a deficiency in EDNS0 spec (or my
understanding of it :-). Is there a reason to assume that client could
possibly lost ability to understand particular EDNS option/feature during
lifetime of one TCP connection?

4. Intermediary Considerations
Sentence
"Should a non-keepalive-aware
intermediary sit between a client and server that both support
keepalive a potential side effect will be an increased frequency of
the proxy closing idle client connections."
is kind of hard to read, but that is just matter of taste.

-- 
Petr Spacek

---

From: Ray Bellis <[email-masked]>
Date: Mon, 20 Jul 2015 11:19:18 +0200

> or a intentional violation of 6891 section 7.

As I understand it, EDNS allows return of any option so long as the
client sent an OPT RR, irrespective of which options where in the client
request  [but see below]

> lifetime of one TCP connection?

This is a matter of some debate - see the earlier DNSOP thread I started
on June 3rd with subject "Clarification on EDNS 6891"

kind regards,

Ray