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

[Tom Pusateri <[e-mail]>]

> On Jul 11, 2019, at 8:32 PM, Ted Lemon <[e-mail]> wrote:
> 
> On Jul 11, 2019, at 7:39 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> 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.

Tom