Requisitos previos a la reunificación familiar

This technique is similar to log messages and mark messages, except that traceback data is trans- mitted in a new stream, i.e. separate messages. The messages are collected by a victim and used for traceback. Approaches have mostly implemented this using ICMP and so it is also known as ICMP traceback. The additional transmitted messages contain the network device IP addresses and previ- ous and next hop routers. Messages are probabilistically sent to either the source or destination IP

address. As messages are created with a low probability a victim needs to collect many messages to execute traceback and create an attack path. Therefore, the technique is suited to attacks that use many messages, e.g. DoS and DDoS, while not suited to attacks that use few messages. As new messages are generated and sent out-of-band, the original messages are not modified, such as when marking messages. This may provide forensic value and lessen the case for plausible deniability. Approaches

iTrace, perhaps the first approach, was the result of an IETF Working Group (Bellovin et al., 2003). In iTrace, when network devices forward a packet, they also probabilistically send ICMP packets to the destination address. The probability is 1/20,000. The packet contains the routers IP address and an authentication field. The authentication field is used to prevent attack actors from creating spoofed packets. The victim collects the ICMP packets during an attack to reveal all of the routers involved in the attack path and thus create an attack graph, i.e. Figure 3.3 (page 37).

A problem with iTrace is that routers involved in an attack that are far away from the victim are likely to send ICMP traceback packets containing innocent packets. This is because they are further from the attack source and other traffic is traveling through the router. One proposed solution is Intention-Driven ICMP traceback (ID-ICMP) (Mankin et al., 2001). Mankin et al. (2001) find that 99.58% of iTrace messages were not useful, i.e. not implicated in the attack. In fact the first useful iTrace message was generated after 292 useless iTrace messages, containing innocent traffic. To solve this problem, ID-ICMP adds an extra intention-bit that means that the intention of receiving packets from routers can be altered. This flag determines whether or not a user wishes to receive iTrace packets; if a victim is not under attack, then they do not need to receive packets. When an IDS detects an attack it updates the nearest BGP router. To distribute the intention- bit information to routers globally, the approach proposes extending the BGP protocol, using the Community Attribute field in BGP packet-forwarding tables to carry the intention-bit value. This extension is optional, so if a legacy router is encountered which does not understand the value, it will forward the packet regardless.

The approach eliminates some problems found in iTrace; by speeding up the traceback process and reducing unnecessary ICMP packets. It does not resolve issues of single or low-packet attacks. New problems are introduced regarding intention value distribution, which is maintained by BGP. The approach has inherent security flaws; an adversary could modify BGP values so that ID-ICMP messages are not sent to the victim.

ICMP Traceback with Cumulative Path (iTrace-CP) was proposed as an enhancement to iTrace (Lee et al., 2003a). iTrace-CP adds to iTrace by encoding the entire attack path into a specially crafted iTrace-CP message. This means faster construction of the attack graph at the cost of increased storage, computation and bandwidth. The approach suggests possible authentication for identification of corresponding IP and iTrace-CP messages; using a combination of IP packet headers or creating hashes of the non-transforming packet headers. iTrace-CP performs better than iTrace by taking less time to create the attack path when the number of hops is increased. iTrace-CP has also been extended to wireless ad-hoc networks and mobile IPv6 networks (Thing et al., 2005; Lee et al., 2003b; Tsunoda et al., 2008).

Wang and Schulzrinne (2004) propose ICMP Caddie Messages (iCaddie). The approach uses a golf analogy, in which each network device selects a forwarded packet as a ball packet, with a 1/20,000

probability, that then generates a caddie packet to follow the ball packet. Each network device has a caddie counter which indicates for how long this port has not received any caddie messages. After a threshold, the network device will start to act as caddie initiator, which generates caddie messages. Each network device that receives a ball packet and corresponding caddie packet appends its own address, ingress port, timestamp and Hash-based Message Authentication Code (HMAC). The approach suggests additional uses including packet dropping detection, feedback based routing and traceroute functionality. The technique is weak against intention, as resolved by Mankin et al. (2001).

Another example of transmitting separate messages is CenterTrack, an IP Overlay Network for traceback (Stone, 2000). In this approach edge routers are connected to separate traceback stations via IP tunneling. Suspicious traffic is selectively redirected onto an overlay network. Introducing an overlay network is costly, especially when considering the wide-scale at which such an approach needs to be deployed to be effective. This is therefore unlikely to be an attractive prospect for ISPs or governments. This approach also opens new avenues for exploitation; an adversary that is able to subvert an overlay network may be able to access sensitive data that regards the participants of the network. Management of such a network is also an unresolved problem.

Yao et al. (2010) propose passive IP traceback (PIT) which uses network telescopes. Network telescopes, sometimes called darknets, are unused IP address spaces that capture stray traffic that hits them. This traffic is often backscatter from DDoS attacks when randomly generated, spoofed IP source addresses are used. In this approach ICMP messages are detected at network telescopes and an Internet route model is used to reconstruct an attack path. The overarching concept is that spoofed packets can create ICMP error messages on the path towards the victim. Unfortunately the success rate is very low; 23.4% success with ten routers. However, it is intriguing to see that such a technique has potential, as it is non-intrusive; requiring minimal infrastructure and deployment changes and minimal ISP involvement. This approach is subverted when an adversary uses non- random source IP addresses. Also, since ICMP packets are treated differently by Internet users, there is no guarantee that traffic will be available.

Criteria

Attribution artifacts that are collected: Transmit separate messages is a traceback technique and as such attribution artifacts include source IP address and addresses of network devices in the attack path, to create an attack graph. A victim can use this information to contact ISPs closest to the adversary.

Technique reliability: As a traceback technique, this technique is unable to solve the stepping stone problem (page 21) and so cannot be considered to be reliable. However, as noted in message marking and message logging, if used in collaboration with other attribution techniques that present the same conclusion then this may indicate that stepping stones are not used and that the true source origin is in fact the adversary. Due to ICMP traffic being treated inconsistently, traceback messages could be blocked at network boundaries, making the technique less reliable than other traceback techniques. Also the technique requires widespread deployment to be effective.

Technique limitations: ICMP traffic is treated inconsistently by different ISPs and organisa- tions, as it is widely used in some network attacks, yet rarely used for legitimate functionality. ICMP traffic may be manipulated or blocked entirely by firewall rules, meaning that traceback data may

not reach the victim. As an out-of-band technique, ICMP traceback packet generation increases the amount of Internet traffic, especially as packets are generated at all times, not only during an attack. For example, approximately 0.005% of overall network resources would be required for iTrace (Mankin et al., 2001). The intention-bit devised by Mankin et al. (2001), which allows vic- tims to specify whether or not they receive ICMP traceback messages, reduces the overall impact somewhat. Attack actors may be able to send forged ICMP traceback messages to implicate inno- cent parties. Also, attribution after the attack is not possible if a victim has not collected messages during the attack. Finally, ICMP packets are sent to the victim. It may be difficult for the victim to process additional traffic if they are already under a DoS or DDoS attack.

Legal and ethical issues: Transmitting new messages does not require logging or marking of messages, which may reduce privacy concerns. Similar to all traceback techniques, while offering the opportunity to attribute attack packets, innocent packets may too be attributed.

Deployment requirements: As with most traceback techniques, wide-scale deployment is required to be effective. This incurs significant deployment costs, cooperation between ISPs, In- ternet backbone providers and nation states. However, some approaches can still function with non-participating nodes. ID-ICMP has a feature that allows non-participating routers to simply for- ward traffic on (Mankin et al., 2001). This means that the approach can be implemented when not all routers are participating. This helps with incremental deployment. Transmitting extra messages also requires additional bandwidth and so networking devices must be able to process this. Unlike message logging, storage space is not required on network devices.

Relevance outside of the laboratory: ICMP traceback has only been tested in laboratories and not deployed in a wide-scale infrastructure. There are many deployment requirements for this technique, as with all traceback techniques, that make them undesirable for key stakeholders, such as ISPs.

Traceback Summary

This concludes the review of three traceback techniques; message marking, message logging and transmit separate messages. Problems identified that are familiar across all traceback techniques are:

• Successful traceback is only as good as the last IP address. This could be a corporate/campus router IP address due to NAT and other packet transformations. This attribution offers little evidence about the individual who launched the attack. In the case of organisations or campuses, this could be one of thousands. At this point cooperation between the victim and the owner of the attributed IP address is most important (Clark and Landau, 2010b). • Equally successful traceback can lead to a stepping stone such as a compromised system that

belongs to an innocent party.

• Traceback techniques require modification of router software, hardware and/or packets in transit. This results in high costs, questions regarding management, legality, forensic value and security. Also legacy routers may not be capable of installing message logging, marking or transmitting software.

• An attack graph may reveal ISP infrastructure and this is something ISPs are strongly against. A solution is to only show edge routers of ISPs, i.e. edge sampling (Savage et al., 2000).

• Traceback techniques were designed with the intention of attributing attacks that send many packets, e.g. DoS and DDoS. This means that they are not effective against attacks with low packets, with some exceptions (Zhang and Guan, 2007).

• Traceback techniques often go against protocol specifications and disrupt legitimate function- ality. For example, some message marking approaches use the Identification field for traceback data (Belenky and Ansari, 2003a). Protocol specifications state that this field is used for reconnecting fragmented traffic and thus loses its original specified purpose.