Dear authors: Thank you for a very well-written document!
After reading it, I have only one substantive comment, related to the use of rfc2119 keywords: I found only one place in this document where rfc2119 keywords are used properly -- and two additional places where they are used to unnecessarily specify behavior already specified elsewhere (search below for "[2119]"). While it is ok to use Normative language in Informational documents, the sole instance doesn't represent an interoperability requirement, so it isn't needed. The result is that you can eliminate the BCP 14 boilerplate. https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ I have some minor comments and suggestions in-line. Please consider my comments along with other WGLC input. Thanks! Alvaro. ===== [Line numbers from idnits.] ... 205 4. Threat Terminology ... 231 The following figure depicts an example of an SR domain with five 232 attacker types, labeled 1-5. As an example, attacker 2 is located 233 along the path between the SR ingress node and SR endpoint 1, and is 234 therefore an on-path attacker both in the data plane and in the 235 control plane. Thus, attacker 2 can listen, insert, delete, modify 236 or replay data plane and/or control plane packets in transit. Off- 237 path attackers, such as attackers 4 and 5, can insert packets, and in 238 some cases can passively listen to some traffic, such as multicast 239 transmissions. In this example a Path Computation Element as a 240 Central Controller (PCECC) [RFC9050] is used as part of the control 241 plane. Thus, attacker 3 is an internal on-path attacker in the 242 control plane, as it is located along the path between the PCECC and 243 SR endpoint 1. 245 1.on-path 2.on-path 3.mgmt. PCE as a Central 4.off-path 5.off-path 246 external internal plane Controller internal external 247 attacker attacker on-path (PCECC) attacker attacker 248 | | | | | | 249 | | v _____ v ____ _ | __ | 250 | SR __ | _ __ / +---+ \___/ | \ | 251 | domain / | \/ \_/ X-----|PCECC| v / v 252 | \ | | +---+ X \ X 253 v / v | / 254 ----->X------>O--->X---------->O------->O-------------->O----> 255 ^\ ^ /^\ /^ 256 | \___/\_ /\_ | _/\__/ | \___/\______/ | 257 | \__/ | | | 258 | | | | 259 SR SR SR SR 260 ingress endpoint 1 endpoint 2 egress 261 node node 263 Figure 1: Threat Model Taxonomy [minor] s/3.mgmt./3.control ... 272 5. Effect ... 296 * Masquerade: various attacks that result in spoofing or 297 masquerading are possible in IPv6 networks. However, these 298 attacks are not specific to SRv6, and are therefore not within the 299 scope of this document. [nit] Is there a reference that could be used for information? ... 322 - Causing header modifications: SRv6 network programming 323 determines the SR endpoint behavior, including potential header 324 modifications. Thus, one of the potential outcomes of an 325 attack is unwanted header modifications. [minor] Are you specifically referring to rfc8986 when mentioning "SRv6 network programming"? If so, please add a reference. ... 791 Figure 2: Attack Summary 793 7. Mitigation Methods [] It would be very nice if a table could be included to map the attacks described in §6 to any possible mitigation presented in this section. A good place to put it could be right after Figure 2 (at the end of §6). ... 801 7.1.1. Overview 803 As specified in [RFC8402]: 805 By default, SR operates within a trusted domain. Traffic MUST be 806 filtered at the domain boundaries. 807 The use of best practices to reduce the risk of tampering within the 808 trusted domain is important. Such practices are discussed in 809 [RFC4381] and are applicable to both SR-MPLS and SRv6. [nit] Insert a line between the two paragraphs above. Also, use the "blockquote" XML element to highlight the fact that you're quoting from rfc8402. 811 Following the direction of [RFC8402], the current document assumes 812 that SRv6 is a trusted domain and that the traffic is filtered at the 813 domain boundaries. Traffic MUST be filtered at the domain 814 boundaries. Thus, most of the attacks described in this document are 815 limited to within the domain (i.e., internal attackers). [2119] "Traffic MUST be filtered at the domain boundaries." There's no need to re-specify what rfc8402 already specifies. The text is clear about the requirements and the assumptions. Please take this sentence out. 817 Such an approach is commonly referred to as "fail-open", which 818 inherently contains more risk than fail-closed methodologies. 819 Relying on perfectly crafted filters on all edges of the trusted 820 domain poses a demonstrable risk of inbound or outbound leaks if the 821 filters are removed or adjusted erroneously. It is also important to 822 note that some filtering implementations have limits on the size, 823 complexity, or protocol support that can be applied, which may 824 prevent the filter adjustments or creation required to properly 825 secure the trusted domain for a new protocol such as SRv6. [minor] The start of this paragraph sounds a little confusing to me because it seems that "Such an approach..." refers to the previous paragraph when using filters is mentioned, but without explaining why they may not always be an air-tight solution. Suggestion: move the first sentence to the end of the paragraph. ... 906 7.3. Hashed Message Authentication Code (HMAC) ... 918 * The HMAC TLV is OPTIONAL. [2119] "The HMAC TLV is OPTIONAL." rfc8754 is the Normative reference for declaring the HMAC TLV OPTIONAL -- there's no need or reason to respecify it here. s/The HMAC TLV is OPTIONAL./The HMAC TLV is optional [RFC8754]. ... 953 7.4. Control Plane Mitigation Methods ... 967 In centralized SRv6 control plane architectures, such as those 968 described in [I-D.ietf-pce-segment-routing-policy-cp], it is 969 RECOMMENDED that communication between PCEs and PCCs be secured using 970 authenticated and encrypted sessions. This is typically achieved 971 using Transport Layer Security (TLS), following the guidance in 972 [RFC8253] and best practices in [RFC9325]. [2119] s/it is RECOMMENDED/it is recommended ... 986 7.5. Management Plane Mitigation Methods ... 991 Management protocols such as NETCONF and RESTCONF are commonly used 992 to configure and monitor SRv6-enabled devices. These protocols must 993 be secured to prevent unauthorized access, configuration tampering, 994 or information leakage. [minor] Add references to NETCONF and RESTCONF. ... 1014 8. Implications on Existing Equipment [] What do you mean by "existing equipment"? The subsections below discuss devices that are not SRv6-aware and also mention potential issues with SRv6-aware devices. I initially assumed that "existing equipment" might refer to "legacy equipment" (not supporting SRv6), but that is not the case. Suggestion: move the text in §8.2 to §7.1.4 (after filtering is discussed). Then "promote" §8.1 to be §8 (and eliminate the "existing equipment" heading). 1015 8.1. Middle Box Filtering Issues 1017 When an SRv6 packet is forwarded in the SRv6 domain, its destination 1018 address changes constantly and the real destination address is 1019 hidden. Security devices on SRv6 network may not learn the real 1020 destination address and fail to perform access control on some SRv6 1021 traffic. [nit] s/SRv6 network/a SRv6 network/g (several occurrences in this section) [minor] s/fail to perform/incorrectly perform (?) [EoR-11]
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
