Speaking strictly as a participant, I don't see how a trust domain
boundary can exist purely as a polciy demarcation without enforcement
mechanism. An organization may have a boundary on where it wants to run
SRv6 by policy.. But there needs to be an enforced boundary (either at
or around that policy boundary) or folks who are not trusted will be
able to send in SRv6 packets with arbitrary SRH, destination, etc.
This change to the wording does not seem to me as a participant to be
correct.
Yours,
Joel
On 11/6/2025 9:38 AM, [email protected] wrote:
Internet-Draft draft-ietf-spring-srv6-security-09.txt is now available. It is
a work item of the Source Packet Routing in Networking (SPRING) WG of the
IETF.
Title: Segment Routing IPv6 Security Considerations
Authors: Nick Buraglio
Tal Mizrahi
Tian Tong
Luis M. Contreras
Fernando Gont
Name: draft-ietf-spring-srv6-security-09.txt
Pages: 30
Dates: 2025-11-06
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.
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-09.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-srv6-security-09
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
I-D-Announce 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]
