Minutes IETF110: babel
minutes-110-babel-00

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.