Thanks for this, Linda. I have added a bit of text detailing the policy
semantics considerations. At this time we have left out the untrusted
segments text as I believe this is focused on a trusted domain, and our
text . I will wait until we hear a bit more from the WG to see if we should
add some form of that text. As we have avoided giving instructions such as
MUST, SHOULD, etc. Those were terms omitted for that reason.

I look forward to more input from the WG on this.

nb

On Wed, Aug 27, 2025 at 2:22 PM Linda Dunbar <[email protected]>
wrote:

> Dear authors:
>
> Thank you for the clear treatment of SRv6 threats and mitigations in
> draft-ietf-spring-srv6-security-05. In parallel, I’d like to draw the WG’s
> attention to the RTGWG draft “Multi-segment SD-WAN via Cloud DCs” (
> *https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/*
> <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/>
> ), which describes an overlay pattern where a GENEVE header is added
> outside ESP so transit nodes can steer encrypted traffic. When SRH is used
> as a policy/steering carrier, it plays a very similar role to GENEVE;
> therefore, several of Multisegment-SDWAN draft’s Security Considerations
> and mitigations are directly applicable here—especially authenticating the
> outer policy header across multi-admin segments, treating filtering as
> helpful but insufficient by itself, and adopting strict error-handling
> (drop on auth failure, discard malformed TLVs, rate-limit/log). Although
> SRH often resides within a provider SR domain, packets may traverse
> provider or inter-domain paths; the same integrity requirements apply in
> those cases.
>
> Suggested additions:
>
> Location: end of §7.3 “Hashed Message Authentication Code (HMAC)” :
>
> SRH used as a policy carrier across untrusted segments. In deployments
> where SRH conveys steering/policy information that affects forwarding, the
> SRH plays a role analogous to the GENEVE header in RTGWG’s Multi-segment
> SD-WAN: a clear-text outer header whose fields guide transit behavior while
> payload confidentiality is preserved end-to-end by ESP. When such traffic
> may traverse infrastructure outside a single administrative trust boundary
> (e.g., provider domains or inter-domain paths), endpoints SHOULD enable the
> SRH HMAC TLV to provide integrity and origin authentication for the segment
> list, flags/Last-Entry, and relevant SRH TLVs, and nodes MUST drop packets
> that fail SRH-HMAC validation. Reliance on boundary filtering alone is
> operationally fragile and does not mitigate on-path modification or
> off-path insertion.
>
> Operational handling. When SRH carries policy semantics, implementations
> SHOULD (i) discard malformed SRH or invalid TLVs; (ii) drop on
> authentication failure; (iii) rate-limit and log repeated failures; and
> (iv) reject misrouted packets that lack an authorized destination/egress.
> These behaviors mirror the processing/error-handling recommended for the
> GENEVE policy header in Multi-segment SD-WAN and improve robustness when
> SRH crosses multi-admin paths.
>
> Best Regards,
> Linda Dunbar
>
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Thursday, August 21, 2025 1:12 PM
> To: [email protected]
> Cc: [email protected]
> Subject: [spring] I-D Action: draft-ietf-spring-srv6-security-05.txt
>
> Internet-Draft draft-ietf-spring-srv6-security-05.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-05.txt
>    Pages:   30
>    Dates:   2025-08-21
>
> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-srv6-security%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C1cf74d10e7b743c88f9b08dde0ef198a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638914039706823097%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vLgmoPnbonryWsYA44w33VQBsLh1yIKyh64C9yKyAFU%3D&reserved=0
>
> There is also an HTML version available at:
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-spring-srv6-security-05.html&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C1cf74d10e7b743c88f9b08dde0ef198a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638914039706849123%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jR%2FpIsIFFA9HilIcObTUZKdF1qxr5s7t4d8Fa%2F9V7Eg%3D&reserved=0
>
> A diff from the previous version is available at:
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-spring-srv6-security-05&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C1cf74d10e7b743c88f9b08dde0ef198a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638914039706863918%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OyMvEcPzGyD9uGL7ZvImCat%2Bkp3i%2Ba9956HfM%2Fc65FU%3D&reserved=0
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> 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