Minutes IETF102: babel
minutes-102-babel-00

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)?
<there was silence>
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? <no hands were seen by minute taker>

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.