The software driver developed to access the network accelerator in Chapter 4 was updated to support the new functionalities of the filter. As an example, Listing 5.2 depicts a code snippet for a UDP port filtering configuration. In short, after the application starts, it sets an UDP connection with the defined local/remote ports.
Listing 5.2: Simple example for configuring the UDP ports in the peripheral registers.
1 ...
2 #define UDP_REMOTE_CONN_PORT 4001
3 #define UDP_LOCAL_CONN_PORT 4000
4 ...
5 server_conn = udp_new(NULL, UIP_HTONS(UDP_REMOTE_CONN_PORT), NULL);
6 udp_bind(server_conn, UIP_HTONS(UDP_LOCAL_CONN_PORT));
7 ...
8 udp_ports[0] = UDP_LOCAL_CONN_PORT & 0xff;
9 udp_ports[1] = UDP_LOCAL_CONN_PORT >> 8;
10 udp_ports[2] = UDP_REMOTE_CONN_PORT & 0xff;
11 udp_ports[3] = UDP_REMOTE_CONN_PORT >> 8;
12 ...
13 //write UDP ports to buffer
14 filter_config |= UDP_PORTS_MASK;
15 radio_frame_filter_set(UDP_PORTS_MASK, udp_ports);
16 //write the filter config
17 NETSTACK_RADIO.set_value(RADIO_PARAM_RX_MODE, filter_config);
18 ...
Afterwards, it writes the local/remote ports to the peripheral buffer registers fol-lowed by the new filter configuration which is written to the FILTER_REG register.
From now, the network accelerator will reject any UDP connection if the local/re-mote ports mismatch the configured ones. The rest of the software driver follows the same principle as depicted before in Chapter 4, Section 4.3.4.
5.3.5 Handling Security in 6LoWPAN
Data Security
As security is becoming a major requirement for most of IoT applications, cur-rent technology must provide mechanisms that can protect, verify and authenti-cate data exchanged between trusted nodes [45]. However, the traditional security mechanisms that are widely used on the Internet, e.g., IPsec, are too heavy to be integrated on small-constrained devices. Some approaches have already been pro-posed and deployed at two different layers of the IoT network stack, as discussed in [55]. For the MAC layer, the IEEE 802.15.4e standard specifies mechanisms to achieve data encryption and authentication. Despite the last versions of the stan-dard providing security, keys management schemes and authentication policies are not specified, being these issues addressed in the upper layers. For securing the 6LoWPAN communications, and since available IPv6 protocol stacks use IPsec to secure data exchange, Compressed IPsec [159] is proposed as a 6LoWPAN exten-sion for IPsec support. It mitigates the usage of IPsec over the IoT low-end devices while keeping the existing end-points on the Internet unmodified. The Compressed IPsec was implemented in the Contiki-OS µIP stack and its impact was evaluated in terms of memory footprint, packet size, energy consumption and performance under different configurations. Such contribution suggests that future IPsec systems should use cryptographic algorithms such as CBC-128 for encryption and AES-XCBC-MAC-96 mode for authentication. Although these algorithms are suitable to integrate into the low constrained devices, when deployed as software-only, they demand a high level of resources, such as CPU, memory requirements and energy, thus the efficiency of the IPsec can still be improved by resorting hardware support.
The future work pointed by the Compressed IPsec motivate the 6LoWPAN IPsec extension features integration on the CUTE mote, which is not only architecturally compliant, but also complementary to the developed solution. Despite the CUTE mote architecture being able to support security mechanisms for handling the secure
6LoWPAN packets, by easily adding security blocks that resort hardware crypto-graphic modules, their implementations and evaluations, are out of the scope of this thesis, but will be addressed in the future.
DoS Security
The strong connectivity of IoT environments requires a holistic, end-to-end security approach, addressing security and privacy risks at all abstraction levels [54]. Ex-posing resource-constrained endpoint devices to the Internet opens many doors to attackers to exploit device vulnerabilities by creating Denial of Service (DoS) events to reduce, disrupt or completely eliminate the network communication and device availability [54, 188]. There can be different kinds of DoS attacks observed at the MAC layer such as misbehavior and selfish attacks. Malicious nodes manipulate the MAC protocol parameters such as back-off time, network allocation vector value and short inter frame space, or flood the network with a large number of dummy pack-ets. Under such scenarios, the attacker nodes can capture entire network bandwidth causing legitimate nodes to fail to communicate with other nodes, consequently decreasing the throughput of the nodes significantly. A proper DoS detection mech-anism allied to an efficient packet filter can contribute for more efficient and reliable communication systems. Given this, the proposed work can trigger future research focused on hardware DoS detection mechanisms for low-end devices.
In [188], Suricata, an open-source IDS system, was used to create an IDS for 6LoWPAN-based networks and implemented over Contiki-OS. Suricata helps creat-ing packet actions (i.e., pass, drop, reject, alert) for a specific protocol (UDP, TCP, ICMP, etc.). Rules are based on packet’s source address and respective source port, destination address with corresponding destination port, followed by other rule op-tions. Such options provide the flexibility to the IDS and novel rule options can be developed to extend the detection parameters. For instance, in the case of a UDP flood attack, an alert can be triggered if the number of received packets is above a defined threshold, e.g., 50 packets per second. The developed filtering features de-ployed under the 6LA, such as the UDP/TCP port filtering, combined with the IDS, can help preventing DoS attacks in a variety of scenarios such as an UDP flooding attack. Taking benefit from the available hardware, the additional overhead caused by the IDS can also be mitigated by the 6LA. Despite related, integrating such functionalities with the IDS is out of the scope of this thesis, but proposed as future work.
5.4 System Evaluation
For evaluating the 6LA, a similar experiment setup to the one presented in Figure 4.10 of Chapter 4, was conducted. The 6LoWPAN filtering (with the source and destination filter modules) along with the IEEE 802.15.4 MAC filters were enabled (needed to extract the IPv6 addresses from the MAC Headers). In addition, the DFD module was enabled, despite not affecting the results. The PAN filter as well as the TCP/UDP modules were disabled. The accelerator was configured to accept packets to its own IPv6 addresses, i.e., Global and Link-Local.
5.4.1 Network Layer: API Evaluation
This first experiment evaluates the system’s performance, comparing both hardware and software implementations for the packet processing and filtering. To evaluate the achieved performance due to offloading filtering software functions to hardware, micro-benchmarks were executed. These were used to measure the execution time needed to read a packet from the radio transceiver and deliver it to the network layer.
The performance evaluation is calculated based on the average time for receiving 1000 packets by the UDP Server 1. Figure 5.8 shows the obtained results for software and hardware filtering when a valid IPv6 packet is received. With the filter disabled, the number of clock cycles required to process and filter one packet is on average 78156. When the filter is enabled, this value is reduced to 67806. This represents a system’s overhead reduction of 13.24% (1.15× speed up), per received packet.
78156 67806
55000 60000 65000 70000 75000 80000 85000 Filter OFF
Filter ON
Clock Cycles
Filter OFF Filter ON
Figure 5.8: API performance evaluation.
5.4.2 Thread-Metric Evaluation
50000 100000 150000 200000 250000 300000 350000 400000
0 4 8 16 32 64 128 256
Thread-Metric Score
UDP Packets/s