[spring] draft-ietf-spring-srv6-security-11 early Secdir review

[Christian Huitema via Datatracker <[e-mail]>]

Document: draft-ietf-spring-srv6-security
Title: Segment Routing IPv6 Security Considerations
Reviewer: Christian Huitema
Review result: Has Nits

This document is titled "Segment Routing IPv6 Security Considerations", which
is rather bland, but the document itself is anything but bland. It is a
methodical evaluation of SRv6 security issues, starting with a well
constructed threat model, going all the way to the evaluation of attacks and
existing mitigations, some of which it finds wanting. It does propose practical
improvements. It is great to see this kind of work coming from the
routing area, and my first reaction is to applaud!

The threat analysis follows a methodical progression: categorization of attackers,
listing of assets, listing of attacks and analysis of mitigations. They consider 5
types of attackers, on path or not, internal or external, and with access to
the control plane. The listing of assets is good, although I would add something
about the privacy of end to end users. I would apply the same remark to the
analysis of attacks. It is rather exhaustive, except maybe for the possible use of SRH
options as a way to track end users or their behavior.

I think the meat of the document is in the analysis of mitigations. I hope that
deployments of SRV6 pay attention to it, and in particular the robust discussion of
Trusted Domains and Filtering in section 1.1, which points out that it might
be insufficient to trust access filtering at the domain borders to ensure safety
of operations. To quote:

   Practically speaking, this means successfully enforcing a "Trusted
   Domain" may be operationally difficult and error-prone in practice,
   and that attacks that are expected to be unfeasible from outside the
   trusted domain may actually become feasible when any of the involved
   systems fails to enforce the filtering policy that is required to
   define the Trusted Domain.

This is typical of the seriousness of this document, which does not attempt to brush off obvious
issues with the idea of "limited domains". Not a really new concept, the old polar bear
adage "crunchy on the outside, chewy on the inside" still applies. Section 7.1.3 proposes
a more efficient remediation: use a dedicated prefix for the SRv6 SIDs inside a domain,
and apply filtering based on these SIDs not only at the border but also "in depth".
 
Section 7.2 advocates convincingly for the use of encapsulation/decapsulation at domain boundaries,
which would largely mitigate external attacks. That's very realistic.

Section 7.3 point out that packet authentication based on well known keys is rather brittle,
due to the difficulties of properly managing such keys. Indeed, we could see security issues
if these keys leaked.

Section 7.4 discusses the mitigation of control plane attacks. This may be something that we would
want to develop in a separate document. Attackers who want to impair a network are likely to
target some internal nodes to gain privileges -- typically, attacking the laptop of a
network administrator to get a foothold, and from there using that administrator's
access right to attack the network management functions. That attack chain can be used against
SRv6, but it can also be used against networks that do not use SRv6. There are potential
mitigations such as least privilege, isolation of function or early detection. Maybe that
should be addressed in a different document.

Section 8 discusses the effect of deploying SRv6 on existing hardware, such as firewalls that
do not understand the SRv6 extensiens, or hardware that is not powerful enough to process the
extension.

Overall, I like this document a lot. My only little remark is that it does not discuss
much potential pricacy issues. SRV6 header carry a significant amount of information,
more information than the the basic IPv6 header. The leak of information through the
IPv6 header information can be mitigated using techniques like privacy addresses or VPNs.
Maybe the draft should discuss whether the SRV6 headers can be used to identify either the
identity behind the addresses or the specific way in which a pair of endpoints communicates?