RFC 6018

RFC 6018: IPv4 and IPv6 Greynets 🎀

okay bestie, this one is about Greynets for both IPv4 and IPv6 and it's so cool 🦋 here are the basics:

• Series: Internet Engineering Task Force (IETF)
• Authors: F. Baker (Cisco Systems), W. Harrop, and G. Armitage (Swinburne University of Technology)
• Category: Informational
• ISSN: 2070-1721
• Date: September 2010
• Obsoletes/Updates: the header doesn't list anything it obsoletes or updates 💅

Abstract

so the abstract is short and sweet ✨ this note talks about a feature that supports building Greynets for IPv4 and IPv6 🌸

Status of This Memo

this is NOT an Internet Standards Track spec, it's published just for info 📚

this doc is a product of the IETF 💜 it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, see Section 2 of RFC 5741 🧚

for the current status, errata, and how to give feedback, check 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. please actually read these, bestie, because they explain your rights and restrictions for this doc 🙈 any Code Components pulled from this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💀

Table of Contents

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

1. Introduction ✨

okay so darknets (also called "Network Telescopes", among other things) have been set up by several orgs, including CAIDA, Team Cymru, and the University of Michigan 🔭 they watch traffic headed to address blocks that aren't actually in use. that traffic becomes visible in one of two ways: either it's captured directly (it's routed to a collector), or you see it through its backscatter (its resulting in ICMP traffic or transport-layer resets) 👀

darknets have two big problems, ngl 💀 first, once their address spaces become known, attackers stop probing them, so they get less effective. second, the admins of those prefixes are under pressure from Regional Internet Registry (RIR) policy and business requirements to deploy them in active networks 😭

[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.

this is the main idea!! 🎀 instead of setting aside whole prefixes that an attacker might probe (and basically inviting discovery), Harrop said individual addresses, or small groups of adjacent ones, in subnets should be set aside for this. each subnet uses different host identifiers, so it's harder for an address scan to find them. the concept is valuable because the addresses or prefixes are harder to map out of an attacker's search pattern, since their presence is more obscure 🦋 Harrop's research used IPv4 [RFC0791] and gave really interesting results 🌈

1.1. History and Experience

the research behind this proposal includes two prototypes, one with IPv4 [RFC0791] and one with IPv6 [RFC2460] 🧚 both have limitations, since they were research experiments and not a finished deployed product.

the original research was done by Warren Harrop and written up in [Harrop]. it was IPv4-only. his premise was that you'd put a virtual or physical machine on a LAN you weren't otherwise using, and use it to spot scans of different kinds 🕵️‍♀️ according to his paper, the idea worked well in a prototype deployment at the Centre for Advanced Internet Architectures (CAIA), Swinburne University of Technology. the basic reason is that a potential attacker reasonably expects that a given address might be in use, and there's no pattern that lets them predict which addresses are being used this way 💅 CAIA then developed and released a prototype FreeBSD-based Greynet system in 2008 built around this premise [Armitage] 🍓

Baker's addition to the concept started from the router. the idea is that the router would be very likely to run into any such scan if it came from off-LAN, and the router has to use Address Resolution Protocol (ARP) or Neighbor Discovery (ND) to identify -- or fail to identify -- the machine in question 🫶 basically, any address that isn't 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, privately offered to do some research on it, and had Owen Stephens build a Linux prototype in spring 2010 💖 they showed the technology was straightforward to implement and that it actually worked in a prototype IPv6 implementation ✨

the open question with IPv6 address scanning is how likely the attack is to happen at all 🤔 Chown originally argued in [RFC5157] that address scans were impossible because of the sheer number of possibilities. however, in September 2010 a report was made to NANOG of an IPv6 address scan, so that's a whole vibe shift 😭 there are also ways to narrow the field. for example, you can observe that a company buys a certain kind of machine or network interface card (NIC), so 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 you can observe DNS, SMTP envelopes, Extensible Messaging and Presence Protocol (XMPP) messages, FTP, HTTP, etc., which carry IP addresses in other ways 👀 such attacks can be limited by using Privacy Addresses [RFC4941], which change periodically and make historical information less useful. but the fact is, those analytic methods exist 🙈

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. these systems may simply record the attempt or the datagram that started it (darknets/Greynets), or they may act as a decoy, luring in potential attacks so the operators can study their activities and methods (honeypots) 🍯

so the goal is to separate nefarious traffic from traffic that's likely normal and important, studying one while facilitating the other 💅

2.1. Deployment Using Routing - Darknets

one obvious way to isolate and identify nefarious traffic is to notice that it's sent to a prefix or address that isn't instantiated 🎯 say a campus uses an IPv4 /24 prefix or an IPv6 /56 prefix but has less than 100 actual subnets. we might use only the odd-numbered subnets (128 of the 256 available in that prefix), and not quite all of those. since the active prefixes are more specific and therefore attract the appropriate traffic, we might also advertise the default prefix from the collector, which attracts traffic aimed at the uninstantiated prefixes in that routing domain 🌸

a second question is about mimicking a host under attack. the collector may simply record this uninvited traffic, or it may reply as a honeypot system 🧚

2.2. Deployment Using Sparse Address Space - Greynets ✨

okay so bestie, IPv4 subnets almost always have some empty space in them 🌸 like, CIDR hands out O(2^n) addresses to a subnet and there are literally never exactly that many systems sitting there, so yeah, gaps everywhere 🙈

with IPv6 it's giving even bigger gaps 💅 even a super huge switched LAN is probably only using a tiny fraction of its addresses. that's on purpose, and Section 2.5.1 of [RFC4291] explains the whole vibe 🦋 if the addresses are spread out pretty randomly across all the possible values, an attacker has a really hard time guessing which ones are actually in use. and that's the opening we're going to use for the unused addresses inside an IP prefix 😭🫶

so routers use IPv4 ARP [RFC0826] and IPv6 Neighbor Discovery [RFC4861] to figure out the MAC (Media Access Control) address of a neighbor that a datagram needs to go to 🎀 both of those specs basically say that when a datagram shows up at a router that serves the target prefix, but the router doesn't know the MAC address for the intended destination, it:

o Enqueues the datagram, o Emits a Neighbor Solicitation or ARP Request, o Waits for a Neighbor Advertisement or ARP Response, and o On receipt, dequeues and forwards the datagram.

once the host's MAC address is sitting in the router's tables (and that's how the address gets proven valid), it's not an issue anymore 🎀✨

now [Harrop] describes the Greynet as something instantiated on an end-host that replies to ARP Requests for every 'dark' IP address 👑 but a tiny tweak to router behavior can level this up 🔥 as well as queuing or dropping a datagram that has triggered an ARP Request or Neighbor Solicitation, the router also forwards a copy of that datagram over an independent link to the Greynet's analytic equipment 🧚 that independent link can be a different physical interface, a circuit, VLAN, tunnel, UDP, or any other encapsulation, or honestly any place such a datagram could be handled 🌈 and depending on what the receiving collector needs, you could also imagine summarizing the info in a form similar to IP Flow Information Export (IPFIX) [RFC5101] [RFC5610] 💜

the analytic equipment is now going to receive two types of datagrams 💖 the ones it cares about most are the ones headed for 'dark' IP addresses. less interesting is the irregular case where a datagram arrives for a legit local neighbor who, for some temporary reason, has no MAC address in the router's tables 🙈 datagrams arriving for an IP destination that hasn't gotten an ARP reply (or Neighbor Advertisement) yet might also be forwarded to the analytical equipment over the independent link, or might not, if they're considered unlikely to give any new analytic info 🫶

analytic equipment that depends on the router to recognize 'dark' IP addresses this way can easily track arrival patterns of datagrams headed to unused parts of the network 😭 it can also optionally choose to respond to those datagrams, acting as a honeypot to coax more datagrams out of the remote source 🍓

if the collector replies directly, the attacker may be able to tell from information in or about the datagram 👀 datagrams sent to the same IP subnet might come back with different TTL values, for example. so it may be advisable for the collector to send the reply back through the tunnel, so it looks like it came from the same IP subnet 🦋 and naturally, the collector in this scenario should NOT respond to datagrams destined for 'lit' IP addresses 💀 the intended destination will respond to the router's ARP or Neighbor Solicitation anyway 💅

one implication of this model is that distributed denial-of-service (DDoS) attacks end on router subnets inside a network, instead of stopping on inter-router links 🔥

2.3. Other Filters 🎀

an obvious extension would be to include traffic identified by other filters that make sense to send to the collector 🌸 for example, you could configure the system to forward traffic that fails a unicast Reverse Path Forwarding (uRPF) check [RFC2827] to the collector through that 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 offer, under configuration control, the ability to forward the arriving datagrams that trigger an ARP Request or Neighbor Solicit, and then fail to get the intended response, to an interface, circuit, VLAN, or tunnel going to an analytic system 🫶

4. 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 later forwarding that traffic puts a potential load on the network and the router in question, and that means it's a possible attack 🔥 such an attack has obvious mitigations though: you just pick (in a way the operator thinks is appropriate) a subset of the traffic to forward and discard the rest 💅 also, this attack isn't new, it's just changed in character 🦋 a stream that would instantiate the attack today results in a load of ARP or Neighbor Solicit messages that every listening host has to intelligently discard 💜 the new attack also eats bandwidth that's presumably set aside specifically for that purpose 👑

exactly which subset of traffic is interesting and economical to forward is intentionally left open 🌈 the 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 is, how that might be mitigated, and so on 🍓 possible selection algorithms that depend 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.

5. Acknowledgements 🫶

algorithms for learning about Internet attack behavior by observing backscatter traffic have 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, and they also made useful comments on it 🧚 Albert Manfredi commented on the distinction between a LAN (as defined by IEEE 802) and an IP subnet 🦋

Tim Chown [RFC5157] has observed that, at least at the time of writing that RFC, address scanning attacks in IPv6 had 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, and Fred Baker has suggested approaches based on addressing information exchanged by applications 💅 so we believe these 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 into this text 🎀 his fundamental comment was, however, that "it works" ✨💜

6. References 📚

6.1. Normative References

[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.

6.2. Informative References

[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.

Authors' Addresses 🧚

Fred Baker Cisco Systems Santa Barbara, California 93117 USA

EMail: fred@cisco.com

---

Warren Harrop Centre for Advanced Internet Architectures Swinburne University of Technology PO Box 218 John Street, Hawthorn, Victoria, 3122 Australia

EMail: wazz@bud.cc.swin.edu.au

---

Grenville Armitage Centre for Advanced Internet Architectures Swinburne University of Technology PO Box 218 John Street, Hawthorn, Victoria, 3122 Australia

EMail: garmitage@swin.edu.au 💖