Markdown Version | Session Recording

Session Date/Time: 13 May 2025 14:00

SPRING

Summary

The SPRING Working Group held an interim meeting focused on accelerating the draft-ietf-spring-srv6-security-considerations document towards an anticipated publication by the end of the year. The meeting included a detailed review of recent updates to the draft, particularly changes made to address data plane security, terminology, and filtering recommendations. Key discussions revolved around the use of different IPv6 address types (ULA, RFC 9602 prefix, GUA) for SRv6 SIDs, the document's relationship with existing SRv6 RFCs, and the delineation of control plane and management plane security considerations. A general sense of the room indicated satisfaction with the current direction of the draft.

Key Discussion Points

• Chairs' Opening Remarks: The meeting's primary goal is to finalize the draft-ietf-spring-srv6-security-considerations document by the end of the year, including an update at IETF 123 in Madrid and a likely interim meeting before November. All participants were encouraged to review and comment.
• Presenter's Update (Nick) on Draft Revisions:
  • Acknowledged previous guidance which helped refine the document's direction, particularly on May deliverables.
  • Noted extensive work by Tal on PRs and document updates.
  • Core Changes:
    • Tied together data plane and control plane attacks.
    • Refined threat terminology to distinguish internal versus external attacks.
    • Simplified Figure 1, reducing it to five attack types.
    • Changed "impact" to "outcome" throughout the document for consistency.
    • Expanded on system integrity attacks in Section 5, detailing path selection/avoidance, header modifications, and Denial of Service (DoS) attacks (resource exhaustion, forwarding loops, packet discard).
    • Expanded on-path modification attacks in Section 6.2.1 (SID list modifications, DA manipulation, TLV modifications) and removed a table for readability.
    • Cleaned up the effects section (Section 6.2.3), providing a concise list and referring back to Section 5 for details.
    • Added an attack summary table in Section 6.7.
    • Expanded filtering details and refined "trusted domain" terminology in Section 7.1.1, including a better description of "fail open" scenarios.
    • Trusted Domain Reference: Discussion on re-adding a reference to the "Kamari draft" (or similar safer domains draft) in Section 7.1.1, as removing it for being non-adopted weakened the document's clarity. A sense of those present indicated re-adding the reference would be beneficial.
    • Added more details on SR filtering in Section 7.1.2.
    • Added address range filtering in Section 7.1.3, with reference to RFC99 (presumably RFC 9602).
• Discussion on Address Range Filtering (Section 7.1.3):
  • Order of Address Types: Tom raised a point about the ordered list of infrastructure address ranges (ULA, RFC 9602 prefix, GUA), suggesting RFC 9602 prefix should be first and GUA potentially removed or heavily caveated due to security concerns.
  • GUA Security: There was strong sentiment that GUA usage in SRv6 security context is problematic, especially regarding the trusted domain concept in RFC 8402.
  • ULA Usage: Debate on whether ULA should be recommended at all, or if specific caveats are sufficient.
  • Sesh's View: Agreed to reorder (RFC 9602 first), but preferred adding caveats for ULA and GUA rather than outright removal, noting that some deployments may already use them. Suggested deferring deeper ULA discussions to SRv6 ops.
• Document's Purpose and Relationship to Existing RFCs:
  • Alvaro emphasized the document's role is to illustrate security issues and potential mitigations, not to mandate specific solutions or recommend one over another. Examples should be presented as such.
  • Alvaro suggested the draft should complement existing SRv6 RFCs (e.g., 8402, 8764, compression RFCs), not replace their security considerations. He proposed adding "Updates RFC 8402" (and other relevant RFCs) to the draft's header to indicate this relationship.
• Structure of Threat Model Section:
  • Eric suggested splitting Section 4 (Threat Terminology) into two: one for Terminology and a new section for the Threat Model, for better logical flow.
  • Eric also questioned a specific sentence in Section 4 regarding nodes sending/receiving packets without traversing SR ingress/egress.
  • Tal clarified that the renaming to "Threat Terminology" was intentional to avoid confusion, as "threat model" can be a broad term.
• Reachability Filtering: Bruno suggested adding text to the address range filtering section about reachability filtering, specifically ensuring the SRv6 block is not advertised in BGP to external peers, or ideally, never originated.
• Further Document Changes (Nick):
  • Expanded on HMAC TLV usefulness in Section 7.3.
  • Refined middlebox filtering section (Section 8) for readability.
• Control Plane vs. Management Plane:
  • Eric questioned the distinction. Nick defined control plane as protocols that control the data plane, and management plane as access to the platform (e.g., SSH, out-of-band management).
  • Discussion indicated physical security/out-of-band management might be out of scope. General agreement that if the management plane is compromised, deeper SRv6 specific issues are secondary.
• On-path/Off-path for Control/Management Plane Attacks:
  • Dereck questioned the relevance of on-path/off-path for control/management plane attacks, especially with TLS, and asked for SRv6-specific examples.
  • Tal responded that this terminology comes from prior security RFCs and that future sections on control/management plane will clarify SRv6-specific aspects, rather than general control plane security.
  • Dereck also raised a point about PCC terminology that would be taken offline.
• "Operationally Difficult and Error-prone" Text (Section 7.1.1):
  • Ketan asked for clarification on this statement in the context of trusted domains.
  • Nick and Tal explained it refers to the significant effort required to maintain a uniform and secure filtering policy across a large domain, as a single misconfiguration can lead to a "fail open" scenario. This is relevant to SRv6 attack vectors, acknowledging the general difficulty of such tasks in any large network.

Decisions and Action Items

• Decision: Accelerate draft-ietf-spring-srv6-security-considerations aiming for completion by end of 2023.
• Decision: The document will consistently use "outcome" instead of "impact."
• Decision: The address range filtering list in Section 7.1.3 will be reordered to prioritize the RFC 9602 prefix.
• Decision: The document will provide caveats and guidance for using ULA and GUA addresses in SRv6 security contexts, rather than outright prohibiting them.
• Decision: The document should explicitly state its relationship to existing SRv6 RFCs (e.g., "Updates RFC 8402") in its header, indicating it complements their security considerations.
• Action Item (Nick/Authors): Reintroduce a reference to the "Kamari draft" (or similar safer domains draft) in Section 7.1.1 regarding trusted domains.
• Action Item (Nick/Authors): Consider reversing the order of Section 7.1.2 (SRH filtering) and Section 7.1.3 (Address Range Filtering) for better flow, and seek input on this from the list.
• Action Item (Tom): Draft and submit text to the mailing list regarding ULA/GUA usage, particularly for the address range filtering section.
• Action Item (Sesh/Joel/Nick): Review the "safer domains draft" for text related to "fail open" issues in trusted domains and incorporate or reference it.
• Action Item (Eric): Provide specific suggestions for splitting Section 4 into "Threat Terminology" and "Threat Model," and for clarifying the questioned sentence in Section 4.
• Action Item (Bruno): Propose specific text for the address range filtering section concerning reachability filtering, emphasizing non-advertisement of SRv6 blocks to external BGP peers.
• Action Item (Derick/Tal): Work offline to clarify PCC terminology and the application of on-path/off-path for control plane attacks.
• Action Item (Ketan/Authors): Continue discussion on the "operationally difficult and error-prone" text in Section 7.1.1 to ensure its message is clearly conveyed.
• Action Item (All Participants): Remain engaged with the draft, providing reviews and comments on upcoming submissions.

Next Steps

• IETF 123 (Madrid, July): Present updates focusing on control plane threat model, attacks, and mitigations.
• September Interim: Address management plane threat model, attacks, and mitigations.
• The working group aims to complete the draft by the end of 2023.