Thanks for the review. Comment inline. On Wed, Sep 23, 2026 at 7:34 AM Jean-Michel Combes via Datatracker <[email protected]> wrote: > > Document: draft-ietf-spring-srv6-security > Title: Segment Routing IPv6 Security Considerations > Reviewer: Jean-Michel Combes > Review result: Has Issues > > Hi, > > I have been selected as the Operational Directorate (opsdir) reviewer for this > Internet-Draft. > > The Operational Directorate reviews all operational and management-related > Internet-Drafts to ensure alignment with operational best practices and that > adequate operational considerations are covered. > > A complete set of _"Guidelines for Considering Operations and Management in > IETF Specifications"_ can be found at > https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/. > > While these comments are primarily for the Operations and Management Area > Directors (Ops ADs), the authors should consider them alongside other feedback > received. > > - Document: Segment Routing IPv6 Security Considerations > (draft-ietf-spring-srv6-security-16) > > - Reviewer: Jean-Michel COMBES > > - Review Date: 2026-09-23 > > - Intended Status: Informational > > --- > > Hi, > > As I already reviewed a previous version of this document (cf. > https://datatracker.ietf.org/doc/review-ietf-spring-srv6-security-11-opsdir-early-combes-2026-02-24/), > I focus this review on the differences between this version of the document > and > the version of the already reviewed document. > > I have only one Major Issue and I am fine with the rest of the document. > > - Section 7.6. "Layer 2 Mitigation" > <JMC> > <Major Issue> > Initially, my concern was only a Minor Issue. > But, MACsec is proposed to mitigate all attacks mentioned in the document (cf. > Section 7.7), which, IMHO, looks strongly like a “Just use IPsec” – > s/IPsec/MACsec here, often used in the past :) This is the reason why I raised > my concern as a Major Issue instead as a Minor Issue. > > Regarding the issue itself, IMHO, it is important to give details about “In > some circumstances”. Indeed, AFAIK, MACsec doesn’t provide generally > “end-to-end security”: for example, when the goal is to secure exchanges > between two communicating nodes and there is, at least, either a router or a > switch between the two communicating nodes. So, from an operational point of > view, deploying MACsec (i.e., spent time/resources) might not always provide > the expected results (i.e., “end-to-end security” between two communicating > nodes). </JMC>
How does this sound: OLD: In some circumstances it may be possible to mitigate passive listening and packet insertion by leveraging [MACsec] to encrypt traffic at the media access control (MAC) layer by using encryption between two connected devices. This methodology prevents unauthorized access to traffic over a given point to point path by encrypting and authenticating data in transit at Layer 2, which prevents passive interception and mitigates packet-insertion DoS from unauthorized on-path nodes. Much like the encryption mechanisms noted for protocol communication and management access, this level of protection can provide integrity and authenticity to all higher layer communications over a given layer 2 path. NEW: How does this sound: OLD: In some circumstances it may be possible to mitigate passive listening and packet insertion by leveraging [MACsec] to encrypt traffic at the media access control (MAC) layer by using encryption between two connected devices. This methodology prevents unauthorized access to traffic over a given point to point path by encrypting and authenticating data in transit at Layer 2, which prevents passive interception and mitigates packet-insertion DoS from unauthorized on-path nodes. Much like the encryption mechanisms noted for protocol communication and management access, this level of protection can provide integrity and authenticity to all higher layer communications over a given layer 2 path but comes with operational trade-offs and added complexity. Additionally, there are design scenarios where this is impractical or otherwise not possible. > > Hope that helps. > > Thanks in advance for your reply. > > Best regards, > > JMC. > > > _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
