Heartbeat Regularity

The first heartbeat property that we discuss is referred to as heartbeat regularity. We have identified two classes of heartbeats in this domain: regular and irregular. Informally, regular heartbeats are

the type of heartbeats one would expect to observe in a perfect world. That is, these heartbeats are

“always on”. Irregular heartbeats are everything else. This can include heartbeats that do not last indefinitely, or that get interrupted in some way. In this section, we define what makes a heartbeat regular or irregular. In addition, we summarize the general usage of each as manifested in our dataset.

4.2.1 Regular Heartbeats

In the simplest case, heartbeats are persistent and continuous, occurring at regular intervals through-out the entire duration of the observational period. This is a network heartbeat in the most intuitive sense. However, this viewpoint bars any non-deterministic interruptions and does not account for typical end-user behaviour. Thus, we refer to such heartbeats as regular heartbeats.

We define a heartbeat to be regular if its lifespan is within two periods of the length of the observational period. The lifespan of a heartbeat is defined as the elapsed time between the first and last observed connections. This laxity allows a heartbeat to have occurred just prior to the start of an observational period, and another just after the end, as illustrated earlier in Figure 3.4(b).

Two examples of regular heartbeats in our edge network are NTP and regular OS update checks.

The normal behavior of NTP creates an easily identifiable periodic pattern, as illustrated in Fig-ure 3.4(d). Our campus network also hosts a Linux OS mirror. This machine is periodically queried by update applications (such as Yum) over HTTP to check for and retrieve OS updates. This too produces a clear periodic pattern.

During our 7-week observational period, we observed 232 regular heartbeats. A breakdown of the protocols and ports of these heartbeats is displayed in Table 4.3.

As demonstrated in Table 4.3, the majority of the regular heartbeats take place in the system port range. The regular heartbeats are further broken down in Table 4.4.

As demonstrated in Table 4.4, the most frequently occurring regular TCP heartbeats are com-posed of HTTP and HTTPS traffic. HTTP heartbeats were used by a variety of services, but can

Table 4.3: Statistical summary of the regular and irregular heartbeats.

Table 4.4: Summary of all observed regular heartbeats.

Number of Heartbeats Protocol Port Registered Service

112 UDP 123 NTP

1 TCP 103 Genesis Point-to-Point Trans Net

1 TCP 137 NetBIOS

beats that periodically check for software or data updates from a server. On our edge network, we found many types of update checks (e.g., software, operating systems, anti-virus, databases, security certificates). Conversely, data posts involve periodically uploading data to a server. We observed several different examples of data posts, including backups and logging.

Other TCP heartbeats were related to a variety of applications. Some of these applications, such as NetBIOS (TCP/137 and 138), are used to provide network services. The rest perform application-specific tasks such as the XFER Utility (TCP/82) that transfers data, or the Apple Filing Protocol (TCP/548) that maintains a connection to the Apple Filing Service.

UDP heartbeats in the system port range primarily had to do with network services and scan-ning. In our dataset, 8 out of 11 DNS heartbeats, 8 out of 17 NetBIOS heartbeats, and all of the SNMP (UDP/161) heartbeats were generated by Internet-scale scanning projects at Ruhr Univer-sity [41]. Those that were not scanning-related were legitimate updates of DNS cache information, or NetBIOS service information.

Similar to the system port range, heartbeats in the UDP user port range were related to scanning and application services. All heartbeats directed towards SSDP (UDP/1900) were generated by the same research project mentioned above [41]. The other UDP heartbeat in this range was related to the Teredo protocol [24], used for IPv6 tunneling.

4.2.2 Irregular Heartbeats

As conveyed in Table 4.3, most heartbeats are irregular. Computers that produce heartbeats can change IP addresses, be shut off overnight, be rebooted, have transient Internet connectivity, or lose power. Additionally, some applications may only generate heartbeats part of the time. Such conditions can cause irregular heartbeats, as shown in Figure 4.3.

Irregular heartbeats are to be expected on a modern edge network, which services a myriad of devices and purposes. The majority of the devices on our network are for personal use, and are therefore more likely to follow usage patterns that produce irregular heartbeats. Thus, having

(a) Discontinuous Heartbeat (b) Noisy Heartbeat

(c) Skipped Heartbeat (d) Interleaved Heartbeats Figure 4.3: Examples of irregular heartbeats.

In addition to user behaviour, many types of irregularity can be caused by network middle-boxes, such as DHCP and NAT. For example, a DHCP server dynamically assigns IP addresses, so that at a different point in the logs, the same laptop (with a particular heartbeat) may have a differ-ent IP, and the previously observed IP may represdiffer-ent a differdiffer-ent laptop (without a heartbeat). This DHCP churn is quite common and has a variety of underlying causes as noted by Padmanabhan et al. [33].

Figure 4.3 illustrates four distinct causes of irregularity that we have identified over the course of our investigation.

Figure 4.3(a) shows a discontinuous heartbeat. These irregular heartbeats are caused when a

host stops generating heartbeats before the end of the log or starts generating a heartbeat late into the log. This kind of irregularity can be caused by user behaviours (e.g., shutting off the machine or application) or by a change of IP address as described above. This type of irregular heartbeat is detected well by our detection mechanism.

Figure 4.3(b) depicts a noisy heartbeat. In this case, there are communications in the heartbeat channel in addition to the heartbeat itself. This can be caused by a lack of response from the recipient, prompting the sender to reissue the heartbeat. Additionally, an application may use the heartbeat channel for other activities such as data transfer. These types of heartbeats cause the variance of connection inter-arrival times to increase, thus they may go undetected.

Figure 4.3(c) shows a skipped heartbeat. Skipped beats are caused when a host generates a heartbeat, but fails to make one or more of the connections in the heartbeat. These heartbeats are most likely due to user behaviour. Skipped beats can also thwart our detection technique by increasing the variance in a similar manner to noisy heartbeats.

Figure 4.3(d) shows an interleaved heartbeat. Interleaved heartbeats are caused when a middle-box on a network multiplexes traffic from multiple hosts. For example, a NAT middle-box relays/forwards traffic from multiple other hosts on a network. This causes irregularity since the traffic from mul-tiple hosts can become interleaved on connection records that share a common IP address. Once interleaved, the time series has complex phasing/offsets, and the variance may exceed the detec-tion threshold. In our dataset, the endpoint for a laptop network manifested this type of irregularity.

Several laptops had the same heartbeat, but the periodic communications were interleaved together.

Thus, each time series was disrupted and none of the individual heartbeats were detected automat-ically. They were instead identified by manually investigating oddities in our data.

When examining the entire 7-week dataset, our detection method fails to identify many irreg-ular heartbeats correctly. Due to this, we suggest irregirreg-ularity as an interesting avenue for future work. However, irregular heartbeats are a normal part of the network ecosystem, thus it is impor-tant to consider them for characterization.

In order to improve the detection of irregular heartbeats, we conducted our detection method at three levels of granularity: hourly, daily, and aggregate. Each stage of detection was done independently. Once all three stages were complete, the heartbeats were merged together and duplicates were removed.

This method increases the chance of detecting irregular heartbeats by varying the log duration.

On our dataset, this method increased the number of detected heartbeats by 111% (see Table 3.2).

Irregular heartbeats accounted for 244,337 (99.9%) of the detected heartbeats.

The protocol and port breakdown of irregular heartbeats are presented in Table 4.3. Irregu-lar heartbeats have a protocol/port usage nearly identical to the overall usage presented in Fig-ure 4.2(b). This is because they make up almost all of the detected heartbeats. Thus, irregular heartbeats are representative of heartbeats in general.