Thanks for the great review. Comments Inline. On Wed, Oct 7, 2026 at 12:52 PM Roman Danyliw via Datatracker <[email protected]> wrote: > > 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/ > > > OLD:
| Packet insertion and | Trusted domains and filtering (7.1)| | replaying (6.2.3) | Encapsulation of packets (7.2) | | | HMAC (7.3) | | | MACsec (7.6) | NEW: | Packet insertion and | Trusted domains and filtering (7.1)| | replaying (6.2.3) | Encapsulation of packets (7.2) | | | MACsec (7.6) | > ---------------------------------------------------------------------- > 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. How does this sound: OLD: 2. A packet containing an SRH may not be destined to the SR domain, as it may be simply transiting the domain. Therefore, filtering solely based on the presence of an SRH, at either SR ingress or SR egress, is not necessarily recommended. Instead, this scenario is mitigated by encapsulating packets on the domain boundary, as discussed in Section 7.2. While inter-SR-domain scenarios are a violation of the trust model described above, the operational practices recommended here aim to preserve interoperability and avoid blanket behaviors that would break SR when adjacent networks follow different practices. For these reasons SRH filtering is not necessarily a useful method of mitigation. NEW: 2. A packet containing an SRH may not be destined to the SR domain, as it may be simply transiting the domain. Such a packet is not destined to a SID of the domain, so it is forwarded as a plain IPv6 packet and its SRH is not inspected within the domain (Section 4.2 of [RFC8754]); a packet from outside the domain that is destined to a SID of the domain is dropped by the filtering described in Section 7.1.3. Packets from outside the SR domain are therefore not processed as SRv6 within it. Therefore, filtering solely based on the presence of an SRH, at either SR ingress or SR egress, is not a useful method of mitigation. Where such transit traffic is carried across the SR domain using SRv6, it is encapsulated at the domain boundary as discussed in Section 7.2: the received packet, including any SRH, becomes the payload of an outer IPv6 header originated within the domain, and is tunneled through the transit SR domain without exercising SRv6 functions there. While inter-SR-domain scenarios are a violation of the trust model described above, the operational practices recommended here aim to preserve interoperability and avoid blanket behaviors that would break SR when adjacent networks follow different practices. > > ** 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. OLD: When the O-flag is used for OAM functions, as defined in [RFC9259], implementations should enforce rate limiting to mitigate potential DoS attacks triggered by excessive control plane signaling. NEW: When the O-flag is used for OAM functions, Section 2.1.1 of [RFC9259] requires the processing node to rate-limit the number of packets punted to the OAM process, which mitigates denial-of-service attacks that exploit the O-flag. Roman Danyliw DISCUSS 3 — Section 7.7 mitigation table > > ** 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 ]== Please excuse the formatting here, it probably won't translate to email: OLD: | Packet insertion and | Trusted domains and filtering (7.1)| | replaying (6.2.3) | Encapsulation of packets (7.2) | | | HMAC (7.3) | | | MACsec (7.6) | NEW: | Packet insertion and | Trusted domains and filtering (7.1)| | replaying (6.2.3) | Encapsulation of packets (7.2) | | | MACsec (7.6) | > > > I have implemented these in -18, if they meet your approval I can incorporate them with the next submission. > > _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
