Homenet Interim Meeting

Friday, April 23, 2021

Chairs: Stephen Farrell, Barbara Stark

AD: Éric Vyncke

Agenda

• Administrivia: Agenda bashing, notes, attendance
• draft-ietf-homenet-front-end-naming-delegation-13: Simple Provisioning of
  Public Names for Residential Networks
• draft-ietf-homenet-naming-architecture-dhc-options-10: DHCPv6 Options for Home
  Network Naming Authority
• Where to go from here

Administrivia: Agenda bashing, notes, attendance

Chair Slides

Do stub network discussion in another interim at late May. Ted will start discussion on mail list to get some momentum before the call.

DNS Outsourcing Infrastructure (Daniel)

Slides: DNS Outsourcing Infrastructure

Éric (no hat): Maybe not include DoH because it doesn't support transfer option?

Ted: Agrees

Daniel: OK

Ted: Has anyone implemented?

Daniel: Yes. Ray implemented.

Michael: I ran Ray's code. I want to create different client implementation but haven't yet.

Ted: So, Michael, you believe it works?

Michael: Yes.

Ted: In Figure 1 chart -- this is a bit hard to read. You don't mention that IN ADDR zone can also be done this way. Also, it's not clear what relationship is between home network zone and HNA.

Michael: We can add these by making figure taller. And add lines to connect components appropriately.

(Carsten, in chat): Make that a separate diagram

Ted: What about user ability to redact things they don't want public?

Michael: The idea is that this would be opt in (so no need to redact, a priori). The convenience is they don't have to copy IP addresses and when IP addresses change, they get updated. I would also expect it to filter out privacy addresses.

Daniel: I think we're discussing those points in the draft. But if there is more, we're happy to have those.

Ted: I was asking because in diagram you only mention public homenet zone and not private. But diagram is already complicated.

Michael: I'm not opposed to discussing the private zone but am worried it would actually increase confusion.

Ted: Yes, I agree that managing the private zone would be out of scope for this doc.

Michael: If we put private zone in box by itself and show it is unconnected to all, would that be ok?

Ted: What I'm really trying to call your attention to is that devices in the LAN won't always be querying the public homenet zone. They'll likely query private homenet zone. And public is subset of private and gets updated from private?

Daniel: I get your point. I think that's feasible. We'll see what we can put in diagram. I think there is also text on that.

Ted: And temporary addresses aren't advertised, so you won't see those.

Stuart: That's right. They aren't published as addresses for inbound.

Ted: So no need to filter.

Michael: I was thinking that if they showed up, we would filter.

Ted: But how would you know?

Michael: Good point. But there are some patterns that we recognize. Like LLA and ULA.

Daniel: Does mDNS use any other non-private IP?

Ted: mDNS will always use LLA. It does also use ULA. So filtering of ULA is relevant.

Ted: You never say what HNA is in DHCP document. You should include that.

Stephen: Should we discuss what to do about WGLC?

Daniel: We can.

Stephen: Other technical comments, first?

Erik Kline (from chat): What is the auth story here?

Daniel: We had long list of authors for historical reasons.

Michael: Author or authentication?

Erik (from chat): Authentication

Michael: People want to be able to go to 3rd parties. By having blob that can be copied and pasted, we're making it possible to avoid typos. But ther is also OAUTH possibility. This is all configuration, but also explicit authorization. Then we expect this to be validated in TLS. So synchronization channel is DNS over TLS. Ray convinced us this was easier to do over DNS.

Erik: How does ISP trust the homenet to do the update?

Michael: There is the zone transfer. The better question is how the homenet trusts the ISP to do the AXFR. That is all set up in the synchronization channel. Certificate is provided then.

Barbara (no hat): Should you have IANA considerations for the various transport options (DoT, Do53, etc.)?

Michael/Daniel: We'll look at that.

Ted: And you should only list the ones you want used. If you don't want Do53 used, you shouldn't list that either.

Daniel: Not a problem to add. Should we go for specification required? I used 2 bytes.

Ted: Specification required should be ok, since you do want people to document what they're doing.

Stephen: Other technical comments? Hearing none, we will go on to process.

Stephen: How many people have read this? Please reply in chat. / There were 2 yes and 2 partial/quick scan.

Stephen: How many people will review? / 3 people.

Stephen: Does anyone think this would be a bad idea? / There was no-one who said anything.

Éric: When you issue WGLC in homenet, you could copy DPRIVE and INTAREA and the INT area directorate for DNS and DHC for DHCP options.

Stephen: Then we will let Eric use his influence to get additional review and go forward with WGLC?

Daniel: We'll update the document. Expect that in next few days. But I don't think that will impact WGLC.

Stephen: We don't want update after WGLC starts.

Daniel: Then wait a week for update and start WGLC.

Closing Remarks

Stephen: Stub resolver discussion noted in intro.

Ted: And I will update the draft.

Blue Sheets

1. Erik Kline, Google
2. Stephen Farrell, Trinity College Dublin
3. John Border, Hughes
4. Carsten Bormann, TZI
5. Ted Lemon, Apple
6. Stuart Cheshire, Apple
7. Éric Vyncke, Cisco
8. Chris Box, BT
9. Michael Richardson, Sandelman Software Works
10. Barbara Stark, AT&T
11. Daniel Migault Ericsson
12. Oliver Borchert, NIST
13. Rongli Sun, Google
14. Suvesh Pratapa
15. Martin Turon
16. David Millman
17. Kazunori Fujiwara, JPRS
18. John Border
19. Ray Hunter