Roman, I believe we have addressed these in revision -19, please let us know if these meet your requirements and what else we need to address.
Thanks! nb On Mon, Oct 12, 2026 at 9:44 AM Nick Buraglio <[email protected]> wrote: > 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]
