Internet Engineering Task Force 106, 18 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF106-DNSSD_HOMENET-20191118-1330

Description

DNSSD HOMENET meeting session at IETF106
2019/11/18 1330

https://datatracker.ietf.org/meeting/106/proceedings/

A

B

C

We always pick on the same people.

D

Well, I will volunteer to do at the time what I'm not talking.

A

And I will be there too, and for anyone I know that a lot of viewers shy, including a lot of people for whom English is not your native language, but that's the beauty of ether part is. If you get more people and eat the part, then it simply becomes. Everybody is filling in the holes of everyone else and it's a whole lot of structure. So the more people we have an ether pad as long as you're, not like doing malicious things.

A

A

Highly recommend it for everybody who even wants to consider maybe getting more involved in ATF. It's a wonderful thing. I will get you anything past, okay, David, take it away. Yeah stir okay, because this is a joint session where there are two blue sheets. For each of these things. There's a home vet and at the MSSD, should I talk into the microphone there's HomeNet and DNS SD on each of these, and so, if you're going to stay here, for both, please put your name on both.

A

That would be much appreciated. Okay,.

A

This has the other.

C

Alright, let's get started so we're gonna start with a half hour of DNS, SD and so getting started, so it is Monday. This is the note. Well, it's a very big slide and I'm not gonna. Keep it up long enough.

C

But if you haven't read the note well, please actually look it up in your favorite search engine and actually do read it you, just by being here and saying things you have requirements relating to patents, for example that you need to be aware of, and also the ATF has, a code of conduct that we will be enforcing. So if you're not aware of, what's in that code of conduct, please go and form yourself, but it's pretty reasonable stuff, just be nice to everyone around you and everything will go great.

C

So a few reminders anytime. You go up to the microphone. Please state your name clearly, so the minute taker can take it down. Please review our documents, so we keep progressing them and we make sure they are the highest quality output possible and please sign the blue sheets that are going around right now.

C

So we have in case you're searching for the links you can pull up these slides in the tools. These are some links mainly for people that are not in the room and just a usual reminder. We have a github organization and any draft author that would like their draft on there to facilitate collaboration, should just let us know and we'll so get that set up for you very quickly.

C

So our main goals for today's sessions are to get an update on our current documents to discuss more early work and discuss kind of what we're going with all this and also our privacy efforts.

C

So here's our agenda specific to DNS SD, not to home net. So our first half hour session has these three items and our second session later today we'll be discussing privacy. Would anyone like to bash the once twice sorry, success and Stuart.

D

Thank you David, so I'm here to give some updates on our documents. The first one I'm talking about is Service registration protocol, which is reminder a way for devices offering services to use a variant of DNS updates to record that in the network as an alternative to using multicast right now. The primary application of this is silikal thread. Mesh networking, which is an initiative that came out of nest, their home, thermostats and smoke detectors use this.

D

It's built on the same I, Triple, E, 802, dot, 15.4 radio that things like ZigBee use the difference is ZigBee is a vertical proprietary network architecture for everything, from the addressing the naming and the application protocol. That runs on top of it here at the IETF. We believe in the longevity of IP based applications, because even when the hardware changes the same application, software carries on running. So that is my strong predisposition.

D

The people who start at the thread group have the same philosophy and they are running 6lowpan ipv6 over these I Triple E radios. They are quarter megabit per second, roughly ten meter range, similar in range and speed to Bluetooth, low-energy, but much more IP friendly, so standard IP software runs over these without having to be rewritten. What the thread group is adding is mesh networking, because 6lowpan just defines one hop ipv6 and the thread group also defines the onboarding commissioning process how you give a device, the credentials to be on the mesh.

D

What they don't have right now is any firm specification for self-discovery other than a sort of hand. Wavey think saying: well, just use multicast like Ethernet does we know that multicast is inefficient and slow and unreliable on Wi-Fi? The same is true even more so on these thread mesh networks, when you have a mesh in you're forwarding the multicast, multiple hops to reach the whole mesh, when potentially only one device is interested or maybe no devices is even more wasteful than Wi-Fi, so we have been proposing using SRP.

D

The great opportunity here is thread is a bad brand new think there is some limited deployment with the nest products, but it's certainly not as widespread as Wi-Fi is. So we have an opportunity to define something good from the start and we don't have a backwards compatibility legacy issue to deal with if we could go back in time 20 years. Maybe we should have done this for Wi-Fi as well, but we didn't so. The transition for Wi-Fi will take longer, but we have a great opportunity now.

D

The last thread, all members meeting was two weeks ago in Switzerland and I. Was there pitching these ideas to try to get support from the rest of the thread? Community I can report that that was very successful. They had. They have green lighted this for as a work item to to take on that, doesn't necessarily mean it will be part of a future specification.

D

But if we're successful, then it will so that's a great opportunity, I think to start thread mesh networking out right from the start instead of starting with multicast and then realizing it doesn't work and having to retrofit something on and then having a legacy support issue.

D

Part of what we want to have here is thread border routers that implement this SRP server and ideally make that a mandatory requirements that to be a certified thread, border router. You have to implement this. Of course, the some politics involved there in getting that language into the specification, getting everybody to agree that that's the requirements, but that's what we're going to try to do so.

D

Anybody in the room, who's interested in working on this we'd love to have more implementations and more collaboration on the document. Second document to talk about is the roadmap.

D

This needs to be updated and it was not because I was away working on this thread group meeting and putting together all all my materials to pitch these ideas there. This is intended for the time being to be a living document. That's updated to be the table of contents for all the other documents, so to speak. I would love to have co-authors join me on this. This is not absolutely not intended to be a one-man.

D

Show I'm I'm often up here at the front of the room talking about things but I don't intend it to be that way. So if there's anybody interested in joining in, please don't be shy about doing that. I.

D

I hope Ted can hear us. I know. Ted was going to add some comments as well. So, okay.

E

Hi there so I, don't have a huge amount to say, but just just regarding the SRP stuff, I've been doing a ton of work on the SRP stuff over the last. Like you know three months, and you know the first thing to say about the spec is that it seems to be proving itself to be a good spec I've definitely found some some gaps in the spec which need to be updated.

E

It's at this point. It's getting to be pretty mature, though so I'm gonna come out, probably before the next IETF not super before the next IETF, because I've got a lot of work on my plate before the next IETF, but I'm gonna come out with a new version of the spec and at that point, I'm gonna propose that people give it a serious read, and we do a last call on it because you know this is. This is a real thing that, at this point is you know, I've got running code.

E

There's gonna be an open-source version of this that's out and available both for IOT devices and for regular.

E

You know hosts, and it would be good to get people to read over it and see if they can see gaps that I missed I mean there's a couple of really obvious things that I missed like, for example, the document doesn't actually say how to remove an SRP update, and it also doesn't say what to do if you're just advertising a host but no services so right now, the document would actually reject an update of that sort, which I think is actually probably wrong, because because then you don't actually get feature parity with dns SD over multicast dns, so things like that are still still in progress and need to be updated, and it would be really awesome if anybody's interested in doing updates to this I'm, hoping that I'll be able to get the source code out.

E

So if people want to hack on it rather than writing their own from scratch, it'll be very adaptable that the source code that I'm working on right now has an adaptation layer. So you can make it run on whatever hardware you want by just adding like a about ten functions of. You know that provides things like send a UDP packet and you know wake up at this time kind of stuff, so that would be great I. Think that's about all I have to say about it I.

E

This is the main thing I've been working on for the last couple months, so I don't really have any new updates for the other stuff. But obviously that's still, you know the the particularly the relay document is still hanging fire and eats needs some work. So because is there anything else, Fitz should say about the story. Now.

D

That's good I just wanted to give you a chance to update, because Ted and I were together at the thread group meeting in Switzerland and actually did a demo using some prototype border router devices from arrow from Linksys and the Google nest hubs, and that demo was successful and we showed different vendors products. Interoperating. We had an iPhone running the home kit, app talking over Wi-Fi to the Linksys border, router over thread to a simulated home kit accessory alight I. Guess it wasn't simulated, it was a real LED light.

D

It just wasn't a very bright one. This little development kit with a surface mount LED, but in terms of software, that is exactly a a home kit, controlled light and on the same thread. Mesh Google was showing an Android phone using the Google Nest software to lock and unlock a door lock and to us at the IETF. That's not particularly remarkable to the IOT vendors.

D

Seeing different vendors products work at the same time on the same mesh was absolutely mind-blowing, so we got a lot of interest because right now, if you buy IKEA smart LEDs, you need an IKEA hub. You buy Philips, you bulbs, you need a Philips hub you by Comcast home security system. You need a Comcast hub, they're all ZigBee, but they don't talk to each other, so the uh so.

D

The idea that a single border router from any vendor could actually support multiple different applications at the same, at the same time, from two other vendors that was remarkable, so we are working to to push forwards on this and and demonstrate that this is real, because that's what we want. We want a world where thread is like Wi-Fi. You can buy one access point from pretty much anybody and expect that all your devices will work with it.

F

Yes, so yeah, thank you for.

D

Your name Daniel.

F

Amigo Eric, so this is a great work and I come in to review the next version of the draft. Thank you, I'm not gonna review the code, but the draft yes, okay,.

D

Thanks and thanks Oh.

E

Stuart one thing I wanted to mention about the work that Daniel is working on actually Daniel you, this is something you might want to think about. Is that in order to do like DNS SD, well, actually, nevermind I'll do that in the home. That thing it's not really a okay thing. All.

D

Right just wait: 13 minutes, yeah it'll.

C

Require team you had off and putting the next one on.

D

Next document, the relay as Ted said this needs an update, Ted knife both been busy would love to work with us on this and I'll make this call again. I I have heard people say that this is the Ted and Stuart show, and that's not our intention, and if it seemed like, we didn't welcome other people contributing I apologize for that, because that was never our intention.

D

There was a time not so long ago when Ted was not working on this and he got interested and started working on it. So if Ted can do it, we're definitely open to other people getting more involved too, and then the final update I have is on push notifications, which is in the same cluster with the discovery proxy, and this is all reviewed.

D

Last call I actually approved, ready to be published and, as part of this group you may know, we have an old thing that we developed at Apple like a decade ago, which is the udp-based variant of push notifications. Now experience with this showed that something that maybe we should have known.

D

But it's a lesson that we learned is that building your own hackie protocol on top of UDP is rarely a good idea and that's why push notifications is defined to run over TCP and we retired the q documents made a new draft and we've implemented it, and it's been reviewed and it's great and when this was published, I asked the independent stream editor to publish the llq document as an informational document. Just for the historical record that this is the old thing.

D

If you see these packets, this is what they mean, but with the clear forward reference saying, don't implement this. Do the new thing instead and in the process of doing that, he said: I see an IPR disclosure on this and and I apologized to the workgroup in the ITF. That was totally my fault. This was a decade ago.

D

I had totally forgotten about it, so I have asked Apple legal to basically apply that same IPR disclosure to the push notifications draft offering that patent under the same terms, because that's our intention what we said ten years ago applies now big companies, things move slowly, but I'm hopeful cross fingers that literally any day. Now we will get that disclosure in and that can unblock this and then all three documents can go ahead and get published, hopefully by the end of the ER. That would be nice to get to get 2019 dates on these.

D

So that is the final update on that. Thank you and you stirred any questions.

A

Here's the summary of what Stuart just told you there's your waiting for DNS push, which is waiting for the patent IPR declaration and we have the privacy and security requirements which are in working group last call is that right? That's what this data said.

C

The privacy requirements we'll be discussing at the privacy session at 6:10 tonight.

A

The SRP document is still a working group document and comments are welcomed and encouraged. That's the word.

A

Okay, so I did send an email to the list because we have owned again off again discussed. Do we whatever want to recharter, and so these were some points, I kind of grouped some of them together that Tom buso teri had brought up as things maybe to consider. There was very minimal discussion. I think there was one email that said: yeah, maybe I don't know.

A

um That's just my summary of it, and so I'd like to you know, ask maybe hear if any of these call out to you- and you know, really resonate and like have your name attached to them, or something and you'd like to see us recharter.

A

C

The the idea here is our current charter for dns SD was really focused on losing the dependency on multi guests and so in particular, like the hybrid proxy, was the main work item which is about to be published once all that's done and like the documents that Stuart was talking about once we wrap all those up, one possibility is we declare success and close the working rule. Another possibility is, there are other topics that some people find interesting, so you recharter to incorporate those into our charter and work on them.

C

But in order to do that, we need people who are willing to pick up that work so.

C

That's why like, if we, these are potential ideas for things we can work on, but if we don't have individual contributors interested in working on those, then they won't happen.

C

Anyone then Ted. So.

F

Daniel Erickson Danielle, Mugu, Erickson I think well, if you're willing to reach out her I think maybe we should have a scope that is also I mean merging the home. That activity is related to the naming so.

C

Is that item number one or something else, I.

F

Don't know the ongoing work within the home net I would say well.

C

So we wouldn't reach order to take over home net right. So what are you sorry? Can you elaborate on what you're thinking well.

F

The thing is: I believe that we need to I mean the work being done in DNS. Sd is quite close to I mean they're, not independent, from what is being done in home net, so it might be helpful. We have everything in one place. If that simpler, that's a bit related to naming I think that's, maybe if we need to reach out there, but I can I'm not asking to reach out or say.

C

Thank you. That's that's a good point. All right, Ted yeah.

E

So one point about what Daniel actually just said is that in order to do so remember we have this thing called the DNS discovery, proxy DNS st discovery proxy. It looks like an authoritative server, but it doesn't actually retain any state.

E

It's a stateless sort. I mean it's got a cache, but essentially it's a stateless, authoritative server and one of the things Daniel is working on is how do we set up a secondary so that so that people are hammering on the primary server to get answers to questions all the time and I think that there's actually a problem to solve there in that? If we have a DNS SD discovery proxy, it would be nice to be able to do something that has that effect. But it's not going to work using zone transfers.

E

It's gonna have to work using DNS push, so so writing a document that talks about how that works might be worth doing, hopefully, after actually trying it so so I think there is actually some work to do there and you know continuing on that. I mean we're not done with with the SRP stuff and by the way, that's a continuation of the moving from multicast. A unicast there's clearly more work to do on that, if only just finishing the document, but possibly also after that and we haven't finished the relay document.

E

I think that it's important that we finish that so so I, don't think we're quite ready to say we're done yet I mean maybe we're getting there. That's not to say that we can't recharter, but but I just want to make the point that that we are definitely not quite done yet and.

C

That's what we Ted so I didn't mean to say that we're done and we should all go home just when those items are done. The end and I think the items we described fit into our current Charter, yeah and think windows, and even like that new document that you just mentioned I would see that as pertaining to the current Charter, and so when all of those are done would be that situation where we might close down yep.

E

Yeah and by the way, unicast many discovery is actually a solved problem. I'm not convinced me to do any work there, because that's how PD MSSD works. Generally, you asked for a PTR record for a service and it gives you a list of all the known services on that PTR record. You know all that gives you a list of PTR records for each of the services that provide each of the servers that provide that service. So I'm, not if there is a problem to solve there.

E

It's not clear to me from the bullet item what that problem is: okay,.

C

Thanks Ted so ray and then Tim I'll.

G

Come on to vary hunter here, I'll be speaking later on to my own slides, but just a back up on Ted. That I think there's a big gap at a minute on implementation experience around naming how this all fits together and I'm not sure we need a document on it, but we certainly need running code.

C

Thank you. That's really good feedback.

H

Tim Wattenberg I'll, actually, second, what ray just said about working code I think that's, that's quite something which might be, which might be something achievable, which achievable I think there there's quite some code and as Stuart presented some time ago. It's also, for example, available in the in the github repo, but yeah there might be more than one implementation which might be nice. That's my first point. The second point would be that, as we said earlier, the current Charter is kind of focused around reducing multicast traffic and I.

H

Think what we are seeing right now, for example, also with what Stuart presented earlier with this threat model. Let's call it like this and also other techniques, Laura or whatever, so there's still a need for service discovery, maybe in domains which are not specific to this multicast problem, but we're still. We need to kind of solve the idea of how how is service discovery implemented in in those areas and I. Think much of the work which has been done in this working group could be applied for that, but probably there's.

H

There are some ideas which yeah, which we might ooh to think through in this perspective as well, and that might be actually something it's. It's has been a time that I read through the Charter, but maybe I. This is something where we chattering would be good to specify or to to make make it point that it's not only about multicast, but also other transport mechanisms where service describe service discovery is needed will want it thanks. Tim.

D

I'm hearing a common theme: people talk about more code. Experience I'm, really happy to hear that so I'm going to make a suggestion.

D

We have been using the hackathon time at the IETF meetings, but it's often just been me and Ted or me and Ted and Tim. Maybe we can make a plan for the next hackathon to have a concrete list of things that we're going to work on. So if anybody is interested in and willing to contribute to that, send an email to the list or privately to me and Ted, and let's make an actual plan of some concrete things we want to achieve at the next hackathon Stuart.

C

Can I give you the action item of coming up with that original list and posting? You know a list of two things to work on the next second I'm putting on the list for comment. Yes,.

D

I will I will send out a suggested list and I welcome input from other people about what they think that the priorities to work on. Thank you staring.

C

Alright, so we are pretty much out of we have one minute left. So thanks I think the current documents are in good shape, so we're gonna leave that at that I'm gonna quickly plug. We have our second session on the third session today at 6:10 p.m. we'll all be discussing privacy and specifically today, if you use em, DNS, DNS SD the names and everything and the services are in the clear and we're looking at ways to make these things encrypted.

C

So an attacker who's on the same network as you doesn't know what you're certain what services you're searching for, or the name of your devices. So if you think that could be interesting, he's come back. I, yeah, I think it's yeah in this room at 6:10. All right, I think we're going to switch over to home. It.

A

So yeah is it possible to continue on jabber scribe, um but simply on the home net jabber? That would be much appreciated and the note-taking is now going to move over to the home net. Etherpad: hey: can you tee up a few more things and I'm gonna open up the ether pad or well, like you see, you're on jabber.

C

Just the medical folks, let us know that they're gonna keep the DNS SD jabber for home net, so maybe we can keep or can I drop a scribe. Just keep an eye on both is that? Okay, thanks.

A

The same note well applies: go figure.

I

A

We've just discussed the same blue sheet supply and if you haven't signed the blue sheets, where are the blue sheets and anybody need blue sheets and again, there are two sets of blue sheets reach: blue sheets, there's the DNS SD blue sheets and the HomeNet blue sheets, and please sign both okay.

A

A

Okay, so first up is going to be the home naming architecture this the agenda. What wait we have to give people a chance to eat bash anybody want a bash look. Nobody wants to bash um just real quick before.

A

I'm, just it's just it's just okay,.

A

So I did just have you know kind of, like the other one, here's the status. There are three drafts so right now we're going to be talking about so the first one is just sitting there hanging out in Babel, and that is it's waiting for the Babel reference to be done and it's just waiting and waiting, and we don't have anything to do with that.

A

Then the next one um Daniel did just update and he's going to be discussing that on the HNC P that we'll be discussing today doesn't have a draft actually and then there's Ted's draft, which hasn't been updated in a while, but it is awaiting implementations and again you know the hackathon that Stuart mentioned is valid for that as well. Hopefully, oh, look. It's Ted lemon! You want to let him in maybe well Steven. You need to push it harder. There. You go fYI.

E

The the HomeNet, the simple helmet naming stuff there is actually I've been doing some implementation work on that it's a little bit farther in the rear view mirror than three months, but but we have some some running code that does little pieces of that and I I think there's been other work. That's been done on that as well, so so that's there is actually ongoing work. It's not just! It would be nice if somebody did something.

D

Quick comment on it to make about H NCP, for the thread group work that Ted and I have been looking at there is this question: what if you have multiple thread border routers on your network and the thread network is a sufficiently dissimilar technology to Ethernet and Wi-Fi that it doesn't make sense to bridge it. So today, quite often with Wi-Fi, you just bridge it with the ethernet. You have multiple access points. It's all bridge together with thread that isn't an option. So there has been in the existing members of the thread.

D

Group there's been some hand, wavy statements about Oh, H, NCP salts. That I think I. Think this that's a very strong candidate and we need to actually implement it. So, okay,.

A

And the H NCP discussion is part two and we've got some slides on that, and so thank you for teeing that up but you're just a little premature Stewart. Now we're going to talk with Daniel and.

F

Regarding the status, there is another draft I am that is looking at DHCP options to provision the outsourcing infrastructure.

F

We have to see how valid it is when that's gonna be done so also seeing whom that authoritative naming service. So it's an old draft next slide. Oh.

J

F

F

So we basically rewrote the document I think pretty much the full document.

F

What changed is that we specified I mean the protocol that is used in order for the between the HomeNet way, authoritative naming the naming Authority and the outsourcing infrastructure.

F

We reviewed the names, the terminology as well I mean ray, did an implementation of that, so some of the design shows have been driven by the implementation and there is a concrete interest in deploying it. So the next step is I think from well. My expectation is that we review the draft try to see if we can clarify some things between us and then it's in my opinion is going to be pretty much closed. Working guru, that's cold.

F

So this is the high-level picture so.

F

But that's fine, that's fine! Our things in it is on it say so.

I

F

I I'm not going to touch any button to have a pointer, okay,.

F

So, um okay easier so um well, so this is a starting point from the naming architecture within a home net, and so these are all the things we a little bit influenced by the simple naming architecture.

F

These are the functional functionalities that we are dealing with, but the one way you're going to talk about regarding outsourcing is really this one. So you have a public zone and it needs to be outsourced so that any resolution here on the public home net, authoritative servers um can be done on the Internet. So the idea is that within your home net you for people on the internet, they will not reach your home networks, but instead you're able to outsource this to cloud firm or any cloud provider.

H

Just a quick note from remote, it's quite hard because the people cannot see what you're pointing at so.

G

H

You want to say what you're pointing at so that they can follow. Okay, yeah.

F

So should I repeat so. This is a starting point of the I'm, not pointing anything. So it's a bit.

K

L

F

There is nothing to find this is a global picture of what we're moving on for the network. The naming architecture in the home networks and the also saying the the the related parts of the outsourcing is just one piece of that and it's the one represented in red so where you have a connections between a home, metal, 30 and the distributed master as well as the home. The the one represented in black here, the home net, authoritative servers, and maybe some relations with the resolver, which is represented in blue.

K

F

F

So the home that naming authorities what it basically does it builds a zone for the home net. Is that is expected to be reached from outside of the internet, so it's basically the zone of device that you expect to be published on the wild Internet we're using DNS SEC. So the idea is that the home that is generating is key. Keep its key, very secret, sign the zone and push the zone to the outsourcing infrastructure.

F

So the only thing that is a so it's a quite a simple mechanisms, but what we would like to have is a way to automate it that and to make that easy to configure so that it can actually be deployed at scale, which means on very various aamna travelers.

F

Yeah, so you have the key for the DNS and you because you you, the home metal thority, is going to out upload the file to also sing infrastructure. It needs to be authenticated. Those two parties, so we using another set of keys, which is only restricted for the authentication, so the resolver. So when you are in a in your home net, you want to access also the domain name that are being published outside on the outsourcing infrastructure.

F

So suppose you are using cloud for cloud for resourcing, for you, your home needs own and you have a connectivity disruptions. So you want to be able to reach from your home net your names that are, we will read out example.com or, let's say, nasty example.com. You want to be able to reach in within your internet home net, even though you have a connectivity disruptions.

F

How you can do that? Well, it's basically having a way to reach the what is in the public zone it's inside the home net, so you could have an home net, authoritative service. That is doing that for you, okay,.

F

So that's the big picture. Well, I mean it's more zoom, so the important concept are oh yeah, but there is a camera here. No and I should not.

J

F

F

So I can read here, so you have the home that naming Authority you have a public zone and he's doing is outsourcing the zone on the outsourcing infrastructure. So you have a control channel, synchronization channel and the anthem endpoint, where is pushing that zone is called the distribution master yeah, the distribution master, so this distribution master is, is then responsible for distributing this zone again within the cloud infrastructure, but it's not pretty much the purpose of the home network. This is really the purpose of the cloud provider.

F

So what we focus our draft on is to define how you can control a configure, the distribution master, the relations between the HMA and the distribution master and how you can sync your zone between the two. So so that's a yeah, the main part, and as I mentioned, you need to have an authority of servers inside your home net in case of Internet connectivity disruptions, and this is where the home net resolver is going to probably resolve inside the internet. So you can definitely see a small problem here.

F

Is that your resolver, that is, that has to resolve dot? Example.Com is not going to go on the internet, it is going to go on the home net alternative servers, most probably in which case he needs to have. It needs to be provisions and configure to do that. It's not gonna be done. Magically Ted, Daniel.

E

Can you talk sorry Dave? Can you talk just briefly about why it's useful to be able to get an answer about something? That's on the home that when the home net connectivity isn't present nothing, it's not I'm, just curious. What your rationale is.

F

So the question is, why do we need to have the home net wealth or ative service I mean.

E

Now the question is suppose the home that is not doesn't have connectivity to the internet yeah. Why is it important to be able to get a question answered about the service on the home net during that period? Another thing it's not, but that's yeah. That's the question.

F

Well, the prison is that well, it's a requirement from from the initial home net document, but it's because if you want to access your video server or music server, you don't have the the connectivity to access it from outside. So but when you're connected inside, you still need you, okay, so.

E

It's wire it's while you're at home, not while you're away.

M

So Michael Richardson here so Ted, but an indigent answer, the question a little bit differently. um The reason why you don't wish to use video server dot home darpa is because the TLS certificate won't match up and then you'll get all upset and frustrated and then you'll learn to click the right bad warnings that they don't want you to click on.

M

So if, if you did have security, then we'd like the name to resolve correctly within the home net, even when you're not just not connected, so that you can do that, and in particular one of the names that you probably would like to reach is your home router. So you can find out why you don't have internet or fix it right.

M

Does that make sense the room.

I

G

Just I want to say what Michael said: it's so that you can have one device I moves across the boundary to always use the same name. So if your mobile phones connected en-us and there's some security on there, you always use the same name where they you're connected to the Wi-Fi. Whether you're connected to 4G.

F

Is that fine I mean do we have any questions regarding this or no.

F

Two channels, so we have the control channel and so I think. The the important things to realize about this control channel is that basically, we exchanging some configurations between the the two, how and so how we do that we were using a special way to do. That is that the the information is carried by DNS messages.

F

So it's important to realize that it's only we only using the DNS format and they are interpreted in a certain way. By the the other hand, both ends I mean. So when the a chain h, h, n a wants to retrieve some parameters, he is using a an XF. Our query and when he's willing to push some informations is, is using a DNS update.

F

Yeah, so the reason we did not go, we did not use HTTP or JSON object is that while we were working out with DNS libraries, all the DNS libraries have this messages, and so it was much easier. Much lightweight to use this way to carry the information, then the synchronization channel, we're using a primary secondary relation and distribution channel, is almost out of scope of the home net, so securing the channels, so the control channel is authenticated and encrypted using TLS.

F

So we basically did I mean a common way to to secure DNS exchanges to use a TC, but we we remove that. We did not really consider this because well, you have the symmetric keys that have to be renew and provision, so we basically only use TLS a question that was raised is that do we really need to protect with TLS the synchronization channel? Given that the I mean the the content of the public zone is exactly to be public and it's signed with DNS SEC?

F

So this is one of the comment we we received so I'd like to receive I mean to see if there are any any any ideas, any any thoughts on that.

I

Sometimes, there's a draft in deprive on XF or over TLS. Now, that's relatively recent is that what you're, considering using here well.

F

So yeah everything is over TLS, so maybe I have to dig work. Why we need a draft on.

F

Yeah, that's a yeah, okay! It's basically what we.

N

Write yeah right, ballots, I, see so I couldn't go back once like lose time on the D s. Sending for the DNS SEC could I suggest you. Please look at using CD s instead of D s, because that already has the specific semantics that it's for a child publish its das record to its parent. So in conformance servers they can automatically handle taken CD s from the child and push it up into their parents own rather than needing some separated by a mechanism yeah. So.

F

This will be the purpose of the outsourcing infrastructure, and so what we are saying is basically that we we leave that to the outsourcing infrastructure, they could use the CD s or any EPP mechanisms, but.

N

A published CD s record already means please send this to my parents yeah exactly well, that's false.

F

Yeah, so, okay, so with it I mean when I provide the home Nets own I'm, signing it having the CD s in that yeah.

N

Okay delis, so yes, NCDs Rollins, yes, and it should yeah.

K

Yeah yeah yeah, so.

N

Just Ross yeah.

K

F

I

K

But thanks for so as a time check, I think we're down to eight minutes. Okay, so question and Q.

A

G

This one reply to Rea Bella's, definitely use CDF for ongoing operations over the synchronization channel, but- and you can use as a standard for that- not implements it already using CD s records fully aware of that. But the problem is: we've got to establish trust for the initial operations and you can't do that on scale using the existing mechanisms. So what we do is we publish a DES record over the control channel when we're using this certificate on the TR so to establish the initial trust for the DES record.

G

Does that make sense than why we did not.

I

So so I think these are good things to discuss on the mailing list and I also had a question myself about things like factory reset, but maybe that maybe that's in the draft and I just need to read the registration.

G

Of it by the same mechanism by the, if this is the certificate, establishes the trust but.

I

So again, I think there are. Those are good things to discuss on the list.

H

I

I think you're up next anyway. So do you want to just stay there sure.

I

Okay yeah, so let's, let's take trying it take discussion of this to the list.

G

Just a quick introduction: you've probably never seen me before- that I've been working with the ITF since about 2010 or 2009 I believe I first started taking part I, don't turn into trouble nowadays because try to minimize the co2 and I also like staying at home as well anyway, but you can always grab me. V6 ops at glow was dead net for IETF work, I'm.

G

Basically, a network consultant more operational type person than a coder, and this I do pro bono for the idea and I actually own my money as a program manager believe it or not, because the tech, nice techie stuff doesn't pay and your next slide. That's enough about me. Let's talk about the technology, yes, sorry, the question an asteroid reached an excellent point about H NCP's, h, n CP evolution is when I posted to the list in the last few months about H n CP. The response I got was we're done.

G

That's definitely. Water I'd, like to talk about in my few minutes here is: are we done with H n CP, because what I've been doing is I've been hacking with H n CP, as well as implementing the previous draft that we talked about and identifying missing? What's in H n CP? Well from the simple naming draft that dead, wrote arms the front of naming delegation that written together with Daniel, you know those I'm coming to the conclusion that we are missing stuff in H, n CP.

G

So what I've been doing is I've looked at, for example, how it fragments on the network and I've put in a patch for the existing implementation to reduce the number of a ipv6 broad fragment.

G

So any questions on this particular slide.

I

No, no, no okay,.

G

Next slide, and so the point Barbara is I, haven't actually put any draft on at the minute and there's a reason for that is I'm, not sure what we want to do in the work group for H and CP and whether there's any appetite to do it. So that's why I thought we'd just put these questions out. There is both of our drafts, need more functions and are currently available in the implementation of H NCP. The ball gateway to other technologies.

G

Ray has much.

I

Of raised okay, so.

G

There are gaps in what H NCP is doing for us and we.

F

Lost you for a second, because their primary.

G

And secondary service, config, Gateway's and other specialist functions that we may want to run on the UM narrator and the point I'd make is that the h and CP in the RFC's have been published. They assume or appear to assume that all nodes are created, equal and there's, no actual configuration or tiebreak mechanism to say that actually, nowadays, a bit bigger than node basis, it's better to run these central functions on a and B.

G

So what I'm asking is? Do we want to keep all of our nodes equal and it go for fully distributed environment for net? Or do we want to encourage specialization of some services and some things like not unbound external route? I've done some work on that it took 25 megabytes of overlay.

G

Now, that's not big for an ass box, assuming you've got an ass box in your net, but for a Wi-Fi router, that's enormous, so I've got a tp-link router, and that comes with eight Meg's of flash and most of that's taken up with the core of open wrt. So if you put all of this extra stuff on top and don't actually need to enable it, but, for example, a central DNS server, you've suddenly made your small box very expensive by the addition of four dollars of extra flags, which doesn't send a lot of money.

G

But in the cutthroat world of and devices, four dollars is a lot of money per device and then I come under the question of. How do we want to do this? Do we want of tlvs for each function, or do we want to come up with a draft, something like embedded SRV, our ass into a TLV, so that you can elect a master and then bootstrap the service?

G

And this would come to something like Stuart talked about, where you would want to put in an SRV record for a gateway device and then elect the gateway devices depending on whether you want to elect one or whether you want to elect multiple gateway devices.

G

So those what I'm asking for feedback or no and I spoke very quickly about the slides to give some time for feedback in questions.

I

Okay, so we have Daniel in the room, I'm Ted I think it's still in the queue so.

C

I

It's not clear to me how to switch like this. We try hit the button a couple times and see what happens.

I

E

Okay, so a couple things. First of all, I'm really delighted working on this I've been following the work that he's been doing, but I haven't really had time to participate because I've been working on the SRP stuff, so I'm, hoping that that will have a chance to work on this before the next ITF. And, if not, then, then in that, at least in that zone.

E

I think that it's a bit of a red herring to worry about Flash space, because I don't think that that's really the direction that things are going at this point if we were to require that routers provide in a flash base to do this stuff correctly and if there were demand for this functionality.

E

I think that that the the difference in the price of the flash first of all I, don't think, would be four dollars for the part I think would be quite a bit less than that, because the amount of additional flash isn't that much. But secondly, I think that you know that were for the.

I

The day when.

E

Things were raising Thank.

I

E

I

E

Internet connectivity is wonderful so anyway, so I think worrying about footprint is probably not that important. That said, I think it is certainly the case that there will be primary and secondary, and we should figure out how to do that. um So thanks.

I

We have a couple of people here in the room in the queue and zero.

M

Minutes, but so a brief that should work Michael Richardson here so I'm gonna agree with Ted for the reason that if you are, if you look at the market for 100 Meg plus fiber-to-the-home type devices, they are not the 30 for the twenty dollar devices, they are upwards and hundreds of dollars on that couple, bucks for extra flash is probably okay. It's only in the little unity devices that you stick in our pockets and bring to the IETF with us that it's a six dollar it event.

M

So time did you wanna, yeah I, just want to say.

G

Oh great, your good luck but would say that okay, the.

M

Way, we can actually just finish our kind of data tiny, but so.

G

I got off to produce basically three different images. We're gonna have to come up with a heavy image for the big devices and a light image for the small devices.

I

Okay and I think with that we're at a time. Hopefully, people will take these topics to the mailing list and we can discuss them there. Thank you and.

A

Dn SSD is in this room at 1680 1810, which happens to be 610 depending on if you're 12, hour, 8 or 24 hour clock. Yes,.

A

I

Like we could've done, know 10 minutes, baby buster, yeah.

I

So you're not the worst person.