[spring] Re: I-D Action: draft-ietf-spring-srv6-security-09.txt

[Nick Buraglio <[e-mail]>]

Joel,

Would Suresh's text aid in that clarification?

*Following the direction of [RFC8402], the current document assumes that
SRv6 is deployed within a trusted domain and that the traffic is filtered
at the domain boundaries. Traffic MUST be filtered at the domain
boundaries. Thus, most of the attacks described in this document are
limited to within the domain (i.e., internal attackers).*




On Thu, Nov 6, 2025 at 12:22 PM Joel Halpern <[e-mail]> wrote:

> From where I sit, I can't see how the detailed text in 7.1 (MUST be
> filtered) comports with the new text that says that the trust boundary can
> be policy without mechanism.
>
> Yours,
>
> Joel
> On 11/6/2025 12:16 PM, Nick Buraglio wrote:
>
> Joel,
>
> In section 7.1 we provide a fair amount of detail surrounding filtering a
> trusted domain. For example:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *7.1.  Trusted Domains and Filtering 7.1.1.  Overview    As specified in
> [RFC8402]:     By default, SR operates within a trusted domain.  Traffic
> MUST be     filtered at the domain boundaries.     The use of best
> practices to reduce the risk of tampering within the     trusted domain is
> important.  Such practices are discussed in     [RFC4381] and are
> applicable to both SR-MPLS and SRv6.    Following the spirit of [RFC8402],
> the current document assumes that    SRv6 is deployed within a trusted
> domain.  Traffic MUST be filtered    at the domain boundaries.  Thus, most
> of the attacks described in    this document are limited to within the
> domain (i.e., internal    attackers). *
> There is quite a lot dedicated to protecting the TD and what it means if
> it isn't.
> Would that be sufficient?
>
> nb
>
>
>
> On Thu, Nov 6, 2025 at 9:48 AM Joel Halpern <[e-mail]> wrote:
>
>> 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, [e-mail] 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 -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> spring mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>