One document matched: draft-baker-v6ops-greynet-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-v6ops-greynet-05" ipr="trust200902">
<front>
<title abbrev="">IPv4 and IPv6 Greynets</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<author fullname="Warren Harrop" initials="W." surname="Harrop">
<organization>CAIA, Swinburne University of Technology</organization>
<address>
<postal>
<street></street>
<city>Hawthorn</city>
<code>3122</code>
<region>Victoria</region>
<country>Australia</country>
</postal>
<email>wazz@bud.cc.swin.edu.au</email>
</address>
</author>
<author fullname="Grenville Armitage" initials="G." surname="Armitage">
<organization>CAIA, Swinburne University of Technology</organization>
<address>
<postal>
<street></street>
<city>Hawthorn</city>
<code>3122</code>
<region>Victoria</region>
<country>Australia</country>
</postal>
<email>garmitage@swin.edu.au</email>
</address>
</author>
<date year="2010" />
<area>Operations</area>
<workgroup>IPv6 Operations</workgroup>
<abstract>
<t>This note discusses a feature to support building Greynets for IPv4
and IPv6.</t>
</abstract>
<!--
<note title='Foreword'>
</note>
-->
<!--
<note title="Requirements">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</note>
-->
<!--
<?rfc needLines='10' ?>
<texttable anchor='table_example' title='A Very Simple Table'>
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align='center'>ttcol #1</ttcol>
<ttcol align='center'>ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: 'symbols', 'letters', 'numbers',
'hanging', 'format', etc.</t>
<t>
<list style='symbols'>
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor='reference' title='Figure'>
<artwork align='center'>
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section anchor="intro" title="Introduction">
<t>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).</t>
<t>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 RIR policy
and business requirements to deploy them in active networks.</t>
<t><xref target="Harrop"></xref> defines a 'Greynet' by extension, in
these words:</t>
<t><list style="empty">
<t>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.</t>
</list></t>
<t>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 <xref
target="RFC0791">IPv4</xref>, and yielded interesting information.</t>
<section anchor="history" title="History and experience">
<t>The research supporting this proposal includes two prototypes, one
with <xref target="RFC0791">IPv4</xref> and one with <xref
target="RFC2460">IPv6</xref>. Both have limitations, being research
experiments as opposed to deployment of a finished product.</t>
<t>The original research was done by Warren Harrop and documented in
<xref target="Harrop"></xref>. 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 Swinburne University CAIA. 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.</t>
<t>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
ARP or 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 obviously also works
for any system that would implement ARP or Neighbor Discovery, but the
router is an obvious focal point in any subnet.</t>
<t>Tim Chown, 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.</t>
<t>The question that remains with IPv6 address scanning is the
likelihood that the attack would occur at all. Tim originally argued
in <xref target="RFC5157"></xref> that address scans were impossible
due to the sheer number of possibilities. There are, however, ways to
limit the field; for example, one can observe that a company buys a
certain kind of machine or NIC, and 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, XMPP messages, FTP, HTTP, etc, that carry IP addresses in
other ways. We have not yet seen such attacks in the wild that I know
of, but as IPv6 becomes more widely used, one has to believe that such
things will happen. Such attacks can be limited by the use of <xref
target="RFC4941">Privacy Addresses</xref>, which periodically change,
rendering 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.</t>
</section>
</section>
<section anchor="deployment" title="Deploying Greynets">
<t>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).</t>
<t>To accomplish this, we separate nefarious traffic from that which is
likely normal and important, studying one and facilitating the
other.</t>
<section anchor="routing" title="Deployment using routing - Darknets">
<t>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.</t>
<t>A second question involves mimicking a host under attack; the
collector may simply record this uninvited traffic, or may reply as a
honeypot system.</t>
</section>
<section anchor="non_neighbors"
title="Deployment using sparse address space - Greynets">
<t>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.</t>
<t>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 <xref
target="RFC4291"></xref>. 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.</t>
<t>Routers use <xref target="RFC0826">IPv4 ARP</xref> and <xref
target="RFC4861">IPv6 Neighbor Discovery</xref> 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: <list style="symbols">
<t>Enqueue the datagram,</t>
<t>Emit a Neighbor Solicitation or ARP Request,</t>
<t>Await a Neighbor Advertisement or ARP Response, and</t>
<t>On receipt, dequeue and forward the datagram.</t>
</list></t>
<t>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.</t>
<t>In <xref target="Harrop"></xref>, 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 <xref
target="RFC5101">IPFIX</xref><xref target="RFC5610"></xref>.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>One implication of this model is that ddos attacks terminate on
router subnets within a network, as opposed to stopping on
inter-router links.</t>
</section>
<section title="Other filters">
<t>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 <xref
target="RFC2827"></xref> to the collector via the same tunnel.</t>
</section>
</section>
<section anchor="sowhat" title="Implications for router design">
<t>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.</t>
</section>
<!-- possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
<t>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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>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: <list
style="symbols">
<t>All datagrams triggering an ARP Request or Neighbor Solicit,</t>
<t>The subset of those that are not responded to within some stated
interval and are therefore likely dark,</t>
<t>The subset of those that are new; if the address is currently
being solicited, forwarding redundant data may not be useful.</t>
<t>All such datagrams up to some rate,</t>
<t>All such datagrams matching (or not matching) a specified filter
rule,</t>
<t>etc.</t>
</list></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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.</t>
<t>Tim Chown <xref target="RFC5157"></xref> 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.</t>
<t>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".</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include='reference.RFC.0791' ?>
<?rfc include='reference.RFC.0826' ?>
<?rfc include='reference.RFC.2460'?>
<?rfc include='reference.RFC.4291' ?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.4941'?>
<reference anchor="Harrop">
<front>
<title>Greynets: a definition and evaluation of sparsely populated
darknets</title>
<author fullname="Warren Harrop" initials="W." surname="Harrop">
<organization>Swinburne University of Technology, Melbourne,
Australia</organization>
</author>
<author fullname="Grenville Armitage" initials="G."
surname="Armitage">
<organization>Swinburne University of Technology, Melbourne,
Australia</organization>
</author>
<date month="" year="2005" />
</front>
<seriesInfo name="IEEE LCN"
value="IEEE 30th Conference on Local Computer Networks" />
<format target="http://ieeexplore.ieee.org/ielx5/10397/33047/01550875.pdf?tp="
type="PDF" />
</reference>
</references>
<references title="Informative references">
<?rfc include='reference.RFC.2827' ?>
<?rfc include="reference.RFC.5101" ?>
<?rfc include='reference.RFC.5157'?>
<?rfc include="reference.RFC.5610" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 00:52:04 |