Subject: Re: [dnsext] Draft: WGLC draft-ietf-dnsext-dns-tcp-requirements

From: Alfred Hönes <[email-masked]>
Date: Thu, 18 Feb 2010 14:17:48 +0100 (MEZ)

At Wed, 17 Feb 2010 09:58:37 -0800, Nicholas Weaver wrote:
> Overall, I support this draft, ...

+1

(My principal support of the draft should have been clear,
but better repeat it here!)

> ... however, I'd make the following suggestion.
>
> For section 5: Connection handling.

In general, I concur.

But I would prefer to not simply strike the "TBD" in ...

   This document therefore RECOMMENDS that the application-level idle
   period should be of the order of TBD seconds.

... as others have suggested; "tens of seconds" (or even more)
seems to be more appropriate (see below).

> I think a fixed timeout is limiting, rather, I'd suggest text
> perhaps more like this:

>> ...

> At the same time, prematurely closing connections increases client
> query latency.  Since DNS is commonly on the critical path for numerous
> network activities, maintaining low latency is a priority.  Thus this
> document therefore RECOMMENDS that the application-level idle period
> should be undefined, as it will vary based on the traffic a particular
> server received.
>
> A server should monitor its current resource utilization and, when
> under state pressure, MAY elect to terminate idle connections in order
> to free state.  Therefore if the server needs to unilaterally close a
> dormant TCP connection it MUST be free to do so whenever required.
> At the same time, when the idle connections are not consuming
> significant resources, the server SHOULD maintain idle connections
> in order to reduce protocol latency for subsequent queries.

That looks like a valuable recommendation to be made.

>
> Servers MAY instead use a fixed timeout for idle connections, but
> clients MUST NOT rely on such a timeout being consistent.  Likewise,
> a server MAY limit the number of concurrent connections a client has
> outstanding to a number greater than four.  If this limit is exceeded,
> may terminate an arbitrary set of the client's connections until the
> client is below the limit, even if some of the connections have
> outstanding queries.

I miss an important argument (didn't I spell it out already earlier
when the WG discussed adoption of the draft?):

The party doing an "active close" of a TCP connection (more precisely:
the peer sending a FIN before having received one) has to go through
TIME-WAIT state, in order to avoid connection clashes and to mitigate
certain security threats.  Thus, a server actively closing a TCP
connection still has to keep (at least partial) connection state.
The TCP MSL (maximum segment lifetime) cannot be assumed to be
arbitrarily short in these days; routing changes and handover delays
in mobile node connections have increased the real-life MSL
significantly above the level that many folks deemed reasonable
a decade ago or so.
Thus, a server unilaterally closing a TCP connection not only does
not immediately free state, it also runs the danger that the client
will have another query and retry TCP connection setup during his
TIME-WAIT state.

Fernando, are you listening?  Could you please suggest wordsmithed
text to add, or modifications to the proposal from Nicholas, to this
end?

(BTW: It has been suggested on this thread to add a reference to
 Fernando's CPNI "Security Assessment of the Internet Protocol"; but
 most likely the reference should be made to the other CPNI document,
 "Security Assessment of the Transmisison Control Protocol (TCP)".)

> (Rationall:  Timeout on idle connections should be dynamic in
> practice, so it should be expressed as such.
> The server should be allowed to limit the number of outstanding
> connections from any particular client, although there should be a
> default minimum limit)
>

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: [email-masked]
Date: Thu, 18 Feb 2010 13:38:57 +0000

> seems to be more appropriate (see below).

This is straying into "pick a number" territory (which I'm trying to 
avoid), and covers all the way up to the current 120s.

My own view (for what it's worth) is that I really mean seconds (i.e. 2, 
4, etc), and not "tens of" seconds.

> when the WG discussed adoption of the draft?):

In part yes.  Your previous concern mostly appeared to be a 
misunderstanding - that I was trying to reduce the TCP stack timeout.

Hence I adjusted the draft to make it clear that it's only the application 
level timeout that should be reduced.
 
> will have another query and retry TCP connection setup during his

Yes, that's correct.

However in practise I expect that clients will tear down the connection 
far more commonly than servers.

Mark A - if you're listening - what's BIND's behaviour when acting as a 
client?  Can you confirm my supposition?

kind regards,

Ray

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 18 Feb 2010 07:09:23 -0800

> will have another query and retry TCP connection setup during his

A lot (and I mean a LOT) of web servers close idle connections with RST, just because of this issue: close with a RST and you don't need to keep any more state at all.

I interpreted "unilatteraly close" to indicate that a RST-close would be acceptable as well, if others don't, the language should probably be changed to make it clear that if a server wants to close an idle connection with a RST, its perfectly welcome to, because thats what very well may be done.

---

From: [email-masked]
Date: Thu, 18 Feb 2010 15:38:23 +0000

> A lot (and I mean a LOT) of web servers close idle connections with 
> RST, just because of this issue: close with a RST and you don't need
> to keep any more state at all.
> 
> I interpreted "unilatteraly close" to indicate that a RST-close 
> would be acceptable as well, if others don't, the language should 
> probably be changed to make it clear that if a server wants to close
> an idle connection with a RST, its perfectly welcome to, because 
> thats what very well may be done.

Doesn't the existing text cover that (bearing in mind that AFAIK client 
software can't usually play those tricks, it requires O/S support)

"Further recommendations for the tuning of TCP parameters to allow
   higher throughput or improved resiliency against denial of service
   attacks are outside the scope of this document."

s/parameters/stacks/, if that makes it clearer...

Ray

---

From: Paul Vixie <[email-masked]>
Date: Thu, 18 Feb 2010 16:31:34 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Thu, 18 Feb 2010 07:09:23 -0800
> 
> I interpreted "unilatteraly close" to indicate that a RST-close would be
> acceptable as well, if others don't, the language should probably be
> changed to make it clear that if a server wants to close an idle
> connection with a RST, its perfectly welcome to, because thats what very
> well may be done.

any server-initiated close that isn't FIN or isn't timeout-based would be a
protocol change not a clarification, and subject to stronger review here.

for example, folks have said that RST-initiated close based on the number of
open connections would make TCP safe for busy nameservers.  i don't agree,
at present, but my mind is available for further study.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Feb 2010 16:18:52 -0300

> protocol change not a clarification, and subject to stronger review here.

I disagree. Terminating a connection with an RST is an ABORT procedure
call, already specified in RFC 793 for the "abstract" TCP API.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Paul Vixie <[email-masked]>
Date: Thu, 18 Feb 2010 19:24:35 +0000

> Date: Thu, 18 Feb 2010 16:18:52 -0300
> From: Fernando Gont <[email-masked]>
> 

current client expectations are that when this occurs it is an error worthy
of syslog.  i'm not saying that RST isn't defined, i'm saying that using it
this way (server side connection pool management for non-timeout reasons) is
a protocol change for TCP/53, and is not a clarification of the DNS standard.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Feb 2010 17:00:12 -0300

Hello, Paul,

> a protocol change for TCP/53, and is not a clarification of the DNS standard.

If you're going to tear down connections because you're running out of
resources, then it doesn't make sense to get into yet another
resource-intensive operation such as the TCP "graceful close" (i.e., FIN
exchange).

I agree that this would not be a "clarification". But I don't think it
would make sense to recommend servers to close connections when they are
running out of resources without giving them a hint on how to do it
properly. If they just close() the connection, they run the risk of
sockstress-like attacks we all know about.

Thanks,

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Feb 2010 15:21:41 -0500

I can't decide whether this is the sort of procedural issue for which
a chair is useful, or if this is still a technical point about the
protocol (in which case I need no hat).  You can say I'm hat in hand, I
guess.

> sockstress-like attacks we all know about.

I think Paul's point is that, if the document is going to say that, it
is in fact a modification of the protocol, and requires careful study
of what happens if one actually implements such behaviour in
widely-used servers.  So far, the document doesn't actually make that
sort of change to the protocol: it merely says, "You really do need
TCP" and not, "Not only do you need TCP, but you need to be able to
break TCP connections in a way nobody does today."

Because of the difference in effect on the protocol, it seems to me
that a document suggesting another manner for closing TCP connections
other than close() could easily be separated from the draft under
discussion.  Such a document would clearly be a standalone one that
updated a specific part of STD13.

Thoughts?  (Volunteers?)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Feb 2010 18:26:06 -0300

Andrew Sullivan wrote:

> widely-used servers.  

I don't believe this is a change in the protocol. Note that I'm not
arguing "from now on TCP connections used for DNS should be closed with
a 'RST'". I'm arguing that if you're going to tear down a connection
because you're running out of resources, you better to it with an ABORT
call... or else you may be getting into yet more trouble.

> So far, the document doesn't actually make that

Well, it does requires that servers be free to close connections... so
it already shows concerns for DoS attacks....

> updated a specific part of STD13.

I understand that TCP security issues need not be addressed in this
document (which rather aims at requiring support of TCP in DNS
implementations).

However, it is a real and valid concern that of TCP support increasing
the risk of DoS. And I believe that if we're going to require TCP
support, we should also address the concern of DoS... not necessarility
in this document, though.

> Thoughts?  (Volunteers?)

If it comes to general improvements in TCP security, there's already
draft-ietf-tcpm-tcp-security (which, given some tcpm statistics and some
extrapolations, could possibly take more than twenty years to complete
:-) ). However, I believe that it could be of help to provide some
advice along the lines of "TCP tuning for DNS", that could provide
specific advice on how to set various fields and various policies for
DNS (e.g., recommended TCP window to use, recommended timeouts,
recommended ways to tear down connections, etc.).

If there's support for this idea, I volunteer to start writing on a
draft version of such a document.

Thanks,

---

From: Mark Andrews <[email-masked]>
Date: Fri, 19 Feb 2010 09:37:40 +1100

> client?  Can you confirm my supposition?

Named's current behaviour is to perform a query then close the connection.
libbind has the option to keep connections open, but it is not the default.
Netstat uses it from memory.

Named may in the future check to see if there is already a open TCP socket
to the server and re-use it rather than creating a new one.  I don't see
us holding the socket open just on spec at this point.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 18 Feb 2010 23:50:56 +0000

> Date: Thu, 18 Feb 2010 17:00:12 -0300

no, it doesn't.  however, the original DNS RFC's do not contemplate TCP as
a frequently used transport for DNS QUERY, and so they specify such grace,
and there are clients designed with assumptions of that grace.  until and
unless we change the protocol, not merely clarify it, graceful close is
what the protocol is specified to use here.

for correctness, this means starving new TCP sessions at the expense of the
long timeouts specified for existing TCP sessions.  i don't like it but i'm
not ready to say that the spec was unclear and that we can get rid of this
behaviour by merely clarifying the spec.

> sockstress-like attacks we all know about.

this is why some of us are talking about Cookie Transaction TCP, and/or SCTP.
TCP/53 is simply useless by design.

see <http://www.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf>,
noting that the weaknesses of both of DNS's present transports (UDP/53 and
TCP/53) are well understood by those authors.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Feb 2010 00:03:09 +0000

> Date: Thu, 18 Feb 2010 18:26:06 -0300
> arguing "from now on TCP connections used for DNS should be closed with a
> 'RST'". I'm arguing that if you're going to tear down a connection

RFC 1035 4.2.2 does not describe that form of connection management while
it does describe several others.  i recommend that the spec be followed
with regard to TCP connection management, which may require changing the
spec to allow the kind of connection management you are now describing.

---

From: "George Barwood" <[email-masked]>
Date: Fri, 19 Feb 2010 00:11:28 -0000

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 18, 2010 7:24 PM
Subject: Re: [dnsext] Draft: WGLC draft-ietf-dnsext-dns-tcp-requirements 

> a protocol change for TCP/53, and is not a clarification of the DNS standard.

RFC 1035 states:

  - If the server needs to close a dormant connection to reclaim
     resources, it should wait until the connection has been idle
     for a period on the order of two minutes.  In particular, the
     server should allow the SOA and AXFR request sequence (which
     begins a refresh operation) to be made on a single connection.
     Since the server would be unable to answer queries anyway, a
     unilateral close or reset may be used instead of a graceful
     close.
Doesn't this state explicitly that a reset may be used? ( I admit I don't know what
teh distinction between a "unilateral" and "graceful" close is ).
I think a possible clarification is that a reset SHOULD be used, rather than MAY.
That's certainly what I have implemented, although after testing, I see this seems unusual.

Of course if the BIND client closes immediately after a response, this won't normally happen,
so the syslog will stay empty. If the BIND client changes to keeping the connection open, it
would need to change it's syslog policy I think.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Feb 2010 03:00:00 -0300

> teh distinction between a "unilateral" and "graceful" close is ).

Unilateral close is is a reset, as in:

A               B
  --- RST --->

Graceful close is the FIN handshake, as in:

A              B
  --- FIN --->
  <-- ACK ---
  <-- FIN ---
  --- ACK --->

Kind regards,

---

From: [email-masked]
Date: Fri, 19 Feb 2010 08:32:44 +0000

>      unilateral close or reset may be used instead of a graceful

Thanks George, for actually going back to the source and checking :)

Indeed, the protocol does already appear to allow a RST to close a 
connection in those circumstances.

I *think* everyone's concerns about §5 can be addressed simply by adding 
"or reset" after "unilaterally close" for clarity, per the 1035 text.  I 
don't think the TCP resource state differences between FIN/RST needs to be 
addressed here.

I note various comments (mostly Nick W's) about allowing flexibility in 
the timeout.  The draft already says:

  "Servers MAY allow dormant connections to remain open
   for longer periods"

which I believe gives implementers all the flexibility they need.  Does 
adding more text here really help?  Note I'm a fan of short and 
to-the-point RFCs  ;)

Ray

---

From: Alex Bligh <[email-masked]>
Date: Fri, 19 Feb 2010 09:39:49 +0000

--On 19 February 2010 08:32:44 +0000 [email-masked] wrote:

> don't think the TCP resource state differences between FIN/RST needs to
> be addressed here.

I wonder if adding something like "This behaviour is subject to the
requirements of the prevailing TCP RFCs" (or similar) would put people's
mind at rest that the intention is not to change the TCP RFCs.

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 19 Feb 2010 11:56:08 -0500

No hat

> mind at rest that the intention is not to change the TCP RFCs.

I think that's key, but I'd also really like to see something that
points out the basic assumptions Paul Vixie outlines up-thread.  A
completely plausible reading of STD13, or even RFC 2181, is that even
if TCP is required it's going to be unusual and not the standard mode
of operation.  I am on board with those who think modifying the
document to include encouragement of unilaterally closing the
connection needs to be undertaken with great care, and I think if
there will be test to encourage RST further (and I read Ray's proposal
as such encouragement), we ought to have some words that recommend it
be used very carefully.

All of that said, I'm persuaded that indeed the 1035 text permits RST
without much qualification, and I'm ashamed to have missed that
before.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Feb 2010 18:00:17 +0000

> From: [email-masked]
> Date: Fri, 19 Feb 2010 08:32:44 +0000
> 
> > RFC 1035 states:
> > 

after the two minute timeout, you mean.  so we can avoid TIME_WAIT.

> don't think the TCP resource state differences between FIN/RST needs to be 

if you're allowing RST after a two minute idle timeout, it's not a protocol
change.  if you're allowing RST for congestion-oriente dconnection management
that would be a protocol change (not a clarification or other restatement.)

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Feb 2010 18:18:01 +0000

> Date: Fri, 19 Feb 2010 11:56:08 -0500
> From: Andrew Sullivan <[email-masked]>
> 
> without much qualification, and I'm ashamed to have missed that before.

don't be ashamed, because it doesn't matter.  you can wait 3*MSL or you can
wait two minutes, but either way the server has to hold some state for a
long while after any simple query, no matter who initiates the close or why.

changing TCP/53 to allow congestion-driven server-initiated unilateral-close
would *not* be a clarification, it would be a completely new way of working.

---

From: [email-masked]
Date: Sat, 20 Feb 2010 10:20:24 +0000

> 4, etc), and not "tens of" seconds.

	unless you place an upper bound (pick a number) then
	you can't complain when I set, in my implementation,
	a value of 8264000 seconds.

	this is tricky - since the timeout value has quite a bit to
	do with the prevaling network infrastrcuture.  back in the 1980s
	a 120s timeout was credible, given the clock rates on end-nodes
	and the link speeds - typically 56k and 64k speeds.  Todays network
	runs at much higher clock rates and link speeds. - generally

	what I suspect is that in the next 20 years, what we will see is
	a network that spans a much wider range of clock speeds and link 
	rate - and I am concerned about "impedence" mismatch on timeout
	values.

---

From: William Allen Simpson <[email-masked]>
Date: Sat, 20 Feb 2010 09:57:26 -0500

While I support the overall purpose of this draft, it seems to me that
this needs considerable word-smithing before it is ready.

> 	runs at much higher clock rates and link speeds. - generally
Wow, Bill was a lucky guy!  Around here, in the '80s, the IP backbone may
have had speeds of 56K, but we were using 110 bps and 300 bps dialup, and
inter-departmental connectivity was gradually upgrading from 1200 bps
Racal-Vadic "triple modems" to very expensive 2400 bps ($6,000 apiece).
The 300 bps modem banks weren't retired until the '90s.

This specification MUST NOT change the current two minutes (120 seconds)
to a shorter time period.

However, there is a perfectly good TCP option that deals with this issue,
and that SHOULD be referenced here: TCP User Timeout Option [RFC 5482].

> 	rate - and I am concerned about "impedence" mismatch on timeout
UTO can negotiate this, transparently to both parties.

---

From: William Allen Simpson <[email-masked]>
Date: Sat, 20 Feb 2010 10:26:54 -0500

+1

I've held off replying to this thread until it slowed down a bit, and I've
re-read it again.  TCP <RST> is improperly overused here.

RFC 1035 *ONLY* allows "unilateral close or reset" a dormant connection
after "a period on the order of two minutes".  I've always interpreted
that to mean the TCB itself could be thrown away (not a <RST> is sent).

RFC 793:
   As a general rule, reset (RST) must be sent whenever a segment arrives
   which apparently is not intended for the current connection.

Gratuitous <RST> (to close a connection) *without* an incoming segment is
an *abuse* of TCP (and shouldn't work).  This SHOULD be clarified here,
and there SHOULD be a reference to RFC 3360.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 20 Feb 2010 16:31:02 +0000

> Date: Sat, 20 Feb 2010 10:20:24 +0000
> From: [email-masked]
> 

+1.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 Feb 2010 17:08:06 -0300

> UTO can negotiate this, transparently to both parties.

IIRC, the DNS spec and the UTO option address two completely different
issues. The DNS spec addresses the case of *idle* connections (i.e., a
connection that has not been used for anything useful for e.g. the last
two minutes). The UTO option, on the other hand, addresses the *TCP*
user timeout option, which only kicks in when you do send something to
the other end-point, but do not get a TCP *ACK* in, say, two minutes.

So while the UTO option may provide a mechanism for exachanging timeout
values, IMO the semantics of the UTO timeouts are different from the
semantics we need here.

Thanks,

---

From: Mark Andrews <[email-masked]>
Date: Sun, 21 Feb 2010 09:35:53 +1100

> > 	rate - and I am concerned about "impedence" mismatch on timeout

I don't see the speed of light changing in the next 20 years and it is that,
not serialization and queuing delays that dominates round trip times.  We
are at about the best we will get to now.

---

From: [email-masked]
Date: Sun, 21 Feb 2010 12:58:23 +0000

> are at about the best we will get to now.

	clearly you need to catch up on your reading. :)
	20 years ago, the range was 110-64000 ish
	and serialization and queuing delays were predominant.
	and yes, the speed of light was the same then as now.

	today..  12200-1,000,000,000 - (gsm-1g) and looks like
	a somewhat larger spread - meaning serialization and 
	queuing delays will predominate.  same speed of light.

	20 years hence ...  (swag)  active RFID tags (110baud)
	to 100G ... looks like that much wider range of 
	link rates to me and the impedence mismatch will 
	drive up the serialization and queuing delays.
	and yea verily ... the speed of light is almost the 
	same ... **

** www.news.harvard.edu/gazette/1999/02.18/light.html 
** http://www.eurekalert.org/pub_releases/2005-08/epfd-ltt081905.php

--bill

---

From: Brian Dickson <[email-masked]>
Date: Sun, 21 Feb 2010 11:14:35 -0400

>        drive up the serialization and queuing delays.

I beg to differ. ;-)

*30* years ago, i.e. when RFC 793 was written, clock speed was the
dominating factor.
E.g. a PDP-11/20 had a clock speed of 125KHz.

However, 30 years is about 20 doubling intervals per Moore's Law, so
processing power should
be expected to be about 2^20, or 1M, faster.

Since the speed of light in a given medium is a constant, and fibre
and satellite will likely continue
to be used where they are used today, those can be seen as invariant.

Serialization delay is proportional to packet size, and inversely
proportional to link speed.
We're talking about FIN, FIN-ACK, ACK, all minimum packet size (56 B),
so we fix packet size and compare
the impact of link speed alone, vs fixed delay on "c".

To avoid impedance mismatch, it is necessary to accommodate the
longest realistic delay,
rather than the shortest.

At 1M times improvement, clock speed is off the table for being the
problem child.

The worst case for bidirectional paths is likely to include no more
than 1 circuit of the earth
on fibre (~ 200ms), plus up to 4 hops via GEO satellite @ 280ms.
Double for RTT, and you get about 2.6 seconds.

While I sincerely doubt that anyone will be putting an authority
server on an RFID tag, it is conceivable
that one might put a recursive resolver on one, so I'll give you your
110bps rate for serialization delay of about 4 seconds.

So, whether it is 2.6 or 4 seconds, it is still low numbers of seconds.

And if you don't believe in RFID tags doing DNS, then speed of light
*is* the dominating worst-case that needs
to be accommodated.

+1 on negotiating close-wait time, rather than using fixed values.

And, IMHO, a more sensible approach for a resource-starved server,
would be (at relative "defcon" values):
(5) Start by slowing down processing of SYNs
(4) Reap idle TCBs gracefully, starting with those with smallest RTT's observed
(3) Next, presume un-acked SYNs are DOS junk, and start RST'ing those
older than TBD seconds (2.6 or 4 or whatever you think is best for
you)
(2) Reject SYNs (however you want, possibly RST)
(1) ungraceful reaping

... repeat until resources back at reasonable levels, i.e. back down
the DEFCON levels from 1 to 5 as available resources hit appropriate
levels.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Sun, 21 Feb 2010 17:01:25 +0000

> Date: Sun, 21 Feb 2010 11:14:35 -0400
> From: Brian Dickson <[email-masked]>
> ...

if we keep it that way, yes.  some aspects of the dnssec design (precomputed
signatures including negative spans for secure nxdomain) were crafted with an
eye toward protecting the server's CPU.  others like the choice of crypto-alg
were done with an eye toward protecting the client's CPU.  we could easily
have done as the commodity platforms do and assume that all that new CPU is
for us not for our customers, thus using it up on stupid background sh*t and
leaving clock speed on the table as a potential problem child.

see also the differences between internal clock, I/O clock, and memory clock.
fairly often we look at moore's law and say, systems are twice as fast as they
were 18 months ago.  and that's true if you're not doing a lot of memcpy().
but, object oriented garbage collected interpreted thread-safe languages use
so much memory bandwidth for abstraction maintainance that many systems are
no faster even though their "clock speed" suggests that they ought to be.

i'm not taking anything away from your main point.  but this side point needs
clarification lest we forget that there are still hardware issues near "the
table" waiting to land on "the table" and become once again problem children.

> +1 on negotiating close-wait time, rather than using fixed values.

we learned a lot from RTT measurement and sorting when selecting nameservers,
and from RTT estimation for TCP clocking purposes.  it seems to me that this
learning ought to flow back toward session timeout interval selection somehow,
and maybe transaction timeout interval selection also.

> the DEFCON levels from 1 to 5 as available resources hit appropriate

we're (mostly william simpson but others including myself are involved) are
taking a different approach in TCP/CT, which is to include cookies in SYNs
so as to keep TCB's from being created until 3-way, and to allow payloads in
both SYN and SYN/ACK, and do away with RST and FIN-WAIT altogether.  there's
no reason we have to be shackled to the limitations of UDP/53 and TCP/53 for
the full lifetime of the internet.

---

From: William Allen Simpson <[email-masked]>
Date: Sun, 21 Feb 2010 12:39:07 -0500

> E.g. a PDP-11/20 had a clock speed of 125KHz.
Gosh, I don't even remember the clock speed on the Interdata 7/16 and
7/32.  But I disagree that clock speed has much to do with this issue.

> to be used where they are used today, those can be seen as invariant.
Here, we agree.  This is (in part) a speed of light issue.

> rather than the shortest.
Agreed!

> At 1M times improvement, clock speed is off the table for being the
Agreed.

> Double for RTT, and you get about 2.6 seconds.
Here's where we disagree.  The worst case bi-directional path is likely
satellite (or the moon), but multiplied by the IP 255 hop limit.

> So, whether it is 2.6 or 4 seconds, it is still low numbers of seconds.
No, it's 255 times that!  Low number of minutes.

> +1 on negotiating close-wait time, rather than using fixed values.
+2.  But a default value of 2 minutes is a good choice for DNS, and really
cannot be changed without some form of option negotiation....

> (5) Start by slowing down processing of SYNs

I don't understand how this helps, and it adds complexity.

> (4) Reap idle TCBs gracefully, starting with those with smallest RTT's observed

That seems to me to be the first and best plan.

> older than TBD seconds (2.6 or 4 or whatever you think is best for

Since when are these supposed to have a RST?

Besides, we have better ideas for fixing the SYN state problem....

---

From: William Allen Simpson <[email-masked]>
Date: Sun, 21 Feb 2010 12:50:30 -0500

> values, IMO the semantics of the UTO timeouts are different from the
True, that's your design, but the last time I looked at it (a draft),
it said:

    A second use of the TCP User Timeout Option is advertisement of
    shorter-than-default user timeouts. This can allow busy servers to
    explicitly notify their clients that they will maintain the state
    associated with established connections only across short periods of
    disconnection.

That seemed a perfect match for DNS.  But otherwise, we could define
something of the sort as an EDNS0 option, instead.

---

From: William Allen Simpson <[email-masked]>
Date: Sun, 21 Feb 2010 13:16:39 -0500

> the full lifetime of the internet.
Paul and I were writing at the same time.  TCPCT solves a number of these
issues, but we don't even have 2 interoperable implementations yet.  So,
we cannot actually put TCPCT in a BCP yet.  Maybe next year. :-)

---

From: Alex Bligh <[email-masked]>
Date: Sun, 21 Feb 2010 18:51:49 +0000

> satellite (or the moon), but multiplied by the IP 255 hop limit.

You are seriously suggesting that the design constraint should be the
ability to reliably reach an auth server by 255 hops to the moon and back?

Firstly, no one is making UDP optional, so this particular sub-optimal
routing could be supported by UDP.

Secondly, I had thought that if the SYN sender doesn't receive the
ACK within 75 seconds, the connection establishment is aborted. So
paths with an RTT longer than 75 seconds are not going to support
TCP (without tuning) anyway.

Thirdly, if we really want to support queries via the moon 255 times,
all we need to do is to prevent such an early unilateral close by
the server until a reply has been sent.

Let's hope whoever routed this circuit via the moon 255 times didn't
decide putting a NAT in the way was a good idea too, or that would
time out.

Oh, and for completeness, your multiplier is wrong. If I route a circuit
via the moon via frame relay or similar, I could take you to the moon
and back a few hundred times on a single IP layer hop. So why stop at 255?

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Feb 2010 10:54:27 -0500

> *30* years ago, i.e. when RFC 793 was written, clock speed was the

[&c]

This offshoot is interesting, and I don't want at all to discourage
discsussion of the topic.

I do, however, wish to encourage people to change the subject line if
you're not actually responding to the WGLC for the document.  Thanks!

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 22 Feb 2010 16:06:04 -0500

> ability to reliably reach an auth server by 255 hops to the moon and back?
Note: this isn't "reliably reach", this is reliably reject duplicate
and/or misrouted datagrams....

RFC 791:
     Some higher level reliable connection protocols are based on
     assumptions that old duplicate datagrams will not arrive after a
     certain time elapses.  The TTL is a way for such protocols to have
     an assurance that their assumption is met.

I'm suggesting that as TCP was designed and implemented, the moon was a
consideration.  You are old enough to remember moon landings?  You do
know that TCP/IP was originally specified at that time?

> TCP (without tuning) anyway.
Please read RFC 1122:

"In particular, R2 for a SYN segment MUST be set large enough to provide
retransmission of the segment for at least 3 minutes"

> and back a few hundred times on a single IP layer hop. So why stop at 255?
That reading of the DNS over TCP standard is pointless.  Once somebody has
done such silly things, it doesn't work well.

Doing silly things is not a goal, and not worthy of our time here.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 22 Feb 2010 22:20:30 +0000

> know that TCP/IP was originally specified at that time?

Sure, but things move on. Hence, for instance, DTN.

-- 
Alex Bligh

---

From: William Allen Simpson <[email-masked]>
Date: Tue, 23 Feb 2010 11:23:03 -0500

> Sure, but things move on. Hence, for instance, DTN.
Where is the proposed standard that specifies making DNS over TCP
delay tolerant by _shortening_ the timeouts?

---

From: Alex Bligh <[email-masked]>
Date: Tue, 23 Feb 2010 17:45:50 +0000

> delay tolerant by _shortening_ the timeouts?

I meant the right way to do DNS to Mars or whatever (we can argue
about the moon) is not DNS over TCP, but DNS over (e.g.) some other
transport (DTN).

-- 
Alex Bligh

---

From: William Allen Simpson <[email-masked]>
Date: Wed, 24 Feb 2010 13:38:01 -0500

> about the moon) is not DNS over TCP, but DNS over (e.g.) some other
Rather than making up strawman proposals, perhaps you could stick to
the topic at hand?

---

From: Alex Bligh <[email-masked]>
Date: Wed, 24 Feb 2010 18:57:37 +0000

> Rather than making up strawman proposals, perhaps you could stick to

This is relevant to the topic at hand (at least as much as your
objection to it is). You based an objection to the minimum time
to hold a TCP session open prior to unilateral close by a server
on 255 hops to the moon and back. I argue that this is an irrelevant
consideration as this is not a suitable use for TCP+DNS in the first
place; DTN would be suitable transport. You may disagree with me
and think we should be designing DNS over TCP with RTTs of
2 x 255 x 1.26 seconds, which is fine; however, your disagreement
does not make my argument off topic any more than it makes yours
off topic.

I see in the mean time this argument has been punted to the appropriate
TCP group (I'm not clear whether exclusively or not, if so
it seems we are both now off topic).

-- 
Alex Bligh