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 <[email protected]> wrote: > > > > On Wed, Jul 22, 2026 at 7:20 PM Tom Hill <[email protected]> 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 >> >> _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
