Reviewer: Tero Kivinen Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document adds new information elements for transmitting segment routing over IPv6 related information over IPFIX. The security considerations section claims: There exists no significant extra security considerations regarding allocation of these new IPFIX IEs compared to [RFC7012]. The first question is that if there is no significant extra security considerations, so what non-significant extra security considerations there is? On the other hand the 7012 security considerations say: The IPFIX information model itself does not directly introduce security issues. Rather, it defines a set of attributes that may, for privacy or business issues, be considered sensitive information. For example, exporting values of header fields may make attacks possible for the receiver of this information; this would otherwise only be possible for direct observers of the reported Flows along the data path. The underlying protocol used to exchange the information described here must therefore apply appropriate procedures to guarantee the integrity and confidentiality of the exported information. These protocols are defined in separate documents, specifically the IPFIX protocol document [RFC7011]. Meaning that this document should explain whether any of the attributes it exports have any privacy concerns, or whether it exports header values which attacker might not otherwise have. So the security considerations should mention whether any of those information elements it export has any privacy concerns or not (and if so, add note that the protocol transporting these should provide suitable security). Also this document allows two ways of exporting same information (srhSegmentIpv6BasicList and srhSegmentIPv6ListSection). This always causes a question what can someone do if it provides both but the values are different? Can it cause that one data collector parses one list and another data collector uses the other list, and can it then cause differences in the collectors behavior based on which one they used? Are both of them allowed to be used at the same time? The operational considerations say that: It is not expected that an exporter would support both srhSegmentIPv6BasicList and srhSegmentIPv6ListSection at the same time. But it is not explained what happens if both are used at the same time, and what happens if both are used but the contents is different? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
