idnits 2.17.1 draft-baker-opsec-passive-ip-address-01.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4443, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC792, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC792, updated by this document, for RFC5378 checks: 1981-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 7, 2012) is 4219 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security F. Baker 3 Internet-Draft G. Van de Velde 4 Updates: 792, 4443 (if approved) Cisco Systems 5 Intended status: Standards Track October 7, 2012 6 Expires: April 10, 2013 8 Passive IP Addresses 9 draft-baker-opsec-passive-ip-address-01 11 Abstract 13 This note suggests an approach to minimizing the attack surface of 14 the network elements - routers, switches, and middleware - of a 15 network. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 10, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 53 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3 54 1.3. Examples of attacks . . . . . . . . . . . . . . . . . . . . 3 55 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Making the address useless . . . . . . . . . . . . . . . . 5 57 2.2. ICMP/ICMPv6 handling . . . . . . . . . . . . . . . . . . . 6 58 2.3. Removing the address from routing . . . . . . . . . . . . . 6 59 2.4. DNS and Reverse DNS . . . . . . . . . . . . . . . . . . . . 7 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 4.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 8 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 This note suggests an approach to minimizing the attack surface of 73 the network elements - routers, switches, and middleware - of a 74 network. 76 1.1. Requirements Language 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 1.2. Problem Statement 84 The problem, at least in its first instance, is a side effect of 85 diagnostics used in the Internet. Tools such as mtr, traceroute, and 86 pingplotter operate by sending streams of packets to a remote address 87 with varying hop limit values in IPv6 [RFC2460] or Time to Live in 88 IPv4 [RFC0791], and receiving ICMP [RFC0792] or ICMPv6 [RFC4443] 89 messages that indicate which interfaces the packet stream traversed 90 in the forward direction. Path MTU [RFC1191] [RFC1981] discovery 91 depends on ICMP/ICMPv6 Packet Too Big. Various ICMP/ICMPv6 92 "unreachable" messages respond when routing fails, which are intended 93 to trigger applications to try other peer addresses 94 [I-D.ietf-v6ops-happy-eyeballs], and so on. The IP addresses of 95 these responders can be looked up in Reverse DNS [RFC1033][RFC1912] 96 to build a name that indicates the operator, POP, and equipment in 97 question, which is useful in identifying potential problems in the 98 path. 100 Unfortunately, those addresses can also be used in another way. A 101 motivated adversary can subject routers to TCP RST attacks, load- 102 based DDOS, and other attacks. 104 An alternate way to reduce this potential attack vector is to not use 105 addresses that are valid beyond the link it is attached towards. A 106 sollution describing considerations around this is given in 107 [draft-ietf-opsec-lla-only] while passive IPv6 addresses will provide 108 network path visibility withought increasing large extend of 109 vulnerability for the devices using down the traffic path. 111 1.3. Examples of attacks 113 To pick one example, attacks are being reported in which residential 114 broadband customer's CPE Router is targeted with large volume SNMP 115 GET Requests. The address of the router is not generally known; in 116 IPv4, that may be a result of NAPT use, with the address being 117 harvested from exchanges. It may be obtained from a traceroute to a 118 server behind the router, or it may be determined by analysis of SMTP 119 envelopes. 121 Another example is attacks on BGP peering. BGP neighbors often peer 122 between the loopback addresses of neighboring routers, to make the 123 TCP session stable in the presence of link outages, but may peer 124 using interface addresses. If a router is configured to use 125 interface addresses in ICMP/ICMPv6 messages and to peer using those 126 same addresses, the ICMP response exposes information that can be 127 used in a RST attack on routing. It also facilitates any other kind 128 of attack on the router, such as the previously noted SNMP attack 129 (even if the router knows to refuse the message, it consumes CPU). 130 If global addresses are not used - routers use link-local or private 131 addresses - that makes it harder for an attacker to attack the 132 router, but it means that traceroute and other uses are compromised, 133 which is an attack on network forensics. If link-local addresses are 134 used on the interfaces and ICMP is configured to use the loopback 135 address, the router is again exposed to RST attacks. 137 2. Proposal 139 The simplest solution seems to be to enable the router to hide in 140 plain sight - to use an address as the source address in ICMP and 141 other messages that is identifiable using Reverse DNS (and therefore, 142 through the name, useful for network diagnostics and communication 143 between operators), but does not facilitate attacks. 145 The fundamental theory behind this proposal is the Principle of Least 146 Privilege, which in this application is that an entity in the 147 Internet must be able to access only the information and resources 148 that are necessary for its legitimate purpose. In this case, it is 149 reasonable, for various reasons, to enable a random user to identify 150 the path his or her traffic is using or to identify a system in his 151 path when reporting operational issues to an administration. It is 152 not reasonable, or at least not required, that the user be able to 153 specifically interact with any of those systems in the general case. 155 We propose that the source IP address in an ICMP/ICMPv6 message, or 156 indeed any message sent to a host that has no inherent need to 157 contact the specific system, be useful for Reverse DNS, but not for 158 touching the system. Ideally, it is not routable to the system in 159 the first place; The passive character of this type of addres address 160 comes to play if a packet with this address as destination address on 161 a targetted device and is delivered to the interface, it is summarily 162 dropped. Such an address is referred to as a "passive address", and 163 if it comes from a specific prefix, the prefix is referred to as a 164 "passive prefix". Addresses that are routable and not dropped on 165 receipt will, for the purposes of this specification, be called 166 "active" IP addresses. 168 A passive address is sementically non-disguisable from any other type 169 of address and has no requirement for any new type of address-family. 170 Any IPv4 or IPv6 address can become a passive address by a 171 configuration knob when specifying the interface IP address for the 172 Interface or device. 174 2.1. Making the address useless 176 Every interface in the Internet has an address, with the exception of 177 IPv4 unnumbered interfaces; even those have addresses that they use, 178 which are the actual address of some other interface on the same 179 system. Increasingly, this is in fact a list of addresses, some of 180 which are IPv4 and some of which are IPv6. 182 We propose that any address allocated to an interface on 183 infrastructure equipment be given two binary attributes: 185 UseInICMP: If the address has this attribute TRUE, the corresponding 186 address may be used as the source address of ICMP or ICMPv6 187 messages and other messages sent to hosts that have no need to 188 actually touch the system. It is otherwise FALSE. 190 Respond: If the address has this attribute TRUE, the device will 191 process and respond to packets it receives that have this as a 192 destination address; it is an active address. If the attribute is 193 FALSE, the address is a passive address. 195 If UseInICMP is set TRUE on a Global Unicast Address or Unique Local 196 Address, the address will be available for use in ICMP messages. If 197 "Respond" is set TRUE, traffic sent to the address will be served in 198 the usual way. This describes the present Internet usage. If 199 Respond is set FALSE, traffic sent to the address will be summarily 200 discarded, in effect presenting a "local firewall" blockage related 201 to the address. 203 An address that has UseInICMP set FALSE will not be used as the 204 source address of an ICMP message. That address will be 205 indiscoverable via ICMP messages. If Respond is TRUE and the address 206 becomes known by other means, such as DNS, traffic sent to the 207 address will be served in the usual way. If Respond is set FALSE, 208 traffic sent to the address will be summarily discarded, in effect 209 presenting a "local firewall" blockage related to the address. 211 The scenario in view here is that 212 o an address that is used to access the system would have UseInICMP 213 FALSE (the address is not leaked in such messages) and Respond 214 TRUE (messages sent to the address MAY be operated on by the 215 system). 217 o an address that is used in ICMP and similar messages would have 218 UseInICMP TRUE (the address MAY be leaked in such messages) and 219 Respond FALSE (messages sent to the address will be dropped on 220 receipt). 222 2.2. ICMP/ICMPv6 handling 224 Per [RFC4443], an ICMP Response such as Time Exceeded or Parameter 225 Problem is sent from "the" source address of the interface that 226 detected the issue. This specification narrows that: it SHOULD use 227 one of the source addresses that have the attribute UseInICMP set to 228 TRUE. If no address has that attribute TRUE, it SHOULD NOT send the 229 message. 231 2.3. Removing the address from routing 233 If the passive address is taken from any prefix that is not 234 advertised in routing, it will be difficult for an adversary to route 235 to the address, which simplifies the treatment of certain forms of 236 attacks. It is not impossible; a system on the same LAN could send a 237 crafted packet that would arrive anyway. However, especially in 238 inter-domain routing, it is often quite reasonable to believe that 239 addresses exist that need not be advertised to a neighboring network. 241 One example of such an address, in IPv6, might be a Unique Local IPv6 242 Unicast Address [RFC4193], or a global unicast address or prefix. 243 There are obvious operational issues in the use of a global prefix; 244 it is easy to accidentally advertise it. In an IPv4 network, the 245 counterpart might be to use an [RFC1918] address, or to use another 246 prefix that one chooses to not advertise. 248 Link Local addresses SHOULD NOT be used in this context; while they 249 are obviously unroutable except on the local LAN, they are not useful 250 in Reverse DNS. 252 One problem with this relates to Ingress Filtering [RFC2827]. If the 253 prefix used for passive addresses is not advertised to the 254 neighboring network and the neighboring network is using unicast 255 reverse path filtering, it will filter these responses. For this 256 reason, a network doing this SHOULD advise neighboring networks of 257 passive prefixes for the purpose of inclusion in ingress filters. 259 2.4. DNS and Reverse DNS 261 [RFC1912] recommends that "For every IP address, there should be a 262 matching PTR record in the in-addr.arpa domain." In IPv6, there is 263 an important special case, in that link-local addresses are not 264 reflected there, and are used in routing protocols for local 265 communication among IPv6 routers. Like other addresses, passive IP 266 addresses SHOULD have a corresponding Reverse DNS entry; these names 267 help with traceroute and in fault diagnosis. While active addresses 268 may be expected to have A or AAAA records in the administration's own 269 DNS, there is little point for doing so for passive addresses, as 270 they are unresponsive and very likely unreachable. 272 However, the names given to passive addresses SHOULD NOT be directly 273 similar to the names given active IP addresses. For example, it may 274 be useful to name the interfaces on a certain router so as to 275 identify the router - "ethernet7.card3.router5.lax.example.com". If 276 the correlation to the name of the loopback interface 277 ("router5.lax.example.com") is obviously derivative, the security 278 value is largely forfeit, although it might require human 279 interaction. Such names should differ enough that they are not 280 readily intuited, such as "rack12.lax.example.com". 282 3. IANA Considerations 284 This memo asks the IANA for no new parameters. 286 Note to RFC Editor: This section will have served its purpose if it 287 correctly tells IANA that no new assignments or registries are 288 required, or if those assignments or registries are created during 289 the RFC publication process. From the author's perspective, it may 290 therefore be removed upon publication as an RFC at the RFC Editor's 291 discretion. 293 4. Security Considerations 295 This entire note could be described as addressing a set of security 296 considerations. It is not a complete solution to attacks on 297 infrastructure - if loopback addresses, which are used for network 298 management and other purposes are generally known, the infrastructure 299 can still be attacked. However, it is an important reduction of the 300 attack surface. It creates no attack surface that did not already 301 exist. 303 4.1. Privacy Considerations 305 This proposal also introduces no new privacy issues. 307 5. Acknowledgements 309 This document grew from a conversation among the authors, John 310 Brzozowski, and Thienpondt Hans. Merike Keao's review was very 311 helpful. 313 6. Change Log 315 Initial Version: 1 March 2012 317 2th version: 7 October 2012 319 7. References 321 7.1. Normative References 323 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 324 September 1981. 326 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 327 RFC 792, September 1981. 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 333 (IPv6) Specification", RFC 2460, December 1998. 335 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 336 Message Protocol (ICMPv6) for the Internet Protocol 337 Version 6 (IPv6) Specification", RFC 4443, March 2006. 339 7.2. Informative References 341 [I-D.ietf-v6ops-happy-eyeballs] 342 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 343 Dual-Stack Hosts", draft-ietf-v6ops-happy-eyeballs-07 344 (work in progress), December 2011. 346 [RFC1033] Lottor, M., "Domain administrators operations guide", 347 RFC 1033, November 1987. 349 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 350 November 1990. 352 [RFC1912] Barr, D., "Common DNS Operational and Configuration 353 Errors", RFC 1912, February 1996. 355 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 356 E. Lear, "Address Allocation for Private Internets", 357 BCP 5, RFC 1918, February 1996. 359 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 360 for IP version 6", RFC 1981, August 1996. 362 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 363 Defeating Denial of Service Attacks which employ IP Source 364 Address Spoofing", BCP 38, RFC 2827, May 2000. 366 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 367 Addresses", RFC 4193, October 2005. 369 [draft-ietf-opsec-lla-only] 370 , M., "Using Only Link-Local Addressing Inside an IPv6 371 Network", 20012. 373 Authors' Addresses 375 Fred Baker 376 Cisco Systems 377 Santa Barbara, California 93117 378 USA 380 Email: fred@cisco.com 382 Gunter Van de Velde 383 Cisco Systems 384 De Kleetlaan 6a 385 Diegem 1831 386 Belgium 388 Phone: +32 2704 5473 389 Email: gvandeve@cisco.com