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]
