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 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.
Otherwise I'm happy to proceed with the draft.
Tom
_______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
