Subject: [DNSOP] I-D Action: draft-ietf-dnsop-5966bis-02.txt

From: [email-masked]
Date: Mon, 06 Jul 2015 10:04:37 -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           : DNS Transport over TCP - Implementation Requirements
        Authors         : John Dickinson
                          Sara Dickinson
                          Ray Bellis
                          Allison Mankin
                          Duane Wessels
	Filename        : draft-ietf-dnsop-5966bis-02.txt
	Pages           : 17
	Date            : 2015-07-06

Abstract:
   This document specifies the requirement for support of TCP as a
   transport protocol for DNS implementations and provides guidelines
   towards DNS-over-TCP performance on par with that of DNS-over-UDP.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-5966bis/

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-5966bis-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: John Dickinson <[email-masked]>
Date: Mon, 06 Jul 2015 18:06:30 +0100

> ftp://ftp.ietf.org/internet-drafts/
Hi,

We have just submitted a -02 update to the 5966bis draft.

There have been significant changes made since –01 draft in light of the
comments made on list. These include:

  * Significant restructuring and re-wording of the Connection Handling
    section. Split into Current Practice and Recommendations. Provides
    more detail on current practices and divides Recommendations up into
    more granular sub-sections.
  * New text on recommendations for client idle behaviour. Added
    statement that servers MAY use 0 idle timeout.
  * Updated text on server limits on concurrent connections from a
    particular client.
  * Moved TCP message field length discussion to separate section to
    highlight its importance.
  * Added more discussion on DoS risks and mitigation in the Connection
    Handling and Security Considerations section.
  * Removed references to system calls in TFO section.
  * Added more text to Introduction as background to TCP use.
  * Added definitions of Persistent connection and Idle session to
    Terminology section.
  * Re-stated position of TCP as an alternative to UDP in Discussion.
  * Added text that client retry logic is outside the scope of this
    document.

There were a few things we didn't add/change:

  * There were suggestions on the list that both pipelining and
    out-of-order processing should only be performed after explicit
    signalling. We felt that the working group consensus was that this
    was not needed because of the behaviour of existing implementations.

We hope this document has addressed the working groups concerns and hope
that people feel it is ready to progress.

regards
John

---

From: Tony Finch <[email-masked]>
Date: Tue, 7 Jul 2015 12:29:51 +0100

> We have just submitted a -02 update to the 5966bis draft.

I have read through this draft. It looks in good shape to me.

A general comment: can you please grep for lower-case RFC 2119 keywords
and either upper-case them or replace them with different phrasing, so
there is no doubt about whether something is a misspelled requirement or
really a suggestion. (e.g. "ought" instead of "should", "can" instead of
"may".) Section 6.2.1.1 especially.

Is there anything to say about pMTUd on UDP vs TCP?

Section 6.2.2 ought to allow for concurrent zone transfers, since that is
necessary for primary/secondary setups with many busy zones.

Section 6.2.3 "a few seconds" still seems generous, though I suppose it's
hard for a server to tune the timeout to something based on the client's
RTT...

Section 6.2.4 is it worth saying that a client can retry over UDP if it
has not previously received a TC reply to this query?

Section 11:

Wider use of TCP doesn't make servers more vulnerable to DoS attacks, but
rather it increases the likelyhood of accidental DoS due to server
overload.

I think discussing the wider use of TCP just makes it more blatantly
obvious how vulnerable existing servers are to TCP resource exhaustion.
Fixing TCP scalability will make them more resistant to DoS attacks.

Appendix A:

Is this supposed to be just a summary of points made earlier? There are
some points here about TFO and MPTCP which aren't in the main body.

Some editorial nits:

RRL is mentioned twice mentioned twice in the first para.

I suggest changing this paragraph in the intro

   This document therefore updates the core DNS protocol specifications
   such that support for TCP is henceforth a REQUIRED part of a full DNS
   protocol implementation.

to

   The previous version of this document [RFC5966] updated the core DNS
   protocol specifications such that support for TCP became a REQUIRED
   part of a full DNS protocol implementation.

IF TCP -> If TCP
fastopen -> Fast Open
TFO.From -> TFO.  From

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth: South becoming cyclonic 4 or 5, then mainly north 5
to 7 later. Slight or moderate, becoming moderate or rough later. Occasional
rain, fog patches. Moderate, occasionally very poor.

---

From: John Dickinson <[email-masked]>
Date: Wed, 08 Jul 2015 11:19:18 +0100

Hi,

> "may".) Section 6.2.1.1 especially.

Good idea - will do.
> Is there anything to say about pMTUd on UDP vs TCP?

Will give this some thought.
> necessary for primary/secondary setups with many busy zones.

OK
> hard for a server to tune the timeout to something based on the client's
Hopefully, one day there will be some kind of idle timeout signalling. 
What value would you suggest?
> has not previously received a TC reply to this query?

I think this is covered by the "No specific retry
    algorithm is specified in this document."
> rather it increases the likelyhood of accidental DoS due to server
Yes, I agree that statement could be better written. At the very least 
it should say accidental DOS of TCP only. I would hope that UDP would 
still be OK.
> Fixing TCP scalability will make them more resistant to DoS attacks.
Yes
> some points here about TFO and MPTCP which aren't in the main body.

I will make this consistent or consider removing it.
> RRL is mentioned twice mentioned twice in the first para.
Added text in the xref but didn't remove it from the body!
>     part of a full DNS protocol implementation.
I am not sure since we are obsoleting 5966. Will discuss with my other 
authors.
> TFO.From -> TFO.  From
Thanks for the review,
John

---

From: Shane Kerr <[email-masked]>
Date: Tue, 14 Jul 2015 10:31:20 +0000

John,

Looks pretty good, although I have a couple of comments.

First, does it make sense to discuss blocking of network prefixes
rather than IP addresses? This is mentioned a couple of times in the
text, but blocking an IPv6 address is like throwing a pebble in the
ocean. :P (I did a quick Google search to find if there are any RFC's
about this in general, but didn't notice any. Does anybody know of any
standard text about this issue?)

Second, one possible issue for consideration is that it is already a
problem for resolver operators that a single query can cause a *lot* of
work for the resolver. This issue can be magnified with TCP pipelining:
a bad actor can connect to a resolver and queue a ton of queries in a
few packets (consider how many queries will fit in 1460 bytes).

Cheers,

--
Shane

---

From: John Dickinson <[email-masked]>
Date: Thu, 16 Jul 2015 17:10:42 +0100

> standard text about this issue?)

Sounds good to me.

> few packets (consider how many queries will fit in 1460 bytes).

Do you feel this is worse than flooding a server with UDP? Should we 
have rate limiting?

thanks for the review
John

---

From: Ray Bellis <[email-masked]>
Date: Thu, 16 Jul 2015 17:22:38 +0100

> Do you feel this is worse than flooding a server with UDP? Should we

I think the pipelining is a non-issue, or rather one that already exists.

In practise most (if not all) existing DNS servers that support TCP
already suffer this potential problem.

When the client sends a whole series of queries down the connection
without waiting for an answer in general this "just works" because
servers don't routinely flush the incoming TCP read buffer every time
they respond to a packet.

Ray

---

From: Shane Kerr <[email-masked]>
Date: Thu, 16 Jul 2015 21:41:37 +0000

All,

Replying to both John & Ray's mails at once here. Hopefully that is
okay.

On Thu, 16 Jul 2015 17:22:38 +0100

> > Do you feel this is worse than flooding a server with UDP? Should we

I think it is worse than flooding with UDP. It allows "fire and forget"
actions from clients:

   # we can comfortably fit 20 queries into a single 1280-byte packet
   for i = 1 to 20:
       packet.append(EXPENSIVE_QUERY)
   conn = socket.connect_tcp("someserver", port=53)
   conn.write(packet)
   # the process can quit and the queries still go...
   exit(0)

If you have (for example) a maximum of 5 queries per client, then as
soon as one finishes you'll start another one. All from a 7-packet
exchange on the client side, versus a 40-packet exchange with UDP.
(See, TCP can be more efficient!!!)

The goal of this could be load on the resolver, load on upstream
authoritative servers, or something more creative....

> already suffer this potential problem.

True.

It's not clear to me whether out-of-order processing makes pipelining
better or worse, actually.

But perhaps a document about TCP in DNS might want to mention this
issue?

> they respond to a packet.

I don't even think there is a race-free way to flush the incoming
TCP read buffer. :P

Cheers,

--
Shane

---

From: Ray Bellis <[email-masked]>
Date: Thu, 16 Jul 2015 23:22:13 +0100

>     # the process can quit and the queries still go...

That shoudn't be possible - as soon as the client side exits the socket 
will get closed and any subsequent writes from the server side will 
generate an error.  AIUI, some IP stacks will even flush the read buffer 
if they detect a fully closed socket?
> authoritative servers, or something more creative....
I don't think that works (per above)
> But perhaps a document about TCP in DNS might want to mention this
Perhaps.  I do see out-of-order processing as a somewhat larger issue 
than pipelining, though, simply because the possibility exists that some 
clients will assume that the packets come back in request order, and 
fail to check the QID.
> I don't even think there is a race-free way to flush the incoming TCP 
> read buffer
That might explain why it's not done ;-)

Ray

---

From: John Heidemann <[email-masked]>
Date: Fri, 17 Jul 2015 18:35:48 -0700

>authoritative servers, or something more creative....

I think one has to be careful comparing TCP and UDP attacks here.

Yes, this is a DoS attack.  The question is not can TCP be used to
attack, but is it WORSE than UDP?  Or how is it better and worse?

You say 7 packets vs. 40 packets.  When under DoS, is DNS per-packet
constrained or bitrate-constrained?  With modern routers my
understanding is it's usually bitrate not packet count that is the
limit.  Bitrate is about the same for UDP vs. TCP.

Both UDP and TCP will have to do application-level rate limiting.
The neat thing about TCP is rate limiting is far easier
because your 7 packets are all unambiguously from the same source.
(As opposed to UDP where the attacker will be spoofing the source
address.)

Liang Zhu did some testbed experiments of DNS under UDP and TCP
attacks---we found that DNS/TCP can be quite a bit more robust to DoS
than UDP when one takes basic defenses like the HTTP people do (that is:
rate-limit queries per connection, connections per IP, and use SYN
cookies).  See Figure 4 and section V-B in
http://www.isi.edu/~johnh/PAPERS/Zhu15b.pdf for graphs.
(These do not include your specific attack, but do consider spoofing and
non-spoofing.)

Use of TCP will require hardening DNS servers' TCP compared to today.
But in today's hostile Internet, such hardening seems necessary anyway.

   -John Heidemann

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Jul 2015 10:27:41 -0700

John Heidemann wrote:
> ...

in this solution space, possible outcomes are "better", "worse", "no
change", "not better", and "not worse". i think shane is arguing for
"never better and sometimes worse" here.

> ...

if it were in our power (or especially in amazon's or google's or
akamai's power) to cause the internet to be made up of mostly modern
routers, then it would be so. alas, it is not in our power, and the
internet will always have a long tail of routers we wish didn't exist
any more. thus the aphorism, "the least reliable and most expensive part
of the internet is OPM -- other people's networks."

for dns, we must design for the internet we will always have, not the
internet we will always want. and on the internet we have, packets per
second are a common bottleneck, such that an attacker knows they can
reliably deny service with a small number of small packets, which do not
saturate any link, but which do saturate the kinds of routers and
firewalls people actually do still buy and use today.

-- 
Paul Vixie

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Sat, 18 Jul 2015 17:46:33 +0000

# This is an impossible, and true directive.  Yes, we must do our best.  We can never 
# control either case; "what we want" or "what remains".

/Hugo

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

---

From: John Heidemann <[email-masked]>
Date: Sat, 18 Jul 2015 23:09:53 -0700

>"never better and sometimes worse" here.

Correct.  And I'm suggesting that (1) there's a misstep in that argument.
He equates full-size TCP packets with short UDP packets to reach his
"sometimes worse" claim.

And I'm also suggesting (2) TCP allows a path to MUCH better against DoS.

>firewalls people actually do still buy and use today.

I agree, we need to prevent "an attacker knows they can
reliably deny service with a small number of small packets, which do not
saturate any link".

But that is not *Shane's scenario*.

Shane's scenario was 7 FULL-LENGTH TCP packets vs. 40 SHORT UDP packets.
That is what I meant by "bitrate is about the same for UDP vs. TCP".
Shane's attack is not a shrew-style attack on TCP---he IS saturating the
link, just with aa few big packets instead of many short packets.

The first point you were making is we cannot change the routers:

>or dns, we must design for the internet we will always have, not the
>second are a common bottleneck,
>...

Agreed, we cannot upgrade other people's routers.

But, I'm sorry, if you're running DNS on an old router, you're trivially
DoS-able today.  Millions of insecure computers to tens of Mb/s
uplinks.  It only takes a couple to saturate a link, either in packets
or bits.

My second point was (2) TCP allows a path to MUCH better.

>> (These do not include your specific attack, but do consider spoofing and

Let me state the advantage more explicitly:

With UDP and spoofed source addresses, each attacker gets to hit you
with their full line rate, AND you have to service all the queries.
This exhausts your incoming bitrate, packet rate, or CPU speed
depending on how you're configured.

With TCP, you get a whole bunch of defenses:

- Spoofing is prevented with SYN cookies, so a spoofing attacker never
  gets to hit you with Shane's full length packets in the first place.
  The spoofed IPs are stopped at the SYN with NO state on the defender's
  server.

  SYNs are much faster to handle than full DNS queries.  In our
  scenario, 1 or 2 UDP attackers could flood our small server at about
  300k queries/s.  But we could easily handle 250k SYNs/s with SYN
  cookies.  (The kernel turns them around without any application
  involvement.)

-  No spoofing forces the attacker to reveal each zombie's identity.
  Now that attackers have to show their identity (no spoofed source
  addresses!), you can do MUCH EASIER rate limiting.

  Start by limiting concurrent connections per source IP.  The attacker
  now must deploy 6000 zombies where 2 or 6 would do before.

  To prevent Shane's attack, one also has to rate limit queries per
  connection.  We didn't consider this specific attack,
  but I think the defense follows.

The numbers and graphs I quote above are in Figure 4 and section V-B in
<http://www.isi.edu/~johnh/PAPERS/Zhu15b.pdf> if you want details about
our setup.

This data supports the the claim that TCP can be "better".
I still don't see a complete "sometimes worse" argument.

   -John Heidemann

---

From: Petr Spacek <[email-masked]>
Date: Mon, 20 Jul 2015 12:19:26 +0200

> 	Filename        : draft-ietf-dnsop-5966bis-02.txt

The -02 version of the draft makes a lot of sense to me, here are only two nits:

Section 5 says:

"... TCP should be considered a valid alternative transport to
   UDP, not purely a fallback option.".

To me it seems as the very very core of the draft. Personally I would add this
to Introduction and even to Abstract to make it super clear. Now it is kind of
buried.

6.1.  Current practices
Explicit reference to edns-tcp-keepalive could be good so it is easier to read
and follow, especially if edns-tcp-keepalive gets finalized.

-- 
Petr Spacek

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 21 Jul 2015 18:30:15 +0200

> On 20 Jul 2015, at 12:19, Petr Spacek <[email-masked]> wrote:
> 

Many thanks for the review. 

> On 20 Jul 2015, at 12:19, Petr Spacek <[email-masked]> wrote:
> 
> Section 5 says:
> 

Thanks - good point. 

> and follow, especially if edns-tcp-keepalive gets finalized.

Yes, the only reason it wasn’t there is that the 5966bis-02 was ready when the status of the edns-tcp-keepalive draft was still a bit up in the air. Now keepalive has moved forward it makes sense to add the reference. 

Sara.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 25 Jul 2015 19:24:17 -0700

John Heidemann wrote:
>>> ... With modern routers my understanding is it's usually bitrate not packet count that is the limit. Bitrate is about the same for UDP vs. TCP. ...
>> ... on the internet we have, packets per second are a common bottleneck, such that an attacker knows they can reliably deny service with a small number of small packets, which do not saturate any link, but which do saturate the kinds of routers and firewalls people actually do still buy and use today.
>
> I agree, we need to prevent "an attacker knows they can reliably deny service with a small number of small packets, which do not saturate any link".

wait, we may not agree, since i don't see similarity between my
statement and your restatement. it makes no difference in my view what
an attacker knows. attack resources are cheap. like spam, ddos need not
be targeted. for example, the 400Gbit/sec DDoS against spamhaus a few
years ago was done with random destination addresses of spoofed-source
queries, and enough of these random destinations provided an answer, to
create operational problems for spamhaus' online presence.

> But that is not *Shane's scenario*.

other than clarifying what i thought shane meant, i plan to stay out of
that scenario, since his proposed python script looked like it needed a
non-spoofed source address, and so it demonstrates a different weakness
than the ones i spend most of my time thinking about.

> link, just with aa few big packets instead of many short packets.

well, if i read it correctly, the link being saturated actually
participated in session setup, and so i'll leave you and him to follow
that thread without me.

> But, I'm sorry, if you're running DNS on an old router, you're trivially DoS-able today. Millions of insecure computers to tens of Mb/s uplinks. It only takes a couple to saturate a link, either in packets or bits.

from a protocol evolution standpoint, our burden is to not make things
worse for someone who has a working configuration today. so when i
consider old routers, i don't wonder if they can't be targeted today,
only whether they will be more naturally targeted by a prospective
change to the protocol.

so for example, i argued extensively against "just use tcp as the
primary transport for dns" because without some kind of new signaling,
this would create resource exhaustion attacks against servers who
strictly and/or simplistically implement the DNS standard's tcp
connection management. whereas, if tcp can be negotiated without
creating such an attack vector, i have no objections. what i hope this
demonstrates is that i think explicitly-consenting protocol agents
should work together however they want, but that consent cannot be seen
as implied.

in that same way and for similar reasons, we should design around the
assumption that most of the weak far-side routers will not be upgraded
in our lifetimes, and we should both subtract out any current method of
packet-bombing them with spoofed-source requests, and also not add any
new method of such packet-bombing. we should never say "since they're
weak, they're already vulnerable, and so we don't have to worry about
making their situation worse."

>>> cookies).

i don't think anybody has argued against what can be proved in a lab,
and few of us here have argued against what could be built using a new
port number. zhu's work shows a system having better worst-case
performance, and worse best-case performance, than the current dns
system. and as long as any change to the
when-to-use-tcp-and-for-how-long predicate is explicitly negotiated with
the default being to assume that the other end wants the old behaviour,
i think those tradeoffs (better worst-case, worse best-case) are
reasonable. so, i didn't include that part of your post, since i wasn't
disagreeing with it.

since you brought it up, i do want to know what the udp response policy
will be for servers who have a new-style (explicitly negotiated)
persistent tcp session in place. ideally, there will be some capability
for multiple tcp sessions between the same endpoints (like the web does
on tcp/80) and also some capability to simply ignore udp queries from
currently-connected-far-ends (since these may be spoofed, and we'd like
the existence of a tcp session to protect against that vector.)

the rest of this is even more off-topic and inside-baseball, but not (in my view) irrelevant or uninteresting:
 
> ...
>
> With UDP and spoofed source addresses, each attacker gets to hit you with their full line rate, AND you have to service all the queries. This exhausts your incoming bitrate, packet rate, or CPU speed depending on how you're configured.

with RRL we showed that it's not necessary to service all of the
queries. a careful drop policy along with a careful TC-signaled TCP
transport switch can result in successful cache fills such that the
far-end application gets good service even when the vast majority of the
attack volume is dropped. this is a minor matter but i'd like the record
to be clear.

> - Spoofing is prevented with SYN cookies, so a spoofing attacker never gets to hit you with Shane's full length packets in the first place. The spoofed IPs are stopped at the SYN with NO state on the defender's server.

SYN cookies are a solution to a different problem (TCB overrun attacks).
what stops spoofing when TCP is used is the random initial sequence
number of the SYN-ACK. again, a small matter.

> ...
>
> This data supports the the claim that TCP can be "better". I still don't see a complete "sometimes worse" argument.

i think tcp is never better than udp, but that doesn't matter, since it
has better worst-case performance, and udp's worst-case performance
includes spoofed-source attacks, which are hard to live with.

it's possible that shane didn't understand that he was comparing a
tcp-based attack (where spoofing can't work) against udp-based attacks
(where it can.) there are a lot of moving parts in this thread, and a
lot of timezone traversals by its participants.
-- 
Paul Vixie

---

From: John Heidemann <[email-masked]>
Date: Sun, 26 Jul 2015 22:21:37 -0700

>create operational problems for spamhaus' online presence.

Hmmm, I was attempting to quote back exactly what you said.  Clearly
something failed.

I concur that if you place the empahsis on the first three words that
were quoted, then the statement is silly.  I didn't mean it that way,
and I assume you didn't originally mean it that way either.

>than the ones i spend most of my time thinking about.

I thought Shane made a thoughtful contribution: the observation that one
can bulk-up a DNS-over-TCP with multiple requests, thus 7 TCP packets do
the work of 40 UDP.  That was a useful and accurate observation.

My gripe is that going on to suggest that those 7 TCP packets are "easier"
than the 40 UDP packets is incorrect for modern routers.
In particular, characterizing Shane's scenario as "an attacker...[that
can]...reliably deny service with a small number of small packets, which
do not saturate any link" is incorrect.

His TCP attack demands roughly the same number of bits as the UDP
attack---counting packets here is misleading.

>participated in session setup, and so i'll leave you and him to follow

If you want to bring up some other TCP scenario, that's great.  Let's
not confuse it with what Shane proposed.

>making their situation worse."

The DNSOP WG discussion seems to be trending towards TCP with
explicit signaling.

BUT signaling seems quite off the point of Shane's thread, so perhaps
that discussion is best had in a separate thread.

>reasonable. so, i didn't include that part of your post, since i wasn't

Glad to hear it!

>the existence of a tcp session to protect against that vector.)

I don't think there has been discussion about that topic.
Such a transition brings up a lot of issues.

I have some ideas, but it seems premature to talk about handling UDP
queries until we have significant deployment experience with
DNS-over-TCP.  I hope we will get there :-)

>attack volume is dropped. this is a minor matter but i'd like the record

Interesting.  I didn't realize RRL included TC signaling to switch to
DNS-over-TCP on DoS (I had read http://www.redbarn.org/dns/ratelimits,
and BIND's AA-00994 and AA-01000, but only the BIND manual goes into the
TC option in detail).  That's a excellent use of both transport protocols.

>number of the SYN-ACK. again, a small matter.

It seems to me that that framing focuses on the payload.

SYN cookies then prevent resource exhaustion (the number of TCBs on the
server) that happens in the SYN-ACK exchange; the part that actually
results in denial.

Seems to me like it's six vs. a half-dozen.

>includes spoofed-source attacks, which are hard to live with.

I'm not sure how you reconcile "tcp is never better than udp" and "it
has better worst-case performance".  But it sounds like we have several
points of agreement on TCP's potential role in handling DoS.

And the poor 7-TCP-packet attack seems now thoroughly beaten to death.

   -John Heidemann

---

From: Paul Vixie <[email-masked]>
Date: Sun, 26 Jul 2015 22:56:10 -0700

John Heidemann wrote:
> ...
>
>> since you brought it up, i do want to know what the udp response policy will be for servers who have a new-style (explicitly negotiated) persistent tcp session in place. ideally, there will be some capability for multiple tcp sessions between the same endpoints (like the web does on tcp/80) and also some capability to simply ignore udp queries from currently-connected-far-ends (since these may be spoofed, and we'd like the existence of a tcp session to protect against that vector.)
>
> I don't think there has been discussion about that topic. Such a transition brings up a lot of issues.
>
> I have some ideas, but it seems premature to talk about handling UDP queries until we have significant deployment experience with DNS-over-TCP. I hope we will get there :-)

that won't happen. or at any rate we should all we can to prevent it
from happening. don't be alarmed-- what i mean is, until we have some
idea what we'll do with parallel tcp sessions and what we'll do with
concurrent udp transactions from the same initiator, we MUST NOT deploy,
and we will therefore not garner any deployment experience.

"build it first, secure it later" has not worked, ever, anywhere, for
anybody.

> TC option in detail).  That's a excellent use of both transport protocols.

really? i wrote ISC-TN-2012-1 (which is linked from the .../ratelimits
page referenced above) and i thought this text was clear:

   2.2.8. TC-RATE (2). When a query would be dropped due to rate limiting,
   we randomly send back a truncated response instead once per TC-RATE
   queries.  This tells a victim whose address is being forged to retry
   using TCP. It's recommended that TC-RATE be set lower than LEAK-RATE. If
   TC-RATE is set to zero then this behaviour is disabled.

and:

   4.1. A victim whose IP address is forged in a large request flow should
   normally expect to experience unavoidable congestion on their Internet
   link.  However, if all forged requests are sent to a small number of
   servers and if those servers implement rate limiting as described in
   this document then the victim will see a small amount of unsolicited
   response traffic and will at the same time have higher than normal UDP
   retry and truncation/TCP counts if they themselves ask the affected
   servers any question which solicits the same answer as is being
   solicited in the attack.

what different words would you suggest, to better explain this concept?

> Seems to me like it's six vs. a half-dozen.

no, really. syn cookies help with TCB congestion even when spoofing is
not used.

> has better worst-case performance".

you make an excellent point. let me be correct this time:

i think tcp's betterness vs. udp for dns only occurs in worst-case
scenarios, but those scenarios are currently driving headlines, and are
worth investing in. it is moderately saddening to me that we have to pay
in best-case performance to get this worst-case benefit, and i would
have preferred an RFC 6013 based approach (cookies all the time, tcp
close is soft/temporary, and opportunistically save/reuse the prior
window size on any subsequent session) but since Google TFO won that
war, it's time to move on.

-- 
Paul Vixie

---

From: John Heidemann <[email-masked]>
Date: Mon, 27 Jul 2015 00:10:49 -0700

>"build it first, secure it later" has not worked, ever, anywhere, for

I'm sorry, I feel like I'm stuck in "bring me a rock".

There's been plenty of discussion about how one can safely deploy
DNS-over-TCP (that is: security is not worse).  That is not this thread.

If you want to talk about transitioning UDP to TCP and sunsetting UDP,
that's a new topic.  That's not "secure it later".

>what different words would you suggest, to better explain this concept?

Great text.  I missed it as the 8th of 10 references on the redbarn
page, and not mentioned on the two AA pages.  Mea cupla.

   -John Heidemann

---

From: Paul Vixie <[email-masked]>
Date: Mon, 27 Jul 2015 11:12:37 -0700

John Heidemann wrote:
>> from happening. don't be alarmed-- what i mean is, until we have
>> some idea what we'll do with parallel tcp sessions and what we'll do
>> with concurrent udp transactions from the same initiator, we MUST NOT
>> deploy, and we will therefore not garner any deployment experience.

please remind me what thread in what forum i should join in order to
participate.

> that's a new topic.  That's not "secure it later".

it is, though. dns protocol agents have a very long tail. it takes at
least a decade to get something like EDNS or DNSSEC to show up in the
field in large numbers, and apparently at least two decades to make it
the default.

you only get one shot, operationally speaking, at getting folks to
deploy any new tcp session option. if at that time you don't also advise
them as to how many tcp sessions to permit in parallel, and what to do
with udp packets having the same endpoints while a session is open, then
you'll have added a new feature (and its associated complexity) without
doing anything to actually stop the problem you started with
(spoofed-source reflection and/or amplification.)

-- 
Paul Vixie