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

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

Paul Vixie wrote:

> any server-initiated close that isn't FIN or isn't timeout-based
> would be a protocol change not a clarification, ...

+1

In particular: a protocol change for TCP, not DNS !

>        ... and subject to stronger review here.

Not only *here*, go through the purgatory of TCPM!  :-)

> 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.

+1

Misconception of RST unfortunately is widespread.

Some explanations (only a sketch!) might help to inform the uninitiated:

Who's in doubt about the purpose of RST: please visit Section 3.4
of RFC 793.

RST, per the standard, is only sent in response to an inbound TCP
segment that the recipient cannot handle due to lack of matching
connection state, and to indicate to the sender of that segment
that there's something seriously wrong.
RST is never to be sent spontaneously, since that could only happen
if the sender has (full) connection state.

Roughly speaking, two conditions exist for RST to be sent, per RFC 793:

a)  During connection setup (connection not yet established!),
    when the recipient of a segment can derive from the lack of
    SYN that the peer is out of synch in the state machines
    (old duplicate connection problem);

b)  If the recipient has *no* connection state (unless it maintains
    a passive OPEN -- he is "listening" on the destination port --
    and the inbound segment is a pure SYN segment).

These rules are purposely crafted to exclude states incurring the risk
of with potential race conditions related to packets in the network,
in these case delays are inserted by the TCP state machines to allow
delayed packets to leave the network (TIME-WAIT state, in particular).

RFC 793 (on page 36) clearly says:

| Reset Generation
|
|   As a general rule, reset (RST) must be sent whenever a segment arrives
|   which apparently is not intended for the current connection.  A reset
|   must not be sent if it is not clear that this is the case.

Note that the text predates RFC 2119, and all normative language
conceptionally needs to be upcased in order to arrive at the
contemporary IETF style.

BCP 60, RFC 3360, addresses another kind of abuse of RST; listeners
to this list, in particular implementers, might be interested in
Sally Floyd's presentation of the history and purpose of RST
contained in that RFC.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| 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: Fernando Gont <[email-masked]>
Date: Thu, 18 Feb 2010 17:35:29 -0300

Hi,

As is usually the case, Alfred is right with his analysis (which is not
a surprise coming from one of the few human-beings alive having read all
or most the entire RFC series! :-) ).

However, there seems to be ambiguity/contradiction in RFC 793 between
all the text that Alfred quoted, and the description of the ABORT call.
So I believe that spec-wise, it'd be within the spec to tear down
connections by issuing an ABORT procedure call.

There are other instances of RST generation (kindly pointed out by
Alfred off-list, and described in the CPNI TCP paper) that clearly are
outdated (e.g., RFC 793 mandates generation of an RST if the security
level, or compartment, or precedence doesn't much that of the connection).

Clearly, the state of affairs of TCP spec-wise is not what one would
expect. There's quite a bit that is missing, and quite a bit does is
outdated. -- Not to mention the stuff that is buried deep into the
document, and that does not respect today's principle of least surprise
(as the aforementioned security level/precedence issue above).

Thanks,
Fernando

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

---

From: Nicholas Weaver <[email-masked]>
Date: Sun, 21 Feb 2010 12:07:04 -0800

> In particular: a protocol change for TCP, not DNS !

That protocol change has already happened for HTTP:  Both web clients and web servers are very aggressive in closing connections with RST instead of FIN, particularly IIS and IE:

Please see
Martin Arlitt and Carey Williamson. An Analysis of TCP Reset Behaviour on the Internet. 
SIGCOMM Comput. Commun. Rev., 35(1):37–44, 2005.

RST for terminating connections (especially in something like DNS or HTTP where the server won't be able to reply to any more requested data ANYWAY and is closing connections to free state, so half-open connections are rather meaningless) is accepted practice these days on the HTTP side, regardless of what the RFCs say for RST's semantics.

---

From: "George Barwood" <[email-masked]>
Date: Mon, 22 Feb 2010 16:20:57 -0000

----- Original Message ----- 
From: "Nicholas Weaver" <[email-masked]>

> That protocol change has already happened for HTTP:  Both web clients and web servers are very aggressive in closing connections with RST instead of FIN, particularly IIS and IE

I notice that Microsoft TCP implementations appear to go to TIME_WAIT state rather than CLOSED on reception of a RST,
contrary to the standard, AFAICS. This does seem to make some sense though.

I can see that the use of RST is doubtful. Even if no activity has been seen by the server for 2 minutes, that doesn't mean
the client might not have just sent a packet, and therefore a subsequent connection could in theory re-use sequence numbers,
with unpredictable results.

However, with the "standard" ( increment every 4 microsecond) method of generating initial sequence
numbers, it seems unlikely that there would be a problem in practice, given that DNS queries are low bandwidth.

Also,  since a DNS query will always fit in a single packet, and the DNS client will validate the question
when processing the response, it may be hard to get a real problem.

I'm left with an uneasy feeling though, and theory and practice seem to be diverging in a slightly alarming way.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 22 Feb 2010 17:47:19 +0000

> From: "George Barwood" <[email-masked]>
> Date: Mon, 22 Feb 2010 16:20:57 -0000
> 
> > That protocol change has already happened for HTTP: Both web clients
> > and web servers are very aggressive in closing connections with RST
> > instead of FIN, particularly IIS and IE
> 
> I notice that Microsoft TCP implementations appear to go to TIME_WAIT
> state rather than CLOSED on reception of a RST, contrary to the standard,
> AFAICS. This does seem to make some sense though.

that's because when other people start bending the standard, then everybody
else has to bend it back.  sort of makes me wish that first movers wouldn't.

> I can see that the use of RST is doubtful. Even if no activity has been
> seen by the server for 2 minutes, that doesn't mean the client might not
> have just sent a packet, and therefore a subsequent connection could in
> theory re-use sequence numbers, with unpredictable results.

not only that, RST is dangerous in its own right, and some implementations
just ignore it.  you don't have to have the right sequence number, so all
you have to know is the initiator's port number (one of about 60000), both
ip addresses, and the constant "53", in order to spoof-close a connection.
(bgp routers can put MD5 into the TCP header, so that bgp sessions won't be
subject to this trivial denial-of-service attack.)

this is why TCP/CT does away with RST and supports trusted unilateral FIN.
in other words, rather than misuse RST, william is fixing FIN so that there
is no longer any reason to misuse, or even to have, RST.

> Also, since a DNS query will always fit in a single packet, and the DNS
> client will validate the question when processing the response, it may be
> hard to get a real problem.

updates do not always fit in a single packet.  not all of dns is in QUERY.
and i can imagine SIG(0) where multiple keys are in use, not fitting in a
single packet, even for QUERY.  let's not simplify our assumptions into the
realm of absurdity.

> be diverging in a slightly alarming way.

+1.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 22 Feb 2010 12:16:57 -0800

> subject to this trivial denial-of-service attack.)

Actually, the spec says "in window", and a lot of stacks only accept direct in sequence RSTs, to prevent this issue from occuring.

The BGP routers also use the TTL 256 trick as well.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 22 Feb 2010 16:09:25 -0500

After consuting with our AD the chairs have decided to take the TCP 
details questions off the table in this working group and ask
the Transport AD's to help us get expert answers.

Thus the quesions in section 5 are not part of the working group
last call i.e.
	How long to keep socket open ?
and	What are acceptable/preferred ways for server to close 	
         connection prematurely.

Thus the question on the table is simplified to:
	Do the members of the working group think this document,
	that specifies that TCP transport must be supported by all DNS
	implementation is beneficial?

Once this question is answered in the positive, formal advice will
be requested, the chairs will notify working group in advance as to 
where that discussion will take place.

Once we get advice on recommendations to put in section 5 the document 
will be updated and submitted for IETF Last Call after short review by
this working group.

	Olafur

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 22 Feb 2010 13:25:22 -0800

>        implementation is beneficial?

"all DNS implementations", no; "all *general purpose* DNS implementations", yes.

---

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

> 	implementation is beneficial?

Yes, though the carve out currently in the document is OK.

-- 
Alex Bligh

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Feb 2010 19:34:55 -0300

>     implementation is beneficial?

Yes. And it should be published asap.

But I don't get it. Why don't we ship the I-D as is? It does what it is
supposed to do, already. Leave the advice on what to do with TCP (how to
"tune" it for DNS) for another *separe* I-D.

This I-D is very well withIn the wg charter. Do we really need to
wait/depend from other areas WGs?

Thanks,

---

From: Edward Lewis <[email-masked]>
Date: Mon, 22 Feb 2010 17:06:11 -0600

>"all DNS implementations", no; "all *general purpose* DNS 

Yes, "general purpose".

"General purpose DNS implementations" - means "DNS implementations 
released with NO INTENTION of being scoped for only a particular use 
case or set of use cases."

The "intention" clause is used to cover the fact that "no one really 
knows the future."

(Although I still don't know how the IETF can require anyone do 
anything without declaring a protocol police force.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 22 Feb 2010 23:53:46 +0000

+1.

> Date: Mon, 22 Feb 2010 13:25:22 -0800
> From: Matthew Dempsky <[email-masked]>
> 

i think this horse is dead.  rbldnsd and other non-general-purpose subset
implementations already leave out so many required elements of the protocol,
that adding one more required element that these don't implement, is no big
deal.  can we please move on.