Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


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


 This 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

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

Baker, et al. Informational [Page 1] RFC 6018 IPv4 and IPv6 Greynets September 2010

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

 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).
 Darknets, of course, have two problems.  As their address spaces
 become known, attackers stop probing them, so they are less
 effective.  Also, the administrators of those prefixes are pressured
 by 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.
 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

Baker, et al. Informational [Page 2] RFC 6018 IPv4 and IPv6 Greynets September 2010

 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.

1.1. History and Experience

 The research supporting this proposal includes two prototypes, one
 with IPv4 [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

Baker, et al. Informational [Page 3] RFC 6018 IPv4 and IPv6 Greynets September 2010

 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.

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
 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 or address that is not
 instantiated.  If a campus uses an IPv4 /24 prefix or an IPv6 /56
 prefix but contains less than 100 actual subnets, for example, we
 might use only odd numbered subnets (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,
 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
 honeypot system.

2.2. Deployment Using Sparse Address Space - Greynets

 IPv4 subnets usually have some unallocated space in them, if only
 because Classless Inter-Domain Routing (CIDR) allocates O(2^n)
 addresses to an IP subnet and there are not exactly that many systems

Baker, et al. Informational [Page 4] RFC 6018 IPv4 and IPv6 Greynets September 2010

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

Baker, et al. Informational [Page 5] RFC 6018 IPv4 and IPv6 Greynets September 2010

 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.

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 that fail
 a unicast Reverse Path Forwarding (uRPF) check [RFC2827] 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 to an analytic
 system the 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.

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 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 selects (in a manner the operator
 deems appropriate) a subset of the traffic to forward and discards
 the rest.  In addition, this attack is not new; it is only changed in

Baker, et al. Informational [Page 6] RFC 6018 IPv4 and IPv6 Greynets September 2010

 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
 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
 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
 o  Select all datagrams up to some rate.
 o  Select all datagrams matching (or not matching) a specified filter

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; 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 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

Baker, et al. Informational [Page 7] RFC 6018 IPv4 and IPv6 Greynets September 2010

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

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,

Baker, et al. Informational [Page 8] RFC 6018 IPv4 and IPv6 Greynets September 2010

 [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
 Warren Harrop
 Centre for Advanced Internet Architectures
 Swinburne University of Technology
 PO Box 218
 John Street, Hawthorn,
 Victoria, 3122
 Grenville Armitage
 Centre for Advanced Internet Architectures
 Swinburne University of Technology
 PO Box 218
 John Street, Hawthorn,
 Victoria, 3122

Baker, et al. Informational [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6018.txt · Last modified: 2010/09/30 17:19 (external edit)