idnits 2.17.1 draft-ietf-opsec-lla-only-02.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 22, 2012) is 4204 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-ospf-prefix-hiding-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities for M. Behringer 3 IP Network Infrastructure E. Vyncke 4 Internet-Draft Cisco 5 Intended status: Informational October 22, 2012 6 Expires: April 25, 2013 8 Using Only Link-Local Addressing Inside an IPv6 Network 9 draft-ietf-opsec-lla-only-02 11 Abstract 13 In an IPv6 network it is possible to use only link-local addresses on 14 infrastructure links between routers. This document discusses the 15 advantages and disadvantages of this approach to help the decision 16 process for a given network. 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 April 25, 2013. 35 Copyright Notice 37 Copyright (c) 2012 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. Requirements Language . . . . . . . . . . . . . . . . . . . 3 54 2. Using Link-Local Address on Infrastructure Links . . . . . . . 3 55 2.1. The Approach . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.4. Internet Exchange Points . . . . . . . . . . . . . . . . . 6 59 2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 An infrastructure link between a set of routers typically does not 71 require global or even unique local addressing [RFC4193]. Using 72 link-local addressing on such links has a number of advantages, for 73 example that routing tables do not need to carry link addressing, and 74 can therefore be significantly smaller. This helps to decrease 75 failover times in certain routing convergence events. An interface 76 of a router is also not reachable beyond the link boundaries, 77 therefore reducing the attack horizon. 79 We propose to configure neither globally routable IPv6 addresses nor 80 unique local addresses on infrastructure links of routers, wherever 81 possible. We recommend to use exclusively link-local addresses on 82 such links. 84 This document discusses the advantages and caveats of this approach. 86 Note: [I-D.ietf-ospf-prefix-hiding] describes another approach for 87 OPSFv2 and OSPFv3 by modifying the existing protocols while this 88 document does not modify any protocol but works only for IPv6. 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC2119 [RFC2119] when 95 they appear in ALL CAPS. These words may also appear in this 96 document in lower case as plain English words, absent their normative 97 meanings. 99 2. Using Link-Local Address on Infrastructure Links 101 This document proposes to use only link-local addresses (LLA) on all 102 router interfaces on infrastructure links. Routers typically do not 103 need to be reached from nodes of the network, nor from outside the 104 network. For an network operator there may be reasons to send 105 packets to an infrastructure link for certain monitoring tasks; many 106 of those tasks could also be handled differently, not requiring 107 routable address space on infrastructure links. 109 2.1. The Approach 111 Neither global IPv6 addresses nor unique local addresses are 112 configured on infrastructure links. In the absence of specific 113 global or unique local address definitions, the default behavior of 114 routers is to use link-local addresses notably for routing protocols. 116 These link-local addresses SHOULD be hard-coded to prevent the change 117 of EUI-64 addresses when changing of MAC address (such as after 118 changing a network interface card). 120 ICMPv6 [RFC4443] error messages (packet-too-big, time-exceeded...) 121 are required for routers, therefore a loopback interface must be 122 configured with an IPv6 address with a greater scope than link-local 123 (this will usually be a global scope). This greater than link-local 124 scope IPv6 address must be used as the source IPv6 address for all 125 generated ICMPv6 messages sent to a non link-local address and must 126 belong to the operator and be part of an announced prefix (with a 127 suitable prefix length) to avoid being dropped by other routers 128 implementing [RFC3704]. 130 The effect on specific traffic types is as follows: 132 o Control plane protocols, such as BGP, ISIS, OSPFv3, RIPng, PIM 133 work by default or can be configured to work with link-local 134 addresses. 136 o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo 137 request ... can be addressed to loopback addresses of routers with 138 a greater than link-local scope address. Router management can 139 also be done over out-of-band channels. 141 o ICMP error message can be sourced from a loopback address. They 142 must not be sourced from link-local addresses when the destination 143 is non link-local. 145 o Data plane traffic is forwarded independently of the link address 146 type. 148 o Neighbor discovery (neighbor solicitation and neighbor 149 advertisement) is done by using link-local unicast and multicast 150 addresses, therefore neighbor discovery is not affected. 152 We therefore conclude that it is possible to construct a working 153 network in this way. 155 2.2. Advantages 157 Smaller routing tables: Since the routing protocol only needs to 158 carry one loopback address per router, it is smaller than in the 159 traditional approach where every infrastructure link addresses are 160 carried in the routing protocol. This reduces memory consumption, 161 and increases the convergence speed in some routing failover cases 162 (notably because the Forwarding Information Base to be downloaded to 163 line cards are smaller but also because there are less prefixes in 164 the Routing Information Base hence accelerating the routing 165 algorithm). Note: smaller routing tables can also be achieved by 166 putting interfaces in passive mode for the IGP. 168 Reduced attack surface: Every routable address on a router 169 constitutes a potential attack point: a remote attacker can send 170 traffic to that address, for example a TCP SYN flood, or he can 171 intent SSH brute force password attacks. If a network only uses 172 loopback addresses for the routers, only those loopback addresses 173 need to be protected from outside the network. This significantly 174 eases protection measures, such as infrastructure access control 175 lists. See also [I-D.ietf-grow-private-ip-sp-cores] for further 176 discussion on this topic. 178 Lower configuration complexity: LLAs require no specific 179 configuration (except when they are statically configured), thereby 180 lowering the complexity and size of router configurations. This also 181 reduces the likelihood of configuration mistakes. 183 Simpler DNS: Less routable address space in use also means less DNS 184 mappings to maintain. 186 2.3. Caveats 188 Interface ping: If an interface doesn't have a routable address, it 189 can only be pinged from a node on the same link. Therefore it is not 190 possible to ping a specific link interface remotely. A possible 191 workaround is to ping the loopback address of a router instead. In 192 most cases today it is not possible to see which link the packet was 193 received on; however, RFC5837 [RFC5837] suggests to include the 194 interface identifier of the interface a packet was received on in the 195 ICMP response; it must be noted that there are little implemention of 196 this ICMP extension. With this approach it would be possible to ping 197 a router on the loopback address, yet see which interface the packet 198 was received on. To check liveliness of a specific interface it may 199 be necessary to use other methods, for example to connect to the 200 router via SSH and to check locally or use SNMP. 202 Traceroute: Similar to the ping case, a reply to a traceroute packet 203 would come from a loopback address with a greater than link-local 204 address. Today this does not display the specific interface the 205 packets came in on. Also here, RFC5837 [RFC5837] provides a 206 solution. 208 Hardware dependency: LLAs are usually EUI-64 based, hence, they 209 change when the MAC address is changed. This could pose problem in a 210 case where the routing neighbor must be configured explicitly (e.g. 211 BGP) and a line card needs to be physically replaced hence changing 212 the EUI-64 LLA and breaking the routing neighborship. But, LLAs can 213 be statically configured such as fe80::1 and fe80::2 which can be 214 used to configure any required static routing neighborship. 216 Network Management System (NMS) toolkits: If there is any NMS tool 217 that makes use of interface IP address of a router to carry out any 218 of NMS functions, then it would no longer work, if the interface is 219 missing routable address. A possible workaround for such tools is to 220 use the routable loopback address of the router instead. Most vendor 221 implementations allow the specification of the loopback address for 222 SYSLOG, IPfix, SNMP. LLDP (IEEE 802.1AB-2009) runs directly over 223 Ethernet and does not require any IPv6 address so dynamic network 224 discovery is not hindered when using LLDP. But, network discovery 225 based on NDP cache content will only display the link-local addresses 226 and not the loopback global address; therefore, network discovery 227 should rather be based on the Route Information Base to detect 228 adjacent nodes. 230 MPLS and RSVP-TE [RFC3209] allows establishing MPLS LSP on a path 231 that is explicitly identified by a strict sequence of IP prefixes or 232 addresses (each pertaining to an interface or a router on the path). 233 This is commonly used for Fast Re-Route (FRR). However, if an 234 interface uses only a link-local address, then such LSPs cannot be 235 established. At the time of writing this document, there is no 236 workaround for this case; therefore where RSVP-TE is being used, the 237 approach proposed in this document does not work. 239 2.4. Internet Exchange Points 241 Internet Exchange Points (IXPs) have a special importance in the 242 global Internet, because they connect a high number of networks in a 243 single location, and because significant part of Internet traffic 244 pass through at least one IXP. An IXP with all the service provider 245 nodes requires therefore a very high level of security. The address 246 space used on an IXP is generally known, as it is registered in the 247 global Internet Route Registry, or it is easily discoverable through 248 traceroute. The IXP prefix is especially critical, because 249 practically all addresses on this prefix are critical systems in the 250 Internet. 252 Apart from general device security guidelines, there are generally 253 two additional ways to raise security (see also 254 [I-D.jdurand-bgp-security]): 256 1. Not to announce the prefix in question, and 258 2. To drop all traffic destined to the IXP prefixes from traffic 259 from remote locations. 261 Not announcing the prefix of the IXP however would frequently result 262 in traceroute and similar packets (required for PMTUd) to be dropped 263 due to uRPF checks. Given that PMTUd is critical, this is generally 264 not acceptable. Dropping all external traffic to the IXP prefix is 265 hard to implement, because if only one service provider on an IXP 266 routes does not filter correctly, then all IXP routers are reachable 267 from at least that service provider network. 269 As the prefix used in IXP is usually longer than a /48 it is 270 frequently dropped by route filters on the Internet having the same 271 net effect as not announced the prefix. 273 Using link-local addresses on the IXP may help in this scenario. In 274 this case, the generated ICMP packets would be generated from 275 loopback interfaces or from any other interfaces with globally 276 routable sources without any configuration. However in this case, 277 each service provider would use his own address space, making a 278 generic attack against all devices on the IXP harder. Also all the 279 loopback addresses on the IXP can be discovered by a potential 280 attacker by a simple traceroute; a generic attack is therefore still 281 possible, but it would require significantly more work. 283 In some cases service providers carry the IXP addresses in their IGP 284 for certain forms of traffic engineering across multiple exit points. 285 If link local addresses are used, these cannot be used for this 286 purpose; in this case, the service provider would have to employ 287 other methods of traffic engineering. 289 2.5. Summary 291 Using link-local addressing only on infrastructure links has a number 292 of advantages, such as a smaller routing table size and a reduced 293 attack surface. It also simplifies router configurations. However, 294 the way certain network management tasks are carried out today has to 295 be adapted to provide the same level of detail, for example interface 296 identifiers in traceroute. 298 3. Security Considerations 300 Using LLAs only on infrastructure links reduces the attack surface of 301 a router: loopback addresses with routed addresses are still 302 reachable and must be secured, but infrastructure links can only be 303 attacked from the local link. This simplifies security of control 304 and management planes. The proposal does not impact the security of 305 the data plane. This proposal does not address control plane 306 [RFC6192] attacks generated by data plane packets (such as hop-limit 307 expiration or packets containing a hop-by-hop extension header). 309 As in the traditional approach, this approach relies on the 310 assumption that all routers can be trusted due to physical and 311 operational security. 313 4. IANA Considerations 315 There are no IANA considerations or implications that arise from this 316 document. 318 5. Acknowledgements 320 The authors would like to thank Salman Asadullah, Brian Carpenter, 321 Benoit Claise, Simon Eng, Wes George, Janos Mohacsi, Alvaro Retana, 322 Ivan Pepelnjak for their useful comments about this work. 324 6. References 326 6.1. Normative References 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, March 1997. 331 6.2. Informative References 333 [I-D.ietf-grow-private-ip-sp-cores] 334 Kirkham, A., "Issues with Private IP Addressing in the 335 Internet", draft-ietf-grow-private-ip-sp-cores-07 (work in 336 progress), July 2012. 338 [I-D.ietf-ospf-prefix-hiding] 339 Yang, Y., Retana, A., and A. Roy, "Hiding Transit-only 340 Networks in OSPF", draft-ietf-ospf-prefix-hiding-05 (work 341 in progress), July 2012. 343 [I-D.jdurand-bgp-security] 344 Durand, J., Pepelnjak, I., and G. Doering, "BGP operations 345 and security", draft-jdurand-bgp-security-02 (work in 346 progress), September 2012. 348 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 349 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 350 Tunnels", RFC 3209, December 2001. 352 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 353 Networks", BCP 84, RFC 3704, March 2004. 355 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 356 Addresses", RFC 4193, October 2005. 358 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 359 Message Protocol (ICMPv6) for the Internet Protocol 360 Version 6 (IPv6) Specification", RFC 4443, March 2006. 362 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 363 Rivers, "Extending ICMP for Interface and Next-Hop 364 Identification", RFC 5837, April 2010. 366 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 367 Router Control Plane", RFC 6192, March 2011. 369 Authors' Addresses 371 Michael Behringer 372 Cisco 373 400 Avenue Roumanille, Bat 3 374 Biot, 06410 375 France 377 Email: mbehring@cisco.com 379 Eric Vyncke 380 Cisco 381 De Kleetlaan, 6A 382 Diegem, 1831 383 Belgium 385 Email: evyncke@cisco.com