Hi, I support adoption. Please find some non-blocking comments that authors can work on.
# Minor - Should you call out RFC 8986 Network programming in the Introduction? - Section 2, it gives the impression that the control and management plane are not in scope but we do have section 6.4. Update this section to include text about the control and management plane. - Section 4; It would be good to be explicit about what it means for the SR domain to be cryptographically secured. It is not clear if HMAC (section 7.3) is an example or THE technique that makes an SRv6 domain cryptographically secure. - Section 5; for Masquerade the reference provided is RFC 9088 but that RFC does not use the term. - Section 6.2.4 to Section 6.2.6; I guess these subsections were supposed to be under a section heading (recon attack) that is missing? - Section 6.4; Should one also mention compromised PCE or SDN controller? It seems the current focus is mainly on IGP? In this text - "Injection can be performed by off-path attackers, while removal, replaying and listening require on-path access."; if this is about injection of control plane packets, is it wise to use on-path and off-path? - Section 7.1; I wonder if we should say more about the operational side of these filtering techniques. For section 7.1.2, should we also include RFC-to-be 9602 (draft-ietf-6man-sids)? - Delete sections 12 and 13, they are duplicates! # Nits - Expand SRv6 in the title and abstract - Add reference for Segment Routing Header (SRH) as [RFC8754] - s/reliance of a new header/reliance on a new header/ - Section 3.2 can also include - SR, LUA, GUA, DA - s/applied baed on/applied based on/ - s/using LUA addresses/using ULA addresses/ - s/from the last entry in the ./from the last entry in the SRH./ (?) - s/keeeping/keeping/ - s/do not posses/do not possess/ - s/PE device a as source address/PE device as source address/ - Please run the text through a grammar check, many issues that I did not list! Thanks! Dhruv On Mon, Aug 5, 2024 at 6:35 PM Alvaro Retana <aretana.i...@gmail.com> wrote: > Dear WG: > > This message starts a two-week adoption call for > ddraft-bdmgct-spring-srv6-security, ending on August/19. From the > Abstract: > > 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. > > > https://datatracker.ietf.org/doc/draft-bdmgct-spring-srv6-security/ > > > Please review the draft and consider whether you support its adoption > by the WG. Please share any thoughts with the list to indicate support > or opposition -- this is not a vote. > > If you are willing to provide a more in-depth review, please state it > explicitly to give the chairs an indication of the energy level in the > working group willing to work on the document. > > WG adoption is the start of the process. The fundamental question is > whether you agree the proposal is worth the WG's time to work on and > whether this draft represents a good starting point. The chairs are > particularly interested in hearing the opinions of people who are not > authors of the document. > > Note that the IESG requested that the WG deliver a document covering > security considerations for SRv6. This document is intended to satisfy > that request. > > Thanks! > > Alvaro (for the Chairs) > > _______________________________________________ > spring mailing list -- spring@ietf.org > To unsubscribe send an email to spring-le...@ietf.org >
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
