Dear authors: Thank you for taking on this work!
I am providing this review with my Chair Hat on in parallel with the adoption call. Please consider it in addition to the other comments you receive. In general, the current draft is a very good start! I know it is a work in progress, and I expect changes along the way. Having said that, I want to highlight some high-level points to consider as you continue the work. (1) Scope §2 and the document generally focus on the data plane, but the control plane plays a significant part in an SRv6 network. The control plane should also be considered. Many possible control plane threats (overclaiming, filtering, etc.) are not specific to SRv6 but may expose themselves differently in an SRv6 network. §6.4 is a start, but I believe more is needed. (2) Threat Model Even though the threat model mentions external attackers, §6 focuses on internal attacks, indicating that "it is assumed that SRv6 is deployed within a limited domain [RFC8799] with filtering at the domain boundaries, forming a trusted domain with respect to SRv6." However, the first set of mitigation methods (§7) concerns the domain boundary. The formulation of the threat model and the assumptions need to be aligned to the mitigations offered. (3) Relationship to Existing Work It is not clear from the current text what the relationship between existing work (specifically the existing Security Considerations) and this document is. I hope that this document will not have to include "everything" (among other reasons because it would require a great deal of duplication) but that it can refer to, complement, or augment (as needed) any existing guidance. IOW, I expect to see more text of the form: "as rfcxxx recommends, use ABC", "rfczzzz already covers this topic", or "in addition to what is recommended in rfcggg....". Even some text like "the recommendation in this document replaces what was recommended in rfchhh". I also included comments in-line (see below). Thanks! Alvaro. [Line numbers from idnits.] ... 123 1. Introduction ... 137 * SRv6 makes use of the SRH which is a new type of Routing Extension 138 Header. Some of the security considerations of the SRH are 139 discussed in [RFC5095] and [RFC8754]. [] The SRH is specified in RFC8754. To be strict, RFC5095 doesn't talk about the SRH. RFC8754 already refers to RFC5095 in its Security Considerations. 141 * SRv6 consists of using the SRH on the IPv6 dataplane, and 142 therefore known security considerations of IPv6 [RFC9099] are 143 applicable to SRv6 as well. [] Please also point to the Security Considerations in rfc8200. 145 * While SRv6 uses what appear to be typical IPv6 addresses, the 146 address space is processed differently by segment endpoints. A 147 typical IPv6 unicast address is comprised of a network prefix, 148 host identifier, and a subnet mask. A typical SRv6 segment 149 identifier (SID) is broken into a locator, a function identifier, 150 and optionally, function arguments. The locator must be routable, 151 which enables both SRv6 capable and incapable devices to 152 participate in forwarding, either as normal IPv6 unicast or SRv6. 153 The capability to operate in environments that may have gaps in 154 SRv6 support allows the bridging of islands of SRv6 devices with 155 standard IPv6 unicast routing. [] Adding references to rfc8986 and draft-ietf-6man-sids (which should soon be an RFC) would be useful. ... 160 2. Scope of this Document ... 181 We note that SRv6 is under active development and, as such, the above 182 documents might not cover all protocols employed in an SRv6 183 deployment. [] For future versions: draft-ietf-6man-sids is in the RFC Editor's queue and draft-ietf-spring-srv6-srh-compression is with the IESG. Both should be RFCs by the time we're done processing this document. ... 205 4. Threat Model ... 223 On-path vs. Off-path: On-path attackers are located in a position 224 that allows interception, modification or dropping of in-flight 225 packets, as well as insertion (generation) of packets. Off-path 226 attackers can only attack by insertion of packets. [] Could an off-path attacker be able to interact with the control plane? The definition seems to be incomplete. Or maybe I'm interpreting "packets" as data plane... 228 The following figure depicts the attacker types according to the 229 taxonomy above. As illustrated in the figure, on-path attackers are 230 located along the path of the traffic that is under attack, and 231 therefore can listen, insert, delete, modify or replay packets in 232 transit. Off-path attackers can insert packets, and in some cases 233 can passively listen to some of the traffic, such as multicast 234 transmissions. [] This taxonomy is focused on the data plane -- I believe the control plane should also be considered. [] "Off-path attackers...can passively listen to some of the traffic, such as multicast transmissions." Even if listening to only "some of the traffic", wouldn't the node be on-path? ... 265 In the context of the current document it is assumed that SRv6 is 266 deployed within a limited domain [RFC8799] with filtering at the 267 domain boundaries, forming a trusted domain with respect to SRv6. 268 Thus, external attackers are outside of the trusted domain. 269 Specifically, an attack on one domain that is invoked from within a 270 different domain is considered an external attack in the context of 271 the current document. [] rfc8799 is not an IETF consensus document. IMO, this document would be better served if a description of what is considered a "limited domain" is included -- instead of doing it by reference. 273 Following the spirit of [RFC8402], the current document mandates a 274 filtering mechanism that eliminates the threats from external 275 attackers. This approach limits the scope of the attacks described 276 in this document to within the domain (i.e., internal attackers). [] "mandates a filtering mechanism" I couldn't find the MUST/REQUIRED text. The statement feels out of place when describing the threat model -- if you keep it here, point to the section where the requirement is specified. ... 292 5. Impact 294 One of the important aspects of a threat analysis is the potential 295 impact of each threat. SRv6 allows for the sending of IPv6 packets 296 via arbitrary paths. An attack on SRv6 may cause packets to traverse 297 arbitrary paths within an SR domain. This may allow an attacker to 298 perform a number of attacks on the victim networks and hosts that 299 would be mostly unfeasible for a non-SRv6 environment. [] s/sending of IPv6 packets/forwarding of IPv6 packets [] "SRv6 allows for the sending of IPv6 packets via arbitrary paths. An attack on SRv6 may cause packets to traverse arbitrary paths within an SR domain." I guess this text means that the attack uses a *different* set of "arbitrary paths" (when compared to the intended forwarding path). Please clarify. 301 The threat model in [ANSI-Sec] classifies threats according to their 302 potential impact, defining six categories. For each of these 303 categories we briefly discuss its applicability to SRv6 attacks. 305 * Unauthorized Access: an attack that results in unauthorized access 306 might be achieved by having an attacker leverage SRv6 to 307 circumvent security controls as a result of security devices being 308 unable to enforce security policies in the presence of IPv6 309 Extension Headers (see [RFC9098]), or by directing packets through 310 paths where packet-filtering policies are not enforced. [] [ANSI-Sec] doesn't explicitly define what "Unauthorized Access" is. As you're doing here, it explains it by example. However, I believe that doing it this way is non-exhaustive and can easily leave out important examples/considerations. For example, the examples above are about circumventing access control. But that is not comprehensive (or even a representative example). "Unauthorized system access to carry out attacks" is an example given in [ANSI-Sec] that is also applicable to SRv6: an internal attacker could gain unauthorized access to a node inside the SR domain. rfc3552 calls this impact "Unauthorized Usage" or "Inappropriate Usage". An example of "inappropriate usage" may be directing packets through a path that is not intended for the traffic (because it is reserved for other traffic, has low resources, or whatever else). All this is to say: please use well-understood/defined concepts (like the ones in §2/rfc3552). [] Also, I searched the document for other mentions of "Unauthorized Access", but didn't find any. What is the purpose of defining the impact if it won't be mentioned later (when discussing specific attacks or possible mitigations)? [Disclaimer: I didn't look in detail at the other impact terms in this section.] ... 357 6.1. Attack Abstractions 359 Packet manipulation and processing attacks can be implemented by 360 performing a set of one or more basic operations. These basic 361 operations (abstractions) are as follows: [] These abstractions focus on the data plane. What about control plane-related abstractions? On one hand, similar basic operations can be listed for the control plane. On the other hand, the operations are not specific to SRv6. For example, it's possible to listen passively to routing protocols, independently of whether SRv6 is used or not. Consider referencing rfc4593. ... 419 6.2.3. Impact ... 434 Preferring a specific path: The packet can be manipulated to avert 435 packets to a specific path. This attack can result in allowing 436 various unauthorized services such as traffic acceleration. 437 Alternatively, an attacker can avert traffic to be forwarded 438 through a specific node that the attacker has access to, thus 439 facilitating more complex on-path attacks such as passive 440 listening, recon and various man-in-the-middle attacks. It is 441 noted that the SR modification attack is performed by an on-path 442 attacker who has access to packets in transit, and thus can 443 implement these attacks directly. However, SR modification is 444 relatively easy to implement and requires low processing resources 445 by an attacker, while it facilitates more complex on-path attacks 446 by averting the traffic to another node that the attacker has 447 access to and has more processing resources. [] "man-in-the-middle" is not inclusive. The usual replacement term is "on-path". ... 472 6.2.4. Overview [] It feels like a new section header is needed before this subsection: "Recon Attack" ?? ... 554 6.4.3. Impact 556 A compromised control plane or management plane can impact the 557 network in various possible ways. SR policies can be manipulated by 558 the attacker to avoid specific paths or to prefer specific paths, as 559 described in Section 6.2.3. Alternatively, the attacker can 560 compromise the availability, either by defining SR policies that load 561 the network resources, as described in Section 6.2.3, or by 562 blackholing some or all of the SR policies. A passive attacker can 563 use the control plane or management plane messages as a means for 564 recon, in a similar manner to Section 6.2.3. [] It is true that some of the results from §6.2.3 can be seen, but some of them may require multiple nodes to be compromised. Consider expanding on that. [] "blackholing" is not inclusive. Consider "dropping". ... 586 7.1.1. SRH Filtering 588 SRv6 packets rely on the routing header in order to steer traffic 589 that adheres to a defined SRv6 traffic policy. Thus, SRH filtering 590 can be enforced at the ingress and egress nodes of the SR domain, so 591 that packets with an SRH cannot be forwarded into the SR domain or 592 out of the SR domain. Specifically, such filtering is performed by 593 detecting Next Header 43 (Routing Header) with Routing Type 4 (SRH). [] Several places, including this text from §4, talk about the assumptions...and then the text focuses on the threats and mitigations inside the SRv6 domain: In the context of the current document it is assumed that SRv6 is deployed within a limited domain [RFC8799] with filtering at the domain boundaries, forming a trusted domain with respect to SRv6. IOW, external attacks are not considered anywhere, except the first few mitigation methods. I'm pointing this out not to say that they should be out of scope, but to say that they were not considered before. 595 Because of the methodologies used in SID compression 596 [I-D.ietf-spring-srv6-srh-compression], SRH compression does not 597 necessarily use an SRH. In practice this means that when compressed 598 segment lists are used without an SRH, filtering based on the Next 599 Header is not relevant, and thus filtering can only be applied baed 600 on the address range, as described below. [] rfc8754 says that "the SRH MAY be omitted". IOW, this case applies to all cases, not just when using C-SIDs. ... 625 7.3. Hashed Message Authentication Code (HMAC) ... 638 * The HMAC TLV is OPTIONAL. [] "OPTIONAL" is an rfc2119 keyword...but it is not used Normatively in this case (the Normative statement is in rfc8754). s/OPTIONAL/optional ... 656 8.1. Limitations in Filtering Capabilities 658 [RFC9288] provides recommendations on the filtering of IPv6 packets 659 containing IPv6 extension headers at transit routers. SRv6 relies on 660 the routing header (RH4). Because the technology is reasonably new, 661 many platforms, routing and otherwise, do not posses the capability 662 to filter and in some cases even provide logging for IPv6 next-header 663 43 Routing type 4. [] This is true...but the text may not age well. Considering including something like "at the time of this writing..." 665 8.2. Middlebox Filtering Issues ... 672 The security devices on SRv6 networks need to take care of SRv6 673 packets. However, the SRv6 packets usually use loopback address of 674 the PE device a as source address. As a result, the address 675 information of SR packets may be asymmetric, resulting in improper 676 filter traffic problems, which affects the effectiveness of security 677 devices. For example, along the forwarding path in SRv6 network, the 678 SR-aware firewall will check the association relationships of the 679 bidirectional VPN traffic packets. And it is able to retrieve the 680 final destination of SRv6 packet from the last entry in the . When 681 the <source, destination> tuple of the packet from PE1 to PE2 is 682 <PE1-IP-ADDR, PE2-VPN-SID>, and the other direction is <PE2-IP-ADDR, 683 PE1-VPN-SID>, the source address and destination address of the 684 forward and backward VPN traffic are regarded as different flow. 685 Eventually, the legal traffic may be blocked by the firewall. [] s/in the ./in the SRH. [] TBH, you lost me in the description above. Wouldn't the same issue be present in IPv6 networks that don't use SR? ... 788 14. References [] I didn't check the status of the references. [EoR-02] _______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
