IETF 88 - Homenet Agenda Thursday 7 November 2013, 09:00 - 11:30, Regency D Chairs: Mark Townsley, Ray Bellis AGENDA: WG Administrivia - Note Well, note takers, Jabber scribe, (Chairs, 5m) Homenet Architecture draft-ietf-homenet-arch-11 (Tim Chown, 25m) Outcomes from IESG Review Source/Dest Routing draft-baker-rtgwg-src-dst-routing-use-cases-00 (Fred Baker, 20m) Update on inter-area discussions draft-xu-homenet-traffic-class-01 (Shu Yang, 10m) Naming and Service Discovery (Daniel Migault, 20m) draft-mglt-homenet-front-end-naming-delegation-03 draft-mglt-homenet-naming-architecture-dhc-options-00 draft-mglt-homenet-dnssec-validator-dhc-options-02 draft-cao-homenet-mif-srvdis-00 (Cao Zhen, 10m) draft-andrews-dnsop-pd-reverse-02 (Evan Hunt, 10m) Security draft-behringer-homenet-trust-bootstrap-01 (Michael Behringer, 10m) draft-kline-homenet-default-perimeter-00 implementation report (Markus Stenberg and Erik Kline, 15m) Homenet / HIPnet Design Team draft-winters-homenet-sper-interaction-00 (Timothy Winters, 20m) =========== 09:02 - Start WG Administrivia - Note Well, note takers, Jabber scribe, (Chairs, 5m) Mark Townsley (MT): How many of you have homenetworks? How many have two homenetworks Everybody has one, everybody has opinions about them. Therefore, as your home is your castle, your opinions can run pretty strong Observed in IESG reviews, some of the discuss comments were very long, but the message was much of the "this is very important, we're glad that this is being done". Keep this in mind, for balancing perceived criticism from IESG. Ray Bellis (RB): Solicit minute takers, scribe. Ask for agenda bashing? No comments, ask Tim to come up to present update on IESG review on architecture document 9:05 - Homenet Architecture draft-ietf-homenet-arch-11 Outcomes from IESG Review Tim Chown: Intent is to run through the updates since the last meeting (& -10) Attracted an awful lot of comments from the reviewers. Thinks that there is a reasonable amount of consensus, will walk through the changes and the open issues from IESG review. About 85 or so points raised by 10 different ADs. Expressed appreciation for helpful and clarifying input from directorate reviews. A version -11 was submitted, but still things to solve in a -12 Slide 3: Walked through the changes, notably that the title had been slightly changed to contain "Principles" got some microphone time, otherwise "the odd sentence removed here and there". Also, that routing issues should be discussed in routing area, which he believes has happened this week. Slide 4: Comments on open-source text, presented the new Peter Lothberg: What is "light weight"? Today, it's different from what it was yesterday and what it will be tomorrow? Why do we not take this sentence out of the slide? Tim Chown: Certain daemons that are running are in fact (counterintuitively) more light-weight than one might expect. Lee Howard:  Seems odd to insist on open source implementations, we really should care more about interoperable implementations (although, does appreciate open source) As a general principle, fine Dave Crocker OS implementations are spectacularly successful in becoming reference implementations, and their effects on the market is important. James Woodyatt Important that in the home, we have OS - that's where hackers are playing, and need to be able to hack Lee Howard: Agree, but those are Layer-8 considerations. We want OS implementations, but it is not a measure of success for the WG Peter Lothberg: Why do we make an exception to the process, just say "interoperable implementations"? Barry Leiba: I am not one of the ones who want to see OS mentioned a lot in the documents, but I think that what we have now is fine. Says that it is "important consideration" is fine Ted Lemon: The WG did come to consensus on stronger language than that previously. Dave Thaler: On previous topic, lightweight. There's a document in the lwig WG, which is a terminology document, and I suspect that you do not use light-weight in the same way as does lwig. Maybe want to pick a different term here, or clarify what you mean by this. Mark Townsley: Give us one... Dave Thaler: You're saying "axis is important, lower is better", so propose to state the axis rather than invent a term. Ray Bellis: We're ratholing here, move on please Charles Perkins: OS, what system? Linux? C? Tim Chown: Back to the slides, slide 5, 6 - open issues presented. (No comments from room) Slide 7, this might get some comments from the room. Asks if there are any strong comments or views? Fred Baker: The 2nd bullet ("Will security be sacrificed at the altar of zeroconf") is not phrased in a neutral fashion. Define security? And the answer "it is a trade-off" is not particularly helpful. Seems like instead of pointing out the obvious, you'd be better off asking for threat analysis and risk assesment. Tim Chown: Very nice quote that came from one of the ADs, but yes. We were looking at how you could do autoconfiguration of routers, detect the links to ISP. There's a potential where you can introduce vulnerabilities Would be great to have a volunteer to do an analysis and assessment. Tina Tsou: Back to slide 6. To OAM session, your intention is to have OAM tours, or the general requirements considerations. Tim Chown: Certainly needs a separate document for that, is Ted here? Mark Townsley: Spoke with Ted and Benoit a little bit. For this doc, I think we can manage with a paragraph or so, is that right, Ted? Ted Lemon: Yes, the goal is not to have a full OAM arch discussed here, that an operator can enable, but rather have a task in this document. Mikael Abrahamsson: Security is a trade-off, sure, but it is important to get this document done, so let us get it done, all security trade-off's are now totally flux given the recent developments. So get it out, there's other work to be done. Lee Howard: Security, seems the current state of the arts, based on v6ops, needs some weasel- words to say that "it changes over time" Tim Chown: Continuing with slide, bullet on multicast scopes bullet point If we are going to autoconfigure, scope 3 is the highest Michael Richardson: ROLL has dealt with this, Ralph and he has discussed yesterday and agreed on some text that should come out. Believes that the text for scopes 4 and 5 where it says "administratively configured" and people believe that it means "an administrator", but it is really as opposition to be "topologically autoconfigured" (3 and below) whereas 4 and 5 can be "autoconfigured by other means". Believes that we can automatically configure 5, therefore, but not topologically. Kerry Lynn: Want to say to Ted and others that the RFCs do not necessarily preclude autoconfiguration of 4 and 5, they do say that 3 and below MUST be. Just pointing out the distinction that 3 and below it's "by topology", but 3 would only pertain to part of the subnet. My concern about 5 is that if there are ISPs managing the edge router in the home, and make that part of their "five", it can't also be part of the "five inside the home" Ralph Droms: That business about "can't be both", multicast-zones apply to interfaces, not to devices. A router managed by ISP can well have an ISP-facing interface part of the ISP-scope-5, with another home-facing interface be part of the hone-facing-scope-5. Also, affirm the  type-3 Ted Lemon: Just want to clarify that this wasn't my discuss, it was Brian's discuss. Mark Townsley: If we're OK with 3, then do that and Brian will (as far as I have heard) clear his discuss. This document needs to leave soon. Kerry Lynn: My point was that it can't be 3, as it will pertain only to part of the homenet, because of the consensus that has been formed in other WGs. Tin Chown, Mark Townsley, Ted Lemon: We have to take this off-line. Tim Chown: Back to slides....slide 8 now. 9 Number of open issues from IESG is shrinking rapidly, aim at continuing resolving issues rapidly. Seems we're getting there. 9:35 - Source/Dest Routing draft-baker-rtgwg-src-dst-routing-use-cases-00 (Fred Baker, 20m) Update on inter-area discussions Fred Baker: The same slides I am using in the RTGWG the other day, I am doing it quickly, but really want to have the discussion from the homenet perspective. There's a RTGWG draft, and the reason for that is that we had a meeting in Berlin, and there was a feeling that it would be nice to take out yet another wg working on this and move to RTGWG, so this is the usecase. Motivating also, customer devices today come with two ports: one ISP-facing, one home-facing. If you have two upstreams, you have two devices, and you have to deal with "an outgoing packet coming to the wrong customer gateway", what do we do? Discussing several motivating examples, from enterprise, home, video-service, ... Generalizing from that, wound up with the two basic requirements (on slide "Generalizing"), and with some observations on ambiguities possible in FIB. Any comments? Dave Thaler: Clarifying question: if there's ambiguity,my understanding is that it is because there are multiple possibilities, all of which could (assuming no ingress filtering) work. One might be more efficient, but it would get there. So you have policies that overlap, right? Is that right? Fred Baker: I would disagree...what if one of them doesn't result in a route, I can't get to the less specific to the more specific route. Mikael Abrahamsson: Homenet depends on a lot of things, and is tying this together. Where does this belong? Fred Baker: Trying to find that out. Right now, it is done in a WG not chartered to do this (homenet) but need to agree on a place to do this and send it there. Mikael Abrahamsson: Need to find out for all the work we do depend on, where is it done. Should we try to figure out in, say, the next month or so "what needs to be done and where should it be done?" Mark Townsley: When this WG was chartered, we had to make a choice. Routing/addressing/ service-discovery, we found that if these were not done at the same time and in the same place, it'd be done wrongly. Also, it is not the protocols, as much as how they interact among each other, that is the challenge. As we approach the maturity of the WG, I see various places where the IETF says "nonono, that's my area, I want to do that". And that's good, we want to see universal solutions made, but also, we want it done coherently. That's up to Ted and the ADs to fight this out. Charles S....???: An example is worth a thousand words. I have seen a great many use-cases, but I have not seen an example of a forwarding table... Fred Baker: Look through the I-D, it's there. I'll look for it and forward it to you. Michael Richardson: The ambiguity David went at was, that you have two incompatible policies. You either have to go to A or you have to  go to B, when you write down the policy in one form, it turns out to have exactly the same expression as the opposite scenario. Fred Baker: B-FLETS is a great example. Advertises a default route into the home, but doesn't give access to the great wide Internet, only to the video service. So, sending packets to the Internet via the B-FLETS ISP just won't work. It's not as it should be, but it's how it is. Markus Stenberg: Brilliant, but this is actually a bad example, providing hosts with more information than they should...should not advertise a default route that doesn't exists. Sounds wrong. Fred Baker: That's another discussion David L.....: Is this intended to be extended, or can we be done with the use-cases and start do the things we're supposed to do? Fred Baker: I can break the requirements into a separate draft Don Sturek: The firewall settings on these ISP is liable to be very different, and can be configured in ways that may make this  not work Dave Thaler: Yes, I did figure out what you were talking about. A previous speaker pointed out (Markus) that the B-FLETs setup is bad, should not advertise default routes. Should recommend "don't do this for simple cases like this when you still advertise the same number of prefixes". If you have 18 specific routes, you will aggregate into a default route, because you can't do 18 specific (that's the number, look it up). The recommendation should be "don't do unnecessary aggregation" Peter Lothberg: We're reliving the things we did in the bast, from a single backbone to the spaghetti we have today, the home is just another ISP in this context. Maybe we should look back and solve the general case, rather than one specific corner case after another. 9:58 - draft-xu-homenet-traffic-class-01 (Shu Yang, 10m) Shu Yang (SY) Rohan Mahy: When I read this document, a thing I didn't understand, when you have multiple border routers, one administratively managed by the ISP, one in the home managed by the home user, and both configured to route the same prefix. Is there a situation where you can have conflicting configurations? Shu Yang: Discussed in berlin, match for dest or src prefix as first priority. We picked dest prefix as first priority. Rohan Mahy: There's no conflict resolution Shu Yang: Yes there is Acee Lindem: Great that you have implemented this. Did you do it twice, once with source-prefix first, then one with Fred's heuristics. A lot of people are arguing if we do not solve the right problem, if destination is the first priority. Fred Baker: You did 3 implementations, first MTR implementation, the next two were this stuff with different FIBs James Woodyatt: I have no problem with this draft, great, thank you. 10:10 - Naming and Service Discovery (Daniel Migault, 20m) draft-mglt-homenet-front-end-naming-delegation-03 Daniel Migault: presenting the document, and changes up to -03 Bob Hinden: Question about your premise. Who is going to provide this service, am I going to pay for it? Daniel Migault: Who you want Bob Hinden: I can certainly understand having a 2nd ISP at home, but beyond that. I do not understand the practical deployment considerations where this would happen. I think that this is not for the most common user(s) Mikael Abrahamsson: Typically, this would be your ISP that would handle and offer this for you. Lee Howard: Think that this is heading in the right direction, my concern is related to Bob's: if you have a domain name, and want this to be handled, you need to do something, it is not a zeroconf-solution. Tim Chown: Did you just say that accessing stuff at home is only for advanced users, Ray? Ray Bellis: Currently, yes - if we do this right, no. Mikael Abrahamsson: Would like to see this be zeroconf, entirely. John Levine: Seems to be a generalization of what I pay DYN $20/year for. James Woodyatt: I think I understand what this draft is trying to do, and if I do understand it correctly, I really do not want this to be zeroconf. It is a way of taking names inside your home and publishing them in the public DNS horizon. I gather that people do not want to have all their mDNS advertisements automatically sent out for the world. Mikael Abrahamsson (and Michael Richardson): Zeroconf, in that this is the /mechanism/, but you should still be able to "click-to- publish" James Woodyatt: I understand what dynamic configuration is. I m OK with how zone information gets transferred up to some DNS service being automatically configured, but not "zero". Want to make sure, this is a terminology issue, do not call it "zero" because the decision has to be the users. Dave Thaler: Follow up on James' point. I thought that his main pint was for home devices "inside my castle", I do not want them to be in a public authoritative server, but in a private authoritative server that /I/ can access from wherever, but not that everybody can. This is an important point, we need to have that discussion. Daniel Migault: The CPE can't guess what you want public and not. Need some interaction. If you are buying a domain name, at some point, the CPE can't guess that you did that either, so that needs to be done, and can be done with a GUI. Mark Townsley: Fair to say that the next two presentations are DHCP options enabling this, so this is details, where the previous one was the big picture? Daniel Migault: First, yes, the second is how to have DNSSEC always on Mark Townsley: Pick one of the two, you can't do both, no time. Daniel Migault: The DHC-options Mark Townsley: Great, the second one goes to the list. 10:25 - draft-mglt-homenet-naming-architecture-dhc-options-00 Daniel Migault: Presenting the details On Slide 6, asking to the WG: Can we say that an IPv6 master MUST have an IPv6 address? Mark Townsley: Really good question, taking it to the list, we really need an answer to that, but we do not have time today. If you're sitting there nodding, tell us why (on the list), if you're sitting there shaking your heads, also tell us why (again, on the list)! Daniel Migault: Resume presentation James Woodyatt: Why don't I just send out an URI, a pre-built template of the zone-file?