On 18/12/20 01:18, Iván Arce (Quarkslab) wrote:
Hello
On 12/17/20 9:51 PM, Joe Touch wrote:
On Dec 17, 2020, at 4:21 PM, Ted Lemon <mellon@xxxxxxxxx> wrote:
On Dec 17, 2020, at 6:47 PM, Joseph Touch <touch@xxxxxxxxxxxxxx
<mailto:touch@xxxxxxxxxxxxxx>> wrote:
What you add as a requirement ends up excluding as a platform. That’s
the antithesis of Internet design.
The point is that these are tradeoffs of *implementation*, and should
not be described as protocol deficiencies.
It sounds like what you’re saying is that it’s a SHOULD, not a MUST?
At the *protocol* level, it’s nothing. Only as an implementation
suggestion.
As noted before, RFC 6528, a proposed standard, already mandates with
SHOULD and algorithm to generate TCP ISNs
(https://tools.ietf.org/html/rfc6528#page-4)
Also, RFC 3550 "Real Time Protocol" (RTP), an Internet Standard, has
very specific guidance for how to generate certain identifiers:
(https://tools.ietf.org/html/rfc3550#page-59)
It is also not sufficient to obtain an SSRC identifier simply by
calling random() without carefully initializing the state. An
example of how to generate a random identifier is presented in
Appendix A.6.
And RFC2460 suggested to generate the IPv6 Frad ID with a global
counter, and this is rfc793 for the ISN:
To avoid confusion we must prevent segments from one incarnation of a
connection from being used while the same sequence numbers may still
be present in the network from an earlier incarnation. We want to
assure this, even if a TCP crashes and loses all knowledge of the
sequence numbers it has been using. When new connections are created,
an initial sequence number (ISN) generator is employed which selects a
new 32 bit ISN. The generator is bound to a (possibly fictitious) 32
bit clock whose low order bit is incremented roughly every 4
microseconds. Thus, the ISN cycles approximately every 4.55 hours.
Since we assume that segments will stay in the network no more than
the Maximum Segment Lifetime (MSL) and that the MSL is less than 4.55
hours we can reasonably assume that ISN's will be unique.
etc., etc., etc.
Joe knows this, of course.
But I guess the goal here is not to do collaborative work and improve
the document, but to thwart its publication.
[..]
Our draft does not mandate any algorithm, it mandates that protocol
authors do an analysis of impact of the transient identifiers they put
in their protocols, document that analysis, and recommend appropriate
algorithms. It does not say that any said algorithm must be a MUST.
Perhaps we could add text saying that protocol authors should not forbid
that implemeters not comply with the recommended algorithms.
It's simple: it's up to the implementation whether they want to have the
algorithm be a "MUST", "SHOULD", or anything else. Or simply suggest one
possible way to generate the numeric ID, even without RFC2119 language
"The following figure illustrates one possible algorihtm...."
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
