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@ietf.org if you reply to or forward this review. The purpose of this document appears to be to distill lessons from draft-irtf-pearg-numeric-ids-history and draft-irtf-pearg-numeric-ids-generation (both of which I found informative) into actionable advice for draft authors. However, the document's Section 5 contains no normative statements and recommendation 2 is seems somewhat too broad in introducing a privacy considerations requirement. It may be possible to fix this Section by couching recommendations 1 and 3 probably as mandatory and focusing recommendation 2 on security while citing the details of potential security vulnerabilities covered in draft-irtf-pearg-numeric-ids-generation Section 8. An alternative to a BCP might be to attempt to achieve the goals in some other way, such as adding the issues raised in the predecessor documents to those considered in Directorate reviews. Overall, if the intent is to move the IETF toward requiring privacy considerations in documents, more extensive guidance is required than is provided here. For example, SDOs such as the W3C now expend considerable effort on identifying issues relating to fingerprinting, a topic which is only touched on in this document. The emphasis appears to be not on privacy issues in general as on implementation lessons learned from the use of transient identifiers used in unsecured protocols. If so, a BCP may not be the best way to influence implementers. If the focus is to be on draft authors, then as the IETF addresses some of the security gaps (e.g. QUIC versus TCP, DNS privacy) it would be useful to clarify how much of the advice remains relevant (e.g. which advice applies to fields that lack confidentiality and/or integrity protection, what threats persist even with end-to-end security). Specific comments: Abstract Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks... To prevent such flaws in future protocols and implementations, this document updates RFC 3552, requiring future RFCs to contain analysis of the security and privacy properties of any transient numeric identifiers specified by the protocol. [BA] For a privacy analysis, why focus only on "transient" numeric identifiers? 1. Introduction Network protocols employ a variety of transient numeric identifiers... poor selection of numeric identifiers, usually as a result of... [BA] The first paragraph mentions "transient numeric identifiers" whereas the second paragraph just uses the term "numerical identifiers", potentially broadening the scope of concern to issues such as fingerprinting. Was this intentional? o Predictable TCP sequence numbers o Predictable transport protocol numbers o Predictable IPv4 or IPv6 Fragment Identifiers o Predictable IPv6 IIDs o Predictable DNS TxIDs [BA] References? Is the intent to restrict the examples only to unsecured protocols and fields sent in cleartext? As a result, advice in this area is warranted. [BA] A BCP needs to go beyond "advice", to providing actionable (and normative) guidance. 3. Issues with the Specification of Transient Identifiers Finally, there are protocol implementations that simply fail to comply with existing protocol specifications. That is, appropriate guidance is provided by the protocol specification (whether the core specification or or an update to it), but an implementation simply fails to follow such guidance. For example, some popular operating systems (notably Microsoft Windows) still fail to implement transport-protocol port randomization, as specified in [RFC6056]. [BA] Is the audience implementers or document authors? 4. Common Flaws in the Generation of Transient Identifiers This Section would seem to fit well as a summary within draft-irtf-pearg-numeric-ids-history When one identifier is employed across contexts where such constancy is not needed, activity correlation is made made possible. For example, employing an identifier that is constant across networks allows for node tracking across networks. [BA] This can be relevant even if the identifier is encrypted (e.g. if the attacker is a website utilizing the identifier for fingerprinting). 5. Security and Privacy Requirements for Identifiers When a protocol specifies transient numerical identifiers, it is critical for the protocol specification to: 1. Clearly specify the interoperability requirements for the aforementioned identifiers (e.g., required properties such as uniqueness, along with the failure severity if such properties are not met). 2. Provide a security and privacy analysis of the aforementioned identifiers. 3. Recommend an algorithm for generating the aforementioned identifiers that mitigates security and privacy issues, such as those discussed in [I-D.irtf-pearg-numeric-ids-generation]. [BA] Recommendations 1 and 3 seem reasonable, but probably should be couched in normative language. Recommendation 2 would appear to require reworking; the document is not specific enough to serve as a guideline for a privacy considerations section. Perhaps a reference should be provided to the security vulnerabilities covered in draft-irtf-pearg-numeric-ids-generation Section 8.