Re: [Dots] AD review of draft-ietf-dots-server-discovery-10

[Benjamin Kaduk <[e-mail]>]

Hi Jon,

Thanks for ths implementation insight (I reply to the original message that
has the complete list of mechanisms you implemented, presumably in priority
order).

A few notes inline.

On Mon, Sep 21, 2020 at 10:51:27AM +0100, Jon Shallow wrote:
> Hi Ben,
> 
> > -----Original Message-----
> > From: Dots [mailto: [e-mail]] On Behalf Of
> > Benjamin Kaduk
> > Sent: 18 September 2020 21:22
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [Dots] AD review of draft-ietf-dots-server-discovery-10
> 
> Thanks for this,
> 
> I have implemented this (for both DOTS client r and Call Home DOTS server)
> as
> IP-Address
> Domain
> DHCP
> S-NAPTR
> DNS-SD
> And one or more of these can be defined, so providing a search order.
> 
> I will try to address the more technical comments that you raised as some of
> these may have been triggered by doing the above work.  For the sake of
> brevity, I am skipping over the nits which can be addressed by the authors.
> 
> > 
> >    o  Expiry of a lease associated with a discovered DOTS agent.
> > 
> > Is this specifically a DHCP lease, or a more generic concept?
> 
> Interesting question - DNS has a TTL - should we be enforcing a refresh here
> as well?
> - my implementation does not do this at present

I see Med added mention of TTL in the staged changes, which helps clue in
the reader.  I don't know whether we specifically need to mandate a
refresh, since that is probably covered by the core DNS specs (not that
they are an easy read to digest...)

> >       Let's consider that the DOTS server is reachable at
> >       2001:db8:122:300::1 while the Call Home DOTS client is reachable
> >       at 2001:db8:122:300::2.  The DHCP server will then return one DOTS
> >       reference identifier and a list that includes both
> >       2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP
> >       client.  That list is passed to the DOTS client (or Call Home DOTS
> >       server) which will try to establish connections to the addresses
> >       of that list and destination port number TBD1 (or TBD2).  As a
> >       result, the DOTS client (or Call Home DOTS server) will select
> >       2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server (or
> >       Call Home DOTS client).
> > 
> > I mostly expect pushback from TSV-area reviewers about giving the
> > allocated port numbers such importance in selecting the peer address to
> > use.
> 
> We do need a method for differentiation between whether the address is for a
> DOTS server or Call Home Dots client.

Definitely.  They tend to try to push people to use a dynamic
port-discovery mechanism and avoid assuming that a registered port is used
for the registered use, but I don't have great insight into the specific
considerations there, so we may have to wait and see.

> > Section 5.1.3
> > 
> >    are used to reach the peer DOTS agent.  In other words, the name
> >    conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying
> >    resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a
> >    response.
> > 
> > I'm not sure how much of this needs to end up in the document itself,
> > but can we walk through the scenarios here, especially when the
> > DNS-resolution addresses for the name in question differ from the
> > addresses in OPTION_V6_DOTS_ADDRESS?  I don't understand yet why/how
> > this scheme ends up being safe, and am hoping that you have a head start
> > over me on doing the analysis :)
> 
> I don't immediately recall the rational for this, but if both are returned
> there needs to be a preference for one of them and  think that
> OPTION_V6_DOTS_ADDRESS is the priority.  It is conceivable that the
> OPTION_V6_DOTS_RI, when resolved, may point to an address that is not in the
> local domain (i.e. traffic needs to go via a DOTS gateway rather than direct
> to a DOTS server).
> 
> >    If the DHCP client receives OPTION_V6_DOTS_RI only, but
> >    OPTION_V6_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
> > 
> > Is there a reason to make this "use the first one" vs. "ignore the whole
> > thing as malformed?
> 
> 5.1.1. implies that that there can only be a singular dots-agent-name, so I
> would go for "ignore the whole thing as malformed" (but raise an alert that
> there is a misconfiguration).

Med noted that rejecting it would prevent receiving the requested service.
This is hopefully an exceptional case, so presumably would not matter too
much, and is just a tradeoff on strict compliance vs runtime resiliance
(roughly speaking, the Postel principle).

> > 
> > Section 5.2.3
> > 
> >    To discover a peer DOTS agent, the DHCPv4 client MUST include both
> >    OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter
> > Request
> >    List Option [RFC2132].
> > 
> > Why is the v4 case a MUST but the v6 case was only MAY?
> 
> I think that this was down to NAT being more likely in V4, and so the IP
> addresses take preference over the domain name returned.  That said, I guess
> V6 could be a MUST as well.
> 
> I do recall that I had issues with the DHCP client (Centos) for V4 - where I
> could not just ask for these options and get back a sensible response -
> there was an inherent assumption that it would normally be used for getting
> the DHCP IP/Name etc for the requesting interface, not for just requesting
> the information of some remote object.  This was not an issue for V6.  It
> maybe that I had to provide both options for it to work - I need to go back
> and test this out at some point.
> 
> > 
> > Section 6
> > 
> >    1.  A DNS domain name is retrieved for each combination of interface
> >        and address family.  A DOTS agent has to determine the domain in
> >        which it is located relying on dynamic means such as DHCP
> >        (Section 5) . [...]
> > 
> > Hmm, this may be worth a closer look.  If I understand correctly, if the
> > procedures in Section 5 only give you a name, you're supposed to use DNS
> > to get IP addresses to talk to, from that name.  So is this procedure
> > only applicable when the A/AAAA lookup fails?  Otherwise I'm not sure
> > how you would get only a name but not full contact information, from the
> > section 5 procedure.  Or, if the intent of "the name is passed to a name
> > resolution library" in Section 5 is to induce the S-NAPTR lookups
> > defined here, Section 5 should be more clear about that.
> 
> My understanding was that we need to start with a seed domain that needs to
> be 'acquired' from somewhere.  The standard domain that is allocated to a
> device may not be the same domain that handles the DOTS S-NAPTR - hence
> OPTION_V(4|6)_DOTS_RI responses can be used to get the DOTS relevant domain.
> 
> > 
> >    a.example.net.
> >    IN AAAA  2001:db8::1
> > 
> > I'm sure my INT-area colleagues will appreciate the IPv6 examples :)
> 
> I firmed up on the final version of this after many failing attempts to get
> things right and working!

Thanks again,

Ben