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? _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
