DNSSD WG Agenda IETF95, Buenos Aires Monday 4th April 2016 3.50pm - 5.20pm local time Chairs’ Introduction Tim: Focus will be on first three docs and WG last calls; also have threats doc and privacy doc to consider Chairs, 5 mins ===== Discussion: WGLC of Hybrid Unicast/Multicast DNS-Based Service Discovery Stuart Cheshire, 25 mins draft-ietf-dnssd-hybrid-03 https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03 Stuart summarized the last call comments... From Tim Chown: editorial improvements not possible to build NSEC next record relations From Ray Hunter: moving devices appear to be new devices concerned that multicast packets might cause multicast storms; multicast is not forwarded so storms can't happen Stuart to add ASCII art diagram to show how unicast is used to contact hybrid-proxy server From Ted Lemon: Abstract too long "Stitching" document needed Push DNS updates to a central repository - client driven - quiet in steady state rich-text names domain delegation - enterprise/managed scenario not a problem Mention ULAs - forwarded inappropriately TTL=0 for all responses? if using DNS rather than mDNS, use TTL=0 because it's unicast; however, TTL=0 suppresses caching and might have a performance impact allow resolution of .local names on other links; i.e., could this technique be used to extend the mDNS query to other links. Not an issue; not how hybrid proxy works change notifications? Why not polling? continuous polling OK on enterprise network don't repeat zone apex discovery here - SOA should be incremented From Marcus Stenberg: proxy can have up to date cache and can do duplicate query suppression; remote device may not TTL limiting - max, min Doc doesn't describe having a device actively doing mDNS then pushing results using DNS update Multicast DNS link stitching requested Long discussion ensued; perhaps can do DNS update and mDNS update in hybrid proxy as authoritative server Ted Lemon: Similar discussion prior to the dnssd WG meeting; I'll offer to write a draft describing the interaction between DNS update and hybrid-proxy Dave Thaler: do not proxy any zones that also get DNS updates SC: this mechanism deals with the devices we have today; at one point, I thought DNS update might be implemented TL: this mechanism is not good for homenet because of the tie-in with network topology SC: there might be a solution using a whitelist Dave Thaler: mDNS names could be disambiguated from others through zones TL: same name in different zones is bad for UI DT: hybrid-proxy is authoritative server for zone; can also do DNS update with appropriate merge logic From Ralph Droms: unnecessary queries; text unclear From Dave Thaler: typo fixes multiple per link - yes? punycode unicast query translated to UTF-8? DDoS words DT discussion: "yes" to translation RD: ULAs? Link-scoped addresses? SC: Link-scoped addresses already ruled out. ULAs will take configuration. TL: homenet will recommend ULAs because upstream addresses may not be stable. TC: operational BCP may be needed SC: hybrid-proxy is a building block; may need some additional work for homenet Resolution: Authors will edit draft-ietf-dnssd-hybrid-03 according to that input and publish rev -04. Next step will be to decide with Terry whether another WG last call will be needed to review -04 for completeness and submit the draft to the IESG for publication. ===== Discussion: Next Steps for DNS Push Notifications Tom Pusateri, 15 min draft-ietf-dnssd-push-07 https://tools.ietf.org/html/draft-ietf-dnssd-push-07 Tom reviewed changes to doc since last IETF; see slides for updates... TL: should aovid special cases; doc should mandate keepalive Andrew Sullivan: Shouldn't reinvent what dnsop has just done SC: dnsop doc in RFC Editor 48 hour is "time to die" not "keepalive" AS: dnsop doc gives server a mechanism to inform the client about how long the server is willing to keep the session up Shane Kerr: what is motivation to keep session open? SC: reason is to avoid polling; built in to mDNS; we need a similar mechanism for unicast DNS SK: keepalive replaces polling with keepalive? DT: difference is notification comes immediately, not just at poll time SC: keepalive allows server to garbage collect terminated sessions DT: has a strong preference for doing keepalive at DNS layer, not TCP layer Wes Hardaker: polling message doesn't preclude push notification; i.e., use a query over the session as a keepalive TL: Have server send keepalive or "something" which will cause TCP session to die TP: What message? TL: Could be new "null" message; if client implements this spec, client will know how to process new message type TP: Issue - server needs to send FIN before closing connection to flush remaining data; if client sends RST, server won't need to flush data Bernie Volz: probably difficult to enforce through socket interface; it's a well-know problem in the web space TC: do you have implementation feedback? TP: Stuart has gotten some Resolution: need a -08 Authors to refactor document to separate TCP session management from push notifications. TCP session management to go to dnsop WG. Normative references to drafts? Update to how to close the TCP connection ===== Discussion: WGLC of On Interoperation of Labels between DNS and Other Resolution Systems Andrew Sullivan, 10 mins draft-ietf-dnssd-mdns-dns-interop-02 https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-02 DT (jabber discussion): automatic handling of UTF-8; client has a theory about where to use UTF-8; do that (which is already covered in the draft) TC: ready to push forward unless there are objections TL: looks very good, ready to go; hope I didn't miss anything DT: Technical parts good; needs editorial clarifications about "what the problem is" TC: A small update to help it through the IESG process? Resolution: Andrew to work with DT to clarify the problem statement; any other comments should be posted to mailing list; ready for IESG after next revision ===== Discussion: -03 version of Scalable DNS-SD (SSD) Threats Hosnieh Rafiee, 10 mins draft-otis-dnssd-scalable-dns-sd-threats-03 https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-03 Skipped due to time constraints ===== Discussion: New draft: Privacy Extensions for DNS-SD Christian Huitema, 10 mins draft-huitema-dnssd-privacy-00 https://tools.ietf.org/html/draft-huitema-dnssd-privacy-00 Christian: mDNS is huge privacy leak due to advertisements and can be used for identification TL: does a device really want to advertise its services on a network it "doesn't know"? CH: remaining silent preserves privacy but limits utility TL: devices introduce each other "at home" SC: work needs to be done; perhaps mobile devices shouldn't be advertising services at all? TC: this work is not currently in charter; chairs to ask AD about adding when WG recharters Dan York: what are thoughts around key distribution CH: Lots of existing technologies; tend to be peer-to-peer TP: When one plugs a phone into a computer, user is asked "do you want to trust this computer"; when selecting a WiFi network, there is an implicit "trust" CH: lots of scenarios in which private use of untrusted network would be useful Resolution: WG thinks this is useful work Question to AD: can we take on this work? ===== Discussion on next steps for handling dnssd threat/privacy issues Which issues matter? Are they operational or are any protocol-specific issues? Should we merge the two drafts? ===== Summary: SC to produce -04 rev of his draft; chairs to consult with Terry about another WG last call "Push notifications" document needs additional discussion and revision to account for discussion of session management from meeting AS and DT to edit label interop draft before submitting to IESG without another WG last call WG interested in privacy work; discussion to continue on the mailing list Hybrid proxy and label interop about ready to publish, WG to discuss rechartering for: * Operational and scenario practices hybrid-proxy and other building blocks * Privacy * Coexistence of DNS update and hybrid-proxy * Threats document