Subject: [DNSOP] Stephen Farrell's Discuss on draft-ietf-dnsop-edns-tcp-keepalive-05: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 06 Jan 2016 12:57:56 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-edns-tcp-keepalive-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Before I ballot yes on this I have a question to ask.
Most likely the answer will be the obvious one and we'll be
done, but I want to check and if the answer is not the
obvious one then holding the discuss as we fix stuff would
be correct I think.

The question: how does this option play with DNS over
DTLS? [1] 

The reason I ask is that there may be a need in that case
for some similar option (or a TLS extension maybe) though
for the DTLS session lifetime and not a TCP session
lifetime. At present you are saying that this option is
not it. And that's a fine answer but you could also have
said that this could also be used for DTLS session
lifetime handling. And that last might make sense for
operational reasons (not sure really, but could be).  

   [1] https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- intro: "However, TCP transport as currently deployed has
expensive setup overhead." That seems a bit wrong as the
3-way h/s is an inherent part of TCP and isn't really
specific to DNS with TCP trasnport not is it a deployment
issue. I'd suggest just delete the sentence and merge the
remaining part of tha para with the next.

- 3.3.2: What's the last sentence of this section about?
A case where a TCP session is handed over? Might be no
harm saying why (via a reference to anything would be
fine)

---

From: sara <[email-masked]>
Date: Wed, 6 Jan 2016 21:49:13 +0000

> On 6 Jan 2016, at 20:57, Stephen Farrell <[email-masked]> wrote:
> 
>   [1] https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03 <https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03>

Speaking for myself I don’t see this as the solution to managing DTLS sessions, I think that would be better handled with a TLS extension. 

I think the implication here is “expensive setup overhead compared to using UDP for DNS”, with the following paragraph going into the details of that comparison. I would like to keep the sentence, but suggest adding that proviso at the end to make it clearer. 

> harm saying why (via a reference to anything would be

Last sentence in 3.3.2 is:
“The DNS server SHOULD send a edns-tcp-keepalive option with a timeout of
   0 if it deems its local resources are too low to service more TCP
   keepalive sessions, or if it wants clients to close currently open
   connections.”

There is more discussion in section 3.4 including:

“Based on TCP session resources servers may signal a TIMEOUT value of
   0 to request clients to close connections as soon as possible.  This
   is useful when server resources become very low or a denial-of-
   service attack is detected and further maximises the shifting of
   TIME_WAIT state to well-behaved clients.”

So would it help to add “as discussed in the next section” to the end of section 3.3.2?

Regards

Sara.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 6 Jan 2016 21:58:39 +0000

Hiya,

>> Most likely the answer will be the obvious one and we'll be done,
>> but I want to check and if the answer is not the obvious one then
>> holding the discuss as we fix stuff would be correct I think.
>> 
>> The question: how does this option play with DNS over DTLS? [1]
>> 
>> The reason I ask is that there may be a need in that case for some
>> similar option (or a TLS extension maybe) though for the DTLS
>> session lifetime and not a TCP session lifetime. At present you are
>> saying that this option is not it. And that's a fine answer but you
>> could also have said that this could also be used for DTLS session 
>> lifetime handling. And that last might make sense for operational
>> reasons (not sure really, but could be).
>> 
>> <https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03>
> 
> Speaking for myself I don’t see this as the solution to managing DTLS
> sessions, I think that would be better handled with a TLS extension.

Yes, that's the obvious answer, and a not bad answer. Did the
dnsop WG (or dprive) consider the issue already? If yes, then
I'll just clear and we're done.

If not, I'm fine with being guided by the chairs and AD since
linking these would be a bit odd (even if possibly useful), so
will clear when one of 'em tells me.

>> expensive setup overhead." That seems a bit wrong as the 3-way h/s
>> is an inherent part of TCP and isn't really specific to DNS with
>> TCP trasnport not is it a deployment issue. I'd suggest just delete
>> the sentence and merge the remaining part of tha para with the
>> next.
> 
> I think the implication here is “expensive setup overhead compared to
> using UDP for DNS”, with the following paragraph going into the
> details of that comparison. I would like to keep the sentence, but
> suggest adding that proviso at the end to make it clearer.

That's fine.

>> - 3.3.2: 

Oops:-) Typo there sorry, the one that puzzled me is at the end
of 3.2.2 where it says " This holds true even if a previous
edns-keepalive-option exchange occurred on the existing TCP
connection."

Sorry again:-)

Cheers,
S

>> What's the last sentence of this section about? A case
>> where a TCP session is handed over? Might be no harm saying why
>> (via a reference to anything would be fine)
> 
> Last sentence in 3.3.2 is: “The DNS server SHOULD send a
> edns-tcp-keepalive option with a timeout of 0 if it deems its local
> resources are too low to service more TCP keepalive sessions, or if
> it wants clients to close currently open connections.”
> 
> “Based on TCP session resources servers may signal a TIMEOUT value
> of 0 to request clients to close connections as soon as possible.
> This is useful when server resources become very low or a denial-of-

---

From: sara <[email-masked]>
Date: Thu, 7 Jan 2016 10:54:31 +0000

> On 6 Jan 2016, at 21:58, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>> 
> dnsop WG (or dprive) consider the issue already? 

It is a good question, but it wan't explicitly discussed AFAIK. 

> edns-keepalive-option exchange occurred on the existing TCP

Ah, this is to do with the semantics of EDNS0 exchanges. It just clarifies that if the server chooses not to send the option in this scenario it is effectively equivalent to the server sending a 0 timeout (indicating it does not want to continue with keepalive) even it if previously indicated it supported it. 

Sara.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 7 Jan 2016 14:52:52 +0000

Hi Sara,

On 07/01/16 10:54, sara wrote:
>>> Speaking for myself I don’t see this as the solution to managing
>>> DTLS sessions, I think that would be better handled with a TLS
>>> extension.
>> 
>> Yes, that's the obvious answer, and a not bad answer. Did the dnsop
>> WG (or dprive) consider the issue already?
> 

Okey-dokey, I'll ask Joel how he prefers to handle this on the
call today and go with whatever he recommends.

> 
>>>> - 3.3.2:
>> 
>> Oops:-) Typo there sorry, the one that puzzled me is at the end of
>> 3.2.2 where it says " This holds true even if a previous 
> Ah, this is to do with the semantics of EDNS0 exchanges. It just
> clarifies that if the server chooses not to send the option in this
> scenario it is effectively equivalent to the server sending a 0
> timeout (indicating it does not want to continue with keepalive) even
> it if previously indicated it supported it.

Ah grand, I get it now. I think the way you've explained it above
is clearer for me anyway, so maybe consider saying it that way if
you do any more changes.

Cheers,
S.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 7 Jan 2016 07:04:52 -0800

> call today and go with whatever he recommends.

oh goodie, happy to discussion, definitely not the arbiter of taste.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>