Joe,
On 17/12/20 20:35, Joseph Touch wrote:
On Dec 14, 2020, at 9:12 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx
<mailto:fgont@xxxxxxxxxxxxxxx>> wrote:
Flawed IDs introduce problems. IDs that are not flawed do not.
Christian has expressed much of my position, with the exception of the
following:
I don't know what's his "position". Reality is that we have been
receiving objections against our document for things that are not even
in our document.
I've explained that the requirements are in Section 5. Reqs #1-#2 simply
spells out that every specs should nevertheless do. Req #3, says "if
you've found issues, just suggest an algorithm that deals with it in the
best possible way. Perios.
IMO - protocols MUST NOT limit how IDs are selected or used. The issue
isn’t the protocol spec; it’s the implementation.
Current protocol specs not only do not spell out the interoperability
requirements, but also over-specify the generation of their IDs.
Transient numeric IDs have interoperability constraints that you must
comply with. When implementations enforce further requirements without
an interoperability rationale *THAT* is a protocol limiting the IDs.
What we mean is:
#1: Spell out the interop req. i.e., tell us the properties that the IDs
must have. -- we want to know the minium requirements the IDs need to
comply to.
#2: Analyze the possible implications of such IDs.
#3: If you found any possible issues in #2, just suggest something to
the implementer that complies with #1 and deals gracefully with #2.
We devote to protocol specs and have produced flawed specifications in
this respect for a long time. Why should we expect every single
implementer to do this analysis on their own to come up with a sensible
algorithm?
What I want to avoid is breaking the potential for IoT devices to use
these protocols simply because they can’t implement the approaches
described here.
Fair enough. Now when picking an algorithm, you'll probably have, say,
the best option which might be more expensive and mitigate most/all
issues, and, say, a lightweight version that e.g. mitigates some/most
issues.
Explain the trade-offs of which, and suggest implementers when to use
which ("this one is most sensible for constrained devices, and this one
is sensible for the general case"). Done.
I also want to avoid a receiver saying “hey, sender, you picked the IDs
badly, so I won’t connect to you”.
That's of course sensible. And that's why we have #1.
THe only way in which you can avoid this is when the interoperability
requirements are clear. Now when talking about some of QUIC's IDs, and
asking for why things are done, Christian response was, essentially,
"oh, that's in the mail archive of the tons of discussions we have had".
That approach of coming up with requirements is doom to led to both
interoperability problem (because you don't know what to comply with for
things to work), and security/privacy issues (because there's no
analysis of the implications of such IDs).
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
