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

[David Schinazi <[e-mail]>]

Hi Kyle,

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. 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.

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. 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.

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.

David

On Fri, Apr 14, 2023 at 7:44 AM Kyle Rose via Datatracker <[e-mail]>
wrote:

> Reviewer: Kyle Rose
> Review result: Ready with Issues
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> [e-mail] if you reply to or forward this review.
>
> This document is Ready with Issues.
>
> The only issue I will note with this scheme is one that I'm sure has been
> litigated to death on the mailing list, and that may be unresolvable
> within the
> bounds of technically-permissible but unobserved reordering behavior on
> networks: that packets will be delivered more-or-less in-order to receivers
> within each category (unicast and multicast). If that is true in practice,
> and
> especially if it is a property that network device vendors already have as
> an
> explicit requirement when implementing packet handling queues, then it's
> probably fine to note that clearly, and maybe to explain the reasoning
> behind
> the RECOMMENDED vs. OPTIONAL mitigations in section 1.
>
> I am frankly more concerned that RFCs 7298 and 8967 both made it to
> publication
> with only one mention of the word "reordering" between them, perhaps
> suggesting
> a lack of vendor attention to, or knowledge of, the work being done in this
> space. Given the near complete absence of any normative prohibition against
> packet reordering in datagram handling, this oversight may reflect
> insufficient
> prior outreach to subject matter experts that should be noted and
> corrected by
> ADs in future work for which packet handling behavior by on-path devices
> is of
> critical importance to protocols being developed.
>
> Other notes:
>
> Section 3.1.1. If the problem with maintaining more queues is that the
> 4-tuple
> comprises "the only fields...protected by the MAC", a natural solution
> might be
> to protect that field, as well. I'm not suggesting that is desirable;
> rather, I
> note there is no discussion in this draft, or in RFC 8967, discussing the
> motivation behind the choice of header fields to protect with the MAC.
>
> Nits: there is an HTML entity rendered as literal text ("Gr&#246;ber") in
> the
> Acknowledgements section of the HTML I am reading
> (https://www.ietf.org/archive/id/draft-ietf-babel-mac-relaxed-04.html).
> Make
> sure to follow tools guidance for encoding non-Latin characters in drafts.
>
>
>
> _______________________________________________
> babel mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/babel
>