2020-04-20 IETF homenet WG interim meeting ===================================== Logistics: ========== Webex details: https://ietf.webex.com/ietf/j.php?MTID=mab3e771a8ed42ba6b338bc316524a757 Jabber room: xmpp:homenet@jabber.ietf.org?join etherpad: https://etherpad.ietf.org/p/notes-20200420-homenet [ Chairs - don't forget to hit "record" button:-) ] Chairs: - Barbara Stark - Stephen Farrell AD: Eric Vyncke Minute taker: - chairs + help, in etherpad Agenda: ======= 1. Agenda bash -- note that interim is scheduled for 90 minutes, but we may not use all of that https://datatracker.ietf.org/meeting/interim-2020-homenet-01/materials/slides-interim-2020-homenet-01-sessa-chair-slides Stephen Farrell went over the chair slides. There was no agenda bashing. 2. Outsourcing Home Network Authoritative Naming Service (draft-ietf-homenet-front-end-naming-delegation-10) Michael Richardson / Daniel Migault (30 minutes) https://datatracker.ietf.org/meeting/interim-2020-homenet-01/materials/slides-interim-2020-homenet-01-sessa-outsourcing-authoritative-naming-service Daniel Migault presented the slides. Control channel sets up the Synchronization Channel (which is just AXFR). Ted Lemon: Is there a case where you need to be originating a HTTP connection from the ISP to the user? Michael Richardson: I don't think so. Ted: Any time you have a home router accepting a HTTPS connection, there can be an issue. Michael: No, it's just an AXFR. Stephen: This is not the way DoH was intended to be used. It's not protecting privacy. Michael: We aren't doing DNS requests. We're doing DNS updates. We're not doing it through the DoH server. We're doing it through the domain service distribution manster to update the NS record. Daniel: DoH would be mutially authentcated. Stephen: Mutual authentication with DoH could be considered an anti-pattern. It helps tracking of clients. Michael: We're just looking at HTTP because it allows us to carry the OAuth token. But if we could find a way to carry the token outside the HTTP container we could do DoT as originally intended. Daniel: Michael: Distribution master will never be a public DoH server. Stephen: That relationship for client auth needs more eyeballs. Michael: We don't really want to go the HTTPS route, would prefer DoT. But don't know how to do the OAuth with DoT. Warren Kumari: Improving privacy was an intent of DoH and DoT. Even if this isn't for public Internet, it will make people concerned and you will get pushback. Doing a new protocol might be a better approach. Michael: If we go to straight HTTPS with no DNS, would that be preferable? Jim Reid: Michael: Yes, that's true. Ted: You can use Sig 0 (asymmetric key). If you need help figuring that out, let me know. Also, TLS can use client certs. Why do you want to use OAuth? Michael: A home router needs to be authorized to talk to the service hosting your zone. That's something you probably set up from your phone or so using a credit card. That's probably best done using an OAuth flow to the home router. The home router then needs to be able to present credential to service. Ted: That's needlessly complicated. I think you don't need it because you've already established trust in the browser. You log in to registrar and copy and paste the DNS record. They thing that has the private key used to sign the zone is in the DNS record. Michael: We do have CDS record now. So you don't even need to copy/paste necessarily. Ted: I think you're better off copy/pasting it. Michael: I don't think that's workable for average person. Ted: But if you do magic in one direction you can also do in other direction. Michael: No, what we're doing is exactly the OAuth flow. Ted: What you're describing is very complicated. Michael: There are many moving parts, but it's a solved problem. Ted: An almost identical flow could be designed to deliver the key to the right place. Michael: I think OAuth is the path of least resistance for the service provider. Ted: I think you're better off using DS instead of OAuth. Michael: Ray did some prototyping already. It is possible to build key in at manufacture but that doesn't scale to all use cases. Ted: It would be useful to see what the flow would look like to use DS record. Michael: I thought that at first. But you have to do NS lookup to zone that is not the public zone. Stephen: I don't recall that discussion from the mailing list. Michael: I got pushback privately. I need to understand whether OAuth key can be carried in TLS and doesn't require HTTPS. So we have to design some other flow that allows the public key of the home router to flow through to the service provider so it can be locked down properly. Stephen: Will discussion be taken to list? Michael: Yes. But I also heard there was a preference for us to use DNS for control channel and not HTTPS. DHCP reverse delegation also works. Stephen: So next step is to take this to the list. Michael: We also need to desribe the proposed OAuth flow better. (ACTION) 3. Stub networks (Ted Lemon) https://datatracker.ietf.org/meeting/interim-2020-homenet-01/materials/slides-interim-2020-homenet-01-sessa-the-stub-networks-problem Ted Lemon presented slides. Michael: (slide 2) I don't think there is a lot of understanding in IETF. Pascal T. is proposing this and there aren't many people participating. Ted: OK. Continuing with slides... Michael: (slide 5) I wouldn't say NAT64 is a solution. It's a workaround for having no IPv6 on the "backbone". Ted: Yes. Bear with me. Continuing... Ted: (slide 9) "No special requirements" is copy/paste mistake. Michael: (slide 10): A reason why HNCP+Babel isn't of interest to Pascal is because he wants devices to move around to different stub networks without renumbering. Though Babel could router /128 addresses. Ted: Yes, I haven't gotten into mesh networks with varying topology. Michael: There's a lot that needs to be done to make it all work. Ted: I'm not trying to bash Pascal's solution but am using it to launch discussion here. I'm presenting this to raise awareness about problems people are facing. We don't have a solution for plug and play stub network. I think this is an important problem. The homenet problem is a different use case, and we should consider this problem in the homenet space. We don't want to do nothing and end up with NAT64 solution. Ted: Michael: A reason I think the proxy ND solution is useful because it just works. Proxy ND going out of constrained networks is also good because there are no loops. Maybe we can find a nice transition from proxy ND to full DNS-SD solution. Also, it can run in parallel with HNCP+Babel, so it isn't a competition. Ted: There are 2 gaps in what you just said. Neighbor Discovery is a lazy protocol. I don't maintain table of all neighbors. Only those I communicate with. mDNS also works this way. mDNS isn't a publish protocol. It's a query protocol. There isn't a way to enumerate all services on network through mDNS. I think Pascal is using ND so router knows everything connected. Michael: Yes, stub router has database of everything behind it. Ted: And I don't think that makes sense in a home network. Something I've been working on in dnssd WG is Service Recovery Protocol (SRP). I think SRP may be practical solution for general case, and proxy ND is not. We also have DNS-SD discovery proxy as solution. I think we can incrementally move towards this. RA reachability may be step in the right direction. Putting HNCP on stub routers may help. Stephen: Where should WG go with this and not just Ted and Michael? Ted: I don't know the answer to that. I'm talking about this because I'm curious. As next step maybe I should write draft. I think homenet is right place but am unsure. Michael: the RA thing should be done by some smart graduate students, write a paper, and report results. They may be negative, but the failures will be very interesting. ACTION: tell Brian Carpenter and other connected people. Stephen: So Ted, you will write draft and try to drum up enthusiasm. Ted: Yes. 4. AOB Stephen: Is there any other business? Eric Vyncke: It's good that this will be written in an ID. We can see afterwards where it might go. Ted: OK. Meeting adjourned 11 minutes early.