On Mon, Aug 19, 2024 at 11:29 AM Dhruv Dhody <dhruv.i...@gmail.com> wrote: > > 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.
+1 > > - 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. Thanks, we'll clean that up. > > - Section 5; for Masquerade the reference provided is RFC 9088 but that RFC > does not use the term. Will fix this. > > - 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? Will fix this. > > - 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? This is an interesting point. We've so far avoided much talk of controllers, but large scale networks are likely to employ something to control LSPs and pre-computed paths, among other things. Will consider how to best address this. > > - 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)? Up until now we'd left that out. I'll talk with the group and see what the consensus is, and how we'd best add details. > > - Delete sections 12 and 13, they are duplicates! +1 > > # 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! Will address the nits, and definitely run through some grammar tooling. > > 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
