|
Dear Tero, Med and Rob Thanks a lot for the SECDIR review. Below the feedback from the authors inline.
Looking forward to your feedback and please let me know if we should proceed to add suggested paragraph in the security section for the document version. Best wishes Thomas TK> 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]. TK> 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. TK> 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). TG> The authors believe that the security consideration section in RFC7012 Are adequately describing what needs to be taken care to ensure privacy concerns. However the following sentence helps the implementers to remind what kind of data is being exported and privacy concerns shall be
properly addressed. We propose therefore to extend the Security Considerations with the following paragraph in -09 version:
TG Example> Privacy Considerations described in Section 11.8 of [RFC7012] SHOULD be considered for all described IEs. They export provider data plane metrics which describe how packets are being forwarded within the SRv6 core network. TK> 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? TG> If the IPFIX metering process would implement srhSegmentIpv6BasicList and srhSegmentIPv6ListSection differently, intentionally or unintentionally, then this document describes, the IPFIX data collection process would simply collect different values and a network operator would see that they won't match. However this is a very unlikely scenario as the operational consideration states since it does not make sense to implement both because they expose the same information with a different structure. Even in the case of one collector receiving
srhSegmentIPv6BasicList and another one receiving srhSegmentIPv6ListSection,
the same conclusions hold. TK> 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. TG> The document doesn't prevent to implement both at the same time. The phrasing Is correct. TK> 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? TG> Besides that both would be exported, nothing else would happen. ---- 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? |
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
