10. Security Considerations

This section preserves the RFC text for RPL DAO Projection and root-initiated routing state, including P-DAO, P-DAO-ACK, P-DAO-REQ, PDR-ACK, VIO, SIO, RPI, SRH, Storing and Non-Storing P-Routes, Tracks, IANA registrations, and normative behavior.

Original RFC Text

10.  Security Considerations

   It is worth noting that per [RPL], every node in the LLN is RPL-aware
   and can inject any RPL-based attack in the network.  This
   specification uses messages that are already present in RPL [RPL]
   with optional secured versions.  The same secured versions may be
   used with this specification, and whatever security is deployed for a
   given network also applies to the flows in this specification.

   The LLN nodes depend on the RPL Root and RANs for their operation.  A
   trust model is necessary to ensure that the right devices are acting
   in these roles, avoiding sinkhole attacks (as is done in Section 7 of
   [RFC7416]).  This trust model could be, at a minimum, based on a
   Layer 2 secure joining and link-layer security.  This is a generic
   6LoWPAN requirement; see Req-5.1 in Appendix B.5 of [RFC8505].

   In a general manner, the Security Considerations in [RPL] and
   [RFC7416] apply to this specification as well.  In particular, link-
   layer security is needed to prevent denial-of-service attacks,
   whereby a rogue router creates a high churn in the RPL network by
   constantly injecting forged P-DAO messages and using up all the
   available storage in the attacked routers.

   When applied to radio LLNs such as IEEE Std 802.15.4, the lower-layer
   frame protection can be leveraged with an appropriate join protocol.
   The 6TiSCH Constrained Join Protocol (CoJP) [RFC9031] uses the RPL
   Root as 6LBR.  The join protocol could be extended to provide
   additional key material for pledges to 6LBR communication when
   additional end-to-end security is desired beyond the hop-by-hop
   security from the lower layer.

   With this specification, the Root MAY generate P-DAO messages but
   other nodes MUST NOT do so.  P-DAO-REQ messages MUST be sent to the
   Root.  This specification expects that the communication with the
   Root is authenticated but does not enforce which method is used.

   Additionally, the trust model could include a role validation (e.g.,
   using a role-based authorization) to ensure that the node that claims
   to be a RPL Root is entitled to do so.  That trust should propagate
   from egress to ingress in the case of a Storing Mode P-DAO.

   This specification suggests some validation of the VIO to prevent
   basic loops, i.e., by avoiding a node that appears twice.  But that
   is only a minimal protection.  Arguably, an attacker that can inject
   P-DAOs can reroute any traffic and rapidly deplete critical resources
   such as the spectrum and battery in the LLN.