idnits 2.17.1 draft-ietf-opsec-lla-only-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 : ---------------------------------------------------------------------------- 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 (September 21, 2012) is 4234 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 September 21, 2012 6 Expires: March 25, 2013 8 Using Only Link-Local Addressing Inside an IPv6 Network 9 draft-ietf-opsec-lla-only-01 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 March 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 and Possible Workarounds . . . . . . . . . . . . . 5 58 2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 An infrastructure link between a set of routers typically does not 70 require global or even unique local addressing [RFC4193]. Using 71 link-local addressing on such links has a number of advantages, for 72 example that routing tables do not need to carry link addressing, and 73 can therefore be significantly smaller. This helps to decrease 74 failover times in certain routing convergence events. An interface 75 of a router is also not reachable beyond the link boundaries, 76 therefore reducing the attack horizon. 78 We propose to configure neither globally routable IPv6 addresses nor 79 unique local addresses on infrastructure links of routers, wherever 80 possible. We recommend to use exclusively link-local addresses on 81 such links. 83 This document discusses the advantages and caveats of this approach. 85 Note: [I-D.ietf-ospf-prefix-hiding] describes another approach for 86 OPSFv2 and OSPFv3 by modifying the existing protocols while this 87 document does not modify any protocol but works only for IPv6. 89 1.1. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC2119 [RFC2119] when 94 they appear in ALL CAPS. These words may also appear in this 95 document in lower case as plain English words, absent their normative 96 meanings. 98 2. Using Link-Local Address on Infrastructure Links 100 This document proposes to use only link-local addresses (LLA) on all 101 router interfaces on infrastructure links. Routers typically do not 102 need to be reached from nodes of the network, nor from outside the 103 network. For an network operator there may be reasons to send 104 packets to an infrastructure link for certain monitoring tasks; many 105 of those tasks could also be handled differently, not requiring 106 routable address space on infrastructure links. 108 2.1. The Approach 110 Neither global IPv6 addresses nor unique local addresses are 111 configured on infrastructure links. In the absence of specific 112 global or unique local address definitions, the default behavior of 113 routers is to use link-local addresses notably for routing protocols. 115 These link-local addresses SHOULD be hard-coded to prevent the change 116 of EUI-64 addresses when changing of MAC address (such as after 117 changing a network interface card). 119 ICMPv6 [RFC4443] error messages (packet-too-big, time-exceeded...) 120 are required for routers, therefore a loopback interface MUST be 121 configured with an IPv6 address with a greater scope than link-local 122 (this will usually be a global scope). This greater-than-link scope 123 IPv6 address MUST be used as the source IPv6 address for all 124 generated ICMPv6 messages sent to a non-link-local address and MUST 125 belong to the operator to avoid being dropped by other routers 126 implementing [RFC3704]. 128 The effect on specific traffic types is as follows: 130 o Control plane protocols, such as BGP, ISIS, OSPFv3, RIPng, PIM 131 work by default or can be configured to work with link-local 132 addresses. 134 o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo 135 request ... can be addressed to loopback addresses of routers with 136 a greater than link-local scope address. Router management can 137 also be done over out-of-band channels. 139 o ICMP error message can also be sourced from the loopback address. 141 o Data plane traffic is forwarded independently of the link address 142 type. 144 o Neighbor discovery (neighbor solicitation and neighbor 145 advertisement) is done by using link-local unicast and multicast 146 addresses, therefore neighbor discovery is not affected. 148 We therefore conclude that it is possible to construct a working 149 network in this way. 151 2.2. Advantages 153 Smaller routing tables: Since the routing protocol only needs to 154 carry one loopback address per router, it is smaller than in the 155 traditional approach where every infrastructure link addresses are 156 carried in the routing protocol. This reduces memory consumption, 157 and increases the convergence speed in some routing failover cases 158 (notably because the Forwarding Information Base to be downloaded to 159 line cards are smaller but also because there are less prefixes in 160 the Routing Information Base hence accelerating the routing 161 algorithm). Note: smaller routing tables can also be achieved by 162 putting interfaces in passive mode for the IGP. 164 Reduced attack surface: Every routable address on a router 165 constitutes a potential attack point: a remote attacker can send 166 traffic to that address, for example a TCP SYN flood, or he can 167 intent SSH brute force password attacks. If a network only uses 168 loopback addresses for the routers, only those loopback addresses 169 need to be protected from outside the network. This significantly 170 eases protection measures, such as infrastructure access control 171 lists. See also [I-D.ietf-grow-private-ip-sp-cores] for further 172 discussion on this topic. 174 Lower configuration complexity: LLAs require no specific 175 configuration, thereby lowering the complexity and size of router 176 configurations. This also reduces the likelihood of configuration 177 mistakes. 179 Simpler DNS: Less greater-than-link-local address space in use also 180 means less DNS mappings to maintain because DNS is not really 181 suitable to contain link-local addresses as DNS has no clue to the 182 link scope. 184 2.3. Caveats and Possible Workarounds 186 Interface ping: If an interface doesn't have a routable address, it 187 can only be pinged from a node on the same link. Therefore it is not 188 possible to ping a specific link interface remotely. A possible 189 workaround is to ping the loopback address of a router instead. In 190 most cases today it is not possible to see which link the packet was 191 received on; however, RFC5837 [RFC5837] suggests to include the 192 interface identifier of the interface a packet was received on in the 193 ICMP response; it must be noted that there are little implemention of 194 this ICMP extension. With this approach it would be possible to ping 195 a router on the loopback address, yet see which interface the packet 196 was received on. To check liveliness of a specific interface it may 197 be necessary to use other methods, for example to connect to the 198 router via SSH and to check locally or use SNMP. 200 Traceroute: Similar to the ping case, a reply to a traceroute packet 201 would come from a loopback address with a greater than link-local 202 address. Today this does not display the specific interface the 203 packets came in on. Also here, RFC5837 [RFC5837] provides a 204 solution. 206 Hardware dependency: LLAs are usually EUI-64 based, hence, they 207 change when the MAC address is changed. This could pose problem in a 208 case where the routing neighbor must be configured explicitly (e.g. 209 BGP) and a line card needs to be physically replaced hence changing 210 the EUI-64 LLA and breaking the routing neighborship. But, LLAs can 211 be statically configured such as fe80::1 and fe80::2 which can be 212 used to configure any required static routing neighborship. 214 Network Management System (NMS) toolkits: If there is any NMS tool 215 that makes use of interface IP address of a router to carry out any 216 of NMS functions, then it would no longer work, if the interface is 217 missing routable address. A possible workaround for such tools is to 218 use the routable loopback address of the router instead. 220 MPLS and RSVP-TE [RFC3209] allows establishing MPLS LSP on a path 221 that is explicitly identified by a strict sequence of IP prefixes or 222 addresses (each pertaining to an interface or a router on the path). 223 This is commonly used for FRR. However, if an interface uses only a 224 link-local address, then such LSPs can not be established. A 225 possible workaround is to use loose sequence of IP prefixes or 226 addresses (each pertaining to a router) to identify an explicit path 227 along with shared-risk-link-group (to not use a set of common 228 interfaces). 230 2.4. Summary 232 Using link-local addressing only on infrastructure links has a number 233 of advantages, such as a smaller routing table size and a reduced 234 attack surface. It also simplifies router configurations. However, 235 the way certain network management tasks are carried out today has to 236 be adapted to provide the same level of detail, for example interface 237 identifiers in traceroute. 239 3. Security Considerations 241 Using LLAs only on infrastructure links reduces the attack surface of 242 a router: loopback addresses with routed addresses are still 243 reachable and must be secured, but infrastructure links can only be 244 attacked from the local link. This simplifies security of control 245 and management planes. The proposal does not impact the security of 246 the data plane. This proposal does not address control plane 247 [RFC6192] attacks generated by data plane packets (such as hop-limit 248 expiration or packets containing a hop-by-hop extension header). 250 As in the traditional approach, this approach relies on the 251 assumption that all routers can be trusted due to physical and 252 operational security. 254 4. IANA Considerations 256 There are no IANA considerations or implications that arise from this 257 document. 259 5. Acknowledgements 261 The authors would like to thank Salman Asadullah, Brian Carpenter, 262 Benoit Claise, Simon Eng, Wes George, Janos Mohacsi, Alvaro Retana 263 for their useful comments about this work. 265 6. References 267 6.1. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, March 1997. 272 6.2. Informative References 274 [I-D.ietf-grow-private-ip-sp-cores] 275 Kirkham, A., "Issues with Private IP Addressing in the 276 Internet", draft-ietf-grow-private-ip-sp-cores-07 (work in 277 progress), July 2012. 279 [I-D.ietf-ospf-prefix-hiding] 280 Yang, Y., Retana, A., and A. Roy, "Hiding Transit-only 281 Networks in OSPF", draft-ietf-ospf-prefix-hiding-05 (work 282 in progress), July 2012. 284 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 285 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 286 Tunnels", RFC 3209, December 2001. 288 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 289 Networks", BCP 84, RFC 3704, March 2004. 291 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 292 Addresses", RFC 4193, October 2005. 294 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 295 Message Protocol (ICMPv6) for the Internet Protocol 296 Version 6 (IPv6) Specification", RFC 4443, March 2006. 298 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 299 Rivers, "Extending ICMP for Interface and Next-Hop 300 Identification", RFC 5837, April 2010. 302 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 303 Router Control Plane", RFC 6192, March 2011. 305 Authors' Addresses 307 Michael Behringer 308 Cisco 309 400 Avenue Roumanille, Bat 3 310 Biot, 06410 311 France 313 Email: mbehring@cisco.com 315 Eric Vyncke 316 Cisco 317 De Kleetlaan, 6A 318 Diegem, 1831 319 Belgium 321 Email: evyncke@cisco.com