IPv4 and IPv6 Greynets
draft-baker-v6ops-greynet-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on October 23, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This note discusses a feature to support building Greynets for IPv4 and IPv6.

Table of Contents

1.  Introduction
2.  Deploying Greynets
    2.1.  Deployment using routing - Darknets
    2.2.  Deployment using tunnels - Greynets
    2.3.  Other filters
3.  Implications for router design
4.  IANA Considerations
5.  Security Considerations
6.  Acknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative references
§  Authors' Addresses

1.  Introduction

Darknets, also called "Network Telescopes" among other things, have been deployed by several organizations including CAIDA, Team Cymru, and the University of Michigan, to look at traffic directed to addresses in blocks that are not in actual use. Such traffic becomes visible by either direct capture (it is routed to a collector) or by virtue of its backscatter (its resulting in ICMP traffic or transport layer resets).

[Harrop] (Harrop, W. and G. Armitage, “Greynets: a definition and evaluation of sparsely populated darknets,” 2005.) 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 on LANs be set aside for the purpose, using different host identifiers on each LAN 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 (Postel, J., “Internet Protocol,” September 1981.) [RFC0791], and yielded interesting information.

It has been observed [RFC5157] (Chown, T., “IPv6 Implications for Network Scanning,” March 2008.) that address scanning is less effective in IPv6 (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) [RFC2460] networks, as there are more addresses to scan. The observation is of limited value, in that there are other approaches to identifying IPv6 systems, such as reading the 'Received:' lines in SMTP envelopes. Such attacks can be limited by the use of Privacy Addresses (Narten, T., Draves, R., and S. Krishnan, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” September 2007.) [RFC4941], which periodically change, rendering such historical information less useful, but the fact is that such analytic methods exist. Greynets are a tool that can be used to isolate and analyze them.

2.  Deploying Greynets

Corporate IT departments and other network operators frequently run collectors or other kinds of sensors. A collector is a computer system on the Internet that is expressly set up to attract and "trap" nefarious attempts to penetrate computer systems. Such systems may simply record the attempt or the datagram that initiated the attempt (darknets/greynets), or they may act as a decoy, luring in potential attacks in order to study their activities and study their methods (honey pots).

To accomplish this, we separate nefarious traffic from that which is likely normal and important, studying one and facilitating the other.

2.1.  Deployment using routing - Darknets

One obvious way to isolate and identify nefarious traffic is to realize that it is sent to a prefix that is not instantiated on a LAN. If a campus uses an IPv4 /24 prefix or an IPv6 /56 prefix but contains less than 100 actual LANs, for example, we might use only odd numbered LANs (128 of the 256 available in that prefix), and not quite all of those. Knowing that the active prefixes are more specific and therefore attract appropriate traffic to their LANs, we might also advertise the default prefix from the collector, attracting traffic directed to the uninstantiated prefixes in that routing domain.

A second question involves mimicking a host under attack; the collector may simply record this uninvited traffic, or may reply as a honey pot system.

2.2.  Deployment using tunnels - Greynets

IPv4 LANs usually have some unallocated space in them, if only because CIDR allocates O(2^n) addresses to a LAN and there are not exactly that many systems there.

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] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.). 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 a LAN prefix.

Routers use IPv4 ARP (Plummer, D., “Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware,” November 1982.) [RFC0826] and Neighbor Discovery (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.) [RFC4861] to determine the MAC address of a neighbor to which a datagram needs to be sent. Both specifications intend that when a datagram arrives at a router serving the target prefix, but which doesn't know the MAC address of the intended destination, it should:

• Enqueue the datagram,
• Emit a Neighbor Solicitation or ARP Request,
• Await a Neighbor Advertisement or ARP Response, and
• On receipt, dequeue and forward the datagram.

Once the host's MAC address is in the router's tables (and in so doing proven valid), the matter is not an issue.

In [Harrop] (Harrop, W. and G. Armitage, “Greynets: a definition and evaluation of sparsely populated darknets,” 2005.), 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 behaviour can augment this model. As well as queuing or dropping a datagram that has triggered an ARP (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, or tunnel.

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 neighbour 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 should also be forwarded to the analytical equipment over the independent link.

Assuming the analytic equipment knows which IP addresses are in use, it can easily track arrival patterns of datagrams destined to unused parts of the network. It may also optionally chose to respond to such datagrams, acting as a collector 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 LAN 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 LAN. 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.

2.3.  Other filters

An obvious extension of the concept would include traffic identified by other filters as appropriate to send to the collector. For example, one might configure the system to forward traffic failing a unicast reverse forwarding path (uRPF) check [RFC2827] (Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” May 2000.) to the collector via the same tunnel.

3.  Implications for router design

The implication for router design applies to the IPv4 ARP and IPv6 Neighbor Discovery algorithms. It might be interesting to provide, under configuration control, the ability to forward arriving datagrams that trigger an ARP Request or Neighbor Solicit, and then fail to receive the intended response, to an interface, circuit, VLAN, or tunnel to an analytic system.

4.  IANA Considerations

This memo asks the IANA for no new parameters.

Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the author's perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion.

5.  Security Considerations

This note describes a tool for managing IPv4 and IPv6 network security. Like any tool, it has limitations and possible attacks. If discarding traffic under overload is a good thing, then holding and subsequently forwarding the traffic instead places a potential load on the network and the router in question, and as such represents a possible attack. Such an attack has obvious mitigations, however; one simply, in a manner the operator deems appropriate, selects a subset of the traffic to forward and discards the rest. In addition, this attack is not new; it is only changed in 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, and 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 include:

• All datagrams triggering an ARP Request or Neighbor Solicit,
• The subset of those that are not responded to within some stated interval,
• All such datagrams up to some rate,
• All such datagrams matching (or not matching) a specified filter,
• Such datagrams arriving within some interval, after which they are filtered out,
• Alternating intervals in which all such datagrams are forwarded and no such datagrams are forwarded,
• And so on.

6.  Acknowledgements

Learning about Internet attack behavior by observing backscatter traffic has been used by CAIDA, University of Michigan, Team Cymru, and others. Harrop extended them in his research. This formulation of the notion originated in a discussion among the authors in 2005. This note grew out of a conversation with Paul Vixie and Rhette Marsh on Internet traffic sensors.

7.  References

7.1. Normative References

7.2. Informative references

Authors' Addresses