[spring] Mike Bishop's No Objection on draft-ietf-spring-srv6-security-17: (with COMMENT)

[Mike Bishop via Datatracker <[e-mail]>]

Mike Bishop has entered the following ballot position for
draft-ietf-spring-srv6-security-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/



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