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 <noreply@xxxxxxxx> 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
tsv-art@xxxxxxxx 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ö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
babel@xxxxxxxx
https://www.ietf.org/mailman/listinfo/babel
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
