On Tue, Oct 13, 2020 at 4:28 AM <mohamed.boucadair@xxxxxxxxxx> 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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
