IETF 90 - Homenet Agenda Friday 25th July 2014, 09:00 - 11:30, Canadian room Chairs: Ray Bellis and Mark Townsley 0. Administrivia Blue Sheets Note Well Ted Lemon (AD): The abbreviated Note Well is not legit. There is one that you can use, but this is not it. Ray Bellis: The abbreviated Note Well has some contentious text in it. Ted Lemon: We'd like to use the official abbreviated. Note taker - Thomas Clausen Jabber relay - Ole Troan Agenda Bashing Mark Townsley: HNCP might need a bit more time, came up yesterday during bits-and-bytes. Status: Homenet architecture has been approved, thanks to the editors and to everybody. Now, time to do some engineering... 1. Routing 09:04 - Routing Protocol Selection Discussion - Mark Townsley (20m) Note that this is not the time to pick, but we need to pick - and this is to start the discussion. Recap decisions that were made last time. HNCP was adopted as WG document for *configuration*, since that was what there was humming for at the last meeting (IETF'89). At the last meeting, humming between zero, one, or more than one routing protocol. Strong hum for one, weak hum for "two or more" at the last meeting (IETF'89). Discussed what the different things implied: choosing a protocol, using HNCP, .. That was the chairs interpretation of what happened last meeting. Now, time to figure out how to progress forward from that, for choosing what protocol work to do. 4 options presented: o 5218 analysis on a given date, to select the most successful, o Requirements document? o Coin-flip o Something Else Hannes Tschofenig: What is most important to people, in my experience, is that they see their name on the front page. So I think that a coin flip is a good way forward. Michael Richardson: I was unaware that "option one" (zero routing protocol) was a possibility. Seems that option 3 (two or more) might, if you buy incompatible products then you essentially are back to "option one". So, my opinion is that if option one can really work, then perhaps we should do that. Otherwise, we should do a coin-flip. Thank you for the idea of establishing a schedule and a date. David Lamparter: I believe we are missing a point to look at: we're only looking at unicast here. At some point, we will need to look at multicast, and we need to ensure that what we chose here will work with multicast. Lorenzo Colitti: Eh...I do not know why option three is there (two or more protocols), if we do option three then we have failed, we end up with one (zero protocols), we cannot count on interoperability. Mark Townsley: Well, it is there because it was discussed -- and because if we fail to accomplish option two, then we may end up with option 3. Lorenzo Colitti: It seems too hard to come up with option 2, so in that sense I think we should document how #1 works, implement it, and get field experiences, then we can also do something better later. If we determine that the ISIS stuff is super cool and we need it, in the field, then we can implement that later. I think that the risk of fragmentation shall be the major consideration here. Mark Townsley: Paraphrase, you support #1 but leave the door open, right? Markus Stenberg: The appeal of #1 is that it has my name on it, but I am not very fond of option #1 since I do not really want to stick metrics etc. into it. But, like Lorenzo I agree that @2 seems hard to accomplish. Currently, the intention of HNCP is not to route, but it can - it just ain't got metrics in it. Ted Lemon: I do not recommend #1 as a solution, since that would likely make HNCP likely take more time in the IESG than did the architecture doc. Option 2 is hard, but everybody wants a homent router that works, and that people should put that desire higher than their personal feelings. Perhaps if I can come up with a really harsh threat, they will - I wont do that today, but just put it out there. We could roll a dice, or something, once we have identified the viable candidates. Lorenzo Colitti: Question to Ted: thy would the time spent in the IESG go above that of the arch doc? Ted Lemon: Because you will be designing a routing protocol, and the RTG ADs won't like that when it happens outside the RTG area. They will hold a DISCUSS. Until they are happy. Speaking as your AD, I agree with that, it's not this wg that should design a new routing protocol. Kerry Lynn: Speaking in favor of #2, trying to find a way of selecting. Perhaps successive sequence of elliminate-the-worst-candidate and end up with one, eventually, would be an approach, that's often how it works when electing to public office. Mikael Abrahamsson: #1 is not an option, it becomes "our own routing protocol" since we need to set up routes. I think that we need to select one, that has been tested, that there's running code, tested, ... we need one. Acee Lindem: I was just going to say, that there has been a lot of side conversations. There are people who feel very strongly, and #1 will be hard because of those feelings, and we would have to get it to the RTG area WG, which picks up routing work that doesn't really fit anywhere else. David Lamparter: Would like to extend Ted's argument with technical arguments: we do not have ready-made testing tools for a new routing protocol, etc. -- not just a bureaucratic argument, but a technic argument RJ Atkinson: I think that what I heard the chairs said that given HNCP has been adopted for configuration, given that, we probably do not have a routing protocol that can do something other than routing. There's a routing protocol that everybody has on the shelf, that is in all home-gear, it's RIP. Why not use that? The chairs have chosen to implicitly limit the choice of protocols on the slide, and not included RIP. Mark Townsley: There was no intention to leave RIP off. The slide lists examples, and then "etc." to capture all the others. Steven Barth: Whether you like RIP or not, it's at least valid that not every home router is a big Cisco box, so we do need to consider what devices support, can do, and what we can fit into the devices. Also, an option is say 1 and two, by "SHOULD implement this routing protocol" might work? Lorenzo Colitti: So, a hybrid 1-2 -- not sure that I like that. I think that speed is a little bit of a red herring here. Good points on speed and scaling, but we should turn this into a feasibility check, not a contest: a home router today probably has about the same capacity as a backbone router of 20 years ago, and the networks were bigger then. Hannes Tschofenig: It would be interested to know what the numbers are for the capacity of these devices, if we have them. Mark Townsley: Lorenzo, can you clarify what you mean by "feasibility test"? Lorenzo Colitti: All I meant was, that it would be unfortunate if we picked a protocol that couldn't run on hardware. "It must work" should be a requirement .... 09:25 - IS-IS Implementation Report - Mikael Abrahamsson (10m) Did not do any slides, but was testing and demoing HNCP/Homenet with IS-IS with Fred Baker's src-dest extension, and the various other extensions that are floating around. Code will be open-sourced and will be available, and will come soon. Work on standardizing in IS-IS of the underlaying drafts. So there are now three routing protocols that have been shown to work with homenet: IS-IS. OSPF and Babel. Lorenzo Colitti: Back in the days, before homenet existed, I thought that I liked to put everything into a routing protocol. Now, with HNCP, I do want a flexible and extensible protocol. I like IS-IS more than OSPF in that regard. But, I want to put Ted on the spot, I'd want him to guarantee to help us that the RTG ADs won't block us by saying "you're taking IS-IS and using it where it wasn't designed to be used and we're not happy about that". Ted Lemon: Never heard any of the RTG ADs say they didn't want us to use IS-IS etc. Lorenzo Colitti: Was under the impression that they were not happy with the various extensions (service discovery, src-dest) developed and necessary? Ted Lemon & Ray Bellis: The use of a routing protocol for configuration, that they didn't like. The src-dest extensions etc. seem ok with the RTG ADs. Lorenzo Colitti: Then the hard part becomes to determine the boundary between HNCP and routing protocol. [Gentleman from Ericsson, whose name I sadly didn't catch]: Very good this IS-IS work. If you want pure IPv6, there's a slightly different way of dong it with IS-IS. Acee Lindem: The segment routing extension is pushing complete extensibility for OSPF. Dave Taht: It does seem that we are leaving one important routing protocol out of the room - interoperability with the IoT protocols, we will need to talk to these devices. Mark Townsley & Ray Bellis No protocol is chosen, no protocols are excluded from the discussion yet. [Gentleman from Ericsson, whose name I sadly didn't catch]: The same thing as src-dest routing can be achieved by segment routing. 09:35 - Hybrid Access Network Architecture - Li Xue (15m) - draft-lhwxz-hybrid-access-network-architecture-00 - draft-lhwxz-gre-notifications-hybrid-access-00 Presentation -- on Slide #8, a line started to form at the mike. Mark Townsley: A comment on the scoping aspect. The authors reached out to me and asked if it was in scope. o If it is a single residential gateway that is IPv4 only, then out of scope. o If a single residential gateway with multiple links and IPv6 and different prefixes, then it is within homenet. o Or, if you have multiple gateways and IPv6, it is too. What I saw here was that most examples have a single router, and so that's out of scope, but if we generalize it Erik Kline: It seems implicit, we are talking about two different access technologies offered by the same operator, right? Li Xue: Yes Lorenzo Colitti: If you try to do this with IPv4, it's a lot of work and it is hard to do. If you do it with IPv6, you need a router and a policy there (points to slide 4). In IPv4, you have to coordinate the natting, etc., and there's no way to split this, it's not easy. Ray Bellis: I have seen this done by multi-link VPN and such, Mark Townsley: It can be done on L2 (ISDN and such) but it is hard. Lorenzo Colitti: But IPv6, global addresses, you just route the traffic. What I see is that there really isn't a lot to do, it's policy, it might be a matter of how you define the policy, but if it is single vendor. Li Xue: Don't agree totally. With both upstream and downstream traffic, we need the same policy considerations for upstream and downstream of the same flow Lorenzo Colitti: No Li Xue: Yes Erik Kline: I was going to ask, if you have two different line speeds, how will you solve your packet reordering? Stall the connection to the speed of the slowest link until everything arrives? For the per-packet scheduling option, I am not clear on how this works Markus Stenberg I do not see this as more than a fancy lower layer - I do not see what it does here, my code just needs to care about a single interface. Sri Gundavelli: If you look at this, it maps perfectly to the NEMO requirements. This is like a mobile network, the whole device is moving from one to another network. Aggregation gateway is nothing more than a NEMO Home Agent, and egress. This does not belong to homenet, homenets should be concerned with ingress. I also thought that IETF transport recommendations was to never split a flow over multiple links? Michael Abrahamsson: The only way I think that this maps to homenet is to go and look at it per-flow and do per-flow load-sharing. Giving different prefixes, then you don't need to do anything. I do not see how this fits in homenet. Mark Townsley: If the solution becomes that you have multiple prefixes into the home, and the app ends up deciding which to use, then we have a solution in homenet. Otherwise, we don't. 2. Addressing / Configuration 09:50 - HNCP Updates - Steven Barth (10m) - draft-ietf-homenet-hncp-01 Ray Bellis: I just want to remind everybody that this is WG doc, but editing lately has been driven by the implementation experience of Steven and his team. So please do look at the changes, review, and take ownership of it. Lorenzo Colitti: When you say that a legacy router can be a client of homenet, and you will provide it prefixes, do you plan on giving it just /64, or ... Steven Barth: Can support giving more. Will, of course, give it something useful Lorenzo Colitti: I can see that you would possibly run out of space, so we would probably do good with some guidance here. Steven Barth: We also support reconfigure.....this is a "supposed to MUST implement" for RFC6024 and RFC7084 routers. 10:00 - Prefix Assignment - Pierre Pfister (15m) - draft-pfister-homenet-prefix-assignment-02 Ray Bellis: The chairs are minded to adopt this as a WG document, and so we would like to take a hum to determine this. Mark Townsley: Applicable to HNCP, OSPF, IS-IS -- any link state protocol can use it Lorenzo Colitti: I think that we have talked about this for a long time, and have agreed on the need for prefix assignment. I do question the value of attempting to do back-flips to give legacy routers bigger allocations than they actually need. A router that doesn't support homenet is designed for a world where IPv4 is the predominant tech. I think that it is not worth providing such a router more than a /64 If a router wants more, bigger prefixes, then he has different/more/better equipment. So if a consumer gets a /60, as he does with Comcast, then handing out two /62s then we're halfway out already. Ray Bellis: We do not want to rathole on this, Dave Taht: I'd like to mention the need for forcible retraction: my external gw goes away, then comes back up, and now it gets a new prefix. My devices the all have old and useless prefixes either for a long time, or until I reboot them. Forcible retraction possible in this mechanism? Pierre Pfister: It is possible, yep. Put the preferred lifetime to zero and maximum to some value. We put an option to keep the prefix if the node is disconnected, but if it connects or is reconfigured then it will actively ask all the devices to stop using the prefix. Ray Bellis: Hum for and against adoption: o seemingly strong hum in favor o seemingly week hum against Will take this to the list for confirmation, of course. 3. Naming 10:15 - Front End Naming Delegation and DHC Options - Daniel Migault (15m) - draft-mglt-homenet-front-end-naming-delegation-04 Dave Thaler: I do not know if you already have this, but getting the architecture perspective, this is important: what names do you want to be resolvable, and what don't you. Some entity needs to make that decision, since publishing it resolves some information to the world. Who decides? Daniel Migault: Do not currently deal with that Lee Howard: Keep on doing this, thanks. Because there is setting security policy, setting zones, designating what servers you delegate authority to upstream. A lot of manual config. A little concerned that there's a lot of stuff that regular consumers do not do regularly, and I do not know that we can do better, but... Daniel Migault: That's actually for a second document, how much we can automate, will talk about that. Lee Howard: Looking forward to that. Evan Hunt: The text about DNS views, are you actually recommending against them? Daniel Migault: Yes Evan Hunt: They afford a fairly simple way of ensuring that certain names do and certain others don't get exposed to the world. Recommending against them seems a little strong. Ray Bellis: DNSSEC, makes it difficult, no? Evan Hunt: Can be done (explained quickly two ways it can be done) Daniel Migault: The most problems we have with different views is if you're connected to a homenet link and to another link, then some names resolve on one but not the other link. Evan Hunt: This might actually be a feature, in some contexts and for some names. Juliuz Chroboczek: Have you checked that this is implementable without binding the authoritative server to the CPE? Do you have an implementation? Daniel Migault: Do not have an implementation, but should not be a problem if they are not on the same device. David Lamparter: Somewhat confused by the term "public authoritative server", needs clarification what that is in the draft. Daniel Migault: Can be any server, but will clarify that in the draft. - draft-mglt-homenet-dnssec-validator-dhc-options-02 Peter Koch: I am guilty of not having read this version, but.... You are talking about a single forwarding space, in a single zone We are talking about having multiple providers, with multiple upstreams, prefixes. How is that reflected? Also related to "one CPE" or "something behind the CPE" etc. Daniel Migault: You built the zone (forward zone) and outsource it somewhere. You have the key. For the reverse zone, I need to think about it. Ray Bellis: Hum for adoption draft-mglt-homenet-front-end-naming-delegation-04 For: Muted hum Against: weaker hum Hum for draft-mglt-homenet-dnssec-validator-dhc-options-02 For: Muted hum Against: Muted hum, but possibly a little stronger Will take it to the list, of course, but if you are against could you tell us why? Markus Stenberg: The reason I am humming against is it, that it s too broad a draft for what I care about. It seems excessively broad. 4. Service Discovery 10:30 - DNS SD Hybrid Proxy - Markus Stenberg (10m) - draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-01 Draft was presented, and without pause presentation continued to the next presentation ... 5. Security / Border Discovery 10:40 - Minimalist PCP Proxy - Markus Stenberg (10m) - draft-stenberg-homenet-minimalist-pcp-proxy-00 Michael Abrahamsson: This is good. Need to ask ourselves, do we really want for all protocols to go through weird hoops to support them -- or, should we tell the authors of these protocols to solve them Mark Townsley: This is the scoping thing. We will try to do as much as we can with existing host implementations and stuff, while trying to define, advice and direct on the future. But not only assume that we are directing the future. Phase 0 includes coddling existing implementations as well as we can, Dave Taht: Markus, I share your pain. What I would like to see would be some tools that we can all use to expose these things, rather than on a case-by-case basis. Do you have any tools for that? Markus: Could fire up a wiki or something like that, and maybe that could be useful to motivate people to do something Dave Thaler: As PCP WG chair: some of this discussion would be great to bring to that WG. We will have an interim meeting august 26 7AM west coast time, next time to present this. Will send an invite to this list, also, and invite Marks to present also - have the technical discussion on there. Tim Chown: Similar thoughts as Dave Thaler for DNS-SD. Ray Bellis: Tim, What are your thoughts as to DNS-SD proxy hybrid draft? It has sat here for quite some time, either adopt it here or send it to DNS-SD Tim Chown: Just adopted Stewart's draft in DNS-SD, to be confirmed on the list of course. Should probably bring Markus' work in there also, would be sensible Ray Bellis: We will take this on the list, also. 10:50 - HNCP Security - Pierre Pfister (15m) - draft-bonnetain-hncp-security-00 On slide 7, a line started to form around the mike... Michael Abrahamsson: I am not a crypto wonk, so I cannot evaluate this. Other people's work we can ride off of. IPSec looks good, can't we use that? Can we get help from somewhere? David Lamparter: Can you go back to the cloud-trust-scale-thing (slide 6) This does imply to me where suddenly other routers can be in trust and can not Pierre Pfister: The only network that works is the one in the middle. Michael Richardson: Can you go to almost your first slide. I really, really like the last sentence "preventing an attacker from interfering with a link it is not connected to" - a great baseline for what we can do. Have not read the draft yet, but the slides are great. If we want to go into link security, ...., there is a bootstrap-trust domain and a TLV system that we can use to do all those things. Don't go into that now, we can do that later, extend later. The problem that you are trying to solve is a subset of what 6tisch is trying to solve and there are some commonalities that may be worth sharing in other places. Dave Taht: Two quick comments: Security gives me nightmares. If you go looking for something called THC and run on your homenet, something might concern you. Securing the routing protocol is good. Also would protecting against spoofing 8.8.8.8 inside your network, etc. RFC7298, ... Erik Kline: Much what I had imagined when I wrote interior/exterior trust relationships. But for this slide (3), faking a client, how do you do this? Pierre Pfister: You are a client on your ISP side that tells your ISP that they want to get the updates from within your home network. Erik Kline: Faking an uplink, I am not sure that is a problem, just move it to exterior, and they will be gone. Do not support mixed mode. I would also agree with whoever it was who said do not do the link security now, as we have the tools to bolt it on later as extension. Then, on slide 9, what is "uplink security" Pierre Pfister: Faking an uplink by faking DHCP-PD Hannes Tschofenig: You spent a lot of time on talking crypto. A saying goes "if you think crypto is the solution, then you do not understand the problem" The challenge is to decide who trust whom. Routers would not decide themselves, someone would have to configure -- and that is a nightmare, users can't do that. Pierre Pfister: Can be made so as to not be so complicated: write the ID on each box, and configure... David Lamparter: Are we in this WG going to talk about trust-bootstrap? Mark Townsley: Scope-wise, if we develop a protocol, we have to secure it. How far that extends into trusting the homenet, needs to be worked out. 11:05 - Wrap up 11:15 - End