Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20

Tom Pusateri <> Fri, 12 July 2019 00:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AC1C1200C7; Thu, 11 Jul 2019 17:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2vod9HmUH1Xk; Thu, 11 Jul 2019 17:56:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75CC3120086; Thu, 11 Jul 2019 17:56:27 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 261C3347FA; Thu, 11 Jul 2019 20:56:26 -0400 (EDT)
From: Tom Pusateri <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_29554589-F267-44E4-95C1-ACC0BD02656F"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\))
Date: Thu, 11 Jul 2019 20:56:25 -0400
In-Reply-To: <>
Cc: Stuart Cheshire <>, Eric Rescorla <>, DNSSD <>,, David Schinazi <>, Robert Sparks <>
To: Ted Lemon <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3564)
Archived-At: <>
Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Jul 2019 00:56:31 -0000

> On Jul 11, 2019, at 8:32 PM, Ted Lemon <> wrote:
> On Jul 11, 2019, at 7:39 PM, Tom Pusateri < <>> wrote:
>> There is no back to back reconnect in the #2 case. The server shouldn’t accept the connection after sending a RETRY DELAY to this client. The client may ignore the RETRY DELAY but this doesn’t matter. It’s only a courtesy that the SERVER tells the client how long it has to wait.
> I don’t know how the server refuses connections on a per-client basis.   We certainly don’t describe how to do that in the DSO RFC.  Practically speaking, unless the server is maintaining a list of all the clients that connect to it, it has no idea that client X that it just dropped is client Y that just connected.   Even if it does maintain such a list, it would be unusual for that to allow it to actually drop the connection immediately.   And supposing it does, that might just make the client reconnect a bit faster.   That is, if the SYN gets an RST in response, the client will just get -1 from connect() and call connect() again unless it has some kind of backoff strategy.

What is the point of the server sending a RETRY DELAY TLV if it isn’t going to enforce it?

The purpose of the RETRY DELAY TLV isn’t to say please be nice and wait.

It’s to say, I’ve put this filter in place that I am enforcing for this period of time. You might as well wait until you try to connect again because it won’t do any good to try before the timer expires.

So, yes, you have to keep state when you send a RETRY DELAY. When the timer fires, you remove the filter and allow the connection to proceed. You have state for the current connections and you have state for the RETRY DELAY timers you have running. SYN attacks happen and those are dealt with like any other SYN attack.

As for NAT, you’re going to block everyone coming from the same address. You should use IPv6 if you’re remote and don’t want to get blocked because of a bad actor.

If you don’t filter, you might was well not send a RETRY DELAY because the clients you’re trying to throttle are the ones that are going to ignore it.