idnits 2.17.1 draft-baker-v6ops-greynet-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 12, 2010) is 5003 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational W. Harrop 5 Expires: February 13, 2011 G. Armitage 6 CAIA, Swinburne University of 7 Technology 8 August 12, 2010 10 IPv4 and IPv6 Greynets 11 draft-baker-v6ops-greynet-05 13 Abstract 15 This note discusses a feature to support building Greynets for IPv4 16 and IPv6. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 13, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. History and experience . . . . . . . . . . . . . . . . . . 3 54 2. Deploying Greynets . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Deployment using routing - Darknets . . . . . . . . . . . 5 56 2.2. Deployment using sparse address space - Greynets . . . . . 5 57 2.3. Other filters . . . . . . . . . . . . . . . . . . . . . . 7 58 3. Implications for router design . . . . . . . . . . . . . . . . 7 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 64 7.2. Informative references . . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 Darknets, also called "Network Telescopes" among other things, have 70 been deployed by several organizations including CAIDA, Team Cymru, 71 and the University of Michigan, to look at traffic directed to 72 addresses in blocks that are not in actual use. Such traffic becomes 73 visible by either direct capture (it is routed to a collector) or by 74 virtue of its backscatter (its resulting in ICMP traffic or transport 75 layer resets). 77 Darknets, of course, have two problems. As their address spaces 78 become known, attackers stop probing them, so they are less 79 effective. Also, the administrators of those prefixes are pressured 80 by RIR policy and business requirements to deploy them in active 81 networks. 83 [Harrop] defines a 'Greynet' by extension, in these words: 85 Darknets are often proposed to monitor for anomalous, externally 86 sourced traffic, and require large, contiguous blocks of unused IP 87 addresses - not always feasible for enterprise network operators. 88 We introduce and evaluate the Greynet - a region of IP address 89 space that is sparsely populated with "darknet" addresses 90 interspersed with active (or "lit") IP addresses. Based on a 91 small sample of traffic collected within a university campus 92 network we saw that relatively sparse greynets can achieve useful 93 levels of network scan detection. 95 In other words, instead of setting aside prefixes that an attacker 96 might attempt to probe and in so doing court discovery, Harrop 97 proposed that individual (or small groups of adjacent) addresses in 98 subnets be set aside for the purpose, using different host 99 identifiers in each subnet to make it more difficult for an address 100 scan to detect them. The concept has value in the sense that it is 101 harder to map the addresses or prefixes out of an attacker's search 102 pattern, as their presence is more obscure. Harrop's research was 103 carried out using IPv4 [RFC0791], and yielded interesting 104 information. 106 1.1. History and experience 108 The research supporting this proposal includes two prototypes, one 109 with IPv4 [RFC0791] and one with IPv6 [RFC2460]. Both have 110 limitations, being research experiments as opposed to deployment of a 111 finished product. 113 The original research was done by Warren Harrop and documented in 114 [Harrop]. This was IPv4-only. His premise was that one would put a 115 virtual or physical machine on a LAN that one was not otherwise 116 using, and use it to identify scans of various kinds. As reported in 117 his paper, the concept worked effectively in a prototype deployment 118 at Swinburne University CAIA. The basic reason was that there was a 119 reasonable expectation on the part of a potential attacker that a 120 given address might be represented, and there was no pattern that 121 would enable the attacker to predict which addresses were being used 122 in this way. 124 Baker's addition to his concept started from the router, the idea 125 that the router would be highly likely to encounter any such scan if 126 it came from off-LAN, and the fact that the router would have to use 127 ARP or ND to identify - or fail to identify - the machine in 128 question. In effect, any address that is not currently instantiated 129 in the subnet acts as a greynet trigger address. This obviously also 130 works for any system that would implement ARP or Neighbor Discovery, 131 but the router is an obvious focal point in any subnet. 133 Tim Chown, School of Electronics and Computer Science, University of 134 Southampton, offered privately to do some research on it, and had 135 Owen Stephens do a Linux prototype in spring 2010. They demonstrated 136 that the technology was straightforward to implement and in fact 137 worked in a prototype IPv6 implementation. 139 The question that remains with IPv6 address scanning is the 140 likelihood that the attack would occur at all. Tim originally argued 141 in [RFC5157] that address scans were impossible due to the sheer 142 number of possibilities. There are, however, ways to limit the 143 field; for example, one can observe that a company buys a certain 144 kind of machine or NIC, and therefore its probable EUI-64 addresses 145 are limited to a much smaller range than 2^64 - more like 2^24 146 addresses on a given subnet - or one can observe DNS, SMTP envelopes, 147 XMPP messages, FTP, HTTP, etc, that carry IP addresses in other ways. 148 We have not yet seen such attacks in the wild that I know of, but as 149 IPv6 becomes more widely used, one has to believe that such things 150 will happen. Such attacks can be limited by the use of Privacy 151 Addresses [RFC4941], which periodically change, rendering historical 152 information less useful, but the fact is that such analytic methods 153 exist. Greynets are a tool that can be used to isolate and analyze 154 them. 156 2. Deploying Greynets 158 Corporate IT departments and other network operators frequently run 159 collectors or other kinds of sensors. A collector is a computer 160 system on the Internet that is expressly set up to attract and "trap" 161 nefarious attempts to penetrate computer systems. Such systems may 162 simply record the attempt or the datagram that initiated the attempt 163 (darknets/greynets), or they may act as a decoy, luring in potential 164 attacks in order to study their activities and study their methods 165 (honey pots). 167 To accomplish this, we separate nefarious traffic from that which is 168 likely normal and important, studying one and facilitating the other. 170 2.1. Deployment using routing - Darknets 172 One obvious way to isolate and identify nefarious traffic is to 173 realize that it is sent to a prefix or address that is not 174 instantiated. If a campus uses an IPv4 /24 prefix or an IPv6 /56 175 prefix but contains less than 100 actual subnets, for example, we 176 might use only odd numbered subnets (128 of the 256 available in that 177 prefix), and not quite all of those. Knowing that the active 178 prefixes are more specific and therefore attract appropriate traffic, 179 we might also advertise the default prefix from the collector, 180 attracting traffic directed to the uninstantiated prefixes in that 181 routing domain. 183 A second question involves mimicking a host under attack; the 184 collector may simply record this uninvited traffic, or may reply as a 185 honeypot system. 187 2.2. Deployment using sparse address space - Greynets 189 IPv4 subnets usually have some unallocated space in them, if only 190 because CIDR allocates O(2^n) addresses to an IP Subnet and there are 191 not exactly that many systems there. 193 Similarly, with active IPv6 prefixes, even a very large switched LAN 194 is likely to use a small fraction of the available addresses. This 195 is by design, as discussed in section 2.5.1 of [RFC4291]. If the 196 addresses are distributed reasonably randomly among the possible 197 values, the likelihood of an attacker guessing what addresses are in 198 actual use is limited. This gives us an opportunity with respect to 199 unused addresses within a IP prefix. 201 Routers use IPv4 ARP [RFC0826] and IPv6 Neighbor Discovery [RFC4861] 202 to determine the MAC address of a neighbor to which a datagram needs 203 to be sent. Both specifications intend that when a datagram arrives 204 at a router serving the target prefix, but which doesn't know the MAC 205 address of the intended destination, it should: 207 o Enqueue the datagram, 208 o Emit a Neighbor Solicitation or ARP Request, 210 o Await a Neighbor Advertisement or ARP Response, and 212 o On receipt, dequeue and forward the datagram. 214 Once the host's MAC address is in the router's tables (and in so 215 doing the address proven valid), the matter is not an issue. 217 In [Harrop], the Greynet is described as being instantiated on an 218 end-host that replies to ARP Requests for all 'dark' IP addresses. 219 However, a small modification to router behavior can augment this 220 model. As well as queuing or dropping a datagram that has triggered 221 an ARP Request or Neighbor Solicitation, the router forwards a copy 222 of this datagram over an independent link to the Greynet's analytic 223 equipment. This independent link may be a different physical 224 interface, a circuit, VLAN, tunnel, UDP or other encapsulation, or in 225 fact any place such a datagram could be handled. Depending on the 226 requirements of the receiving collector, one could also imagine 227 summarizing information in a form similar to IPFIX 228 [RFC5101][RFC5610]. 230 The analytic equipment will now receive two types of datagrams. Of 231 most interest will be those destined for 'dark' IP addresses. Of 232 less interest will be the irregular case where a datagram arrives for 233 a legitimate local neighbor who has, for some temporary reason, no 234 MAC address in the router's tables. Datagrams arriving for an IP 235 destination for which an ARP reply (or Neighbor Advertisement) has 236 not yet received might also be forwarded to the analytical equipment 237 over the independent link - or might not, if they are considered to 238 be unlikely to provide new analytic information. 240 Analytic equipment, depending on the router to recognize 'dark' IP 241 addresses in this manner, can easily track arrival patterns of 242 datagrams destined to unused parts of the network. It may also 243 optionally chose to respond to such datagrams, acting as a honeypot 244 to elicit further datagrams from the remote source. 246 If the collector replies directly, the attacker may be able to 247 identify the fact through information in or about the datagram - 248 datagrams sent to the same IP Subnet may come back with different TTL 249 values, for example. Hence, it may be advisable for the collector to 250 send the reply back through the tunnel and therefore as if from the 251 same IP Subnet. Naturally the collector in this scenario should not 252 respond to datagrams destined for 'lit' IP addresses - the intended 253 destination will eventually respond to the router's ARP or Neighbor 254 Solicitation anyway. 256 One implication of this model is that ddos attacks terminate on 257 router subnets within a network, as opposed to stopping on inter- 258 router links. 260 2.3. Other filters 262 An obvious extension of the concept would include traffic identified 263 by other filters as appropriate to send to the collector. For 264 example, one might configure the system to forward traffic failing a 265 unicast reverse forwarding path (uRPF) check [RFC2827] to the 266 collector via the same tunnel. 268 3. Implications for router design 270 The implication for router design applies to the IPv4 ARP and IPv6 271 Neighbor Discovery algorithms. It might be interesting to provide, 272 under configuration control, the ability to forward arriving 273 datagrams that trigger an ARP Request or Neighbor Solicit, and then 274 fail to receive the intended response, to an interface, circuit, 275 VLAN, or tunnel to an analytic system. 277 4. IANA Considerations 279 This memo asks the IANA for no new parameters. 281 Note to RFC Editor: This section will have served its purpose if it 282 correctly tells IANA that no new assignments or registries are 283 required, or if those assignments or registries are created during 284 the RFC publication process. From the author's perspective, it may 285 therefore be removed upon publication as an RFC at the RFC Editor's 286 discretion. 288 5. Security Considerations 290 This note describes a tool for managing IPv4 and IPv6 network 291 security. Like any tool, it has limitations and possible attacks. 292 If discarding traffic under overload is a good thing, then holding 293 and subsequently forwarding the traffic instead places a potential 294 load on the network and the router in question, and as such 295 represents a possible attack. Such an attack has obvious 296 mitigations, however; one simply, in a manner the operator deems 297 appropriate, selects a subset of the traffic to forward and discards 298 the rest. In addition, this attack is not new; it is only changed in 299 character. A stream that would instantiate the attack today results 300 in a load of ARP or Neighbor Solicit messages that all listening 301 hosts must intelligently discard. The new attack additionally 302 consumes bandwidth that is presumably set aside specifically for that 303 purpose. 305 The question of exactly what subset of traffic is interesting and 306 economical to forward is intentionally left open. Key questions in 307 algorithm design include what can be learned from a given sample (are 308 bursts happening, and if so with what data?), what the impact on the 309 router and other equipment in question is, how that might be 310 mitigated, etc. Possible selection algorithms dependent only on 311 state and algorithms typically available in a router include: 313 o All datagrams triggering an ARP Request or Neighbor Solicit, 315 o The subset of those that are not responded to within some stated 316 interval and are therefore likely dark, 318 o The subset of those that are new; if the address is currently 319 being solicited, forwarding redundant data may not be useful. 321 o All such datagrams up to some rate, 323 o All such datagrams matching (or not matching) a specified filter 324 rule, 326 o etc. 328 6. Acknowledgements 330 Algorithms for learning about Internet attack behavior by observing 331 backscatter traffic have been used by CAIDA, University of Michigan, 332 Team Cymru, and others. Harrop extended them in his research. This 333 formulation of the notion originated in a discussion among the 334 authors in 2005. This note grew out of a conversation with Paul 335 Vixie and Rhette Marsh on Internet traffic sensors; they also made 336 useful comments on it. Albert Manfredi commented on the distinction 337 between a LAN (as defined by IEEE 802) and an IP subnet. 339 Tim Chown [RFC5157] has observed that, at least at this time, address 340 scanning attacks in IPv6 have not been reported in the wild. Rhette 341 Marsh has suggested the structure of such an attack, however, and 342 Fred Baker has suggested approaches based on addressing information 343 exchanged by applications. Hence, we believe that such issues may be 344 relevant to IPv6 in the future, when IPv6 is a more interesting 345 target. 347 Tim Chown and Owen Stephens tested the proposal, and made useful 348 comments that have been incorporated in this text. His fundamental 349 comment was, however, that "it works". 351 7. References 353 7.1. Normative References 355 [Harrop] Harrop, W. and G. Armitage, "Greynets: a definition and 356 evaluation of sparsely populated darknets", IEEE LCN IEEE 357 30th Conference on Local Computer Networks, 2005. 359 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 360 September 1981. 362 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 363 converting network protocol addresses to 48.bit Ethernet 364 address for transmission on Ethernet hardware", STD 37, 365 RFC 826, November 1982. 367 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 368 (IPv6) Specification", RFC 2460, December 1998. 370 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 371 Architecture", RFC 4291, February 2006. 373 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 374 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 375 September 2007. 377 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 378 Extensions for Stateless Address Autoconfiguration in 379 IPv6", RFC 4941, September 2007. 381 7.2. Informative references 383 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 384 Defeating Denial of Service Attacks which employ IP Source 385 Address Spoofing", BCP 38, RFC 2827, May 2000. 387 [RFC5101] Claise, B., "Specification of the IP Flow Information 388 Export (IPFIX) Protocol for the Exchange of IP Traffic 389 Flow Information", RFC 5101, January 2008. 391 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 392 RFC 5157, March 2008. 394 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 395 "Exporting Type Information for IP Flow Information Export 396 (IPFIX) Information Elements", RFC 5610, July 2009. 398 Authors' Addresses 400 Fred Baker 401 Cisco Systems 402 Santa Barbara, California 93117 403 USA 405 Email: fred@cisco.com 407 Warren Harrop 408 CAIA, Swinburne University of Technology 409 Hawthorn, Victoria 3122 410 Australia 412 Email: wazz@bud.cc.swin.edu.au 414 Grenville Armitage 415 CAIA, Swinburne University of Technology 416 Hawthorn, Victoria 3122 417 Australia 419 Email: garmitage@swin.edu.au