Internet Engineering Task Force (IETF) F. Baker Request for Comments: 6018 Cisco Systems Category: Informational W. Harrop ISSN: 2070-1721 G. Armitage Swinburne University of Technology September 2010 IPv4 and IPv6 Greynets
AbstractThis note discusses a feature to support building Greynets for IPv4 and IPv6. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6018. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. History and Experience . . . . . . . . . . . . . . . . . . 3 2. Deploying Greynets . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Deployment Using Routing - Darknets . . . . . . . . . . . . 4 2.2. Deployment Using Sparse Address Space - Greynets . . . . . 4 2.3. Other Filters . . . . . . . . . . . . . . . . . . . . . . . 6 3. Implications for Router Design . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 Harrop] defines a 'Greynet' by extension, in these words: Darknets are often proposed to monitor for anomalous, externally sourced traffic, and require large, contiguous blocks of unused IP addresses - not always feasible for enterprise network operators. We introduce and evaluate the Greynet - a region of IP address space that is sparsely populated with "darknet" addresses interspersed with active (or "lit") IP addresses. Based on a small sample of traffic collected within a university campus network we saw that relatively sparse greynets can achieve useful levels of network scan detection. In other words, instead of setting aside prefixes that an attacker might attempt to probe and in so doing court discovery, Harrop proposed that individual (or small groups of adjacent) addresses in subnets be set aside for the purpose, using different host identifiers in each subnet to make it more difficult for an address
scan to detect them. The concept has value in the sense that it is harder to map the addresses or prefixes out of an attacker's search pattern, as their presence is more obscure. Harrop's research was carried out using IPv4 [RFC0791] and yielded interesting information. RFC0791] and one with IPv6 [RFC2460]. Both have limitations, being research experiments as opposed to deployment of a finished product. The original research was done by Warren Harrop and documented in [Harrop]. This was IPv4-only. His premise was that one would put a virtual or physical machine on a LAN that one was not otherwise using, and use it to identify scans of various kinds. As reported in his paper, the concept worked effectively in a prototype deployment at the Centre for Advanced Internet Architectures (CAIA), Swinburne University of Technology. The basic reason was that there was a reasonable expectation on the part of a potential attacker that a given address might be represented, and there was no pattern that would enable the attacker to predict which addresses were being used in this way. CAIA developed and released a prototype FreeBSD-based Greynet system in 2008 built around this premise [Armitage]. Baker's addition to his concept started from the router, the idea that the router would be highly likely to encounter any such scan if it came from off-LAN, and the fact that the router would have to use Address Resolution Protocol (ARP) or Neighbor Discovery (ND) to identify -- or fail to identify -- the machine in question. In effect, any address that is not currently instantiated in the subnet acts as a Greynet trigger address. This clearly also works for any system that would implement ARP or ND, but the router is an obvious focal point in any subnet. Tim Chown, of the School of Electronics and Computer Science, University of Southampton, offered privately to do some research on it, and had Owen Stephens do a Linux prototype in spring 2010. They demonstrated that the technology was straightforward to implement and in fact worked in a prototype IPv6 implementation. The question that remains with IPv6 address scanning is the likelihood that the attack would occur at all. Chown originally argued in [RFC5157] that address scans were impossible due to the sheer number of possibilities. However, in September 2010 a report was made to NANOG of an IPv6 address scan. Additionally, there are ways to limit the field; for example, one can observe that a company buys a certain kind of machine or network interface card (NIC), and
therefore its probable EUI-64 addresses are limited to a much smaller range than 2^64 -- more like 2^24 addresses on a given subnet -- or one can observe DNS, SMTP envelopes, Extensible Messaging and Presence Protocol (XMPP) messages, FTP, HTTP, etc., that carry IP addresses in other ways. Such attacks can be limited by the use of Privacy Addresses [RFC4941], which periodically change, rendering historical information less useful, but the fact is that such analytic methods exist.
Similarly, with active IPv6 prefixes, even a very large switched LAN is likely to use a small fraction of the available addresses. This is by design, as discussed in Section 2.5.1 of [RFC4291]. If the addresses are distributed reasonably randomly among the possible values, the likelihood of an attacker guessing what addresses are in actual use is limited. This gives us an opportunity with respect to unused addresses within an IP prefix. Routers use IPv4 ARP [RFC0826] and IPv6 Neighbor Discovery [RFC4861] to determine the MAC (Media Access Control) address of a neighbor to which a datagram needs to be sent. Both specifications intend that when a datagram arrives at a router that serves the target prefix, but that doesn't know the MAC address of the intended destination, it should: o Enqueue the datagram, o Emit a Neighbor Solicitation or ARP Request, o Await a Neighbor Advertisement or ARP Response, and o On receipt, dequeue and forward the datagram. Once the host's MAC address is in the router's tables (and in so doing the address proven valid), the matter is not an issue. In [Harrop], the Greynet is described as being instantiated on an end-host that replies to ARP Requests for all 'dark' IP addresses. However, a small modification to router behavior can augment this model. As well as queuing or dropping a datagram that has triggered an ARP Request or Neighbor Solicitation, the router forwards a copy of this datagram over an independent link to the Greynet's analytic equipment. This independent link may be a different physical interface, a circuit, VLAN, tunnel, UDP, or other encapsulation, or in fact any place such a datagram could be handled. Depending on the requirements of the receiving collector, one could also imagine summarizing information in a form similar to IP Flow Information Export (IPFIX) [RFC5101] [RFC5610]. The analytic equipment will now receive two types of datagrams. Of most interest will be those destined for 'dark' IP addresses. Of less interest will be the irregular case where a datagram arrives for a legitimate local neighbor who has, for some temporary reason, no MAC address in the router's tables. Datagrams arriving for an IP destination for which an ARP reply (or Neighbor Advertisement) has not yet received might also be forwarded to the analytical equipment over the independent link -- or might not, if they are considered to be unlikely to provide new analytic information.
Analytic equipment, depending on the router to recognize 'dark' IP addresses in this manner, can easily track arrival patterns of datagrams destined to unused parts of the network. It may also optionally choose to respond to such datagrams, acting as a honeypot to elicit further datagrams from the remote source. If the collector replies directly, the attacker may be able to identify the fact through information in or about the datagram - datagrams sent to the same IP subnet may come back with different TTL values, for example. Hence, it may be advisable for the collector to send the reply back through the tunnel and therefore as if from the same IP subnet. Naturally, the collector in this scenario should not respond to datagrams destined for 'lit' IP addresses -- the intended destination will eventually respond to the router's ARP or Neighbor Solicitation anyway. One implication of this model is that distributed denial-of-service (DDoS) attacks terminate on router subnets within a network, as opposed to stopping on inter-router links. RFC2827] to the collector via the same tunnel.
character. A stream that would instantiate the attack today results in a load of ARP or Neighbor Solicit messages that all listening hosts must intelligently discard. The new attack additionally consumes bandwidth that is presumably set aside specifically for that purpose. The question of exactly what subset of traffic is interesting and economical to forward is intentionally left open. Key questions in algorithm design include what can be learned from a given sample (Are bursts happening? If so, with what data?), what the impact on the router and other equipment in question is, how that might be mitigated, etc. Possible selection algorithms dependent only on state and algorithms typically available in a router include: o Select all datagrams that trigger an ARP Request or Neighbor Solicit. o Select the subset of those that are not responded to within some stated interval and are therefore likely dark. o Select the subset of those that are new; if the address is currently being solicited, forwarding redundant data may not be useful. o Select all datagrams up to some rate. o Select all datagrams matching (or not matching) a specified filter rule. RFC5157] has observed that, at least at the time of writing that RFC, address scanning attacks in IPv6 have not been reported in the wild. However, as mentioned in Section 1.1 above, a (partial) scanning attack was recently reported on the NANOG mailing list. Rhette Marsh has suggested the structure of such an attack, however, and Fred Baker has suggested approaches based on addressing
information exchanged by applications. Hence, we believe that such issues may be relevant to IPv6 in the future, when IPv6 is a more interesting target. Tim Chown and Owen Stephens tested the proposal, and made useful comments that have been incorporated in this text. His fundamental comment was, however, that "it works". [Harrop] Harrop, W. and G. Armitage, "Greynets: a definition and evaluation of sparsely populated darknets", IEEE LCN IEEE 30th Conference on Local Computer Networks, 2005. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [Armitage] Armitage, G., Harrop, W., Heyde, A., Parry, L., "Greynets: Passive Detection of Unsolicited Network Scans in Small ISP and Enterprise networks", CAIA, Swinburne University of Technology, December 2008, http://caia.swin.edu.au/greynets/.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008. [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009.