idnits 2.17.1 draft-ietf-opsec-lla-only-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 17, 2012) is 4242 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Behringer 3 Internet-Draft E. Vyncke 4 Intended status: Informational Cisco 5 Expires: February 18, 2013 August 17, 2012 7 Using Only Link-Local Addressing Inside an IPv6 Network 8 draft-ietf-opsec-lla-only-00 10 Abstract 12 This document proposes to use only IPv6 link-local addresses on 13 infrastructure links between routers, wherever possible. It 14 discusses the advantages and disadvantages of this approach to aide 15 the decision 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 February 18, 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 2. Using Link-Local Address on Infrastructure Links . . . . . . . 3 54 2.1. The Suggested Approach . . . . . . . . . . . . . . . . . . 3 55 2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Caveats and Possible Workarounds . . . . . . . . . . . . . 5 57 2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 An infrastructure link between a set of routers typically does not 69 require global or even unique local addressing [RFC4193]. Using 70 link-local addressing on such links has a number of advantages, for 71 example that routing tables do not need to carry link addressing, and 72 can therefore be significantly smaller. This helps to decrease 73 failover times in certain routing convergence events. An interface 74 of a router is also not reachable beyond the link boundaries, 75 therefore reducing the attack horizon. 77 We propose to configure neither globally routable IPv6 addresses nor 78 unique local addresses on infrastructure links of routers, wherever 79 possible. We recommend to use exclusively link-local addresses on 80 such links. 82 This document discusses the advantages and caveats of this approach. 84 1.1. Requirements Language 86 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 87 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 88 described in RFC2119 [RFC2119]. 90 2. Using Link-Local Address on Infrastructure Links 92 This document proposes to use only link-local addresses (LLA) on all 93 router interfaces on infrastructure links. Routers typically do not 94 need to be reached from from users of the network, nor from outside 95 the network. For an network operator there may be reasons to send 96 packets to an infrastructure link for certain monitoring tasks; we 97 suggest that many of those tasks could also be handled differently, 98 not requiring routable address space on infrastructure links. 100 2.1. The Suggested Approach 102 Neither global IPv6 addresses nor unique local addresses are 103 configured on infrastructure links. In the absence of specific 104 global or unique local address definitions, the default behavior of 105 routers is to use link-local addresses. These link-local addresses 106 MAY be hard-coded to prevent the change of EUI-64 addresses when 107 changing of MAC address (such as after changing a network interface 108 card). 110 ICMPv6 [RFC4443] error messages (packet-too-big...) are required for 111 routers, therefore a loopback interface MUST be configured with a 112 global scope IPv6 address. This global scope IPv6 address MUST be 113 used as the source IPv6 address for all generated ICMPv6 messages. 115 The effect on specific traffic types is as follows: 117 o Control plane protocols, such as BGP, ISIS, OSPFv3, RIPng, PIM 118 work by default or can be configured to work with link-local 119 addresses. 121 o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo 122 request ... can be addressed to loopback addresses of routers with 123 a global scope address. Router management can also be done over 124 out-of-band channels. 126 o IICMP error message can also be sourced from the global scope 127 loopback address. 129 o Data plane traffic is forwarded independently of the link address 130 type. 132 o Neighbor discovery (neighbor solicitation and neighbor 133 advertisement) is done by using link-local unicast and multicast 134 addresses, therefore neighbor discovery is not affected. 136 We therefore conclude that it is possible to construct a working 137 network in this way. 139 2.2. Advantages 141 Smaller routing tables: Since the routing protocol only needs to 142 carry one loopback address per router, it is smaller than in the 143 traditional approach where every infrastructure link addresses are 144 carried in the routing protocol. This reduces memory consumption, 145 and increases the convergence speed in some routing failover cases. 146 Note: smaller routing tables can also be achieved by putting 147 interfaces in passive mode for the IGP. 149 Reduced attack surface: Every globally 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, or he can 152 intent SSH brute force password attacks. If a network only uses 153 loopback addresses for the routers, only those loopback addresses 154 need to be protected from outside the network. This significantly 155 eases protection measures, such as infrastructure access control 156 lists. See also [I-D.ietf-grow-private-ip-sp-cores] for further 157 discussion on this topic. 159 Lower configuration complexity: LLAs require no specific 160 configuration, thereby lowering the complexity and size of router 161 configurations. This also reduces the likelihood of configuration 162 mistakes. 164 Simpler DNS: Less address space in use also means less DNS mappings 165 to maintain. 167 2.3. Caveats and Possible Workarounds 169 Interface ping: If an interface doesn't have a globally routable 170 address, it can only be pinged from a node on the same link. 171 Therefore it is not possible to ping a specific link interface 172 remotely. A possible workaround is to ping the loopback address of a 173 router instead. In most cases today it is not possible to see which 174 link the packet was received on; however, RFC5837 [RFC5837] suggests 175 to include the interface identifier of the interface a packet was 176 received on in the ICMP response; it must be noted that there are 177 little implemented of this extension. With this approach it would be 178 possible to ping a router on the loopback address, yet see which 179 interface the packet was received on. To check liveliness of a 180 specific interface it may be necessary to use other methods, for 181 example to connect to the router via SSH and to check locally. 183 Traceroute: Similar to the ping case, a reply to a traceroute packet 184 would come from a loopback address with a global address. Today this 185 does not display the specific interface the packets came in on. Also 186 here, RFC5837 [RFC5837] provides a solution. 188 Hardware dependency: LLAs are usually EUI-64 based, hence, they 189 change when the MAC address is changed. This could pose problem in a 190 case where the routing neighbor must be configured explicitly (e.g. 191 BGP) and a line card needs to be physically replaced hence changing 192 the EUI-64 LLA and breaking the routing neighborship. But, LLAs can 193 be statically configured such as fe80::1 and fe80::2 which can be 194 used to configure any required static routing neighborship. 196 NMS toolkits: If there is any NMS tool that makes use of interface IP 197 address of a router to carry out any of NMS functions, then it would 198 no longer work, if the interface is missing globally routable 199 address. A possible workaround for such tools is to use the globally 200 routable lopback address of the router instead. 202 MPLS and RSVP-TE [RFC3209] allows establishing MPLS LSP on a path 203 that is explicitly identified by a strict sequence of IP prefixes or 204 addresses (each pertaining to an interface or a router on the path). 205 This is commonly used for FRR. However, if an interface uses only a 206 link-local address, then such LSPs can not be established. A 207 possible workaround is to use loose sequence of IP prefixes or 208 addresses (each pertaining to a router) to identify an explicit path 209 along with shared-risk-link-group (to not use a set of common 210 interfaces). 212 2.4. Summary 214 Using link-local addressing only on infrastructure links has a number 215 of advantages, such as a smaller routing table size and a reduced 216 attack surface. It also simplifies router configurations. However, 217 the way certain network management tasks are carried out has to be 218 adapted to provide the same level of detail, for example interface 219 identifiers in traceroute. 221 3. Security Considerations 223 Using LLAs only on infrastructure links reduces the attack surface of 224 a router: Loopback addresses with globally routed addresses are still 225 reachable and must be secured, but infrastructure links can only be 226 attacked from the local link. This simplifies security of control 227 and management planes. The proposal does not impact the security of 228 the data plane. This proposal does not address control plane 229 [RFC6192] attacks generated by data plane packets (such as hop-limit 230 expiration). 232 As in the traditional approach, also this approach relies on the 233 assumption that all routers can be trusted due to physical and 234 operational security. 236 4. IANA Considerations 238 There are no IANA considerations or implications that arise from this 239 document. 241 5. Acknowledgements 243 The authors would like to thank Salman Asadullah, Janos Mohacsi and 244 Wes George for their useful comments about this work. 246 6. References 248 6.1. Normative References 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, March 1997. 253 6.2. Informative References 255 [I-D.ietf-grow-private-ip-sp-cores] 256 Kirkham, A., "Issues with Private IP Addressing in the 257 Internet", draft-ietf-grow-private-ip-sp-cores-07 (work in 258 progress), July 2012. 260 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 261 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 262 Tunnels", RFC 3209, December 2001. 264 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 265 Addresses", RFC 4193, October 2005. 267 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 268 Message Protocol (ICMPv6) for the Internet Protocol 269 Version 6 (IPv6) Specification", RFC 4443, March 2006. 271 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. 272 Rivers, "Extending ICMP for Interface and Next-Hop 273 Identification", RFC 5837, April 2010. 275 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 276 Router Control Plane", RFC 6192, March 2011. 278 Authors' Addresses 280 Michael Behringer 281 Cisco 282 400 Avenue Roumanille, Bat 3 283 Biot, 06410 284 France 286 Email: mbehring@cisco.com 288 Eric Vyncke 289 Cisco 290 De Kleetlaan, 6A 291 Diegem, 1831 292 Belgium 294 Email: evyncke@cisco.com