Hi Alvaro, Thanks for the detailed review. We believe that version 13 addresses these comments: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/13
Please see the responses below, marked [TM]. Cheers, Tal. On Tue, Feb 24, 2026 at 12:51 AM Alvaro Retana <[email protected]> wrote: > > 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/ [TM] We have updated the (small number of) normative words to lower-case. If this remains the case, we will remove the BCP 14 boilerplate. > > > 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 > > [TM] Fixed. > > ... > 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? > > [TM] Updated. > > ... > 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. > > [TM] Updated. > > ... > 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). [TM] A table has been added to the mitigation section. > > > > ... > 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. [TM] Fixed. > > > > 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. [TM] Sentence removed. > > > > 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. > > [TM] Updated. > > ... > 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]. > [TM] Updated. > > > ... > 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 > [TM] Updated. > > > ... > 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. > [TM] Updated. > > > ... > 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). > [TM] The section title has been updated. > > > 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) > [TM] Updated. > [minor] s/fail to perform/incorrectly perform (?) > [TM] Updated. > > [EoR-11] > _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
