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

[David Schinazi <[e-mail]>]

Hi Tom,

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


When you say that the server shouldn't accept the second connection, how
does the server know that the new connection comes from the same client?
Unless you're using TLS client certificates, you have no way of
differentiating clients because of NAT. Or am I missing something?

Thanks,
David


On Thu, Jul 11, 2019 at 4:40 PM Stuart Cheshire <[e-mail]> wrote:

> On 11 Jul 2019, at 14:46, Tom Pusateri <[e-mail]> wrote:
>
> > 1. CLIENT receives SUBSCRIBE from server
> > 3. CLIENT receives PUSH with no change notifications
> > 4. CLIENT receives PUSH notification with ‘collective remove’ TTL and
> non-zero RDLEN
> > 5. CLIENT receives PUSH notification with DNS message length larger than
> 16k
> > 6. CLIENT receives UNSUBSCRIBE from SERVER
>
> Reviewing the list above, I realize that we state explicitly that
> SUBSCRIBE and UNSUBSCRIBE sent from server are both invalid. But we don’t
> enumerate the other bogus message directions.
>
> I have added some clarifying text around this, and will submit an updated
> draft once they open for submissions again. Not that it was every really
> unclear, but it doesn’t hurt to be abundantly unambiguous. I have added:
>
> A server MUST NOT send a RECONFIRM message.
> A client MUST NOT send a SUBSCRIBE response.
> A client MUST NOT send a PUSH message.
>
> All three are fatal errors of the “this should never ever happen” variety.
>
> Stuart Cheshire
>
>