Minutes interim-2020-homenet-01: Mon 14:30
minutes-interim-2020-homenet-01-202004201430-00

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) <Daniel indicated on jabber he is ok with this. He
apparently lost audio.>

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: <moving on to slide 11>

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.