[spring] Re: Chair Review of draft-ietf-spring-srv6-security-11

[Tal Mizrahi <[e-mail]>]

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 <[e-mail]> 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]
>