Re: [Pearg] Spencer Dawkins' Yes on draft-irtf-pearg-numeric-ids-history-09: (with COMMENT)

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Fernado,

On Thu, Jun 16, 2022 at 9:37 PM Fernando Gont <[e-mail]> wrote:

> Hi, Spencer,
>
> Thanks so much for your comments and input! -- In-line...
>
> On 16/6/22 19:33, Spencer Dawkins via Datatracker wrote:
> [....]
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > At a 10K meter level, I love everything about this document. I remember
> > probably 60-70 percent of this history, some of which I was reading about
> > before I started participating in the IETF in 1997, I learned from the
> parts I
> > didn't remember and had probably never seen, and there's no way I could
> have
> > described all of it as well as you did.
> >
> > I wish we had more documents explaining why the IRTF is doing research on
> > aspects of widely deployed protocols.
> >
> > I do have two or three nits about readability and consistency, but I'm
> already
> > a Yes, so Do The Right Thing - I can't say "it's ready" any more clearly
> than
> > balloting "Yes".
> >
> > - Honest question here. In this text from the Introduction,
> >
> > “For more than 30 years, a large number of implementations of the TCP/IP
> > protocol suite have been subject to a variety of attacks, with effects
> ranging
> > from Denial of Service (DoS) or data injection, to information leakages
> that
> > could be exploited for pervasive monitoring [RFC7258]. The root cause of
> these
> > issues has been, in many cases, poor selection of transient numeric
> > identifiers, usually as a result of insufficient or misleading
> specifications.”
> >
> > Does “TCP/IP protocol suite” mean what you intend it to mean?
>
> Well, we used the term as it has been used in classical books such as
> "TCP/IP Illustrated" (Stevens)  or "Internetworking with TCP/IP"
> (Comer). It has also been used by Bellovin in “Security Problems in the
> TCP/IP Protocol Suite”
> (https://www.cs.columbia.edu/~smb/papers/acsac-ipext.pdf)
>   -- but it's also possible that it could mean different things to
> different people.
>

I take your point here, but I also wonder if the term is understood by most
people today, the way it was understood in 1994 (when Stevens was first
published) or 1988 (when Comer was first published). 😉

In related news, OMG I'm old, because I used the first editions of both of
these heavily. But I digress.


> But we could also probably s/TCP\/IP protocol suite/Internet protocols/
> or s/TCP\/IP protocol suite/IETF protocols/ or s/TCP\/IP protocol
> suite/Internet protocol suite/
>
> I'm fine in all cases :-)
>

Looking at your suggestions when I'm awake, I like

 s/TCP\/IP protocol suite/IETF protocols/


best - I think it's the most accurate description.

Do The Right Thing, of course.


> > You follow this with a list of examples that (if I understand correctly)
> > include IPv4, IPv6, “transport protocols”, TCP, and DNS. Just poking at
> one of
> > the references, The Introduction of RFC 6056 calls out
> >
> >     TCP [RFC0793], UDP [RFC0768], SCTP [RFC4960], DCCP
> >     [RFC4340], UDP-lite [RFC3828], and RTP [RFC3550] (provided the RTP
> >     application explicitly signals the RTP and RTCP port numbers with,
> >     e.g., [RFC3605]).
> >
> > Perhaps those protocols should be part of what I think of when I hear
> “TCP/IP
> > protocol suite”, but they aren’t.
> >
> > - I might have suggested “implementations of Internet network-layer and
> > transport-layer protocols”, but even that doesn’t include DNS, which is
> on your
> > list. And a quick peek at Section 4.4 mentions problems with NTP
> Reference IDs
> > (REFIDs), which is NOT mentioned in the Introduction, but is described
> later in
> > the document, while problems with DNS TxIDs, which is mentioned in the
> > Introduction, is NOT described in Section 4 (the detailed discussion of
> DNS in
> > Section 4 is about predictable port numbers used by DNS
> implementations). Maybe
> > the transient numeric identifier problems with those two
> application-level
> > protocols could be treated consistently in Section 1 and Section 4?
>
> You mean mention all examples in all places/sections?


So my other comment was that the list of examples in the introduction
doesn't match the detailed discussion in Section 4, and I can't think of a
good reason to do that.

ISTM that if you want people to find information about NTP Reference IDs in
Section 4, it should be in the list of examples in the Introduction.

ISTM that if you don't want people to look for information in DNS TxIDs in
Section 4 because there's not any, this shouldn't be in the list of
examples in the Introduction.

   - If you have something to say about DNS TxIDs, adding a short section
   with appropriate references, as you do in the rest of Section 4, would
   match the Introduction.
   - If you don't have anything to say about  DNS TxIDs, you could just as
   easily remove that from the list of examples in the Introduction.

Does that make sense?

> - In Section 4,the phrase “A number of protocol specifications” is used.
> Is
> > that a better way to say what you mean in Section 1 and Section 5? Or is
> there
> > a better way to describe the protocols you’re thinking of in the
> Introduction,
> > without attempting to list them exhaustively?
>
> Please see my proposal above.
>

I like your proposal above.


>
> > - I should also mention that Section 5 also uses the phrase “large
> number of
> > implementations of the TCP/ IP protocol suite”. Whatever you do with this
> > phrase in Section 1, you should probably consider doing in Section 5 as
> well.
>
> Agreed.
>
>
> >
> > - I also have a point of confusion with the phrase “sample transient
> numeric
> > identifiers” in Section 1, and in Section 4. "sample" seems like an
> adjective
> > in those usages. I THINK (correct me if I’m wrong) that this phrase is
> intended
> > to mean “some transient numeric identifiers that have been found to be
> > problematic” - because this isn’t a complete list of the problematic
> > identifiers, right?
>
> Exactly! ("English as a second language" might be playing a role here :-) )
>
> Any suggested tweaks here?
>

Sure. I was thinking you could use

“some transient numeric identifiers that have been found to be problematic”


but tweaking that a bit more to use your proposal above gives

“some transient numeric identifiers used in IETF protocols that have been
found to be problematic”


Does that make sense?

Best,

Spencer


> Thanks!
>
> Regards,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>