Re: [babel] Tsvart last call review of draft-ietf-babel-mac-relaxed-04

[Kyle Rose <[e-mail]>]

On Fri, Apr 14, 2023 at 1:14 PM David Schinazi <[e-mail]>
wrote:

> To respond to your comment about "insufficient prior outreach to subject
> matter experts", you're missing an important bit of context. When RFC 7298
> was written, Babel was RFC 6126 and that only supported sending packets
> over link-local multicast. As you know, there is negligible amount of
> reordering there, for either Wi-Fi or Ethernet, or even overlays for that
> matter.
>

I actually don't know that. If I were designing or implementing something
at the network layer, I would probably try to minimize reordering; but I
don't actually know what is implemented in real world devices. Which is why
I would engage someone with SME in that area if it really mattered to my
design.

> However, when we rewrote Babel in RFC 8966, we added the ability to also
> send packets over link-local unicast. This feature did get implemented, and
> so did HMAC - however no one deployed both simultaneously in production.
> When that was done, we realized that there was indeed an oversight because
> unicast and multicast do get significantly reordered on Wi-Fi. The document
> that you reviewed fixes that oversight. All that to say, we're not
> completely clueless over here in Babel land. We made a mistake not
> foreseeing how two separate features interact, but please don't assume
> incompetence.
>

My review does not assume incompetence, unless one regards not being an
expert in absolutely everything as incompetence (which I don't). I'm
suggesting that something like the assumption that queueing behavior is
basically FIFO over all packets, or that it wouldn't differ based on
destination address, might have been obviously wrong to someone who works
in that area, and that the ADs should make sure document authors are
engaging the right set of expertise. It's not like this was unforeseeable:
it is well known that UDP and IP guarantee nothing about packet delivery
ordering, so any assumption about ordering should immediately prompt
additional scrutiny.


> Back to your first point, yes the document does assume that, when treated
> independently, link-local unicast and link-local multicast are generally
> not reordered much in known deployed link layers.
>

Can you provide a reference for this claim? I don't doubt it's actually
true, but a reference to some research actually verifying it would make a
fine addition to this document and any future 8967bis.


> Maybe making that assumption explicit to help explain why the reordering
> window is optional sounds like a reasonable enhancement. That way if
> someone deploys Babel HMAC later over a new future link layer that
> reorders, they'll know to implement the window.
>

I was making a more general point there that the design choice, reasonable
as it might have been at the time, was not explained anywhere I could find.
That kind of context, even if just in an appendix, is helpful to people
asking "why?" in the future.


> To your other note about adding a protected field, the intent in this doc
> was to build something backwards compatible - but maybe we should note that
> to help explain the design choices.
>

Agreed, thanks.

Kyle