Babel WG – IETF 110 VIRTUAL - Tuesday, 9 March 2021 14:30-15:30 (UTC) Room 6 15:30-16:30 (Europe/Prague) Chairs: Russ White (Juniper) Donald Eastlake (Futurewei) Area Director: Martin Vigoureux (Nokia) Agenda 3 min. Administrativia (scribes), Agenda Bashing, Chairs 5 min. Status, Milestones, Chairs 18 min. Babel IPv4 over IPv6, Juliusz Chroboczek draft-ietf-babel-v4ov6-00 10 min. Babel Information Model, Barbara Stark draft-ietf-babel-information-model-13 18 min. Babel for IEEE 802.11 (Wi-Fi) Mesh, Donald Eastlake 2 min. Wrap-Up, Chairs Minutes [Thanks to Barbara Stark for taking minutes.] Chairs (Administrivia and Status/Milestones) -------------------------------------------- Slides: Agenda and Status Donald Eastlake: Presented and walked through the slides and asked if anyone wanted any changes in the agenda. There was no response. The four core document (applicability, base protocol, and two security protocols) have been published as RFCs 8965 through 8968. David Schinazi: Congratulated the group and particularly to Juliusz Chroboczek on the RFC publication of 4 drafts. [applause] Donald presented three proposed new milestones and asked for comments. The only comment was from Russ White who said the proposed new milestones look good. Babel IPv4 over IPv6 (and Source-Specific Routing) -------------------------------------------------- Slides: Babel: source-specific and v4-via-v6 Juliusz Chroboczek presented the slides. The slides cover topics of source-specific routing and IPv4 over IPv6. Juliusz: The source specific draft is hard to understand. Rather than trying to resolve specific AD DISCUSSes, I plan to re-write the draft. (in chat) Martin Vigoureux asked if the source-specific draft will be WG last called if it is rewritten. (in chat) Russ White answered that it should be, and probably passed through a directorate review as well. On v4-via-v6, the question is the source IP v4 address to use in any v4 ICMP messages generated by a Babel router that does not have a v4 address. Juliusz reviewed the alternatives. David Schinazi: Asked about routeability of the “Auto IP” (RFC3927) IP addresses used for ICMP. But it may be ok if they’re just used as source address, not destination. Will check. Donald: It should be ok as a source. (in chat) Donald Eastlake: There is a dummy IP address defined in RFC 7600,Section 4.8 that might be useful. Barbara Stark: RFC 3927 defines auto-IP addresses, supported by most operating systems. Juliusz: Every device must be able to send ICMP packets. David: More experimentation needed to see what goes in ICMP packets. (in chat) Russ White: Need to watch for uRPF problems here. Juliusz Chroboczek: uRPF breaks BABEL, so it must be disabled. (in chat) Russ White: Loose uRPF could allow BABEL to work, but still cause failures for sources not in the table. Babel Information Model ----------------------- Slides: Babel Information Model Barbara Stark presented the slides. Barbara Stark: How do we resolve the issue with the block, key, and digest sizes? Juliusz Chroboczek: So long as the keys come from some other system, there is no reason to allow them to be arbitrarily sized; the key generation system can ensure the keys are the correct size. Barbara Stark: If long keys are converted at a management station and sent to the routers as binary, there is no problem. I view that all as one system. But some security people are thinking of each MAC implementation as standalone and self-sufficient. Donald: The information model does not need to address where the key comes from, can state the key can be variably sized without impact. Juliusz Chroboczek: RFC 8967, in the security considerations section, states the key should be derived from another system Section 7, fifth paragraph. Barbara Stark: We are using the information model as a guide for user interface. Juliusz Chroboczek: I expect the user to generate the key someplace else and copy/paste the result into the user interface. Barbara Stark: I have to go do battle with Ben Kaduk again. David Schinazi: Ben’s DISCUSS has already been removed, just thinks it's weird there is a restriction here. We can just do what Juliusz says, which should resolve this issue. Martin Vigoureux: Status of the document note: I wanted to get the document through before this IETF. Waiting until this problem is resolved probably means waiting until after the IETF, which means the document will fall below the IESG threshold needed due to IESG turnover and I would need to get some additional AD ballot positions. David Schinazi: Would Martin be willing to approve this document today if Barbara promises to address this? Martin Vigoureux: That would be breaking a promise to Ben Kaduk. David Schinazi: We could just remove the text entirely so Martin can approve. Barbara Stark: That would be problematic; there needs to be some restriction to prevent configuration problems. Will try to iron this out with Ben today. Donald Eastlake: Maybe take this into email/outside the meeting. Babel for IEEE 802.11 (Wi-Fi) Mesh ---------------------------------- Slides: Babel for IEEE 802.11 (Wi-Fi) Mesh Donald Eastlake presented the slides. Juliusz Chroboczek: Two problems: Much of the complexity of Babel is due to handling an IP address in two physical locations that do not have synchronized sequence numbers. If you are working at layer 2, you would only advertise it from one place so it is much simpler. Donald: You hope MAC addresses are not duplicated. But in real world you can have this. Juliusz: Not normal. We don’t want to have synchronized sequence numbers. You need something simpler than Babel. Juliusz: Second point: When 802.11 mesh was defined, it had the two routing protocols as I recall. Donald Eastlake: The other was based on OSLR (I think). But in 802.11, there was great pressure to simplify things and so the OLSR based routing protocol was dropped. Final version only has HWMP. Implementations of 802.11 OLSR mesh never got out of the laboratory. It is my opinion that 802.11 mesh needs a better routing protocol and Babel, with distance vector routing plus the improvements and resulting good ability to handle links with unstable metric., would be strong. Juliusz: I think BABEL is better than OLSR. Is there market demand for a new protocol in 802.11s? Donald Eastlake: I don’t think there is a unified community that you could easily ask. David Schinazi: In this WG, we’ve had an implementation-first mindset, do you have an implementer lined up? Donald Eastlake: No, but the timeline would be fairly relaxed. Perhaps sending a liaison in July and only proceeding after we get a supportive reply. David Schinazi: We shouldn’t recharter to take this work on unless we have implementors on board. Wrap-up Donald: Overtime. Thank you for staying. See you on the list or at the next meeting.