Segment Routing over IPv6 (SRv6) Security Considerations
draft-ietf-spring-srv6-security-18

[Ballot comment]
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  at the end to ensure you have the
full review.

#Updated for v18: Thanks for taking care of the discussion points and several
of the comments/suggestions in my original ballot. I've only retained those
(NON-BLOCKING) points that were not updated or perhaps missed out and deleted
all the rest - I leave them to the authors' discretion.
The idnits extracts still refer to v17.

#new for v18 - please fix the warnings reported by idnits, especially the ones
related to references.

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.


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:


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.

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.


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.

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.

[Ballot 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  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.

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).


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.

[Ballot 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.

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.

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

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].

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

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

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

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.

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

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.

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.

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.

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

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

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,

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

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

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   +-------------+------------------+-----------------------------------+

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.

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.

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.

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

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

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.

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.

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.

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

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.

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.

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

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.

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  tuple of the packet from PE1

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].

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.

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.

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-spring-srv6-security-17
CC @evyncke

Thank you for the work put into this document. It is well structured, easy to read, and quite useful. Thanks to the authors for navigating in muddy waters ;-)

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Zafar Ali for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 6.3.2.1

RFC 8476 is only relevent to communicate the MSD in the SR-MPLS context and not in SRv6 ;-) So `Another example in the context of SRv6 is the advertisement of an incorrect Maximum SID Depth (MSD) value [RFC8476].` should be removed or RFC 9513 be used.

[Ballot comment]

## COMMENTS (non-blocking)

### Section 1

s/deprecated routing header 0/deprecated routing header *type* 0/ ?

s/the bridging of islands of SRv6 devices with standard IPv6 unicast *routing*/the bridging of islands of SRv6 devices with standard IPv6 unicast *forwarding*/ ?

### Section 2

Why not adding RFC 9602 to the list of important RFC as it reserves 5f00::/16 for SRv6, which could simplify some security policies ? It is cited in 7.1.3 though.

Who is the "we" in `we note that SRv6 is under active development` ? The authors ? The SPRING WG ? the IETF community ? Please be clear or rephrase with the passive voice. Also in section 5 and possibly others.

### Section 4

The title somehow disagree with `This section introduces the threat *taxonomy*/, i.e., suggest to change the section title to use "taxonomy" rather than "terminology".

s/The following figure/Figure 1/

### Section 5

Some people may prefer "on-path attacks" rather than `man-in-the-middle attacks`

### Section 6.2.1.1

Adding SRH or SRH TLV is not so easy as it could exceed the MTU, so, the attacked is not so easy to mount. Should this be mentioned ?

### Section 6.3.3.1

Add a normative reference to RFC 9259 about the O-flag in `Segment Routing Header Flags` even if this RFC is cited in the previous paragraph, the link with the O-flag must be clear.

### Section 6.3.4

Rename the section title to "Centralized Control Plane Attacks" to be consistent with the text of 6.3.4.1 ?

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot discuss]
** Sections 7.1.1 and 7.1.2.

-- Section 7.1.1 says “the current document assumes that SRv6 is a trusted domain and that the traffic is filtered at the domain boundaries.  Filtering at SR ingress nodes is intended to mitigate modification and insertion attacks, while filtering at SR egress nodes is intended to mitigate outbound leaks.”

-- Section 7.1.2 says “A packet containing an SRH may not be destined to the SR domain, as it may be simply transiting the domain.”

These sections appears to be providing conflicting guidance on what crosses the domain boundary of a trusted domain.  Section 7.1.1 appears to suggest that SR traffic gets dropped on ingress and egress of the boundary.  However, Section 7.1.2 suggests that SR domain might accept packets transiting from outside an SR domain which seems like the definition of an “insertion attack” (inconsistent with the guidance in Section 7.1.1).  Likewise, it seems difficult for a node on the boundary of the trust domain to distinguish between SRH legitimately transiting the network from a leaked or forged SRH.

Section 7.2 could be suggesting that this language in Section 7.1.2 applies to encapsulated traffic.  Is that the only case?  If so, the text could be clearer.

** Section 7.4
  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.

The above guidance seems to be a weaker restated of Section 2.1.1 of RFC9259:
  The processing node MUST rate-limit the number of packets punted to
  the OAM process to a configurable rate.  This is to avoid impacting
  the performance of the OAM and telemetry collection processes.
  Failure to implement the rate limit can lead to a denial-of-service
  attack, as detailed in Section 3.

This document’s text suggests there is flexibility and RFC9259 seems very clear with mandatory guidance.

** Section 7.7, Figure 3

This section lists HMAC as a mitigation for replay attacks.  It might be possible to construct a protocol design that makes this possible, but the HMAC TLV defined in RFC8754 doesn’t appear to do that alone.  Section 7.3 of this document seems to acknowledge that with the following text:

==[ snip from Section 7.3 ]==
  *  For the lifetime of the pre-shared key validity, an internal
      attacker who does not have access to the pre-shared key can
      capture legitimate packets, and later replay the SRH and HMAC from
      these recorded packets. 
==[ snip ]==

[Ballot comment]
Hi Nick, Tal, Tian , Luis, and Fernando,

Thank you for the effort put into this document.

Thanks also to Jean-Michel Combes for the OSPDIR review and the authors for engaging.

Several of the attacks in the document are also applicable to non-SR as an attacker that act from within a network can do a lot of damage, for example, this one:

      -  Causing packets to be discarded: an attacker may cause a packet
        to be forwarded to a point in the network where it can no
        longer be forwarded, causing the packet to be discarded.

..but that is OK.

Please find below some few comments:

# For authors convenience, I sent a PR with some suggestions: https://github.com/buraglio/draft-bdmgct-spring-srv6-security/pull/79.

# Steering is a TE function

CURRENT:
  SRv6 is a traffic engineering, encapsulation and steering mechanism
  utilizing

TE/steering is redundant. Please refer to TE components in RFC9522.

# The text can be simplified and avoid repetition. For example, the following can be simply deleted:


CURRENT:
SRv6 is
  fundamentally bound to the IPv6 protocol and introduces the
  aforementioned new extension header. 


Or

*  SRv6 may use the SRH which is a type of Routing Extension Header
      defined by [RFC8754]. 

# Clarification

CURRENT:
  *  While SRv6 uses what appear to be typical IPv6 addresses, the
      address space is processed differently by segment endpoints.  A
      typical IPv6 unicast address is comprised of a network prefix and
      a host identifier. 

and other SID list mention;

Check if e a reminder of the clarifications in draft-ietf-6man-sidlist-clarification is useful here.

# Not sure how this is used in the document

CURRENT:
  The following IETF RFCs were selected for security assessment as part
  of this effort:

  *  [RFC8402] : Segment Routing Architecture

  *  [RFC8754] : IPv6 Segment Routing Header (SRH)

  *  [RFC8986] : Segment Routing over IPv6 (SRv6) Network Programming

  *  [RFC9020] : YANG Data Model for Segment Routing

  *  [RFC9256] : Segment Routing Policy Architecture

  *  [RFC9491] : Integration of the Network Service Header (NSH) and
      Segment Routing for Service Function Chaining (SFC)

  *  [RFC9524] : Segment Routing Replication for Multipoint Service
      Delivery

  *  [RFC9800] : Compressed SRv6 Segment List Encoding

For example, how the SFC/NSH was used in the analysis?

# Source routing in general

CURRENT:
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.

I don’t think this is accurate as this would apply for any source routing approach.

# Billing bypass

CURRENT:
        example in order to avoid the billing service or circumvent
        access controls and security filters.

I don’t this one

# Idem for this one:

CURRENT:
        This can result in
        allowing various unauthorized services such as traffic
        acceleration. 

# Use RFC9907#section 3.7.1 boilerplate instead

CURRENT:
  Management protocols such as NETCONF [RFC6241] and RESTCONF [RFC8040]
  are commonly used to configure and monitor SRv6-enabled devices.
  These protocols must be secured to prevent unauthorized access,
  configuration tampering, or information leakage.

  The lowest NETCONF layer is the secure transport layer, and the
  mandatory-to-implement secure transport is Secure Shell (SSH)
  [RFC6242].  The lowest RESTCONF layer is HTTPS, and the mandatory-to-
  implement secure transport is TLS [RFC9846].

Cheers,
Med

[Ballot comment]
# IESG review of draft-ietf-spring-srv6-security-17

CC @MikeBishop

## Comments

### Section 2, paragraph 8
```
    *  [RFC9256] : Segment Routing Policy Architecture

    *  [RFC9491] : Integration of the Network Service Header (NSH) and
        Segment Routing for Service Function Chaining (SFC)

    *  [RFC9524] : Segment Routing Replication for Multipoint Service
```
These RFCs are never mentioned again in the document. If they're relevant, why
not?

RFC 9524 Section 4 has SRv6-specific threats this taxonomy should discuss:
replication-segment loops that "create a storm until ... IPv6 Hop Limit ...
decrements to zero", ICMPv6 Parameter Problem storms toward a spoofed source via
a Replication-SID, the Hop Limit Threshold mitigation, and injection into a P2MP
service. RFC 9256 Section 10 adds SR Policy endpoint spoofing / duplicate
advertisement causing traffic diversion.

### Section 7.1.3, paragraph 11
```
    [RFC8754]'s description of packet filtering.  There are no known
    limitations with filtering on infrastructure addresses, and [RFC9099]
```
...other than the ones you point out in Section 7.1.1?

### Section 7.2, paragraph 1
```
    forwarding decisions within the domain never depend on header fields
    supplied by an untrusted source.  Decapsulating and forwarding the
```
Is this true of flow labels / ECMP?

### Section 7.3, paragraph 7
```
    *  For the lifetime of the pre-shared key validity, an internal
        attacker who does not have access to the pre-shared key can
```
Doesn't section 4 define an attacker without the keys to be external? "An
internal attacker" who is external by definition seems inherently contradictory.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 5, paragraph 13
```
-          amplification by increasing the number hops that each packet is
+          amplification by increasing the number of hops that each packet is
+                                                +++
```

#### Section 6.3.4.1, paragraph 1
```
-    PCE/PCCC in an SR domain, thereby increasing the risk of compromise
+    PCE/PCECC in an SR domain, thereby increasing the risk of compromise
+          +
```

#### Section 7.1.3, paragraph 8
```
-    making it more simple to filter traffic at the edge of the SR
-              -----
+    making it simpler to filter traffic at the edge of the SR
+                    +
```

#### Section 7.2, paragraph 1
```
-    directly from untrusted-facing interfaces.This is a specific case of
+    directly from untrusted-facing interfaces. This is a specific case of
+                                              +
```

### Section 2, paragraph 9

Who is "we"? The IETF? The WG? The authors? In general, first person should
be avoided.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for review of draft-ietf-spring-srv6-security-17

# Many thanks to Henning Rogge and Andrew Alston for the RTGDIR review.

# Thanks for the nice useful writeup. While reviewing i found two easy to resolve items to discuss and few observations you may want to comment upon.

# Through the document please replace the reference to the "last SRH entry" with an explicit field expression. For an ordinary uncompressed SRH, the final policy segment is Segment List[0], not the entry indexed by Last Entry. Please also look into guidance for packets without an SRH and for compressed segment lists. A general instruction to read one SRH entry does not cover those cases, and that should be made explicit within the text.

# Within Sections 1 and 3: Make SRH optionality clear from the introduction.
Please describe SRv6 as "potentially" using an SRH. This will align the opening explanation with the later filtering discussion and avoid suggesting that SRH detection identifies all SRv6 traffic.

# Section 2: Explain how the listed specifications were assessed.
RFC 9491 and RFC 9524 are identified as part of the assessment, but their specific behaviors deserve a short explicit explanation of how the general analysis covers them.

# Section 6.3.2: Cite the SRv6-specific MSD definitions.
It is correct that RFC 8476 supplies the OSPF MSD advertisement framework, but it is insufficient as the sole reference for the SRv6 example.

For completeness you could consider to add RFC 9352, Section 4, and RFC 9513, Section 4. They distinguish Maximum Segments Left, Maximum End Pop, Maximum H.Encaps, and Maximum End D MSD types.

Brgds,
Gunter Van de Velde
Routing Area Director

[Ballot comment]
Thank you for a readable and interesting document. I read this from a transport protocol perspective and have no additional comments. Thanks also to Colin Perkins for his TSV-ART review.

Best wishes,
Gorry

[Ballot comment]
Thank you for a readable and interesting document. I read this from a transport protocol perspective and have no additional comments.
Best wishes,
Gorry

The following Last Call announcement was sent out (ends 2026-09-17):

From: The IESG
To: IETF-Announce
CC: aretana.ietf@gmail.com, draft-ietf-spring-srv6-security@ietf.org, james.n.guichard@futurewei.com, spring-chairs@ietf.org, spring@ietf.org, zali@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Segment Routing IPv6 Security Considerations) to Informational RFC


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Segment Routing IPv6
Security Considerations'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-09-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  SRv6 is a traffic engineering, encapsulation and steering mechanism
  utilizing IPv6 addresses to identify segments in a pre-defined
  policy.  This document discusses security considerations in SRv6
  networks, including the potential threats and the possible mitigation
  methods.  The document does not define any new security protocols or
  extensions to existing protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

This is the Shepherd writeup from Zafar Ali for draft-ietf-spring-srv6-srh-compression.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad agreement for publishing this document. There was no real opposition to this document.
There has been several suggestions for clarification that were addressed. There was interaction by some WG
members.

There were two working group last calls. The second working group's last call received many comments and support for the document's progression. The authors have addressed the comments. The second WGLC was closed on Aug. 11, 2026. 

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
There is no notable controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No, as a shepherd of the document I do not see risk of an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are several existing deployments of SRv6 by multiple vendors by multiple operators
where operators has successfully deployed and secured the SRv6 deployments.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There were good reviews in SPRING WG and several people from 6MAN WG expressed support.
The SPRING WG chairs have ensured to involve the 6MAN WG throughout the process.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, YANG model, media type, or URI type.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not Applicable. No YANG model.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. it is my opinion that this document is needed.
The document is clearly written, complete, correctly designed.
I think it is ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
 
The OPS and SEC directorate reviews have already been completed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status for the document is to proceed as an Informational RFC. This aligns with a specific poll by the WG chairs on the intended status of the draft. The authors of the draft, as well as multiple working group participants, suggested that it be designated as Informational. No objection was raised to the intended status of Informational during the poll. In summary, the document's intended status aligns with the discussion in the working group. Furthermore, all Datatracker state attributes correctly reflect the draft's intended status.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations.
Most recently chairs issued the following IPR) disclosure check as part of the second WGLC:
Link to the most recent intellectual property rights (IPR) disclosure obligations call: https://mailarchive.ietf.org/arch/msg/spring/iRHfp4icIABRc15CUCXzRpcBXlc/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, they have shown their willingness to be listed.
The number of authors and editors on the front page is five.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits was been run and authors will correct the minor error (see below).
Internet-Drafts Checklist done.

idnits 2.17.1

draft-ietf-spring-srv6-security-16.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == There are 3 instances of lines with non-ascii characters in the document.


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There is 1 instance of too long lines in the document, the longest one
    being 2 characters in excess of 72.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Line 254 has weird spacing: '...xternal    int...'

  == Line 255 has weird spacing: '...ttacker    att...'

  -- The document date (29 July 2026) is 13 days in the past.  Is this
    intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

    No issues found here.

    Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

I confirm the points.
This document has no IANA actions.
 
21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None; This document has no IANA actions.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

This is the Shepherd writeup from Zafar Ali for draft-ietf-spring-srv6-srh-compression.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad agreement for publishing this document. There was no real opposition to this document.
There has been several suggestions for clarification that were addressed. There was interaction by some WG
members.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
There is no notable controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No, as a shepherd of the document I do not see risk of an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are several existing deployments of SRv6 by multiple vendors by multiple operators
where operators has successfully deployed and secured the SRv6 deployments.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There were good reviews in SPRING WG and several people from 6MAN WG expressed support.
The SPRING WG chairs have ensured to involve the 6MAN WG throughout the process.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, YANG model, media type, or URI type.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not Applicable. No YANG model.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. it is my opinion that this document is needed.
The document is clearly written, complete, correctly designed.
I think it is ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
 
I think the document will benefit from a directorate review from OPS and SEC areas.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status for the document is to proceed as an Informational RFC. This aligns with a specific poll by the WG chairs on the intended status of the draft. The authors of the draft, as well as multiple working group participants, suggested that it be designated as Informational. No objection was raised to the intended status of Informational during the poll. In summary, the document's intended status aligns with the discussion in the working group. Furthermore, all Datatracker state attributes correctly reflect the draft's intended status.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations.
There have been IPR call as part of the progression of this draft.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, they have shown their willingness to be listed.
The number of authors and editors on the front page is five.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits has been run and error corrected.
Internet-Drafts Checklist done.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

I confirm the points.
This document has no IANA actions.
 
21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None; This document has no IANA actions.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

This is the Shepherd writeup from Zafar Ali for draft-ietf-spring-srv6-srh-compression.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad agreement for publishing this document. There was no real opposition to this document.
There has been several suggestions for clarification that were addressed. There was interaction by some WG
members.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
There is no notable controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No, as a shepherd of the document I do not see risk of an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are several existing deployments of SRv6 by multiple vendors by multiple operators
where operators has successfully deployed and secured the SRv6 deployments.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There were good reviews in SPRING WG and several people from 6MAN WG expressed support.
The SPRING WG chairs have ensured to involve the 6MAN WG throughout the process.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, YANG model, media type, or URI type.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not Applicable. No YANG model.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. it is my opinion that this document is needed.
The document is clearly written, complete, correctly designed.
I think it is ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
 
I think the document will benefit from a directorate review from OPS and SEC areas.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The intended status for the document is to proceed as an Informational RFC. This aligns with a specific poll by the WG chairs on the intended status of the draft. The authors of the draft, as well as multiple working group participants, suggested that it be designated as Informational. No objection was raised to the intended status of Informational during the poll. In summary, the document's intended status aligns with the discussion in the working group. Furthermore, all Datatracker state attributes correctly reflect the draft's intended status.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations.
There have been IPR call as part of the progression of this draft.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, they have shown their willingness to be listed.
The number of authors and editors on the front page is five.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits has been run and error corrected.
Internet-Drafts Checklist done.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

I confirm the points.
This document has no IANA actions.
 
21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None; This document has no IANA actions.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

This is the Shepherd writeup from Zafar Ali for draft-ietf-spring-srv6-srh-compression.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad agreement for publishing this document. There was no real opposition to this document.
There has been several suggestions for clarification that were addressed. There was interaction by some WG
members.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
There is no notable controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No, as a shepherd of the document I do not see risk of an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are several existing deployments of SRv6 by multiple vendors by multiple operators
where operators has successfully deployed and secured the SRv6 deployments.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There were good reviews in SPRING WG and several people from 6MAN WG expressed support.
The SPRING WG chairs have ensured to involve the 6MAN WG throughout the process.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, YANG model, media type, or URI type.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not Applicable. No YANG model.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. it is my opinion that this document is needed.
The document is clearly written, complete, correctly designed.
I think it is ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
 
I think the document will benefit from a directorate review from OPS and SEC areas.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

All Datatracker state attributes correctly reflect the intended status of the draft.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations.
There have been IPR call as part of the progression of this draft.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, they have shown their willingness to be listed.
The number of authors and editors on the front page is five.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits has been run and error corrected.
Internet-Drafts Checklist done.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

I confirm the points.
This document has no IANA actions.
 
21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None; This document has no IANA actions.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents
*This version is dated 4 July 2022.*

This is the Shepherd writeup from Zafar Ali for draft-ietf-spring-srv6-srh-compression.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad agreement for publishing this document. There was no real opposition to this document.
There has been several suggestions for clarification that were addressed. There was interaction by some WG
members.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
 
There is no notable controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No, as a shepherd of the document I do not see risk of an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, there are several existing deployments of SRv6 by multiple vendors by multiple operators
where operators has successfully deployed and secured the SRv6 deployments.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

There were good reviews in SPRING WG and several people from 6MAN WG expressed support.
The SPRING WG chairs have ensured to involve the 6MAN WG throughout the process.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, YANG model, media type, or URI type.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

Not Applicable. No YANG model.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Not Applicable

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. it is my opinion that this document is needed.
The document is clearly written, complete, correctly designed.
I think it is ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
 
I think the document will benefit from a directorate review from OPS and SEC areas.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is requested and indicated in the title page header.
However, it is my opinion that the working group should discuss the intentional status of the
document (Standards Track, informational or BCP) before the handoff.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations.
There have been IPR call as part of the progression of this draft.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, they have shown their willingness to be listed.
The number of authors and editors on the front page is five.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Idnits has been run and error corrected.
Internet-Drafts Checklist done.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

I confirm the points.
This document has no IANA actions.
 
21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

None; This document has no IANA actions.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/