BABEL WG Minutes Hotel Metropole, London, England Thursday, 22 March 2018. 18:10 - 19:10 Park Suite Room Chairs: Russ White (LinkedIn) Donald Eastlake (Huawei) Notes: Barbara Stark, Russ White Jabber: David Schinazi 5 min. Administrativia (scribes), Agenda Bashing, Chairs 5 min. Status, Review of Milestones, Chairs 10 min. Update on the Bird implementation status of Babel Toke Høiland-Jørgensen 10 min. DTLS security implementation for BABEL Juliusz Chroboczek, Antonin Décimo, David Schinazi 10 min. BABEL Information and Data Models Barbara Stark 5 min. Wrap-Up, Chairs --------------- Administrativia, Status, Review of Milestones ============================================= Chairs introduced themselves and presented Agenda and Status slides https://datatracker.ietf.org/meeting/101/materials/slides-101-babel-agenda-and-status-02 No one wanted to add/delete any items. Donald: We are a little behind on milestones; should probably update them but I don't have a proposal; will sort this out on the list. Juliusz Chroboczek: There is consensus on source specific, we should last call. Donald Eastlake: It has been around for a while. Russ White: There are implementations. Donald Eastlake: Will post last call after the meeting. Update on the Bird implementation status of Babel ================================================= Toke Høiland-Jørgensen presented Babel in Bird Implementation Status slides https://datatracker.ietf.org/meeting/101/materials/slides-101-babel-babel-in-bird-implementation-status-00 Russ: How does Bird interop with next hop on v4? Does it try to install and if it fails do something? Toke: I don't recall off-hand. Russ: OK Tony Przygienda: Has anything been done with source-specific routing? Toke: Its in the Linux kernel. Tony Przygienda: You can run BIER. Toke: I will put that on my list. Markus Stenberg : Linux kernel has been source specific 99% ok for last 4 years. 2014-ish I provided some patch for it if I remember right, the 1% is still wrong but only for odd corner cases. DTLS security implementation for BABEL ====================================== Antonin Décimo presented Babel over DTLS slides https://datatracker.ietf.org/meeting/101/materials/slides-101-babel-babel-over-dtls-00 Tony P: Key management is from... The most common attack is replay and this does not protect against that. Antonin: Yes, DTLS does protect against replay. David: To answer Tony -- DTLS gives us replay preotection; you can send messed up hellos with bad sequence numbers, etc. Denis Ovsienko: Is it possible to have a document with security considerations? To talk about bad things, what you meant to achieve, etc. Nice to have section that tells how many bytes are introduced as protocol overhead. Needs to be discussed. David: That depends on the ciphersuite used by DTLS Donald Eastlake: Document would be a great thing to have; DTLS uses handshake to determine keys; you could easily build something that is multicast, but has a group key. Easier to do this if you have some way to distribute the key, such as a point-to-point session already set up, but this is a chicken and egg problem. Juliusz: There was no intention to exclude anyone from writing anything down. It's just the implementation was finished 2 weeks ago. David finished 10 days ago. This is recent stuff and we just haven't written anything yet. Second point I'd like to make is about the 2nd slide. What we now have are 2 extensions for cryptographic security. HMAC is simple and has symmetric key. No encryption or privacy and works over multicast. Babel over DTLS makes you use complex library nobody understands but supports all sorts of crypto. I recommend pushing for HMAC as mandatory to implement with DTLS optional. Donald: You're saying that DTLS pushes the crypto off to someone else, which is fine, but if the crypto is not what you need, it is not useful. Juliusz: If we are trying to protect against DoS, then I was mistaken. Tony P: I've been playing with this stuff for 20 years; replay protection with something like SHA1, something simple, which goes a long way. Where the world is going -- DTLS -- the security guys are coming down on this hard. If you want to deploy the protocol and be successful with it, you need to move in that direction. David: DTLS doesn't just give encryption. It gives key exchange on top of that. It has a cleaner security boundary. You know that everything is completely immune from replay attacks. HMAC makes it harder to have security boundaries. We could also use a combination of both. We could use a key exporter to give to HMAC for Hello. Toke: Having something that's really simple and doesn't give all security features does give me the main things I want. I would also like to be able to have security where I don't have a library. Tony P: There is a layering of security; SHA is simple and integrated, then the replay thing, then confidentiality. People deployed HMAC mostly to prevent against misconfiguration. Russ: And it's really good error detection. Tony P: The replay attacks were there. And confidentiality is important. Russ: Without chair hat. When we were testing HMAC, we determined that turning on encryption in routing protocols is a great way to open yourself to denial of service (DoS) attack at low bit rate. David: I feel very strongly that we should have a separate port for babel over DTLS. Donald: It is possible to get two port assignments, one for secure and one for unsecure David: Most implementations do not implement the SHOULD in Section 4.2.8 of RFC 6347; not comfortable with changing DTLS to support this protocol Juliusz: I believe everything David says can be done in the client. HMAC Secrity Update =================== Donald: Denis, you sent me email saying you wanted to briefly mention the update to HMAC security, rfc7298bis. (Denis presented without slides.) Denis: Talks about what he's doing with HMAC and updating the RFC to fix issues. Would like to request it be a WG item. Donald: If anyone objects doing a WG call for adoption, please hum. OK, will do a call for adoption on the mailing list. Denis: regarding the control plane protection problem, there is a section in 7298 that mitigates this BABEL Information and Data Models ================================= Barbara Stark presented Babel Information Model slides https://datatracker.ietf.org/meeting/101/materials/slides-101-babel-babel-information-model-00 Barbara Presenting: Juliusz and I met on Monday, there will be changes, but this mostly it Configurable; it is up to the implementation to expose what is configurable and what is not. Adding a change log appendix so you can easily see what is changing. Juliusz: You do want to be able to configure filtering rules. The three implementions have different filtering languages. Russ: It is not the job of BABEL to extract filtering rules for each implementation; this is up to the larger framework of the project, such as Bird, FRR, etc. Barbara: I was going to suggest that we do some basic models, and extend if needed Juliusz: I am afraid if we start building filtering rules Donald: Does it make sense to have an opaque block of stuff that only that implementation would understand? Barbara: It would be better for the implementation to expose filtering rules through custom parameters (extending the data model with custom parameters) Donald: So that would be an extension of the model for that implementation. Barabara: Yes. ------------------ Ronald in 't Velt: Read the source specific document, three or four references one each page to th 6126 document; should they be merged? Just a suggestion. David: I would prefer them to stay separate, because it's an optional feature. One RFC for BABEL, every extension is a separate document. Don't need to push the drafts at the same time. Toke: The short documents are my favorite part of this working group. Ronald: The thing is the readability of the extension draft. Not making people have to go to the original to implement. Russ/Donald: We're done. See you on the mailing list.