Roman Danyliw has entered the following ballot position for draft-ietf-spring-srv6-security-17: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** Sections 7.1.1 and 7.1.2. -- Section 7.1.1 says “the current document assumes that SRv6 is a trusted domain and that the traffic is filtered at the domain boundaries. Filtering at SR ingress nodes is intended to mitigate modification and insertion attacks, while filtering at SR egress nodes is intended to mitigate outbound leaks.” -- Section 7.1.2 says “A packet containing an SRH may not be destined to the SR domain, as it may be simply transiting the domain.” These sections appears to be providing conflicting guidance on what crosses the domain boundary of a trusted domain. Section 7.1.1 appears to suggest that SR traffic gets dropped on ingress and egress of the boundary. However, Section 7.1.2 suggests that SR domain might accept packets transiting from outside an SR domain which seems like the definition of an “insertion attack” (inconsistent with the guidance in Section 7.1.1). Likewise, it seems difficult for a node on the boundary of the trust domain to distinguish between SRH legitimately transiting the network from a leaked or forged SRH. Section 7.2 could be suggesting that this language in Section 7.1.2 applies to encapsulated traffic. Is that the only case? If so, the text could be clearer. ** Section 7.4 When the O-flag is used for Operations, Administration, and Maintenance (OAM) functions, as defined in [RFC9259], implementations should enforce rate limiting to mitigate potential denial-of-service (DoS) attacks triggered by excessive control plane signaling. The above guidance seems to be a weaker restated of Section 2.1.1 of RFC9259: The processing node MUST rate-limit the number of packets punted to the OAM process to a configurable rate. This is to avoid impacting the performance of the OAM and telemetry collection processes. Failure to implement the rate limit can lead to a denial-of-service attack, as detailed in Section 3. This document’s text suggests there is flexibility and RFC9259 seems very clear with mandatory guidance. ** Section 7.7, Figure 3 This section lists HMAC as a mitigation for replay attacks. It might be possible to construct a protocol design that makes this possible, but the HMAC TLV defined in RFC8754 doesn’t appear to do that alone. Section 7.3 of this document seems to acknowledge that with the following text: ==[ snip from Section 7.3 ]== * For the lifetime of the pre-shared key validity, an internal attacker who does not have access to the pre-shared key can capture legitimate packets, and later replay the SRH and HMAC from these recorded packets. ==[ snip ]== _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
