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

["jmh.direct" <[e-mail]>]

If that replaced the last edit, that would resolve my concern.Yours,JoelSent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone
-------- Original message --------From: Nick Buraglio <[e-mail]> Date: 11/6/25  1:44 PM  (GMT-05:00) To: Joel Halpern <[e-mail]> Cc: [e-mail] Subject: Re: [spring] Re: I-D Action: draft-ietf-spring-srv6-security-09.txt 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]