Hi, At first, my apologies: I totally missed your reply.
The new text works for me. Best regards, JMC. Le mer. 23 sept. 2026 à 20:11, Nick Buraglio <[email protected]> a écrit : > 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]
