IPv6 Operations F. Baker
Internet-Draft Cisco Systems
Intended status: Informational W. Harrop
Expires: January 26, 2010 G. Armitage
CAIA, Swinburne University of
Technology
July 25, 2009
IPv4 and IPv6 Greynets
draft-baker-v6ops-greynet-01
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 January 26, 2010.
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.
Baker, et al. Expires January 26, 2010 [Page 1]
Internet-Draft IPv4 and IPv6 Greynets July 2009
Abstract
This note discusses a feature to support building Greynets for IPv4
and IPv6.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deploying Greynets . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Deployment using routing - Darknets . . . . . . . . . . . . 4
2.2. Deployment using tunnels - Greynets . . . . . . . . . . . . 4
2.3. Other filters . . . . . . . . . . . . . . . . . . . . . . . 6
3. Implications for router design . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative references . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Baker, et al. Expires January 26, 2010 [Page 2]
Internet-Draft IPv4 and IPv6 Greynets July 2009
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] 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.
It has been observed [RFC5157] that address scanning is less
effective in IPv6 [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 [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
Baker, et al. Expires January 26, 2010 [Page 3]
Internet-Draft IPv4 and IPv6 Greynets July 2009
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 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 tunnels - Greynets
IPv4 subnets usually have some unallocated space in them, if only
because CIDR allocates O(2^n) addresses to an IP Subnet 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]. 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 IP prefix.
Routers use IPv4 ARP [RFC0826] and IPv6 Neighbor Discovery [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:
Baker, et al. Expires January 26, 2010 [Page 4]
Internet-Draft IPv4 and IPv6 Greynets July 2009
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 behaviour 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, or in fact any place such a
datagram could be handled.
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 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 chose 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.
Baker, et al. Expires January 26, 2010 [Page 5]
Internet-Draft IPv4 and IPv6 Greynets July 2009
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] 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.
Baker, et al. Expires January 26, 2010 [Page 6]
Internet-Draft IPv4 and IPv6 Greynets July 2009
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 dependent only on
state and algorithms typically available in a router include:
o All datagrams triggering an ARP Request or Neighbor Solicit,
o The subset of those that are not responded to within some stated
interval and are therefore likely dark,
o The subset of those that are new; if the address is currently
being solicited, forwarding redundant data may not be useful.
o All such datagrams up to some rate,
o All such datagrams matching (or not matching) a specified filter
rule,
o etc.
6. 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 this time, address
scanning attacks in IPv6 have not been reported in the wild. 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.
7. References
Baker, et al. Expires January 26, 2010 [Page 7]
Internet-Draft IPv4 and IPv6 Greynets July 2009
7.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.
7.2. Informative references
[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.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, March 2008.
Authors' Addresses
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com
Baker, et al. Expires January 26, 2010 [Page 8]
Internet-Draft IPv4 and IPv6 Greynets July 2009
Warren Harrop
CAIA, Swinburne University of Technology
Hawthorn, Victoria 3122
Australia
Email: wazz@bud.cc.swin.edu.au
Grenville Armitage
CAIA, Swinburne University of Technology
Hawthorn, Victoria 3122
Australia
Email: garmitage@swin.edu.au
Baker, et al. Expires January 26, 2010 [Page 9]
