idnits 2.17.1 draft-ietf-opsec-lla-only-04.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 (October 20, 2013) is 3839 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0792' is defined on line 335, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-opsec-bgp-security-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPsec Working Group M. Behringer 3 Internet-Draft E. Vyncke 4 Intended status: Informational Cisco 5 Expires: April 23, 2014 October 20, 2013 7 Using Only Link-Local Addressing Inside an IPv6 Network 8 draft-ietf-opsec-lla-only-04 10 Abstract 12 In an IPv6 network it is possible to use only link-local addresses on 13 infrastructure links between routers. This document discusses the 14 advantages and disadvantages of this approach to help the decision 15 process for a given 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 23, 2014. 34 Copyright Notice 36 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Using Link-Local Address on Infrastructure Links . . . . . . 2 53 2.1. The Approach . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.3. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.4. Internet Exchange Points . . . . . . . . . . . . . . . . 5 57 2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Informative References . . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 An infrastructure link between a set of routers typically does not 67 require global or even unique local addressing [RFC4193]. Using only 68 link-local addressing on such links has a number of advantages, for 69 example that routing tables do not need to carry link addressing, and 70 can therefore be significantly smaller. This helps to decrease 71 failover times in certain routing convergence events. An interface 72 of a router is also not reachable beyond the link boundaries, 73 therefore reducing the attack horizon. 75 This document discusses the advantages and caveats of this approach. 77 Note: [RFC6860] describes another approach for OPSFv2 and OSPFv3 by 78 modifying the existing protocols while this document does not modify 79 any protocol but works only for IPv6. 81 2. Using Link-Local Address on Infrastructure Links 83 This document discusses the approach of using only link-local 84 addresses (LLA) on all router interfaces on infrastructure links. 85 Routers typically need to receive packets neither from hosts, nor 86 from nodes outside the network. For an network operator there may be 87 reasons to use greater than link-local scope addresses on 88 infrastructure interfaces for certain operational tasks, for example 89 pings to an interface or traceroutes across the network. This 90 document discusses such cases and proposes alternative procedures. 92 2.1. The Approach 94 Neither global IPv6 addresses nor unique local addresses are 95 configured on infrastructure links. In the absence of specific 96 global or unique local address definitions, the default behavior of 97 routers is to use link-local addresses notably for routing protocols. 99 The sending of ICMPv6 [RFC4443] error messages (packet-too-big, time- 100 exceeded...) is required for routers, therefore another interface 101 must be configured with an IPv6 address with a greater scope than 102 link-local. This will usually be a loopback interface with a global 103 scope address belonging to the operator and part of an announced 104 prefix (with a suitable prefix length) to avoid being dropped by 105 other routers implementing [RFC3704]. For the remainder of this 106 document we will refer to this interface as a "loopback interface". 107 [RFC6724] mandates that greater than link-local scope IPv6 addresses 108 must be used as the source IPv6 address for all generated ICMPv6 109 messages sent to a non link-local address. 111 The effect on specific traffic types is as follows: 113 o Control plane protocols, such as BGP [RFC4271], ISIS [IS-IS], 114 OSPFv3 [RFC5340], RIPng [RFC2080], PIM [RFC4609] work by default 115 or can be configured to work with link-local addresses. 117 o Management plane traffic, such as SSH [RFC4251], Telnet [RFC0495], 118 SNMP [RFC1157], and ICMP echo request [RFC4443], can use as 119 destination address the address of the router loopback interface. 120 Router management can also be done over out-of-band channels. 122 o ICMP error message can be sourced from a loopback interface. They 123 must not be sourced from link-local addresses when the destination 124 is non link-local. See [RFC6724]. 126 o Data plane traffic is forwarded independently of the link address 127 type. 129 o Neighbor discovery (neighbor solicitation and neighbor 130 advertisement) is done by using link-local unicast and multicast 131 addresses, therefore neighbor discovery is not affected. 133 We therefore conclude that it is possible to construct a working 134 network in this way. 136 2.2. Advantages 138 Smaller routing tables: Since the routing protocol only needs to 139 carry one global address (the loopback interface) per router, it is 140 smaller than the traditional approach where every infrastructure link 141 addresses are carried in the routing protocol. This reduces memory 142 consumption, and increases the convergence speed in some routing 143 failover cases (notably because the Forwarding Information Base to be 144 downloaded to line cards is smaller but also because there are less 145 prefixes in the Routing Information Base hence accelerating the 146 routing algorithm). Note: smaller routing tables can also be 147 achieved by putting interfaces in passive mode for the IGP. 149 Reduced attack surface: Every routable address on a router 150 constitutes a potential attack point: a remote attacker can send 151 traffic to that address, for example a TCP SYN flood (see [RFC4987]), 152 or can attempt SSH brute force password attacks. If a network only 153 uses the addresses of the router loopback interface(s), only those 154 need to be protected from outside the network. This may ease 155 protection measures, such as infrastructure access control lists. 157 Without using link-local addresses, it is still possible to achieve 158 the same result if the network addressing scheme is set up such that 159 all link and loopback interfaces have greater than link-local 160 addresses and are aggregatable, and if the infrastructure access list 161 covers that entire aggregated space. See also [RFC6752] for further 162 discussion on this topic. 164 Lower configuration complexity: link-local addresses require no 165 specific configuration, thereby lowering the complexity and size of 166 router configurations. This also reduces the likelihood of 167 configuration mistakes. 169 Simpler DNS: Less routable address space in use also means less 170 reverse and forward mapping DNS resource records to maintain. 172 2.3. Caveats 174 Interface ping: if an interface doesn't have a routable address, it 175 can only be pinged from a node on the same link. Therefore it is not 176 possible to ping a specific link interface remotely. A possible 177 workaround is to ping the loopback address of a router instead. In 178 most cases today it is not possible to see which link the packet was 179 received on; however, RFC5837 [RFC5837] suggests to include the 180 interface identifier of the interface a packet was received on in the 181 ICMP response; it must be noted that there are few implementions of 182 this ICMP extension. With this approach it would be possible to ping 183 a router on the addresses of loopback interfaces, yet see which 184 interface the packet was received on. To check liveliness of a 185 specific interface it may be necessary to use other methods, for 186 example to connect to the router via SSH and to check locally or use 187 SNMP. 189 Traceroute: similar to the ping case, a reply to a traceroute packet 190 would come from the address of a loopback interface, and current 191 implementations do not display the specific interface the packets 192 came in on. Also here, RFC5837 [RFC5837] provides a solution. 194 Hardware dependency: LLAs are usually EUI-64 based, hence, they 195 change when the MAC address is changed. This could pose problem in a 196 case where the routing neighbor must be configured explicitly (e.g. 197 BGP) and a line card needs to be physically replaced hence changing 198 the EUI-64 LLA and breaking the routing neighborship. But, LLAs can 199 be statically configured such as fe80::1 and fe80::2 which can be 200 used to configure any required static routing neighborship. This 201 static configuration is similar in complexity to statically 202 configured greater than link-local addresses, however, it is only 203 required where routing peers are explicitly configured. 205 Network Management System (NMS) toolkits: if there is any NMS tool 206 that makes use of interface IP address of a router to carry out any 207 of NMS functions, then it would no longer work, if the interface is 208 missing routable address. A possible workaround for such tools is to 209 use the routable address of the router loopback interface instead. 210 Most vendor implementations allow the specification of the address of 211 the loopback interfaces for SYSLOG, IPfix, SNMP. LLDP (IEEE 212 802.1AB-2009) runs directly over Ethernet and does not require any 213 IPv6 address so dynamic network discovery is not hindered when using 214 LLDP. But, network discovery based on NDP cache content will only 215 display the link-local addresses and not the addresses of the 216 loopback interfaces; therefore, network discovery should rather be 217 based on the Route Information Base to detect adjacent nodes. 219 MPLS and RSVP-TE [RFC3209] allows establishing MPLS LSP on a path 220 that is explicitly identified by a strict sequence of IP prefixes or 221 addresses (each pertaining to an interface or a router on the path). 222 This is commonly used for Fast Re-Route (FRR). However, if an 223 interface uses only a link-local address, then such LSPs cannot be 224 established. At the time of writing this document, there is no 225 workaround for this case; therefore where RSVP-TE is being used, the 226 approach described in this document does not work. 228 2.4. Internet Exchange Points 230 Internet Exchange Points (IXPs) have a special importance in the 231 global Internet, because they connect a high number of networks in a 232 single location, and because significant part of Internet traffic 233 pass through at least one IXP. An IXP with all the service provider 234 nodes requires therefore a very high level of security. The address 235 space used on an IXP is generally known, as it is registered in the 236 global Internet Route Registry, or it is easily discoverable through 237 traceroute. The IXP prefix is especially critical, because 238 practically all addresses on this prefix are critical systems in the 239 Internet. 241 Apart from general device security guidelines, there are generally 242 two additional ways to raise security (see also 243 [I-D.ietf-opsec-bgp-security]): 245 1. Not to announce the prefix in question, and 247 2. To drop all traffic destined to the IXP prefixes from traffic 248 from remote locations. 250 Not announcing the prefix of the IXP however would frequently result 251 in traceroute and similar packets (required for PMTUd) to be dropped 252 due to uRPF checks. Given that PMTUd is critical, this is generally 253 not acceptable. Dropping all external traffic to the IXP prefix is 254 hard to implement, because if only one service provider on an IXP 255 routes does not filter correctly, then all IXP routers are reachable 256 from at least that service provider network. 258 As the prefix used in IXP is usually longer than a /48 it is 259 frequently dropped by route filters on the Internet having the same 260 net effect as not announced the prefix. 262 Using link-local addresses on the IXP may help in this scenario. In 263 this case, the generated ICMP packets would be generated from 264 loopback interfaces or from any other interfaces with globally 265 routable sources without any configuration. However in this case, 266 each service provider would use his own address space, making a 267 generic attack against all devices on the IXP harder. Also all the 268 addresses of the loopback interfaces on the IXP can be discovered by 269 a potential attacker by a simple traceroute; a generic attack is 270 therefore still possible, but it would require more work. 272 In some cases service providers carry the IXP addresses in their IGP 273 for certain forms of traffic engineering across multiple exit points. 274 If link-local addresses are used, these cannot be used for this 275 purpose; in this case, the service provider would have to employ 276 other methods of traffic engineering. 278 If an Internet Exchange Point is using a global prefix registered for 279 this purpose, a traceroute will indicate whether the trace crosses an 280 IXP rather than a private interconnect. If link local addressing is 281 used instead, a traceroute will not provide this distinction. 283 2.5. Summary 284 Using link-local addressing only on infrastructure links has a number 285 of advantages, such as a smaller routing table size and a reduced 286 attack surface. It also simplifies router configurations. However, 287 the way certain network management tasks are carried out today has to 288 be adapted to provide the same level of detail, for example interface 289 identifiers in traceroute. 291 3. Security Considerations 293 Using LLAs only on infrastructure links reduces the attack surface of 294 a router: addresses of loopback interfaces with routed addresses are 295 still reachable and must be secured, but infrastructure links can 296 only be attacked from the local link. This simplifies security of 297 control and management planes. The approach does not impact the 298 security of the data plane. This approach does not address control 299 plane [RFC6192] attacks generated by data plane packets (such as hop- 300 limit expiration or packets containing a hop-by-hop extension 301 header). 303 As in the traditional approach, this approach relies on the 304 assumption that all routers can be trusted due to physical and 305 operational security. 307 4. IANA Considerations 309 There are no IANA considerations or implications that arise from this 310 document. 312 5. Acknowledgements 314 The authors would like to thank Salman Asadullah, Brian Carpenter, 315 Benoit Claise, Rama Darbha, Simon Eng, Wes George, Fernando Gont, 316 Harald Michl, Janos Mohacsi, Alvaro Retana and Ivan Pepelnjak for 317 their useful comments about this work. 319 6. Informative References 321 [I-D.ietf-opsec-bgp-security] 322 Durand, J., Pepelnjak, I., and G. Doering, "BGP operations 323 and security", draft-ietf-opsec-bgp-security-01 (work in 324 progress), July 2013. 326 [IS-IS] ISO/IEC 10589, ., "Intermediate System to Intermediate 327 System Intra-Domain Routing Exchange Protocol for use in 328 Conjunction with the Protocol for Providing the 329 Connectionless-mode Network Service (ISO 8473)", June 330 1992. 332 [RFC0495] McKenzie, A., "Telnet Protocol specifications", RFC 495, 333 May 1973. 335 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 336 RFC 792, September 1981. 338 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 339 "Simple Network Management Protocol (SNMP)", STD 15, RFC 340 1157, May 1990. 342 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 343 January 1997. 345 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 346 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 347 Tunnels", RFC 3209, December 2001. 349 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 350 Networks", BCP 84, RFC 3704, March 2004. 352 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 353 Addresses", RFC 4193, October 2005. 355 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 356 Protocol Architecture", RFC 4251, January 2006. 358 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 359 Protocol 4 (BGP-4)", RFC 4271, January 2006. 361 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 362 Message Protocol (ICMPv6) for the Internet Protocol 363 Version 6 (IPv6) Specification", RFC 4443, March 2006. 365 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 366 Independent Multicast - Sparse Mode (PIM-SM) Multicast 367 Routing Security Issues and Enhancements", RFC 4609, 368 October 2006. 370 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 371 Mitigations", RFC 4987, August 2007. 373 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 374 for IPv6", RFC 5340, July 2008. 376 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 377 Rivers, "Extending ICMP for Interface and Next-Hop 378 Identification", RFC 5837, April 2010. 380 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 381 Router Control Plane", RFC 6192, March 2011. 383 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 384 "Default Address Selection for Internet Protocol Version 6 385 (IPv6)", RFC 6724, September 2012. 387 [RFC6752] Kirkham, A., "Issues with Private IP Addressing in the 388 Internet", RFC 6752, September 2012. 390 [RFC6860] Yang, Y., Retana, A., and A. Roy, "Hiding Transit-Only 391 Networks in OSPF", RFC 6860, January 2013. 393 Authors' Addresses 395 Michael Behringer 396 Cisco 397 Building D, 45 Allee des Ormes 398 Mougins 06250 399 France 401 Email: mbehring@cisco.com 403 Eric Vyncke 404 Cisco 405 De Kleetlaan, 6A 406 Diegem 1831 407 Belgium 409 Email: evyncke@cisco.com