Dear Andrew, Many thanks for the review and comments! An updated version has been posted: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/12
Please see some replies, marked [TM]. Cheers, Tal. On Mon, Mar 2, 2026 at 1:18 PM Andrew Alston via Datatracker <[email protected]> wrote: > > Document: draft-ietf-spring-srv6-security > Title: Segment Routing IPv6 Security Considerations > Reviewer: Andrew Alston > Review result: Ready > > I have read through the srv6-security document carefully (and a number of > times) and by and large I believe this document to be ready. > > What follows are comments for consideration - though I do not believe they > will > necessarily prevent the document from moving forward. > > Firstly - in section 7.1 it refers to a trusted domain. I would prefer some > further wording to make it clear that the boundaries of a trusted domain must > be such that the trusted domain does not include, for example, servers > connected to the network that third parties have access to. I have seen > several companies that have made the assumption that a trusted domain starts > and stops at the peering/transit interfaces and at the CPE. Forgetting that > hosting servers that customers have access to inside the network create a > breach in the concept of the trusted domain. This is of particular importance > in the case of srv6 - since crafting and sending SRv6 packets from a server > into the network is a trivial exercise. [TM] Right. The text in section 4 regarding trusted domains was updated, and the issue you raised is addressed in the current text. > > I would also like to see some text in this document about potential resource > exhausion caused by maintaining wide filter lists (if you have a few thousand > vlans hosting a few thousand servers - you are going to need to apply > filtering > to each of them, and this can exhaust TCAM space on various devices, as such > the security mechanisms themselves can create its own issues) [TM] Right. The text in the first paragraph of Section 8.2 was revised and now addresses this issue. > > Secondly - from my perspective I believe a document such as this should > probably be a BCP - but this may come later. My question is why this document > is purely informational rather than a BCP? > > Beyond that - I found the document well written and comprehensive, and my > thanks to the authors for all the work put into it. > > > _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
