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. 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). <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. ---------------------------------------------------------------------- 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. 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> _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
