Hi,

I support the publication of draft-ietf-spring-srv6-security-14. It provides 
important aspects of SRv6 networking.

Comment for a possible consideration:
- pointing to MACSec (using it for communication integrity regarding 
SRv6-specifics)
Upper layers like ESP or TLS may protect the user data. However, in the scope 
of SRV6, only the elements considered
to route the packet needs to be considered, whereas such packet header fields 
change during the forwarding. HMAC
has its own limitations (listed properly in the document). Assuming SRV6 links 
are protected by MACsec, passively
listening or spoofing or manipulating packet can only be performed by an 
attacker that has compromised a node.
If MACsec is not deployed, then any on path attacker can perform such 
techniques. So, communication integrity
regarding SRv6-specifics can be provided by MACsec. Maybe worth to state this 
clearly in the document
(i.e., lower layer may help here).

Minor (& subjective) comments:
- insertion: maybe injection might be a more appropriate term (e.g., Section 4. 
Threat Terminology)
- resource exhaustion: maybe worth to add a special form of DoS, where a 
modified path causes drop of time sensitive packets, as too late packets are 
considered invalid (Section 5. Effect)
- packet deletion: maybe packet drop would be a better term (e.g., Section 6.1. 
Attack Abstractions)

Thanks & Cheers
Bala'zs

-----Original Message-----
From: Alvaro Retana via Datatracker <[email protected]>
Sent: Monday, May 18, 2026 9:45 PM
To: [email protected]; [email protected]; 
[email protected]; [email protected]
Cc: [email protected]; [email protected]
Subject: [spring] Second WG Last Call: draft-ietf-spring-srv6-security-14 (Ends 
2026-06-02)

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]

Reply via email to