[spring] Re: Chair Review of draft-bdmgct-spring-srv6-security-02 (Adoption)

[Nick Buraglio <[e-mail]>]

Excellent! Thank you very much for this very detailed review and
input. We will incorporate it into the next version and iterate as the
group provides additional direction.

nb


On Wed, Aug 14, 2024 at 5:25 PM Alvaro Retana <[e-mail]> wrote:
>
> Dear authors:
>
> Thank you for taking on this work!
>
> I am providing this review with my Chair Hat on in parallel with the
> adoption call.  Please consider it in addition to the other comments
> you receive.
>
>
> In general, the current draft is a very good start!  I know it is a
> work in progress, and I expect changes along the way.  Having said
> that, I want to highlight some high-level points to consider as you
> continue the work.
>
> (1) Scope
>
>     §2 and the document generally focus on the data plane, but the control
>     plane plays a significant part in an SRv6 network.  The control plane
>     should also be considered.
>
>     Many possible control plane threats (overclaiming, filtering, etc.) are not
>     specific to SRv6 but may expose themselves differently in an SRv6 network.
>     §6.4 is a start, but I believe more is needed.
>
> (2) Threat Model
>
>     Even though the threat model mentions external attackers, §6 focuses on
>     internal attacks, indicating that "it is assumed that SRv6 is deployed
>     within a limited domain [RFC8799] with filtering at the domain boundaries,
>     forming a trusted domain with respect to SRv6." However, the first set of
>     mitigation methods (§7) concerns the domain boundary.
>
>     The formulation of the threat model and the assumptions need to be aligned
>     to the mitigations offered.
>
> (3) Relationship to Existing Work
>
>     It is not clear from the current text what the relationship between
>     existing work (specifically the existing Security Considerations) and this
>     document is.  I hope that this document will not have to include
>     "everything" (among other reasons because it would require a great deal of
>     duplication) but that it can refer to, complement, or augment (as needed)
>     any existing guidance.
>
>     IOW, I expect to see more text of the form: "as rfcxxx recommends, use
>     ABC", "rfczzzz already covers this topic", or "in addition to what is
>     recommended in rfcggg....".  Even some text like "the recommendation in
>     this document replaces what was recommended in rfchhh".
>
>
> I also included comments in-line (see below).
>
> Thanks!
>
> Alvaro.
>
>
> [Line numbers from idnits.]
>
> ...
> 123     1.  Introduction
> ...
> 137        *  SRv6 makes use of the SRH which is a new type of Routing Extension
> 138           Header.  Some of the security considerations of the SRH are
> 139           discussed in [RFC5095] and [RFC8754].
>
> [] The SRH is specified in RFC8754.  To be strict, RFC5095 doesn't
> talk about the SRH.  RFC8754 already refers to RFC5095 in its Security
> Considerations.
>
>
> 141        *  SRv6 consists of using the SRH on the IPv6 dataplane, and
> 142           therefore known security considerations of IPv6 [RFC9099] are
> 143           applicable to SRv6 as well.
>
> [] Please also point to the Security Considerations in rfc8200.
>
>
> 145        *  While SRv6 uses what appear to be typical IPv6 addresses, the
> 146           address space is processed differently by segment endpoints.  A
> 147           typical IPv6 unicast address is comprised of a network prefix,
> 148           host identifier, and a subnet mask.  A typical SRv6 segment
> 149           identifier (SID) is broken into a locator, a function identifier,
> 150           and optionally, function arguments.  The locator must be routable,
> 151           which enables both SRv6 capable and incapable devices to
> 152           participate in forwarding, either as normal IPv6 unicast or SRv6.
> 153           The capability to operate in environments that may have gaps in
> 154           SRv6 support allows the bridging of islands of SRv6 devices with
> 155           standard IPv6 unicast routing.
>
> [] Adding references to rfc8986 and draft-ietf-6man-sids (which should
> soon be an RFC) would be useful.
>
>
>
> ...
> 160     2.  Scope of this Document
> ...
> 181        We note that SRv6 is under active development and, as such, the above
> 182        documents might not cover all protocols employed in an SRv6
> 183        deployment.
>
> [] For future versions: draft-ietf-6man-sids is in the RFC Editor's
> queue and draft-ietf-spring-srv6-srh-compression is with the IESG.
> Both should be RFCs by the time we're done processing this document.
>
>
>
> ...
> 205     4.  Threat Model
> ...
> 223        On-path vs. Off-path:  On-path attackers are located in a position
> 224           that allows interception, modification or dropping of in-flight
> 225           packets, as well as insertion (generation) of packets.  Off-path
> 226           attackers can only attack by insertion of packets.
>
> [] Could an off-path attacker be able to interact with the control
> plane?  The definition seems to be incomplete.  Or maybe I'm
> interpreting "packets" as data plane...
>
>
> 228        The following figure depicts the attacker types according to the
> 229        taxonomy above.  As illustrated in the figure, on-path attackers are
> 230        located along the path of the traffic that is under attack, and
> 231        therefore can listen, insert, delete, modify or replay packets in
> 232        transit.  Off-path attackers can insert packets, and in some cases
> 233        can passively listen to some of the traffic, such as multicast
> 234        transmissions.
>
> [] This taxonomy is focused on the data plane -- I believe the control
> plane should also be considered.
>
>
> [] "Off-path attackers...can passively listen to some of the traffic,
> such as multicast transmissions."
>
> Even if listening to only "some of the traffic", wouldn't the node be on-path?
>
>
>
> ...
> 265        In the context of the current document it is assumed that SRv6 is
> 266        deployed within a limited domain [RFC8799] with filtering at the
> 267        domain boundaries, forming a trusted domain with respect to SRv6.
> 268        Thus, external attackers are outside of the trusted domain.
> 269        Specifically, an attack on one domain that is invoked from within a
> 270        different domain is considered an external attack in the context of
> 271        the current document.
>
> [] rfc8799 is not an IETF consensus document. IMO, this document would
> be better served if a description of what is considered a "limited
> domain" is included -- instead of doing it by reference.
>
>
> 273        Following the spirit of [RFC8402], the current document mandates a
> 274        filtering mechanism that eliminates the threats from external
> 275        attackers.  This approach limits the scope of the attacks described
> 276        in this document to within the domain (i.e., internal attackers).
>
> [] "mandates a filtering mechanism"
>
> I couldn't find the MUST/REQUIRED text.  The statement feels out of
> place when describing the threat model -- if you keep it here, point
> to the section where the requirement is specified.
>
>
>
> ...
> 292     5.  Impact
>
> 294        One of the important aspects of a threat analysis is the potential
> 295        impact of each threat.  SRv6 allows for the sending of IPv6 packets
> 296        via arbitrary paths.  An attack on SRv6 may cause packets to traverse
> 297        arbitrary paths within an SR domain.  This may allow an attacker to
> 298        perform a number of attacks on the victim networks and hosts that
> 299        would be mostly unfeasible for a non-SRv6 environment.
>
> [] s/sending of IPv6 packets/forwarding of IPv6 packets
>
>
> [] "SRv6 allows for the sending of IPv6 packets via arbitrary paths.
> An attack on SRv6 may cause packets to traverse arbitrary paths within
> an SR domain."
>
> I guess this text means that the attack uses a *different* set of
> "arbitrary paths" (when compared to the intended forwarding path).
> Please clarify.
>
>
> 301        The threat model in [ANSI-Sec] classifies threats according to their
> 302        potential impact, defining six categories.  For each of these
> 303        categories we briefly discuss its applicability to SRv6 attacks