Unfortunate History of Transient Numeric Identifiers
draft-irtf-pearg-numeric-ids-history-11

# Internet AD comments for {draft-irtf-pearg-numeric-ids-history-10}
CC @ekline

## Discuss

## Comments

### S1, S4.4

* It's not clear that NTP refids belong in this list as currently described.
  Specifically, I don't think they're exactly "transient" in the same way
  these other examples are.

  But seeing as how you want to include the discussion of them vis.
  information leakage, I can't see any rewording that would be brief.

### S3

* You could just come out and explicitly say: on path attackers are excluded
  the threat model considered by this document (seems like there's a lot of
  text here that amounts to: we're not considering on path attackers).

## Nits

### S2

* "definitely distinguish" seems overkill  =)
  "distinguish" ought to suffice

### S4.3

* Everywhere an RFC is mentioned by number it doesn't seem like it adds
  anything to have "(formerly draft-foo)", but maybe that's for the
  RFC Editor to decide.

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has reviewed draft-irtf-pearg-numeric-ids-history-10 and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
IANA Operations Manager

[Ballot 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?

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?

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

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

- 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? But that's not what I'm getting from the text.

And it doesn’t help that in Section 3, “sample transient numeric identifiers” means “to sample transient numeric identifiers” - so, there, “sample” is a verb.

[Ballot 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 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?

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?

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

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

- 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? But that's not what I'm getting from the text.

And it doesn’t help that in Section 3, “sample transient numeric identifiers” means “to sample transient numeric identifiers” - so, there, “sample” is a verb.

[Ballot comment]
This document is ready for publication on the IRTF stream.

Two questions, though (my Yes here does not depend on the answers):

(1) I notice that most of the chronologies seem to shift from academic citations to I-Ds and don't shift back; did academia lose interest in these issues at that time, or did the literature search only cover the time before the discussion moved to various IETF working groups?

(2) The document has a significant number of informative references to abandoned I-Ds. Were these submitted for adoption by the associated WGs (i.e., it'd be interesting to know if the WG process failed to address mitigations for these identification issues), or merely intended as points of discussion?

# Document Shepherd

Sara Dickinson

# Technical Summary

This document performs a detailed review of the history of both specification activities in the IETF of transient numeric identifiers, and the implementation of the resulting RFCs. It analyses how the security and privacy properties of the resulting protocols and various implementations have evolved over time, and highlights that in some cases the same sub-optimal patterns have occurred for different identifiers. It servers as a motivational document for two other drafts, I-D.irtf-pearg-numeric-ids-generation and I-D.gont-numeric-ids-sec-considerations which provide guidance on how to improve the process in future.

# Document Quality

The document was initially published in 2016, and has received a variety of reviews following presentation in the SEC area and in SECDISPATCH at different times. It underwent multiple revisions before being presented to PEARG in July 2019 where it was adopted in August 2019. It has received several further reviews from the PEARG members and passed RGLC in December 2020.

Note that the nits tool shows many obsoleted references, but this it to expected given the nature of the document as a review article.