[spring] Re: Second WG Last Call: draft-ietf-spring-srv6-security-14 (Ends 2026-06-02)

[Nick Buraglio <[e-mail]>]

I have a draft with your updates ready to publish assuming the fixes
are acceptable. I also added an additional oversight to the HMAC
section as well. Folks can take a look at the diff here:
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-spring-srv6-security&url_2=https://buraglio.github.io/draft-bdmgct-spring-srv6-security/draft-ietf-spring-srv6-security.txt

nb

On Thu, Jul 23, 2026 at 9:59 AM Nick Buraglio
<[e-mail]> wrote:
>
>
>
> On Wed, Jul 22, 2026 at 7:20 PM Tom Hill <[e-mail]> wrote:
>>
>> On 2026-07-06 19:58, Alvaro Retana wrote:
>> > I would love a positive ack from the people who raised the
>> > issues/suggestions before moving forward.  Specifically, Weiqiang and
>> > Tom.
>>
>> Positive review from the prior objections/suggested alterations that I
>> made, thank you to the authors for incorporating those.
>>
>> However, having read the entire document again top-to-bottom,
>> belligerently, I would suggest that the text of S7.2 is somewhat odd.
>> Generally this document goes to lengths to ensure that it is only
>> describing SRv6 problems, but in 7.2. we see:
>>
>> "7.2. Encapsulation of Packets
>> "Packets steered within an SR domain are typically encapsulated using
>> IPv6. Encapsulation at the SR ingress node, followed by decapsulation at
>> the SR egress node and forwarding of the inner packet without lookup,
>> provides two key benefits:
>>
>> "Mitigates external attacker capabilities against the domain
>>
>> "Supports encapsulation of both IPv4 and IPv6 packets
>>
>> "Practices outlined in Section 5 of [RFC8754] should be followed to
>> ensure exclusivity of use for any prefix configured within the trusted
>> domain."
>>
>> --
>>
>> Primarily, the first line, "Packets steered within an SR domain are
>> typically encapsulated using IPv6." suggests that SR domains are
>> typically routed with SRv6? It might be true, but it's quite the
>> assertion to make here, and this document is only about SRv6 - so the
>> point is moot.
>
>
> I think that's simply awkward wording.
>
>>
>>
>> I am also not particularly sure that 'encapsulation of packets' is a
>> viable mitigation given that it is describing the intended operation of
>> SRv6, and nor do I believe that it is a viable way to protect against
>> external attacks -- because fundamentally the problem is that a router
>> *isn't capable* of distinguishing between SRv6 and IPv6 unless we give
>> it a mechanism to do so, hence draft-ravioli-trusted-domain-srv6, and
>> latterly this draft.
>>
>> I'd recommend removing S7.2 entirely, I think.
>
>
> I don't think we want to remove that section because there is an important up reference to encapsulation in 7.1.2 that was flagged as a "Major Issue" in our Opsdir review that would be orphaned. Alternatively, we could restructure the section to address the inconsistency of "SR Domain" and provide some deeper detail that may make this make more sense. How about something like:
>
> OLD:
>
> Packets steered within an SRv6 domain are typically encapsulated using IPv6. Encapsulation at the SRv6 ingress node, followed by decapsulation at the SRv6 egress node and forwarding of the inner packet without lookup, provides two key benefits:
>
>
> - Mitigates external attacker capabilities against the domain
>
> - Supports encapsulation of both IPv4 and IPv6 packets
>
>
> Practices outlined in Section 5 of [RFC8754] should be followed to ensure exclusivity of use for any prefix configured within the trusted domain.
>
>
> NEW:
>
>
> In SRv6 deployments, an operator may steer traffic using IPv6-in-IPv6 encapsulation, imposing a new outer IPv6 header and SRH at the SR ingress node rather than processing SRH/SIDs on packets received directly from untrusted-facing interfaces.
>
> This is a specific case of the trusted-domain filtering discussed in Section 7.1:
>
> because the outer header and SRH are always originated by a trusted node, forwarding decisions within the domain never depend on header fields supplied by an untrusted source. Decapsulating and forwarding the inner packet without a second lookup at the SR egress node also prevents internal SR-domain information such as segment lists, SIDs, and/or TLVs from being exposed beyond the domain boundary.
>
>
> As discussed in Section 7.1.2, this practice also addresses the case of a packet carrying an SRH while only transiting rather than terminating within the domain. Encapsulation does not by itself protect against an attacker capable of injecting packets that satisfy the domain's boundary-filtering criteria (Section 7.1.3); it is complementary to, but not a substitute for, boundary filtering.
>
>
> Practices outlined in Section 5 of [RFC8754] describe this deployment model, including the address-range exclusivity assumptions its security properties depend on.
>
>
>
> If we wanted we could also mention T.Encaps behavior of RFC 8986, but I don't know that it's necessary here. I think the above text relays the message fairly well. Thoughts?
>
>
>>
>> Otherwise I'm happy to proceed with the draft.
>>
>> Tom
>>
>>