RPL security extension

Development archive
1

Hi All,

I would like to provide security extensions to the RIOT-OS RPL implementation. I probably identified the essential point(s) to start and hook a securing scheme for the routing process.

The first candidate is in the rpl worker thread (rpl_process) that waits for message reception to dispatch the incoming ICMP. Processing DIOs is basically the crucial part here, as the provided information from the DIO directly affect the parent election.

The second one, and directly related to the first, would be the parent election process itself. A Node have to be sure about that a potential parent node does not pretend an arbitrary rank.

With a secured parent election, no untrusted node is used as router by other nodes. (that's the basic idea) So this seems to be the best suited (at least starting-) point to hook a security scheme for RPL. In the diagram from Fabian on 'RPL at future state', the hook would reside in 'RPL Dodag'.

I want to start the implementation here and encapsulate the TRAIL scheme from PR #386 (https://github.com/RIOT-OS/RIOT/pull/386) with the hooks. Regarding the 'RPL at future state' diagram, the hook(s) will migrate to the commonly used 'Forwarding Tables' and secure the 'Next Hop'.

I would ask what you think about it? Does it sound reasonable?

Best regards, Martin

2

Ah, finally I meet someone who wants to implement this.

Can you elaborate on the security objective of this scheme? What does it protect? Against what kind of threats?

Grüße, Carsten

3

Voila Martin,

this makes a lot of sense: Maybe you can provide/sketch the core proposal of interfaces and how they will allow for adding stuff like VeRA, TRAIL, and other reasonable sec. extensions.

... this will also make it easier for Fabian to pick up on this.

Cheers,

Thomas

4

OK, So the threats to be resisted should be (in short), allow an attacking node to: - pretend an arbitrary low rank to pull routes and traffic - replay a previously learned rank advertizement of lower ranked nodes, also to pull routes and traffic which would allow to: - degenerate the routing tree - isolate parts of the network - create a routing blackhole - sniff traffic - ...

The goal of the scheme is to (also in short): - provide security hooks in the implementation of RPL in the crucial points to protect against the threats - define interfaces for the hooks to enable a modular security specific scheme development - try to define security interfaces for the hooks that not only apply to RPL (e.g. securing 'Next Hop') (<- this is future)

Basic sketch (probably a too naiive approach): The first security hook I would think will be directly implemented in: sys/net/routing/rpl/rpl_dodag.c rpl_parent_t *rpl_new_parent(rpl_dodag_t *dodag, ipv6_addr_t *address, uint16_t rank)

here the parent verification process would be initiated and performed, i.e. request for credentials identifying the potential parent as trustworthy.

only if the credentials are provided by the potencial parent it will be added to the list of parents: rpl_parent_t parents[RPL_MAX_PARENTS];

The interface could look similar to:

/** @brief defines interface functions implemented throuh the specific used security module */ #include "routing_security_hooks.h"

/** * @brief Returns if the security scheme identified parent as trustworthy * @param[in] address ponter to ipv6 address of potential parent * @param[in] rank nummeric provided rank from potential parent * @return char 1 if verified; 0 if not verified; 255 if timeout */ char is_potential_parent_trustworthy(ipv6_addr_t *address, uint16_t rank);

The second part would be in: sys/net/routing/rpl/rpl.c void rpl_send(ipv6_addr_t *destination, uint8_t *payload, uint16_t p_len, uint8_t next_header);

/** @brief defines interface functions implemented throuh the specific used security module */ #include "routing_security_hooks.h"

/** * @brief Returns if the security scheme identified destination as trustworthy * @param[in] destination ponter to ipv6 address of potential parent * @return char 1 if verified; 0 if not verified; */ char is_destination_trustworthy(ipv6_addr_t *destination);

Securing to only send the packet if the security scheme returned the destination as trusted.

The actual implementation of the security modules handles all managing of decision, credential requests, timeouts ...

So far the basic sketch of the possible security hooks. I hope its not a too chaotic description. I will provide a more mature description soon.

Best regards, Martin