IPv4 and IPv6 Greynets
Cisco Systems
Santa Barbara
93117
California
USA
fred@cisco.com
CAIA, Swinburne University of Technology
Hawthorn
3122
Victoria
Australia
wazz@bud.cc.swin.edu.au
CAIA, Swinburne University of Technology
Hawthorn
3122
Victoria
Australia
garmitage@swin.edu.au
Operations
IPv6 Operations
This note discusses a feature to support building Greynets for IPv4
and IPv6.
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).
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, and yielded interesting information.
It has been observed that address
scanning is less effective in IPv6
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, 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.
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.
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.
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 . 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 and Neighbor Discovery 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 , 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.
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 to the collector via the same tunnel.
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.
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.
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.
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.
Greynets: a definition and evaluation of sparsely populated
darknets
Swinburne University of Technology, Melbourne,
Australia
Swinburne University of Technology, Melbourne,
Australia