On Fri, May 29, 2026 at 9:42 PM Suresh Krishnan <[email protected]> wrote:
> Hi chairs/authors, > Thank you for your hard work on this important document. I have reviewed > draft-ietf-spring-srv6-security-14 and I think it is ready to progress > further in the IETF process. I do have some minor comments that you may > want to address > > * Section 6.1. > > This sentence is missing a verb and does not read right. Suggest rewording > to > > OLD: > While it is possible for packet manipulation and processing attacks > against all the fields of the IPv6 header and its extension headers, this > document limits itself to the IPv6 header and the SRH. > > NEW: > While packet manipulation and processing attacks are possible against all > the fields of the IPv6 header and its extension headers, this document > limits itself to attacks on the IPv6 header and the SRH. > > Agreed, fixed. > * Section 6.2.1.1. > > This sentence is a bit confusing. Suggest rewording > > OLD: > However, it facilitates more complex on-path attacks by redirecting > traffic to another node that the attacker has access to with more > processing resources. > > NEW: > However, it facilitates more complex on-path attacks by redirecting > traffic to another node, with more processing resources, that the attacker > has access to. > > * Section 8.1. > > Not sure what "take care of” means here? I would suggest using “handle” or > “inspect” depending on what you intend to say here. > Good catch, changed to: NEW: The security devices operating in SRv6 enabled networks need to understand and have the capability to process SRv6 packets. > > Regards > Suresh > > > On May 18, 2026, at 3:44 PM, Alvaro Retana via Datatracker < > [email protected]> wrote: > > > > This message starts a Second WG Last Call for: > > draft-ietf-spring-srv6-security-14 > > > > This Working Group Last Call ends on 2026-06-02 > > > > Abstract: > > SRv6 is a traffic engineering, encapsulation and steering mechanism > > utilizing IPv6 addresses to identify segments in a pre-defined > > policy. 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. > > > > File can be retrieved from: > > > > Please review and indicate your support or objection to proceed with the > > publication of this document by replying to this email keeping > > [email protected] in copy. Objections should be explained and suggestions > to > > resolve them are highly appreciated. > > > > Authors, and WG participants in general, are reminded of the Intellectual > > Property Rights (IPR) disclosure obligations described in BCP 79 [1]. > > Appropriate IPR disclosures required for full conformance with the > provisions > > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > > Sanctions available for application to violators of IETF IPR Policy can > be > > found at [3]. > > > > Thank you. > > > > [1] https://datatracker.ietf.org/doc/bcp78/ > > [2] https://datatracker.ietf.org/doc/bcp79/ > > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/ > > > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-spring-srv6-security-14.html > > > > A diff from the previous version is available at: > > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-srv6-security-14 > > > > _______________________________________________ > > spring mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > >
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
