Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"

[Toke Høiland-Jørgensen <[e-mail]>]

David Schinazi <[e-mail]> writes:

> Hi everyone,
>
> This email starts a three-week adoption call for
> draft-sctl-service-registration
> <https://tools.ietf.org/html/draft-sctl-service-registration> .

I provided some comments on the -00 of this draft back in October[0].
The -01 version addresses one of them (related to how to specify the
TTL), but the others are still relevant, I think.

I don't believe these comments should block adoption, but I figured this
would be a good time to repeat them, since I received exactly zero (0)
responses on my previous email... :)

Relevant parts of the previous comments below:

- It is not clear how to find the server to register with: Section 2
  refers to RFC2136 and RFC3007 for the DNS Update mechanism, and to
  RFC6763 Section 11 for information on how to discover the zones to
  attempt registration in. So from my best reading of this, the client
  should discover the relevant zones, then just send its signed updates
  to any authoritative server for those zones. However, this prevents
  implementing the registration logic as a proxy (as I'm currently
  doing). So I feel like there should be a SRV lookup in there
  somewhere? I seem to recall Stuart telling me that this is indeed
  specified somewhere, but my google fu is failing me right now, and in
  any case it's not clear from the draft how this process is supposed to
  work.

- Address-based ACLs: Obviously, in most cases a client should only be
  able to perform registration if it is actually on the right network.
  Firewalling off the ports from outside the relevant networks is a way
  to ensure this, but it is somewhat of a crude tool. For one, it
  prevents a single registration server / proxy from serving multiple
  networks[1]. For another, it prevents a use case where a client is only
  allowed *initial* registration (when the key is first cached) from
  inside the network, but is allowed to subsequently update the same
  record from anywhere. This is useful to, for instance, have my laptop
  maintain my-laptop.myhome.example.org even when visiting another
  network.

  So another way to ensure this source verification is needed, I think.
  The way I implemented it is to have the registration server only speak
  TCP; that way, source address spoofing is not possible (as that would
  make the handshake fail), and the server can simply implement a
  straight-forward ACL policy.


- It is not quite clear to me whether the sleep proxy described in
  section 4 is an optional feature or if its meant to be mandatory.
  Stuart explained its usefulness for devices that power off when not in
  use, requiring this function will mean that registration servers will
  need to be on the local link, which is somewhat limiting. Also, the
  implementation complexity goes way up (I certainly don't plan to
  implement this feature :)). So I think having a way for the server to
  signal "no, I can't perform sleep proxying" to the client would be
  good to allow things to fail in a graceful way.


-Toke

[0] https://mailarchive.ietf.org/arch/msg/dnssd/n1H-OGDx8BioVqjTuDTz6jmUmoo

[1] I'll add that since the -01 draft now says that the update should
    always be for .local, how is a registration server supposed to know
    which domain a client wants to register in? By source address only?