Re: [Dots] Tsvart last call review of draft-ietf-dots-server-discovery-11

[Kyle Rose <[e-mail]>]

On Tue, Oct 13, 2020 at 4:28 AM <[e-mail]> wrote:
> > * Section 4 says:
> >
> >    The discovery method is reiterated by a DOTS agent upon the
> > following
> >    events:
> >
> >    o  Expiry of a a validity timer (e.g., DHCP lease, DNS TTL)
> >       associated with a discovered DOTS agent.
> >
> > >From my reading, rendezvous information for the DOTS server is
> > "pushed"
> > >to the
> > client via DHCP, so it's not clear the above is actionable. Is it
> > simply the case that a client should use the DOTS server assigned in
> > the most recent lease?
> >
>
> [Med] The intent is to avoid using "stale" servers. So yes, this is about using the server that was most recently discovered but also about not using a server beyond a validity time associated with the discovered server.

I think the wording for this requirement should be normative rather
than buried in the description of the discovery mechanism. Adding a
statement somewhere that "a DOTS agent MUST NOT initiate or continue
communicating with a server whose associated discovery metadata has
expired: for instance, once a DNS TTL or DHCP lease has expired, an
appropriate DOTS server must be rediscovered using one of the
mechanisms in {}."

> > Using DHCP, an inherently insecure protocol, to inform DOTS clients
> > of the hostname of DOTS server knocks this third leg out, calling
> > into question the entire mechanism.
>
> [Med] We didn't include such discussion as this is a variation of agent impersonation (covered by the pointer to RFC8811) and rogue servers in RFC8415. Also, we have the following:
>
>    This document assumes that security credentials to authenticate DOTS
>    server(s) are provisioned to a DOTS client using a mechanism such as
>    (but not limited to) those discussed in [RFC8572] ...
>
> We can add some text to elaborate on this further.

No, I think this is fine as-is. I think I just missed these references to 8572.

> > Is the final label zero-length?
>
> [Med] Yes, as indicated in 5.2.1:
>
>    o  Peer DOTS agent name: The domain name of the peer DOTS agent.
>       This field is formatted as specified in Section 10 of [RFC8415].
>
>  Other parts of the DHCPv4 protocol
> > terminate domain names with a zero-length label. What if a zero-
> > length label appears in some s_i other than the final one?
> >
>
> [Med] Names are validated as per the rules in Section 10 of RFC8415:
>
>    If the DHCP client receives OPTION_V4_DOTS_RI only, but
>    OPTION_V4_DOTS_RI option contains more than one name, as
>    distinguished by the presence of multiple root labels, the DHCP
>    client MUST use only the first name.  Once the name is validated
>    (Section 10 of [RFC8415]), the name is passed to a name resolution
>    library.

Got it. It's a roundabout way of saying "ignore everything after the
first zero-length label". I'm guessing this is well-understood by the
DNS community.

> > RFC 6763 says that an empty TXT record MUST be included alongside
> > the SRV record where DNS-SD is concerned. Should normative language
> > be used here, or should we rely on the normative reference in case
> > that guidance changes in the future?
>
> [Med] I don't think that the use of normative language is needed here. RFC6763 is sufficient by its own.

Sounds good.

Thanks for the follow-up. My apologies for the delay in responding.

Kyle