SecMon: End-to-End Quality and Security Monitoring System

The Voice over Internet Protocol (VoIP) is becoming a more available and popular way of communicating for Internet users. This also applies to Peer-to-Peer (P2P) systems and merging these two have already proven to be successful (e.g. Skype). Even the existing standards of VoIP provide an assurance of security and Quality of Service (QoS), however, these features are usually optional and supported by limited number of implementations. As a result, the lack of mandatory and widely applicable QoS and security guaranties makes the contemporary VoIP systems vulnerable to attacks and network disturbances. In this paper we are facing these issues and propose the SecMon system, which simultaneously provides a lightweight security mechanism and improves quality parameters of the call. SecMon is intended specially for VoIP service over P2P networks and its main advantage is that it provides authentication, data integrity services, adaptive QoS and (D)DoS attack detection. Moreover, the SecMon approach represents a low-bandwidth consumption solution that is transparent to the users and possesses a self-organizing capability. The above-mentioned features are accomplished mainly by utilizing two information hiding techniques: digital audio watermarking and network steganography. These techniques are used to create covert channels that serve as transport channels for lightweight QoS measurement's results. Furthermore, these metrics are aggregated in a reputation system that enables best route path selection in the P2P network. The reputation system helps also to mitigate (D)DoS attacks, maximize performance and increase transmission efficiency in the network.Comment: Paper was presented at 7th international conference IBIZA 2008: On Computer Science - Research And Applications, Poland, Kazimierz Dolny 31.01-2.02 2008; 14 pages, 5 figure

Link failure testing project on a satellite SDN network using Bidirectional Forwarding Detection

This project focuses on implementing a variable grid topology network for simulating an inter-satellite links connection to evaluate link failure detection times in a satellite SoftwareDefined Networking (SDN) using the Bidirectional Forwarding Detection (BFD) protocol (RFC 5880). Today, there is significant growth and deployment of LEO satellite networks, and SDN technology is being successfully used in these LEO satellite constellation networks due to the flexibility that this technology offers in the face of dynamic variation in topology network, limited bandwidth and traffic variations. An important point for the correct operation of these networks is the reliability and stability of the links that interconnect the satellites of the constellation, since this constellation is in permanent motion, orbiting the earth. The work developed in this project is directly related to this topic and the BFD detection protocol has been used to determine the connectivity failures of the test network links. The BFD is a protocol which provides fast forwarding path failure detection times and it is independent from physical media, routing protocols and data protocols. The BFD protocol works in the forwarding plane and is well suited for use with SDN switches. The testbed has been built using the "ContainerNet" Python API to implement the network topology and link interconnection of each satellite node. The satellite switching service is implemented in a docker instance, using OpenVirtualSwitch (OVS) as the internal packet switch of each node. OpenVirtualSwitch is an SDN-compliant programmable switching network device that has support for the BFD protocol. A transmission scenario is built on this switching network. This scenario includes two nodes that work as communication endpoints. The nodes have been configured so that between the endpoints there are two separate alternative paths. In addition to the datapath configuration, the BFD protocol has been configured to monitor the status of each link. A software developed running in all intermediate nodes are able to notify a link failure upstream of the datapath until the end nodes. An then end nodes can switch to another path. The final results must determine which are the BFD parameters to achieve a compromise between the BFD packet signaling period and the bandwidth used to keep the VoIP communication parameters within the acceptable limits in the event of a link failure with a route update

REAL-TIME INSIGHTS-GUIDED BEFOREHAND CALL STATUS AND QUALITY PREDICTION ALERTS FOR TO-BE-CALLED NUMBER

Based on a number of factors (including the available bandwidth, network issues, or service provider issues), when a call is made that call may or not be successful. Additionally, the quality of a call may also experience a setback due to those factors. Currently, there is no “beforehand” guidance system in place within a call control ecosystem which can alert a user to the probable relevant issues before a call is made. Techniques are presented herein that address that deficiency. Aspects of the presented techniques encompass a Real-time Intelligent Insights Engine as part of a real-time calling solution (within, for example, an online communication and collaboration facility). Such an Insights Engine may monitor various important dimensions of a voice over Internet Protocol (VOIP) deployment and provide a caller with a real-time beforehand prediction, through a recommendation facility, based on a sliding timeframe (comprising, for example, the last n minutes) when a to-be-called number is dialed (but before the call is handed over to the network). Depending upon such a recommendation, a caller may decide the fate of their call accordingly. For example, if the caller still wishes to continue then the call may be placed. Alternatively, the caller may abort (or postpone) the call according to the recommendation

Private Communication Detection via Side-Channel Attacks

Private communication detection (PCD) enables an ordinary network user to discover communication patterns (e.g., call time, length, frequency, and initiator) between two or more private parties. Analysis of communication patterns between private parties has historically been a powerful tool used by intelligence, military, law-enforcement and business organizations because it can reveal the strength of tie between these parties. Ordinary users are assumed to have neither eavesdropping capabilities (e.g., the network may employ strong anonymity measures) nor the legal authority (e.g. no ability to issue a warrant to network providers) to collect private-communication records. We show that PCD is possible by ordinary users merely by sending packets to various network end-nodes and analyzing the responses. Three approaches for PCD are proposed based on a new type of side channels caused by resource contention, and defenses are proposed. The Resource-Saturation PCD exploits the resource contention (e.g., a fixed-size buffer) by sending carefully designed packets and monitoring different responses. Its effectiveness has been demonstrated on three commercial closed-source VoIP phones. The Stochastic PCD shows that timing side channels in the form of probing responses, which are caused by distinct resource-contention responses when different applications run in end nodes, enable effective PCD despite network and proxy-generated noise (e.g., jitter, delays). It was applied to WiFi and Instant Messaging for resource contention in the radio channel and the keyboard, respectively. Similar analysis enables practical Sybil node detection. Finally, the Service-Priority PCD utilizes the fact that 3G/2G mobile communication systems give higher priority to voice service than data service. This allows detection of the busy status of smartphones, and then discovery of their call records by correlating the busy status. This approach was successfully applied to iPhone and Android phones in AT&T's network. An additional, unanticipated finding was that an Internet user could disable a 2G phone's voice service by probing it with short enough intervals (e.g., 1 second). PCD defenses can be traditional side-channel countermeasures or PCD-specific ones, e.g., monitoring and blocking suspicious periodic network traffic