BABEL Working Group Meeting Minutes Minutes: with assistance from Barbara Stark, Gabriel Kerneis Jabber: David Schinazi, Christopher Wood Fairmont, The Queen Elizabeth Hotel, Montreal, Quebec Tuesday, 17 July 2018 09:30 - 12:00 Saint-Paul/Saint-Catherine Room Chairs: Russ White (LinkedIn) Donald Eastlake (Huawei) Area Director: Martin Vigoureux (Nokia) [times given are those originally scheduled, not the amount of time actually taken.] 5 min. Administrativia (scribes), Agenda Bashing, Chairs ========================================================== Introductions. Minutes takers and Jabber scribes (see above). Chairs reviewed agenda and asked if there were any requests for additions or deletions. There were none. 5 min. Status, Review of Milestones, Chairs ============================================= slides: Agenda and Status https://datatracker.ietf.org/meeting/102/materials/slides-102-babel-agenda-and-status-03 Donald Eastlake walked through the slides. Donald: Does anyone here or on meetecho have an objection to declaring consensus on the Applicability draft (in WGLC)? Donald: Declared consensus. Donald: We will discuss status of other docs after presentations at end of this meeting. 20 min. HMAC in Babel, Juliusz Chroboczek ========================================== slides: HMAC in Babel https://datatracker.ietf.org/meeting/102/materials/slides-102-babel-hmac-in-babel-00 Juliusz Chroboczek presented remotely. - slide 2: jch@ is not the person who did most of the work. other contributors also attending the meeting (denis, clara, weronika remotely) - slide 3: key rotation is an essential feature. HMAC only does authenticity (authentication), while DTLS also does privacy (encryption). - slide 4: - slide 5: with a pseudo header, a replay attack is still possible, but more difficult to exploit. C has to spoof B's source address because the source address is part of the signature - slide 6: to protect against replay, use a strictly increasing counter (clock, counter, etc). Perfectly safe protocol assuming the receiver keeps state forever from every neighbour. - slide 7: the above is what [RFC] 7298 does (roughly). [stuff I didn't catch about the 2 limitations] - slide 8: we want to avoid persistent state. - slide 9: [meetecho issue] - slide 10: the idea is that whenever you reset your packet counter, you pick a new index. [see slide for details] - slide 11: Two independent implementations, integrated in babeld and bird (not merged into master of either); specification still needs work - slide 12: Still a number of open questions; size of nonce and index, use of packet trailer, explicit vs implicit indexes - slide 13: Open question -- size of nonce - slide 14: packet trailer -- where does hmac live; if within the packet, then must be cleared before computation - slide 15: implicit indexes -- index can be ommitted except in challenge replies - slide 16: ask for wg adoption David Schinazi: On slide 10. If the packet counter wraps you may hit the bit number limit in which case it needs to reset. Juliusz: Yes, or rekey (?) -- if you hit this limit you must recalculate an index David: This document is ready for adoption Christpoher: Support from jabber Donald: Are there any objections to adoption -- none apparent, but will do a confirmation on the mailing list 15 min. DTLS in Babel, David Schinazi ====================================== slides: DTLS in Babel https://datatracker.ietf.org/meeting/102/materials/slides-102-babel-dtls-in-babel-00 David Schinazi presented slides. - slide 2: We need a way to secure BABEL there are situations where you want more complex capabilities, like many trust models, etc. - slide 2: leverages BABEL over unicast; Juliusz considers this a change to the protocol, I do not because my implementation only uses unicast - slide 3: "how it works" - slide 4: open question -- should unencrpted IHU's be allowed? currently are, but we could drop them - slide 5: open question -- everything on the same port or use separate ports Barbara Stark: I see the firewall thing as being irrelevant; used to have two different ports, would prefer two ports Ted Lemon: It would be interesting to articulate a use case for BABEL through a firewall, this does not seem to be an issue David: If you use the same port you have to figure out whether this is a secured BABEL packet or not Denis Ovsienko: If you use two ports, if you have a pair of speakers on one pair of ports, and another pair of speakers on a different set of ports, can they accidentally switch traffic? David: DTLS uses a shared secret, so the two sets of neighbors could not unencrypt one another's packets Denis: This is okay - slide 6: two independent implementations; not interop tested, need to figure out port quesiton first - slide 7: wg adoption? David: Who has read the draft? Denis: Read the draft when it was 8 pages, thought it was too short to discuss Denis: Question on high level approach on the mailing list, when a DTLS has 100-200 neighbors on the same segment, how does this work -- how many sessions? David: Each pair would have a session Denis: Do you think this will cause any problems in real life? David: The goal is not to replace all BABEL deployments with BABEL over DTLS; if you have that many routers, HMAC might be better Denis: I am discussing the use case of a mesh network; it is possible that when there are a lot of mobile nodes in the same location, these kinds of numbers can occur (paraphrasing!) David: Good point, probably need to add applicability text to the document about the amount of state with a lot of routers Juliusz: Would like to answer Denis' comment -- BABEL already quadratic behavior, there is no such thing as a DIS or DR [IS-IS/OSPF pseudonode] Juliusz: If your use case is to plug 200 routers into a single switch, BABEL is not the right protocol Juliusz: DTLS does not change the complexity of the BABEL implementation, or the amount of neighbor state 4 min. Babel Security in Homenet, Barbara Stark ================================================= Barbara Stark presented slides. https://datatracker.ietf.org/meeting/102/materials/slides-102-babel-babel-security-in-homenet-00 Barbara: This is what I am going to be telling Homenet - slide 1: The babel WG has already seen everything here - slide 2: Expected to recommend one security implementation for all BABEL implementations for HOMENET How do you distribute the key and credentials? David: When do we have the conversation about which secuity mechanism to make mandatory to implement in Babel, etc.? Donald: It would be good to have this discussion soon, but after we have drafts for mechanisms adopted. 15 min. Babel information Model, Barbara Stark =============================================== Barbara Stark presented slides. https://datatracker.ietf.org/meeting/102/materials/slides-102-babel-babel-information-model-00 - slide 1: four minor outstanding issues to be addressed, waiting on comments from various people - slide 4: open issues -- "what about this?" Would like to see if anyone has any heartburn about the decisions I've made here Fixed the interfaces objects stuff, Juliusz has not complained in a while, so moving to the closed state Included a few logs to fix the statistics and logs issue You can log your hello messages Not doing any statistics Parameters for security anomalies; added log to look at some of the security parameters Basic security model, which is really about managing credentials and logging them Mahesh Jethanandani: Question on security parameters; have you looked at any of the oher data models that have defined security parameters? Barbara: I will look at these It might be possible to convince Mahesh Jethanandani to write a YANG model based on Barbara's infoprmation model - slide 4: open issues, continued External cost might need more work Multicast history may be too implementation specific Is it okay to modle the transmit and receive costs as integers? Martin Vigoureux: Why don't you need an IANA registry of numbers? Barbara: Because we only have three types right now Martin Vigoureux: Why not have one? Barbara: Because they are painful Martin Vigoureux: Not having them can be painful as well Donald: I think IANA registries are fun :-) Denis: A registry is not required, because the amount of work required to make the protocol support a new type is greater than the work required to add it in the registry Martin Vigoureux: It doesn't take any time to maintain a registry Juliusz: I like BABEL because it is a great platform for experimenting with new link metrics With BABEL, you can expirement, it will still interoperate and work A registry would constrain experimentation Barabara: A registry does not need to be unreadable Martin Vigoureux: I would agree with this Donald: You can have registry entries that are reserved for experimentation Denis: If the link type never never leaves the space of the speaker, it does not need a registry Barbara: Correct David: I agree with what everyone has said so far So long as this is just a string As long as there is some rule that says "everything that starts with an underscore" is experimental, then this is fine Barbara: I will work on writing up text on a registry in this draft Donald: I will help with this - slide 5 Intend to create a TR181 data model Then start WG last call Donald: sounds like a good plan 10 min. Milestones revision, Chairs ==================================== Donald: Applicability draft should be do-able. Any comments on these milestones? Martin Vigoureux: Did you just change the dates? Donald: Added one, and changed the dates for three Martin Vigoureux: These would fit into the current charter, since we are only looking at a year ahead, you should start looking at what to do after this Barbara: Is July 2019 the management thing? Martin Vigoureux: This is YANG Barbara: I'm hoping the management model is much sooner Donald: I will split this [management doc] into two [curetn info model and Yang model] and put this on the mailing list 5 min. Wrap-Up, Chairs ======================== Chairs: Thanks everyone, see you in Bangkok and/or on the mailing list.