Yes, I will do that. If you want I can break them all out - it was simply a time saving experiment on my part (FWIW, I don't know that it actually saved me any time and probably ended up consuming more). Thank you all for the very good suggestions, I think it makes the document all the better.
nb On Tue, Oct 13, 2026 at 1:13 PM Ketan Talaulikar <[email protected]> wrote: > > Hi Nick, > > Thanks for your response. I see that you've tried to consolidate and tackle > the comments from all ADs together. This makes sense and thanks for doing it > this way. > > It makes things a bit harder though for me, but from a quick glance the > changes seem to address my concerns. Thanks for considering the suggestions. > To help me confirm, could you please merge these PRs and post them to the > datatracker so I can update my ballot? > > Thanks, > Ketan > > > On Tue, Oct 13, 2026 at 7:28 AM Nick Buraglio <[email protected]> > wrote: >> >> Thanks for the really thorough feedback. Lots of work inline, also >> addressing all comments since many of them overlap. If folks prefer me >> to break them into individual emails, I can do that, too. For those >> that like me prefer the diffs, they can be viewed >> https://github.com/buraglio/draft-bdmgct-spring-srv6-security/pull/80/changes >> and >> https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-spring-srv6-security&url_2=https://buraglio.github.io/draft-bdmgct-spring-srv6-security/draft-ietf-spring-srv6-security.txt >> (both should be the same diff, different presentation so folks have >> options to use what they're comfortable with). >> >> nb >> >> On Thu, Oct 8, 2026 at 8:47 AM Ketan Talaulikar via Datatracker >> <[email protected]> wrote: >> > >> > Ketan Talaulikar 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: >> > ---------------------------------------------------------------------- >> > >> > Many thanks to the authors and the WG for this important work on SRv6 >> > security considerations. This would be very helpful for everyone >> > implementing >> > and deploying SRv6. >> > >> > Note: This review is provided inline in the idnits output of v17 of this >> > document. Please look for the tag <EoRv17> at the end to ensure you have >> > the >> > full review. >> > >> > There are a couple of topics that I would like to discuss from a >> > clarification >> > perspective. I've also offered some suggestions for your consideration. >> > >> > <discuss-1> Comparison with an unspecified non-SRv6 baseline (Section 5) >> > >> > 291 forwarding of IPv6 packets via predetermined SR policies, which >> > 292 determine the paths and the processing of these packets. An >> > attack >> > 293 on SRv6 may cause packets to traverse arbitrary paths and to be >> > 294 subject to arbitrary processing by SR endpoints and transit >> > routers >> > 295 within an SR domain. This may allow an attacker to perform a >> > number >> > 296 of attacks on the victim networks and hosts that would be mostly >> > 297 unfeasible for a non-SRv6 environment. >> > >> > The non-SRv6 environment that is being referenced here is not specified. I >> > would >> > like to understand which all alternatives were considered and evaluated: >> > MPLS >> > (including SR-MPLS), IP encapsulations and overlays (IP-in-IP, GRE, >> > MPLS-in-IP/UDP, >> > VXLAN, Geneve), and plain IP networks? >> > >> > Are points in this section specific to SRv6? RFC 8402 Section 8.2 lists >> > these >> > as problems that arise "when the assumed trust model is violated". The >> > some of >> > the IP encapsulations share the SR domain's trust model (RFC 4023 Section >> > 8, >> > RFC 7510 Section 6, RFC 8926 Section 6, and more ...), and SRv6 adds an >> > optional SRH integrity check, a dedicated SID prefix and summarizable >> > locators. >> > >> > How about: >> > >> > CURRENT >> > determine the paths and the processing of these packets. An attack >> > on SRv6 may cause packets to traverse arbitrary paths and to be >> > subject to arbitrary processing by SR endpoints and transit routers >> > within an SR domain. This may allow an attacker to perform a number >> > of attacks on the victim networks and hosts that would be mostly >> > unfeasible for a non-SRv6 environment. >> > SUGGEST >> > determine the paths and the processing of these packets. When the >> > trust model of the SR domain [RFC8402] is not enforced, an attack on >> > SRv6 may cause packets to traverse arbitrary paths and to be subject >> > to arbitrary processing by SR endpoints and transit routers within an >> > SR domain. As with source routing and tunneling in other IP networks >> > [RFC6169], this may allow an attacker to perform a number of attacks >> > on the victim networks and hosts. >> >> OLD: >> An attack on SRv6 may cause packets to traverse arbitrary paths and to >> be subject to arbitrary processing by SR endpoints and transit routers >> within an SR domain. This may allow an attacker to perform a number of >> attacks on the victim networks and hosts that would be mostly >> unfeasible for a non-SRv6 environment. >> >> NEW: >> When the trust model of the SR domain [RFC8402] is not enforced, an >> attack on SRv6 may cause packets to traverse arbitrary paths and to be >> subject to arbitrary processing by SR endpoints and transit routers >> within an SR domain. As with source routing and tunneling in other IP >> networks [RFC6169], this may allow an attacker to perform a number of >> attacks on the victim networks and hosts. >> >> > >> > And then, perhaps at the end of section 5 add the following? >> > >> > NEW >> > The effects listed above are not specific to SRv6. They are shared by >> > source routing and tunneling in IP networks [RFC5095] [RFC6169], and >> > IP encapsulations such as IP-in-IP, GRE, MPLS-in-UDP, VXLAN, and >> > Geneve operate under the same model of a trusted domain protected by >> > filtering at its boundary [RFC4023] [RFC7510] [RFC8926]. In addition, >> > SRv6 provides an optional integrity check of the SRH (Section 7.3), a >> > dedicated IPv6 prefix for SIDs that simplifies that filtering >> > [RFC9602], and locators that can be summarized (Section 7.1.3). >> >> >> OLD: >> None >> >> NEW: >> The effects listed above are not unique to SRv6; they are shared by >> source routing and tunneling in other IP networks [RFC5095] [RFC6169]. >> IP encapsulations such as IP-in-IP, GRE, MPLS-in-UDP, VXLAN, and >> Geneve operate under the same model of a trusted domain protected by >> filtering at its boundary [RFC4023] [RFC7510] [RFC8926]. In addition, >> SRv6 provides an optional integrity check of the SRH (Section 7.3), a >> dedicated IPv6 prefix for SIDs that simplifies filtering [RFC9602], >> and locators that can be summarized (Section 7.1.3). >> > >> > >> > <discuss-2> Characterisation of boundary filtering (Section 7.1.1) >> > >> > 837 It should be noted that relying on perfectly crafted filters on >> > all >> > 838 edges of the trusted domain poses a demonstrable risk of >> > inbound or >> > 839 outbound leaks if the filters are removed or adjusted >> > erroneously. >> > 840 It is also important to note that some filtering >> > implementations have >> > 841 limits on the size, complexity, or protocol support that can be >> > 842 applied, which may prevent the filter adjustments or creation >> > 843 required to properly secure the trusted domain for a new >> > protocol >> > 844 such as SRv6. Such an approach is commonly referred to as >> > "fail- >> > 845 open", which inherently contains more risk than fail-closed >> > 846 methodologies. >> > >> > 848 Practically speaking, this means successfully enforcing a >> > "Trusted >> > 849 Domain" may be operationally difficult and error-prone in >> > practice, >> > 850 and that attacks that are expected to be unfeasible from >> > outside the >> > 851 trusted domain may actually become feasible when any of the >> > involved >> > 852 systems fails to enforce the filtering policy that is required >> > to >> > 853 define the Trusted Domain. >> > >> > This presents boundary filtering as fragile and as a particular difficulty >> > for >> > "a new protocol such as SRv6". Two points from the documents this one >> > builds >> > on are missing. First, following RFC 8754 the filtering is simple and of >> > low >> > scale: SIDs come from a block that summarizes into a few prefixes, and RFC >> > 8754 >> > Section 7 notes that "ACLs are easily supported for small numbers of seldom >> > changing prefixes"; the filters are ordinary IPv6 address filters, not >> > protocol >> > parsing. Second, this is how the infrastructure of any IP network is >> > protected >> > (RFC 9099 Section 3.1; RFC 7510 Section 6 for MPLS-in-UDP; RFC 8926 >> > Section 6 >> > for Geneve), so the risk of a missing filter is not specific to SRv6. >> > Suggest >> > keeping the caution of these paragraphs with the following changes; the >> > "fail-open" sentence then also follows the condition it names: >> > >> > CURRENT >> > It should be noted that relying on perfectly crafted filters on all >> > edges of the trusted domain poses a demonstrable risk of inbound or >> > outbound leaks if the filters are removed or adjusted erroneously. >> > It is also important to note that some filtering implementations have >> > limits on the size, complexity, or protocol support that can be >> > applied, which may prevent the filter adjustments or creation >> > required to properly secure the trusted domain for a new protocol >> > such as SRv6. Such an approach is commonly referred to as "fail- >> > open", which inherently contains more risk than fail-closed >> > methodologies. >> > >> > Practically speaking, this means successfully enforcing a "Trusted >> > Domain" may be operationally difficult and error-prone in practice, >> > and that attacks that are expected to be unfeasible from outside the >> > trusted domain may actually become feasible when any of the involved >> > systems fails to enforce the filtering policy that is required to >> > define the Trusted Domain. >> > >> > SUGGEST >> > As in any IP network whose security relies on filtering at its >> > boundary, relying on correctly configured filters on all edges of the >> > trusted domain poses a risk of inbound or outbound leaks if the >> > filters are removed or adjusted erroneously. When SIDs are allocated >> > as described in [RFC8754] and Section 7.1.3, the required filters are >> > few and stable: they match a small number of summarized prefixes, >> > which Section 7 of [RFC8754] notes are easily supported by ACLs, >> > using the same IPv6 address filters that protect the infrastructure >> > of other IP networks [RFC9099]. Where some filtering implementations >> > nevertheless have limits on size or complexity (Section 8.2) that >> > prevent the required filters from being applied, the domain is >> > "fail-open", which inherently contains more risk than fail-closed >> > methodologies. >> > >> > Practically speaking, this means that, as for other IP networks, >> > enforcing a "Trusted Domain" depends on operational discipline, and >> > that attacks that are expected to be unfeasible from outside the >> > trusted domain may become feasible when any of the involved systems >> > fails to enforce the filtering policy that is required to define the >> > Trusted Domain. >> >> OLD: >> It should be noted that relying on perfectly crafted filters on all >> edges of the trusted domain poses a demonstrable risk of inbound or >> outbound leaks if the filters are removed or adjusted erroneously. It >> is also important to note that some filtering implementations have >> limits on the size, complexity, or protocol support that can be >> applied, which may prevent the filter adjustments or creation required >> to properly secure the trusted domain for a new protocol such as SRv6. >> Such an approach is commonly referred to as "fail-open", which >> inherently contains more risk than fail-closed methodologies. >> >> Practically speaking, this means successfully enforcing a "Trusted >> Domain" may be operationally difficult and error-prone in practice, >> and that attacks that are expected to be unfeasible from outside the >> trusted domain may actually become feasible when any of the involved >> systems fails to enforce the filtering policy that is required to >> define the Trusted Domain. >> >> >> NEW: >> As in any IP network whose security relies on filtering at its >> boundary, relying on correctly configured filters on all edges of the >> trusted domain poses a risk of inbound or outbound leaks if the >> filters are removed or adjusted erroneously. When SIDs are allocated >> as described in [RFC8754] and Section 7.1.3, the required filters are >> few and stable: they match a small number of summarized prefixes, >> which Section 7 of [RFC8754] notes are easily supported by ACLs, using >> the same IPv6 address filters that protect the infrastructure of other >> IP networks [RFC9099]. Where some filtering implementations >> nevertheless have limits on size or complexity (Section 8.2) that >> prevent the required filters from being applied, the domain is >> "fail-open", which inherently contains more risk than fail-closed >> methodologies. >> >> Practically speaking, this means that, as for other IP networks, >> enforcing a "Trusted Domain" depends on operational discipline, and >> that attacks that are expected to be unfeasible from outside the >> trusted domain may become feasible when any of the involved systems >> fails to enforce the filtering policy that is required to define the >> Trusted Domain. >> >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I also have some comments and suggestions to offer for consideration. Note >> > that some of the suggestions may help address similar concerns raised by >> > other ADs in their ballots. >> > >> > <editorial> Perhaps gather the practices for securing an SR domain, now >> > spread >> > across Sections 7.1.1 to 7.2 and 8.2, into a short subsection, for example: >> > >> > NEW (perhaps subsection after 7.2?) >> > The practices described in Sections 7.1 and 7.2 can be summarized as >> > follows: >> > >> > * Allocate SIDs from a dedicated address block (Section 7.1.3, >> > [RFC9602]), separate from infrastructure and customer addresses. >> > >> > * Use a hierarchical locator plan that summarizes into a few >> > prefixes [I-D.ietf-srv6ops-srv6addressing]. >> > >> > * Filter packets destined to the SID block at the SR domain >> > boundary and at SRv6 enabled nodes, together with ingress source >> > address validation (BCP 38, BCP 84) (Section 7.1.3; Section 5.1 >> > of [RFC8754]). >> > >> > * Encapsulate traffic at the SR ingress node (Section 7.2). >> > >> > * Do not advertise locators, the SID block, or SR information in >> > BGP outside the SR domain ([RFC8402], Section 9.2 of [RFC9252]). >> > >> > * Where hosts add an SRH, consider the HMAC TLV (Section 7.3; >> > Section 5.2 of [RFC8754]). >> > >> > Again, just a suggestion for the authors' consideration. >> > >> > <about references> Unless the analysis is extended to them, RFC 9020, RFC >> > 9256, >> > RFC 9491 and RFC 9524 could move to the Informative References: nothing in >> > the >> > document as written seems to depends on them? >> > >> > Rest of the comments/suggestions are provide inline in the document text: >> > >> > 19 SRv6 is a traffic engineering, encapsulation and steering >> > mechanism >> > 20 utilizing IPv6 addresses to identify segments in a pre-defined >> > 21 policy. This document discusses security considerations in SRv6 >> > >> > <editorial> The Abstract describes SRv6 as a traffic engineering, >> > encapsulation and steering mechanism in a pre-defined policy. Pre-defined >> > suggests static but it is normally not the case. Suggest RFC 8402's >> > framing: >> > >> > CURRENT >> > SRv6 is a traffic engineering, encapsulation and steering mechanism >> > utilizing IPv6 addresses to identify segments in a pre-defined >> > policy. >> > SUGGEST >> > SRv6 is the instantiation of Segment Routing on the IPv6 data plane, >> > using IPv6 addresses to identify segments. >> >> OLD: Segment Routing over IPv6 (SRv6) is an encapsulation-based >> steering mechanism utilizing IPv6 addresses to identify segments in a >> pre-defined policy. >> >> NEW: Segment Routing over IPv6 (SRv6) is the instantiation of Segment >> Routing on the IPv6 data plane, using IPv6 addresses to identify >> segments. >> >> > >> > >> > 135 * SRv6 may use the SRH which is a type of Routing Extension >> > Header >> > 136 defined by [RFC8754]. Security considerations of the SRH are >> > 137 discussed in Section 7 of [RFC8754], and were based in part >> > on >> > 138 security considerations of the deprecated routing header 0 as >> > 139 discussed in Section 5 of [RFC5095]. >> > >> > <minor> Sections 1 and 5 cite RFC 5095 and [CanSecWest2007] on the >> > deprecated >> > Routing Header type 0 without saying how the SRH differs: it is processed >> > only >> > by the node owning the SID in the destination address (RFC 8754 Section >> > 4.3), >> > and RFC 8754 Section 7.1 concludes that the Section 5.1 protection blocks >> > the >> > RFC 5095 attacks from outside the SR domain. Suggest: >> > >> > CURRENT >> > * SRv6 may use the SRH which is a type of Routing Extension Header >> > defined by [RFC8754]. Security considerations of the SRH are >> > discussed in Section 7 of [RFC8754], and were based in part on >> > security considerations of the deprecated routing header 0 as >> > discussed in Section 5 of [RFC5095]. >> > SUGGEST >> > * SRv6 may use the SRH which is a type of Routing Extension Header >> > defined by [RFC8754]. Security considerations of the SRH are >> > discussed in Section 7 of [RFC8754], and were based in part on >> > security considerations of the deprecated routing header 0 as >> > discussed in Section 5 of [RFC5095]. Unlike routing header 0, >> > the SRH is processed only by the node whose SID is the >> > destination address of the packet, and full implementation of the >> > protection described in Section 5.1 of [RFC8754] blocks the >> > attacks documented in [RFC5095] from outside the SR domain >> > (Section 7.1 of [RFC8754]). >> > >> > CURRENT >> > - Forwarding loops: an attacker might achieve attack >> > amplification by increasing the number hops that each packet is >> > forwarded through and thus increase the load on the network. >> > For instance, a set of SIDs can be inserted in a way that >> > creates a forwarding loop ([RFC8402], [RFC5095], >> > [CanSecWest2007]) and thus loads the nodes along the loop. >> > SUGGEST >> > - Forwarding loops: an attacker might achieve attack >> > amplification by increasing the number of hops that each >> > packet is forwarded through and thus increase the load on the >> > network. For instance, a set of SIDs can be inserted in a way >> > that creates a forwarding loop ([RFC8402], [RFC5095], >> > [CanSecWest2007]) and thus loads the nodes along the loop. As >> > with source routing and tunneling in other IP networks >> > [RFC6324], such loops are bounded by the Hop Limit, and from >> > outside the SR domain they are blocked by the filtering of >> > Section 7.1. >> > >> > For reference, please check RFC 8754, Section 7.1: >> > Full implementation of the recommended protection blocks the attacks >> > documented in [RFC5095] from outside the SR domain, including >> > bypassing filtering devices, reaching otherwise-unreachable Internet >> > systems, network topology discovery, bandwidth exhaustion, and >> > defeating anycast. >> > >> > 184 Inter-Domain Segment Routing scenarios are out of scope for this >> > 185 document as are existing and future protocol specific IPv6 >> > 186 vulnerabilities. Additionally, we note that SRv6 is under >> > active >> > >> > <nit> Perhaps: >> > >> > CURRENT >> > Additionally, we note that SRv6 is under active >> > SUGGEST >> > Additionally, SRv6 is under active >> > >> > 236 transmissions. In this example a Path Computation Element as a >> > 237 Central Controller (PCECC) [RFC9050] is used as part of the >> > control >> > >> > <minor> PCECC is cited as RFC 9050 in Section 4 and as RFC 8283 in Section >> > 6.3.4.1. RFC 8283 is the architecture; RFC 9050 the PCEP procedures. >> > Suggest >> > citing the architecture: >> > >> > CURRENT >> > transmissions. In this example a Path Computation Element as a >> > Central Controller (PCECC) [RFC9050] is used as part of the control >> > SUGGEST >> > transmissions. In this example a Path Computation Element as a >> > Central Controller (PCECC) [RFC8283] is used as part of the control >> > >> > 322 - Avoiding a specific node or path: when an SRv6 policy is >> > 323 manipulated, specific nodes or paths may be bypassed, for >> > 324 example in order to avoid the billing service or >> > circumvent >> > 325 access controls and security filters. >> > >> > 327 - Preferring a specific path: packets can be manipulated so >> > that >> > 328 they are diverted to a specific path. This can result in >> > 329 allowing various unauthorized services such as traffic >> > 330 acceleration. Alternatively, an attacker can divert >> > traffic to >> > >> > <minor> I share Med's view on two examples in Section 5: avoiding "the >> > billing >> > service" and "unauthorized services such as traffic acceleration" are not >> > explained and are not specific to SRv6. Suggest dropping them: >> > >> > CURRENT >> > - Avoiding a specific node or path: when an SRv6 policy is >> > manipulated, specific nodes or paths may be bypassed, for >> > example in order to avoid the billing service or circumvent >> > access controls and security filters. >> > SUGGEST >> > - Avoiding a specific node or path: when an SRv6 policy is >> > manipulated, specific nodes or paths may be bypassed, for >> > example in order to circumvent access controls and security >> > filters. >> > >> > CURRENT >> > This can result in allowing various unauthorized services such as >> > traffic acceleration. >> > SUGGEST >> > (delete the sentence) >> > >> > 371 - Forwarding loops: an attacker might achieve attack >> > 372 amplification by increasing the number hops that each >> > packet is >> > 373 forwarded through and thus increase the load on the >> > network. >> > 374 For instance, a set of SIDs can be inserted in a way that >> > 375 creates a forwarding loop ([RFC8402], [RFC5095], >> > 376 [CanSecWest2007]) and thus loads the nodes along the loop. >> > >> > <minor> The forwarding-loop example also cites RFC 5095 without saying that >> > such loops are bounded by the Hop Limit and are blocked from outside the SR >> > domain by the filtering of Section 7.1. Please see my comments on line 135, >> > which include suggested text for this paragraph. >> > >> > 372 amplification by increasing the number hops that each >> > packet is >> > >> > <nit> Perhaps: >> > >> > CURRENT >> > amplification by increasing the number hops that each packet is >> > SUGGEST >> > amplification by increasing the number of hops that each packet is >> > >> > 505 A reconnaissance attack is limited to on-path internal >> > attackers. >> > >> > <minor> Section 6.2.2.2 limits reconnaissance to on-path internal >> > attackers, >> > while Section 4 (lines 233-236) notes that off-path attackers can in some >> > cases listen passively, for example to multicast. Suggest: >> > >> > CURRENT >> > A reconnaissance attack is limited to on-path internal attackers. >> > SUGGEST >> > A reconnaissance attack is generally limited to on-path internal >> > attackers. >> > >> > 516 While the information collected in a reconnaissance attack does >> > not >> > 517 compromise the confidentiality of the user data, it allows an >> > 518 attacker to gather information about the network which in turn >> > can be >> > 519 used to enable other attacks. >> > >> > 521 Passive eavesdropping can also impact end-user privacy. >> > Observable >> > 522 SRH fields (e.g., the Segment List and SRH TLVs) may enable >> > 523 correlation of flows and tracking of users, endpoints, or >> > services. >> > >> > <minor> Section 6.2.2.3 says observable SRH fields "may enable correlation >> > of >> > flows and tracking of users". RFC 8754 Section 7.3 judges this exposure as >> > applicable within the SR domain and "less relevant as an attacker has other >> > means"; the SRH carries operator SIDs rather than user identifiers, and >> > with >> > encapsulation it does not leave the domain. Suggest: >> > >> > CURRENT >> > Passive eavesdropping can also impact end-user privacy. Observable >> > SRH fields (e.g., the Segment List and SRH TLVs) may enable >> > correlation of flows and tracking of users, endpoints, or services. >> > SUGGEST >> > Passive eavesdropping within the SR domain can also impact end-user >> > privacy. Observable SRH fields (e.g., the Segment List and SRH TLVs) >> > may enable correlation of flows and tracking of endpoints or >> > services, as the outer headers of other encapsulations can. As noted >> > in Section 7.3 of [RFC8754], this disclosure is less relevant as an >> > attacker has other means of learning topology, flows, and service >> > usage, and with encapsulation at the domain boundary (Section 7.2) it >> > does not extend beyond the SR domain. >> > >> > >> > 543 6.2.3.3. Effect >> > >> > 545 The main effect of this attack is resource exhaustion, which >> > 546 compromises the availability of the network, as described in >> > 547 Section 6.2.1.3. >> > >> > <major> This limits the effect of packet insertion to resource exhaustion. >> > An inserted packet can carry any segment list, so its effects are >> > those of a modification attack. The case worth naming is what RFC 8754 >> > Section >> > 7.2 calls service theft, an external packet reaching a service SID; RFC >> > 8754 >> > Section 7.2 and RFC 9252 Section 9.2 show that the boundary filtering >> > denies >> > it, as it does for any IP-based overlay. Suggest, with the insertion row of >> > Figure 2 listing the effects of the modification row: >> > >> > CURRENT >> > The main effect of this attack is resource exhaustion, which >> > compromises the availability of the network, as described in >> > Section 6.2.1.3. >> > SUGGEST >> > Packet insertion can have any of the effects of a modification attack >> > (Section 6.2.1.3), since an inserted packet can carry any segment >> > list; resource exhaustion is the most common. A packet from outside >> > the SR domain that reached a service SID would amount to the service >> > theft described in Section 7.2 of [RFC8754]; as for other IP-based >> > overlays [RFC9099], this is prevented by the filtering at the SR >> > domain boundary (Section 7.1 of this document, and Section 9.2 of >> > [RFC9252]). >> > >> > >> > 602 For example, an attacker may advertise falsified SIDs to >> > manipulate >> > 603 SR policies. Another example in the context of SRv6 is the >> > 604 advertisement of an incorrect Maximum SID Depth (MSD) value >> > 605 [RFC8476]. If the advertised MSD is lower than the actual >> > >> > <minor> The SRv6 MSD types are defined in Section 4 of RFC 9352 and of RFC >> > 9513; RFC 8476 is the OSPF MSD framework. Suggest: >> > >> > CURRENT >> > Another example in the context of SRv6 is the advertisement of an >> > incorrect Maximum SID Depth (MSD) value [RFC8476]. >> > SUGGEST >> > Another example in the context of SRv6 is the advertisement of an >> > incorrect Maximum SID Depth (MSD) value [RFC8476], such as the SRv6 >> > MSD types defined in Section 4 of [RFC9352] and Section 4 of >> > [RFC9513]. >> > >> > 611 An additional case could be the manipulation of backup paths >> > 612 [RFC8355], where the attacker could alter the SIDs defining such >> > >> > <minor> The backup-path example cites the RFC 8355 use cases; the SR >> > backup-path mechanism whose SIDs an attacker would alter is TI-LFA >> > [RFC9855]. >> > Suggest: >> > >> > CURRENT >> > An additional case could be the manipulation of backup paths >> > [RFC8355], >> > SUGGEST >> > An additional case could be the manipulation of backup paths, such as >> > those computed by TI-LFA [RFC9855] for the use cases of [RFC8355], >> > >> > 666 injecting fabricated OAM messages or SRv6 packets with the >> > O-bit set, >> > >> > <nit> Section 6.3.3.2 says "O-bit" twice where the rest of the document and >> > RFC 9259 say "O-flag"; suggest "O-flag" in both places. >> > >> > >> > 692 PCE/PCCC in an SR domain, thereby increasing the risk of >> > compromise >> > >> > <nit> Perhaps: >> > >> > CURRENT >> > PCE/PCCC in an SR domain, thereby increasing the risk of compromise >> > SUGGEST >> > PCE/PCECC in an SR domain, thereby increasing the risk of compromise >> > >> > 739 Management functionality is often defined using YANG data >> > models, >> > 740 such as those specified in [RFC9020], >> > [I-D.ietf-lsr-isis-srv6-yang] >> > 741 and [I-D.ietf-lsr-ospf-srv6-yang]. As with any YANG module, >> > data >> > >> > <minor> RFC 9020 covers the SR base and the SR-MPLS data plane only; the >> > SRv6 >> > base model is in draft-ietf-spring-srv6-yang-base. Suggest: >> > >> > CURRENT >> > Management functionality is often defined using YANG data models, >> > such as those specified in [RFC9020], [I-D.ietf-lsr-isis-srv6-yang] >> > and [I-D.ietf-lsr-ospf-srv6-yang]. >> > SUGGEST >> > Management functionality is often defined using YANG data models, >> > such as the Segment Routing base model [RFC9020] and the SRv6 models >> > in [I-D.ietf-spring-srv6-yang-base], [I-D.ietf-lsr-isis-srv6-yang], >> > and [I-D.ietf-lsr-ospf-srv6-yang]. >> > >> > >> > 788 |Packet |Maliciously inject|* Resource exhaustion >> > | >> > 789 |insertion |packets with a |* Security tooling confusion >> > | >> > 790 | |segment list | >> > | >> > 791 >> > +-------------+------------------+-----------------------------------+ >> > >> > <minor> The insertion row of Figure 2 lists only resource exhaustion and >> > tooling confusion, while an inserted packet can have any of the effects >> > listed >> > in the modification row. Please see my comments on line 543. >> > >> > 866 2. A packet containing an SRH may not be destined to the SR >> > domain, >> > 867 as it may be simply transiting the domain. >> > >> > 869 Therefore, filtering solely based on the presence of an SRH, at >> > 870 either SR ingress or SR egress, is not necessarily recommended. >> > 871 Instead, this scenario is mitigated by encapsulating packets on >> > the >> > 872 domain boundary, as discussed in Section 7.2. While >> > inter-SR-domain >> > 873 scenarios are a violation of the trust model described above, >> > the >> > 874 operational practices recommended here aim to preserve >> > 875 interoperability and avoid blanket behaviors that would break >> > SR when >> > 876 adjacent networks follow different practices. >> > >> > <minor> Related to Roman's DISCUSS on Sections 7.1.1 and 7.1.2: packets >> > from >> > outside the SR domain are never processed as SRv6 within it. One destined >> > to a >> > SID of the domain is dropped at the boundary (RFC 8754 Section 5.1); any >> > other >> > is plain IPv6 transit whose SRH is not inspected (RFC 8754 Section 4.2); >> > transit traffic carried using SRv6 is generally encapsulated and tunnels >> > through. >> > Suggest: >> > >> > CURRENT >> > 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. >> > SUGGEST >> > 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 an 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 necessarily recommended. >> > 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, is then the >> > payload of an outer IPv6 header originated within the domain, and >> > it 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. >> > >> > >> > 878 For these reasons SRH filtering is not necessarily a useful >> > method of >> > 879 mitigation. >> > >> > <nit> Section 7.1.2: the paragraph starting "Therefore, filtering" reads >> > as part of item 2, and the section ends with a second "not necessarily". >> > Suggest starting a new paragraph at "Therefore" and: >> > >> > CURRENT >> > For these reasons SRH filtering is not necessarily a useful method of >> > mitigation. >> > SUGGEST >> > For these reasons, filtering solely on the presence of an SRH is not >> > a useful method of mitigation. >> > >> > 896 In order to apply such a filtering mechanism the SR domain >> > needs to >> > 897 have an infrastructure address range for SIDs and an >> > infrastructure >> > 898 address range for source addresses that can be detected and >> > enforced. >> > >> > <minor> Section 7.1.3 could align with draft-ietf-srv6ops-srv6addressing: >> > SIDs >> > from a range separate from infrastructure and customer addressing (it calls >> > the SID range "infrastructure"), loopbacks optionally taken from the >> > locator, >> > and a hierarchical plan that summarizes so the filters stay few. Now, that >> > draft is focussed on CSID, but the hierarchical and summarization aspects >> > apply >> > for all of SRv6. Suggest: >> > >> > CURRENT >> > In order to apply such a filtering mechanism the SR domain needs to >> > have an infrastructure address range for SIDs and an infrastructure >> > address range for source addresses that can be detected and enforced. >> > SUGGEST >> > In order to apply such a filtering mechanism the SR domain needs to >> > have an address range for SIDs, separate from the infrastructure and >> > customer address ranges, and an infrastructure address range for >> > source addresses, both of which can be detected and enforced. >> > >> > CURRENT >> > Many operators reserve a /64 block for all loopback addresses and >> > allocate /128 for each loopback interface. This simplifies the >> > filtering of permitted source addresses. >> > SUGGEST >> > Many operators reserve a /64 block for all loopback addresses and >> > allocate /128 for each loopback interface. This simplifies the >> > filtering of permitted source addresses. Alternatively, loopback >> > addresses can be allocated from each node's locator >> > [I-D.ietf-srv6ops-srv6addressing], in which case the permitted source >> > addresses are covered by the SID address range. In either case, a >> > hierarchical addressing plan whose locators summarize at domain and >> > area boundaries [I-D.ietf-srv6ops-srv6addressing] keeps the filters >> > to a few stable prefixes. >> > >> > 899 This practice helps prevent the use of SRH and SID information >> > to >> > 900 track individual users or reveal communication patterns outside >> > the >> > 901 trusted domain. Some examples of an infrastructure address >> > range for >> > >> > <minor> This credits the Section 7.1.3 filters with keeping SRH and SID >> > information inside the domain, but both filters act on inbound packets. >> > What >> > keeps that information in is encapsulation with decapsulation at the egress >> > (Section 7.2), together with RFC 8402 Section 8.2's rule that explicit >> > routing >> > information is not leaked. Suggest: >> > >> > CURRENT >> > This practice helps prevent the use of SRH and SID information to >> > track individual users or reveal communication patterns outside the >> > trusted domain. >> > SUGGEST >> > Together with encapsulation at the SR domain boundary (Section 7.2), >> > which keeps SRH and SID information within the domain [RFC8402], this >> > practice helps prevent the use of SRH and SID information to track >> > individual users or reveal communication patterns outside the trusted >> > domain. >> > >> > 902 SIDs are: >> > >> > 904 * The prefix defined in [RFC9602] >> > >> > 906 * ULA addresses >> > >> > 908 * GUA addresses >> > >> > <major> The examples of an address range for SIDs list "ULA addresses" and >> > "GUA addresses" without saying that the SIDs come from a block dedicated to >> > them. The protection of RFC 8754 Section 5.1 rests on SIDs being drawn from >> > such a block (S/s), which is also what draft-ietf-srv6ops-srv6addressing >> > recommends. Suggest: >> > >> > CURRENT >> > Some examples of an infrastructure address range for SIDs are: >> > >> > * The prefix defined in [RFC9602] >> > >> > * ULA addresses >> > >> > * GUA addresses >> > SUGGEST >> > SIDs are best allocated from an address block dedicated to SIDs, for >> > example: >> > >> > * The prefix defined in [RFC9602] >> > >> > * A dedicated ULA block >> > >> > * A dedicated GUA block >> > >> > >> > 920 Many operators reserve a /64 block for all loopback addresses >> > and >> > 921 allocate /128 for each loopback interface. This simplifies the >> > 922 filtering of permitted source addresses. >> > >> > <minor> Loopback addresses can alternatively be allocated from each node's >> > locator, and a hierarchical locator plan keeps the source-address filters >> > to a >> > few stable prefixes. Please see my comments on line 896, which include >> > suggested text for this paragraph. >> > >> > 924 Failure to implement address range filtering at ingress nodes is >> > 925 mitigated with filtering at SRv6 enabled nodes. Failure to >> > implement >> > 926 both filtering mechanisms could result in a "fail open" >> > scenario, >> > 927 where some attacks by internal attackers described in this >> > document >> > 928 may be launched by external attackers. >> > >> > <major> Section 7.1.3 says a missing ingress filter "is mitigated with >> > filtering at SRv6 enabled nodes". As in any IP network, the per-node filter >> > complements rather than replaces the edge filter (RFC 8754 Section 5.1): it >> > relies on source addresses, which can be trusted only where the boundary >> > also >> > drops spoofed sources, the established practice for IP networks in BCP 38 >> > and >> > BCP 84 (see also RFC 9099 Section 3.1). Suggest: >> > >> > CURRENT >> > Failure to implement address range filtering at ingress nodes is >> > mitigated with filtering at SRv6 enabled nodes. Failure to implement >> > both filtering mechanisms could result in a "fail open" scenario, >> > where some attacks by internal attackers described in this document >> > may be launched by external attackers. >> > SUGGEST >> > As in other IP networks, filtering at SRv6 enabled nodes complements >> > address range filtering at ingress nodes, and it relies on the >> > ingress source address validation that IP networks deploy against >> > spoofing (BCP 38 [RFC2827] and BCP 84 [RFC3704]). Failure to >> > implement these filtering mechanisms could result in a "fail open" >> > scenario, where some attacks by internal attackers described in this >> > document may be launched by external attackers. >> > >> > >> > 930 Filtering on prefixes has been shown to be useful, specifically >> > 931 [RFC8754]'s description of packet filtering. There are no known >> > 932 limitations with filtering on infrastructure addresses, and >> > [RFC9099] >> > 933 expands on the concept with control plane filtering. >> > >> > <minor> Lines 930-933 say there are no known limitations with filtering on >> > infrastructure addresses, while Section 8.2 describes ACL and TCAM limits. >> > Both are reconciled by the SID-space practices this document already >> > recommends: with SIDs from a summarizable block the filters are few and >> > stable >> > (RFC 8754 Section 7), and Section 8.2, as operational guidance, can ask >> > operators to check platform limits and point back to them. Suggest: >> > >> > CURRENT >> > Filtering on prefixes has been shown to be useful, specifically >> > [RFC8754]'s description of packet filtering. There are no known >> > limitations with filtering on infrastructure addresses, and [RFC9099] >> > expands on the concept with control plane filtering. >> > SUGGEST >> > Filtering on prefixes has been shown to be useful, specifically >> > [RFC8754]'s description of packet filtering. When SIDs are allocated >> > from a dedicated block that can be summarized, the resulting filters >> > are few and stable, and [RFC9099] expands on the concept with control >> > plane filtering. >> > >> > CURRENT >> > Depending on the scale of the network, SRH filtering can consume a >> > non-trivial portion of these resources. Since filtering resources >> > SUGGEST >> > Depending on the scale of the network, filtering can consume a >> > non-trivial portion of these resources. Since filtering resources >> > >> > CURRENT >> > accommodate larger numbers of access lists. Hardware and software >> > configurations should be considered when designing the filtering >> > capabilities for an SRv6 control and data plane. >> > SUGGEST >> > accommodate larger numbers of access lists. Operators are advised to >> > check the limitations of their platforms when deploying SRv6, and to >> > keep the resources needed for filtering low by following the SID >> > allocation and summarization practices described in Section 7.1.3. >> > >> > 944 supplied by an untrusted source. Decapsulating and forwarding >> > the >> > 945 inner packet without a second lookup at the SR egress node also >> > 946 prevents internal SR-domain information such as segment lists, >> > SIDs, >> > 947 and/or TLVs from being exposed beyond the domain boundary. As >> > >> > <minor> What the SR egress node does with the inner packet after >> > decapsulation >> > is determined by the behavior of the final segment endpoint [RFC8986] (for >> > example, a cross-connect for the End.DX behaviors or a table lookup for the >> > End.DT behaviors), so "without a second lookup" does not hold in general; >> > what >> > keeps SR information from leaving the domain is the decapsulation. Suggest: >> > >> > CURRENT >> > Decapsulating and forwarding the inner packet without a second lookup >> > at the SR egress node also prevents internal SR-domain information >> > such as segment lists, SIDs, and/or TLVs from being exposed beyond >> > the domain boundary. >> > SUGGEST >> > Decapsulating the inner packet at the SR egress node, which then >> > forwards it as specified by the behavior of the final segment >> > endpoint [RFC8986], also prevents internal SR-domain information such >> > as segment lists, SIDs, and/or TLVs from being exposed beyond the >> > domain boundary. >> > >> > 1027 In centralized SRv6 control plane architectures, such as those >> > 1028 described in [RFC9862], it is recommended that communication >> > between >> > 1029 PCEs and PCCs be secured using authenticated and encrypted >> > sessions. >> > >> > <minor> RFC 9862 specifies PCEP extensions for SR Policy candidate paths >> > rather than an architecture; RFC 4655 and RFC 8283 describe the >> > architectures. >> > Suggest: >> > >> > CURRENT >> > In centralized SRv6 control plane architectures, such as those >> > described in [RFC9862], it is recommended >> > SUGGEST >> > In centralized SRv6 control plane architectures [RFC4655] [RFC8283], >> > such as those using the PCEP extensions of [RFC9862], it is >> > recommended >> > >> > 1033 When the O-flag is used for Operations, Administration, and >> > 1034 Maintenance (OAM) functions, as defined in [RFC9259], >> > implementations >> > 1035 should enforce rate limiting to mitigate potential >> > denial-of-service >> > 1036 (DoS) attacks triggered by excessive control plane signaling. >> > >> > <minor> This is related to Roman's DISCUSS on Section 7.4. This states >> > O-flag rate limiting as a recommendation; RFC 9259 Section 2.1.1 already >> > makes >> > it mandatory, and the punt is to the OAM process rather than the control >> > plane. Suggest: >> > >> > CURRENT >> > 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. >> > SUGGEST >> > When the O-flag is used for Operations, Administration, and >> > Maintenance (OAM) functions, Section 2.1.1 of [RFC9259] requires the >> > processing node to rate-limit the packets punted to the OAM process, >> > which mitigates denial-of-service (DoS) attacks that set the O-flag. >> > >> > >> > 1040 The control plane should be confined to a trusted administrative >> > 1041 domain. As specified in [RFC9857], SR Policy information >> > advertised >> > 1042 via BGP should be restricted to authorized nodes, controllers, >> > and >> > 1043 applications within this domain. Similarly, the use of the >> > O-flag is >> > >> > <minor> RFC 9857 is BGP-LS reporting of SR Policies; the distribution of SR >> > Policies in BGP is RFC 9830, whose Section 7 states the same restriction. >> > Suggest: >> > >> > CURRENT >> > As specified in [RFC9857], SR Policy information advertised via BGP >> > should be restricted to authorized nodes, controllers, and >> > applications within this domain. >> > SUGGEST >> > As specified in [RFC9830] and [RFC9857], SR Policy information >> > advertised via BGP and BGP-LS should be restricted to authorized >> > nodes, controllers, and applications within this domain. >> > >> > 1126 When an SRv6 packet is forwarded in the SRv6 domain, its IPv6 >> > 1127 destination address is modified in each segment and the final >> > 1128 destination address is not available in the IPv6 header. >> > Security >> > 1129 devices on SRv6 networks may not learn the real destination >> > address >> > 1130 and incorrectly perform access control on some SRv6 traffic. >> > >> > <minor> Section 8.1 could bring out two aspects: security devices in SRv6 >> > networks are expected to be SRv6-capable (as lines 1132-1133 already say), >> > and >> > this is the same as for other IP encapsulations, whose inner headers >> > likewise >> > sit outside the positions such devices inspect (RFC 2003 Section 6, RFC >> > 6169 >> > Section 3). Suggest: >> > >> > CURRENT >> > When an SRv6 packet is forwarded in the SRv6 domain, its IPv6 >> > destination address is modified in each segment and the final >> > destination address is not available in the IPv6 header. Security >> > devices on SRv6 networks may not learn the real destination address >> > and incorrectly perform access control on some SRv6 traffic. >> > SUGGEST >> > When an SRv6 packet is forwarded in the SRv6 domain, its IPv6 >> > destination address is modified in each segment and the final >> > destination address is not available in the IPv6 header. As with >> > other IP encapsulations [RFC2003] [RFC6169], security devices on SRv6 >> > networks that are not SRv6-capable may not learn the real destination >> > address and incorrectly perform access control on some SRv6 traffic. >> > >> > CURRENT >> > Forwarding SRv6 traffic through devices that are not SRv6-aware might >> > in some cases lead to unpredictable behavior. >> > SUGGEST >> > As with other encapsulations, forwarding SRv6 traffic through devices >> > that are not SRv6-aware might in some cases lead to unpredictable >> > behavior. >> > >> > >> > 1139 example, along the forwarding path in SRv6 network, the SR-aware >> > 1140 firewall will check the association relationships of the >> > 1141 bidirectional VPN traffic packets. It is therefore able to >> > retrieve >> > 1142 the final destination of an SRv6 packet from the last entry in >> > the >> > 1143 SRH. When the <source, destination> tuple of the packet from >> > PE1 >> > >> > <minor> Section 8.1 takes the final destination from "the last entry in the >> > SRH". In RFC 8754 the final segment is Segment List[0], while "Last Entry" >> > names the field indexing the first segment. And the SRH may be absent or >> > carry >> > compressed SIDs, in which case RFC 9800 Section 6.5 gives how the final >> > destination is obtained. Suggest: >> > >> > CURRENT >> > It is therefore able to retrieve the final destination of an SRv6 >> > packet from the last entry in the SRH. >> > SUGGEST >> > It is therefore able to retrieve the final destination of an SRv6 >> > packet from Segment List[0] of the SRH [RFC8754]; when the SRH is >> > absent or the segment list is compressed, the final destination is >> > obtained by applying the segment behaviors as described in [RFC9800]. >> > >> > 1153 Forwarding SRv6 traffic through devices that are not SRv6-aware >> > might >> > 1154 in some cases lead to unpredictable behavior. Security >> > appliances, >> > 1155 monitoring systems, and middleboxes could react in different >> > ways if >> > 1156 they lack support for SRv6 mechanisms, such as the Segment >> > Routing >> > 1157 Header (SRH) [RFC8754]. Additionally, implementation >> > limitations in >> > 1158 the processing of IPv6 packets with extension headers may >> > result in >> > 1159 SRv6 packets being dropped [RFC7872],[RFC9098]. >> > >> > <minor> Unpredictable behavior in devices that are not aware of an >> > encapsulation is shared with other encapsulations and is not specific to >> > SRv6. >> > Please see my comments on line 1126, which include suggested text for this >> > sentence. >> > >> > 1178 In some cases, access-control list (ACL) capacity is a scarce >> > and >> > 1179 potentially shared hardware resource (e.g., TCAM/ACL tables). >> > 1180 Depending on the scale of the network, SRH filtering can >> > consume a >> > 1181 non-trivial portion of these resources. Since filtering >> > resources >> > 1182 can be shared with other features across a given hardware >> > platform, >> > 1183 filtering capabilities should be considered along with other >> > hardware >> > 1184 reliant functions such as VLAN scale, route table size, MAC >> > address >> > 1185 table size, etc. Filtering both at the control and data plane >> > may or >> > 1186 may not require shared resources. For example, some platforms >> > may >> > 1187 require allocating resources from route table size in order to >> > 1188 accommodate larger numbers of access lists. Hardware and >> > software >> > 1189 configurations should be considered when designing the filtering >> > 1190 capabilities for an SRv6 control and data plane. >> > >> > <minor> These ACL and TCAM limits sit uneasily with the "no known >> > limitations" >> > of Section 7.1.3, and the SID allocation practices recommended there keep >> > the >> > filters few and stable. Please see my comments on line 930, which include >> > suggested text for this paragraph. >> > >> > <EoRv17> >> >> Where noted, I have added who has made the comments. I think this >> should be all of them, apologies if I missed one or mis-attributed any >> of the comments. As noted in an earlier email we have implemented >> these in a branch and if they meet approval we will submit all changes >> as -18. >> >> 1 — SRH bullet, routing header type 0 + unlike RH0 (Ketan minor + Éric nit): >> >> OLD: Security considerations of the SRH are discussed in Section 7 of >> [RFC8754], and were based in part on security considerations of the >> deprecated routing header 0 as discussed in Section 5 of [RFC5095]. >> >> NEW: Security considerations of the SRH are discussed in Section 7 of >> [RFC8754], and were based in part on security considerations of the >> deprecated routing header type 0 as discussed in Section 5 of >> [RFC5095]. Unlike routing header 0, the SRH is processed only by the >> node whose SID is the destination address of the packet, and full >> implementation of the protection described in Section 5.1 of [RFC8754] >> blocks the attacks documented in [RFC5095] from outside the SR domain >> (Section 7.1 of [RFC8754]). >> >> 1 — "unicast routing" (Éric, nit): >> >> OLD: allows the bridging of islands of SRv6 devices with standard IPv6 >> unicast routing. >> >> NEW: allows the bridging of islands of SRv6 devices with standard IPv6 >> unicast forwarding. >> >> 2 — spacing fix: >> >> OLD: Additionally,SRv6 is under active development >> >> NEW: Additionally, SRv6 is under active development >> >> 4 threat model text — PCECC reference correction (Ketan, minor): >> >> OLD: In this example a Path Computation Element as a Central >> Controller (PCECC) [RFC9050] is used as part of the control plane. >> >> NEW: In this example a Path Computation Element as a Central >> Controller (PCECC) [RFC8283] is used as part of the control plane. >> >> 5 Effect — "billing service" removal (Ketan, Med): >> >> OLD: in order to avoid the billing service or circumvent access >> controls and security filters. >> >> NEW: in order to circumvent access controls and security filters. >> >> 5 Effect — "traffic acceleration" sentence removal (Ketan, Med): >> >> OLD: This can result in allowing various unauthorized services such as >> traffic acceleration. Alternatively, an attacker can divert traffic >> >> NEW: Alternatively, an attacker can divert traffic >> >> 5 Effect — forwarding loops fix + Hop Limit bound (Ketan minor + Mike nit): >> >> OLD: an attacker might achieve attack amplification by increasing the >> number hops that each packet is forwarded through and thus increase >> the load on the network. For instance, a set of SIDs can be inserted >> in a way that creates a forwarding loop ([RFC8402], [RFC5095], >> [CanSecWest2007]) and thus loads the nodes along the loop. >> >> NEW: an attacker might achieve attack amplification by increasing the >> number of hops that each packet is forwarded through and thus increase >> the load on the network. For instance, a set of SIDs can be inserted >> in a way that creates a forwarding loop ([RFC8402], [RFC5095], >> [CanSecWest2007]) and thus loads the nodes along the loop. As with >> source routing and tunneling in other IP networks [RFC6324], such >> loops are bounded by the Hop Limit, and from outside the SR domain >> they are blocked by the filtering of Section 7.1. >> >> 6.2.2.2 — reconnaissance scope (Ketan, minor): >> >> OLD: A reconnaissance attack is limited to on-path internal attackers. >> >> NEW: A reconnaissance attack is generally limited to on-path internal >> attackers. >> >> 6.2.2.3 — passive eavesdropping privacy (Ketan, minor): >> >> OLD: Passive eavesdropping can also impact end-user privacy. >> Observable SRH fields (e.g., the Segment List and SRH TLVs) may enable >> correlation of flows and tracking of users, endpoints, or services. >> >> NEW: Passive eavesdropping within the SR domain can also impact >> end-user privacy. Observable SRH fields (e.g., the Segment List and >> SRH TLVs) may enable correlation of flows and tracking of endpoints or >> services, as the outer headers of other encapsulations can. As noted >> in Section 7.3 of [RFC8754], this disclosure is less relevant as an >> attacker has other means of learning topology, flows, and service >> usage, and with encapsulation at the domain boundary (Section 7.2) it >> does not extend beyond the SR domain. >> >> 6.2.3.3 — packet insertion effect (Ketan, major): >> >> OLD: The main effect of this attack is resource exhaustion, which >> compromises the availability of the network, as described in Section >> 6.2.1.3. >> >> NEW: Packet insertion can have any of the effects of a modification >> attack (Section 6.2.1.3), since an inserted packet can carry any >> segment list; resource exhaustion is the most common. A packet from >> outside the SR domain that reached a service SID would amount to the >> service theft described in Section 7.2 of [RFC8754]; as for other >> IP-based overlays [RFC9099], this is prevented by the filtering at the >> SR domain boundary (Section 7.1 of this document, and Section 9.2 of >> [RFC9252]). >> >> 6.3.2.1 — backup paths (Ketan, minor): >> >> OLD: An additional case could be the manipulation of backup paths >> [RFC8355], where the attacker could alter the SIDs >> >> NEW: An additional case could be the manipulation of backup paths, >> such as those computed by TI-LFA [RFC9855] for the use cases of >> [RFC8355], where the attacker could alter the SIDs >> >> 6.3.3.2 — "O-bit" → "O-flag" (Éric, nit): >> >> OLD: SRv6 packets with the O-bit set / unauthorized modification of >> the O-bit in transit packets >> >> NEW: SRv6 packets with the O-flag set / unauthorized modification of >> the O-flag in transit packets >> >> 6.3.4 — section title (Éric, editorial): >> >> OLD: ### Central Control Plane Attacks >> >> NEW: ### Centralized Control Plane Attacks >> >> 6.3.4.1 — PCE/PCCC typo (Ketan & Mike, nit): >> >> OLD: of the PCE/PCCC in an SR domain, >> >> NEW: of the PCE/PCECC in an SR domain, >> >> 6.4 — YANG models (Ketan, minor): >> >> OLD: Management functionality is often defined using YANG data models, >> such as those specified in [RFC9020], [I-D.ietf-lsr-isis-srv6-yang] >> and [I-D.ietf-lsr-ospf-srv6-yang]. >> >> NEW: Management functionality is often defined using YANG data models, >> such as the Segment Routing base model [RFC9020] and the SRv6 models >> in [I-D.ietf-spring-srv6-yang-base], [I-D.ietf-lsr-isis-srv6-yang], >> and [I-D.ietf-lsr-ospf-srv6-yang]. >> >> 7.1.3 — "In order to apply" + SID address range (Ketan, major): >> >> OLD: In order to apply such a filtering mechanism the SR domain needs >> to have an infrastructure address range for SIDs and an infrastructure >> address range for source addresses that can be detected and enforced. >> >> NEW: In order to apply such a filtering mechanism the SR domain needs >> to have an address range for SIDs, separate from the infrastructure >> and customer address ranges, and an infrastructure address range for >> source addresses, both of which can be detected and enforced. >> >> 7.1.3 — "This practice helps" > add encapsulation context (Ketan, minor): >> >> OLD: This practice helps prevent the use of SRH and SID information to >> track individual users or reveal communication patterns outside the >> trusted domain. >> >> NEW: Together with encapsulation at the SR domain boundary (Section >> 7.2), which keeps SRH and SID information within the domain [RFC8402], >> this practice helps prevent the use of SRH and SID information to >> track individual users or reveal communication patterns outside the >> trusted domain. >> >> 7.1.3 — SID examples (Ketan, major): >> >> OLD: Some examples of an infrastructure address range for SIDs are: / >> - ULA addresses / - GUA addresses >> >> NEW: SIDs are best allocated from an address block dedicated to SIDs, >> for example: / - A dedicated ULA block / - A dedicated GUA block >> >> 7.1.3 — "making it more simple" (Mike nit) readibility: >> >> OLD: making it more simple to filter traffic at the edge of the SR Domains. >> >> NEW: making it simpler to filter traffic at the edge of the SR Domains. >> >> 7.1.3 — "Failure to implement" paragraph (Ketan, major): >> >> OLD: Failure to implement address range filtering at ingress nodes is >> mitigated with filtering at SRv6 enabled nodes. Failure to implement >> both filtering mechanisms could result in a "fail open" scenario, >> where some attacks by internal attackers described in this document >> may be launched by external attackers. >> >> NEW: As in other IP networks, filtering at SRv6 enabled nodes >> complements address range filtering at ingress nodes, and it relies on >> the ingress source address validation that IP networks deploy against >> spoofing (BCP 38 [RFC2827] and BCP 84 [RFC3704]). Failure to implement >> these filtering mechanisms could result in a "fail open" scenario, >> where some attacks by internal attackers described in this document >> may be launched by external attackers. >> >> 7.1.3 — "no known limitations" (Ketan/Mike, minor): >> >> OLD: There are no known limitations with filtering on infrastructure >> addresses, and [RFC9099] expands on the concept with control plane >> filtering. >> >> NEW: When SIDs are allocated from a dedicated block that can be >> summarized, the resulting filters are few and stable, and [RFC9099] >> expands on the concept with control plane filtering. >> >> 7.2 — missing space (Mike, nit): >> >> OLD: untrusted-facing interfaces.This is a specific case >> >> NEW: untrusted-facing interfaces. This is a specific case >> >> 7.2 — "without a second lookup" (Ketan, minor): >> >> OLD: Decapsulating and forwarding the inner packet without a second >> lookup at the SR egress node also prevents internal SR-domain >> information such as segment lists, SIDs, and/or TLVs from being >> exposed beyond the domain boundary. >> >> NEW: Decapsulating the inner packet at the SR egress node, which then >> forwards it as specified by the behavior of the final segment endpoint >> [RFC8986], also prevents internal SR-domain information such as >> segment lists, SIDs, and/or TLVs from being exposed beyond the domain >> boundary. >> >> 7.4 — PCE architecture references (Ketan, minor): >> >> OLD: In centralized SRv6 control plane architectures, such as those >> described in [RFC9862], it is recommended >> >> NEW: In centralized SRv6 control plane architectures [RFC4655] >> [RFC8283], such as those using the PCEP extensions of [RFC9862], it is >> recommended >> >> 7.4 — RFC9857 → RFC9830 + RFC9857 (Ketan, minor): >> >> OLD: As specified in [RFC9857], SR Policy information advertised via >> BGP should be restricted to authorized nodes, controllers, and >> applications within this domain. >> >> NEW: As specified in [RFC9830] and [RFC9857], SR Policy information >> advertised via BGP and BGP-LS should be restricted to authorized >> nodes, controllers, and applications within this domain. >> >> 8.1 — IP encapsulations comparison (Ketan ,minor): >> >> OLD: Security devices on SRv6 networks may not learn the real >> destination address and incorrectly perform access control on some >> SRv6 traffic. >> >> NEW: As with other IP encapsulations [RFC2003] [RFC6169], security >> devices on SRv6 networks that are not SRv6-capable may not learn the >> real destination address and incorrectly perform access control on >> some SRv6 traffic. >> >> 8.1 — "last entry in the SRH" (Gunter/Ketan, minor): >> >> OLD: It is therefore able to retrieve the final destination of an SRv6 >> packet from the last entry in the SRH. >> >> NEW: It is therefore able to retrieve the final destination of an SRv6 >> packet from Segment List[0] of the SRH [RFC8754]; when the SRH is >> absent or the segment list is compressed, the final destination is >> obtained by applying the segment behaviors as described in [RFC9800]. >> >> 8.1 — "not SRv6-aware" sentence (Ketan, minor): >> >> OLD: Forwarding SRv6 traffic through devices that are not SRv6-aware >> might in some cases lead to unpredictable behavior. Security >> appliances, >> >> NEW: As with other encapsulations, forwarding SRv6 traffic through >> devices that are not SRv6-aware might in some cases lead to >> unpredictable behavior. Security appliances, >> >> 8.2 — "SRH filtering" → "filtering" (Ketan, minor): >> >> OLD: Depending on the scale of the network, SRH filtering can consume >> a non-trivial portion of these resources. >> >> NEW: Depending on the scale of the network, filtering can consume a >> non-trivial portion of these resources. >> >> 8.2 — "Hardware and software configurations" (Ketan minor): >> >> OLD: Hardware and software configurations should be considered when >> designing the filtering capabilities for an SRv6 control and data >> plane. >> >> NEW: Operators are advised to check the limitations of their platforms >> when deploying SRv6, and to keep the resources needed for filtering >> low by following the SID allocation and summarization practices >> described in Section 7.1.3. >> >> >> > >> > >> > _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
