idnits 2.17.1 draft-chown-v6ops-rogue-ra-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 428. 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 Copyright Line does not match the current year -- 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 (July 14, 2008) is 5764 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '1') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '2') (Obsoleted by RFC 8415) == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-ra-guard-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Chown 3 Internet-Draft University of Southampton 4 Intended status: Informational S. Venaas 5 Expires: January 15, 2009 UNINETT 6 July 14, 2008 8 Rogue IPv6 Router Advertisement Problem Statement 9 draft-chown-v6ops-rogue-ra-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 15, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 When deploying IPv6 networks, whether IPv6-only or dual-stack, 43 routers are configured to use IPv6 Router Advertisements to convey 44 information to on link nodes that enable them to autoconfigure on the 45 network. This information includes the implied default router 46 address taken from the observed source address of the Router 47 Advertisement (RA) message. However, in some networks 'bogus' RAs 48 are observed, which may be present due to misconfigurations or 49 possibly malicious attacks on the network. In this draft we 50 summarise the scenarios in which rogue RAs may be observed, and we 51 present a list of possible solutions to the problem. The goal of 52 this draft is to present a framework around which solutions can be 53 proposed and discussed. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Bogus RA Scenarios . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Administrator misconfiguration . . . . . . . . . . . . . . 3 60 2.2. User misconfiguration . . . . . . . . . . . . . . . . . . 4 61 2.3. Malicious misconfiguration . . . . . . . . . . . . . . . . 4 62 3. Methods to Mitigate against Rogue RAs . . . . . . . . . . . . 4 63 3.1. Manual configuration . . . . . . . . . . . . . . . . . . . 4 64 3.2. Secure Neighbor Discovery . . . . . . . . . . . . . . . . 4 65 3.3. Introduce RA snooping . . . . . . . . . . . . . . . . . . 5 66 3.4. Use the Router Preference Option . . . . . . . . . . . . . 5 67 3.5. Rely on Layer 2 admission control . . . . . . . . . . . . 5 68 3.6. Use host-based packet filters . . . . . . . . . . . . . . 5 69 3.7. Use an 'intelligent' deprecation tool . . . . . . . . . . 6 70 3.8. Wait before using new advertisements . . . . . . . . . . . 6 71 3.9. Add a Default Gateway Option to DHCPv6 . . . . . . . . . . 6 72 4. Other considerations . . . . . . . . . . . . . . . . . . . . . 7 73 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 77 9. Informative References . . . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 Intellectual Property and Copyright Statements . . . . . . . . . . 10 81 1. Introduction 83 The Neighbor Discovery protocol [6] describes the operation of IPv6 84 Router Advertisements (RAs), which are used during the IPv6 85 autoconfiguration process, whether stateful (via DHCPv6 [1] or DHCPv6 86 Light [2]) or stateless (as per RFC4862 [7]). In either case, the 87 default router address is drawn directly from the source address of 88 the RA message. In contrast to IPv4, there is no DHCPv6 option to 89 configure a default gateway address. 91 In observing the operation of deployed IPv6 networks, it is apparent 92 that there is a problem with undesired or 'bogus' IPv6 Router 93 Advertisements (RAs) appearing on network links or subnets. By 94 'bogus' we mean RAs that were not the intended configured RAs, rather 95 RAs that have appeared for some other reason. 97 The problem with rogue RAs is that they can cause partial or complete 98 failure of operation on an IPv6 link. As such they are an 99 operational issue for which solution(s) are required, and for which 100 best practice needs to be conveyed. 102 In the next section, we discuss the scenarios that may give rise to 103 rogue RAs being present. In the following section we present some 104 candidate solutions for the problem, some of which may be more 105 practical to deploy than others. 107 2. Bogus RA Scenarios 109 There are three broad classes of scenario in which bogus RAs may be 110 introduced to an IPv6 network. 112 2.1. Administrator misconfiguration 114 Here an administrator incorrectly configures RAs on a router 115 interface, causing incorrect RAs to appear on links and hosts to 116 generate incorrect IPv6 address or other information. In this case 117 the default gateway may be correct, but a host might for example 118 become multi-addressed, possibly with a correct and incorrect address 119 based on a correct and incorrect prefix. There is also the 120 possibility of bad lifetime information being configured. 122 In the case of a Layer 2 VLAN misconfiguration, RAs may 'flood' to 123 unintended links, causing hosts or more than one link to potentially 124 become incorrectly multiaddressed, with possibly two different 125 default routers available. 127 2.2. User misconfiguration 129 In this case a user's device 'accidentally' transmits RAs onto the 130 local link, adding an addition default gateway and prefix 131 information. This is typically seen on wireless (though sometimes 132 wired) networks where a laptop has been used as a home gateway (e.g. 133 a 6to4 gateway) and has then been attached to another network with 134 the gateway configuration still active. A not infrequent cause here 135 is the Windows Internet Connection Sharing service (ICS) which turns 136 a host into a 6to4 gateway; this can be a useful feature, unless it 137 is run when not intended. We have had reports that hosts may not see 138 the genuine RAs on link due to host firewalls, and then turning on a 139 connection sharing service and 6to4 as a result. 141 There are also reported incidents in enterprise networks of users 142 physically plugging Ethernet cables into the wrong sockets and 143 bridging two subnets together, causing an problem similar to VLAN 144 flooding. 146 2.3. Malicious misconfiguration 148 Here an attacker is deliberately generating RAs on the local network 149 in an attempt to perform some form of denial of service or man-in- 150 the-middle attack. 152 3. Methods to Mitigate against Rogue RAs 154 In this section we present a summary of methods suggested to date for 155 reducing or removing the possibility of rogue RAs being seen on a 156 network. 158 3.1. Manual configuration 160 The default gateway can usually be manually configured on a device. 161 This is of course a resource intensive solution, and also prone to 162 mistakes in itself. 164 3.2. Secure Neighbor Discovery 166 The SEND [3] protocol provides a method for hosts and routers to 167 perform secure Neighbor Discovery. At present there are very few 168 SEND implementations available, and SEND is perceived as a complex 169 protocol to deploy. It is also likely that not all scenarios will be 170 able to use SeND, for various reasons. 172 3.3. Introduce RA snooping 174 It should be possible to implement 'RA snooping' in Layer 2 switches 175 in a similar way to DHCP snooping, such that RAs observed from 176 incorrect sources are blocked or dropped, and not propagated through 177 a subnet. One candidate solution in this space called RA-Guard [8] 178 has recently been proposed. This type of solution has appeal because 179 it is a familiar model for enterprise network managers, but it can 180 also be used to complement SeND. 182 It is interesting to note that the Windows ICS that runs a 6to4 183 gateway also starts an IPv4 DHCP service, so any snooping solution is 184 mitigating against both these issues. 186 This type of solution may not be applicable everywhere, e.g. in 187 environments where there are not centrally controlled switches. 189 3.4. Use the Router Preference Option 191 RFC4191 [4] introduced router preference options, such that an RA 192 could carry one of three router preference values: High, Medium 193 (default) or Low. Thus an administrator could use High settings for 194 managed RAs, and hope that 'accidental' RAs would be medium priority, 195 and that hosts implemented this optional protocol. 197 3.5. Rely on Layer 2 admission control 199 In principle, if a technology such as IEEE 802.1x is used, devices 200 would first need to authenticate to the network before being able to 201 send or receive IPv6 traffic. Ideally authentication would be 202 mutual. This may mitigate against a malicious attacker, but doesn't 203 address the misconfiguration issues. 205 3.6. Use host-based packet filters 207 In a managed environment hosts could be configured via their 208 'personal firewall' to only accept RAs from trusted sources. 209 However, the problem is then pushed to keeping this configuration 210 maintained and correct. If a router fails and is replaced, possibly 211 with a new Layer 2 interface address, the link local source address 212 in the filter may be incorrect and no network exists to push the new 213 information to the host. 215 Also, hosts could potentially be configured to discard 6to4-based RAs 216 in a managed enterprise environment. 218 3.7. Use an 'intelligent' deprecation tool 220 It could be possible to run a daemon on a link (perhaps on the router 221 on the link) to watch for incorrect RAs and to send a deprecating RA 222 with router lifetime of zero when such an RA is observed. The KAME 223 rafixd is an example of such a tool, which has been used at IETF 224 meetings with some success. Whether or not such a tool is the 225 preferred method, monitoring a link for observed RAs seems prudent 226 from a network management perspective. Some such tools exist 227 already, e.g. ndpmon. 229 3.8. Wait before using new advertisements 231 It might be possible, in generally static networks, to configure an 232 option such that any new RAs that are seen are not acted upon for a 233 certain period, e.g. 2 hours. This might allow time for a 234 misconfiguration or accidental RA to be detected and stopped, before 235 hosts use the data in the RA. Of course this would add delays where 236 genuine new RAs are required, while new hosts appearing on a network 237 would still be vulnerable (or be unable to configure at all). 239 3.9. Add a Default Gateway Option to DHCPv6 241 It may be possible to define a new Default Gateway Option for DHCPv6 242 that would allow network administrators to only have hosts use DHCPv6 243 for default gateway configuration in managed networks. While such an 244 option could be defined, its ramifications remain unclear. In the 245 absence of RAs, other configuration information would also be 246 missing, e.g. on-link prefix information. Of course, it may be that 247 an RA is still required to inform the host to use DHCPv6, and that 248 may introduce a Catch-22 unless hosts are configured directly to only 249 use DHCPv6. 251 An advantage of DHCPv6 is that should an error be introduced, only 252 hosts that have refreshed their DHCP information since that time are 253 affected, while a rogue RA will most likely affect all hosts 254 immediately. DHCPv6 also allows different answers to be given to 255 different hosts. 257 One objection to introducing such an option is that DHCPv6 in itself 258 is not a secure protocol, and it is also of course subject to 259 misconfigurations, accidental or otherwise. Comparing the threat 260 model for rogue RAs and rogue DHCPv6 servers is an interesting 261 exercise in itself. Use of Authenticated DHCP is currently minimal 262 and thus the (lack of) security is just pushed to another place, 263 albeit one that site administrators are more familiar and (rightly or 264 wrongly) comfortable with. 266 4. Other considerations 268 There are other general observations that have been made. 270 One is that it would generally be prudent for network monitoring or 271 management platforms to be able to observe and report on observed 272 RAs, and whether unintended RAs (possibly from unintended sources) 273 are present on a network. Further, it may be useful for individual 274 hosts to be able to report their address status, e.g. this could be 275 useful during an IPv6 renumbering phased process as described in 276 RFC4192 [5]. 278 The second is how readily a host can recover from bad configuration 279 information, e.g. considering the '2 hour rule' of Section 5.5.3 of 280 RFC4862 (though this applies to the prefix lifetime not the router 281 lifetime). We should ensure that methods exist for a network 282 administrator to correct bad configuration information on a link or 283 subnet, and that OS platforms support these methods. At least if the 284 problem can be detected, and corrected promptly, the impact is 285 minimised. 287 A comment has been made that in the case of 6to4 being run by a host 288 on a subnet that is not administratively configured with IPv6, some 289 OSes or applications may begin using IPv6 to the 6to4 host (router) 290 rather than IPv4 to the intended default IPv4 router. Mitigating 291 against this condition can also be seen to be important. 293 5. Conclusions 295 In this text we have described scenarios via which rogue Router 296 Advertisements (RAs) may appear on a network, and some measures that 297 could be used to mitigate against these. 299 While SEND perhaps offers the most robust solution, implementations 300 are not widely available, and the solution is perceived as complex 301 (parallels can possibly be drawn with Authenticated DHCP in terms of 302 likely deployment). Adding a new DHCPv6 Default Gateway Option would 303 allow configuration by DHCP, and be a method that IPv4 administrators 304 are comfortable with (for better or worse), but such an option would 305 have significant impacts elsewhere, and in any event one must 306 recognise that the security risk is then simply shifted elsewhere. 308 Further feedback on the solutions is certainly welcome. In the 309 meantime, perhaps the simplest initial step would be for RA snooping 310 to be defined and deployed for Layer 2 devices, in such a way that 311 can address (shared) wireless as well as wired networks. One draft 312 proposal in this space, RA-Guard, has recently been published [8]. 314 Alternatively, certain switch platforms can already implement a form 315 of snooping by the administrator configuring Access Control Lists 316 (ACLs) that block RA ICMP messages that might be inbound on 'user' 317 ports. A cleaner solution is desirable though. 319 This topic has also highlighted that some DHCPv6 on-link prefix 320 option may be useful for some scenarios, caused in part by the change 321 of the 'default on-link' rule. This should be seen as independent of 322 whether DHCPv6 is extended to add a Default Gateway Option, which is 323 another open question at this time. 325 The material presented here is relevant to the IETF dhc and v6ops 326 working groups, but the text is labeled as v6ops due to its 327 operational issue focus. Should new DHCP features be defined as a 328 result, we assume these would be presented within the dhc working 329 group. 331 6. Security Considerations 333 There are no extra Security consideration for this document. 335 7. IANA Considerations 337 There are no extra IANA consideration for this document. 339 8. Acknowledgments 341 Thanks are due to members of the IETF IPv6 Operations and DHCP WGs 342 for their inputs on this topic, including but not limited to Iljitsch 343 van Beijnum, David Malone, Tony Hain, Christian Huitema, Remi Denis- 344 Courmant, Chip Popoviciu, Dave Thaler and Tatuya Jinmei. 346 9. Informative References 348 [1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 349 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 350 RFC 3315, July 2003. 352 [2] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) 353 Service for IPv6", RFC 3736, April 2004. 355 [3] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 356 Neighbor Discovery (SEND)", RFC 3971, March 2005. 358 [4] Draves, R. and D. Thaler, "Default Router Preferences and More- 359 Specific Routes", RFC 4191, November 2005. 361 [5] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering 362 an IPv6 Network without a Flag Day", RFC 4192, September 2005. 364 [6] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor 365 Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 367 [7] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address 368 Autoconfiguration", RFC 4862, September 2007. 370 [8] Van de Velde, G., Levy-Abegnoli, E., Popoviciu, C., and J. 371 Mohacsi, "IPv6 RA-Guard (draft-ietf-v6ops-ra-guard-00)", 372 July 2008. 374 Authors' Addresses 376 Tim Chown 377 University of Southampton 378 Southampton, Hampshire SO17 1BJ 379 United Kingdom 381 Email: tjc@ecs.soton.ac.uk 383 Stig Venaas 384 UNINETT 385 Trondheim NO 7465 386 Norway 388 Email: venaas@uninett.no 390 Full Copyright Statement 392 Copyright (C) The IETF Trust (2008). 394 This document is subject to the rights, licenses and restrictions 395 contained in BCP 78, and except as set forth therein, the authors 396 retain all their rights. 398 This document and the information contained herein are provided on an 399 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 400 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 401 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 402 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 403 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 404 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 406 Intellectual Property 408 The IETF takes no position regarding the validity or scope of any 409 Intellectual Property Rights or other rights that might be claimed to 410 pertain to the implementation or use of the technology described in 411 this document or the extent to which any license under such rights 412 might or might not be available; nor does it represent that it has 413 made any independent effort to identify any such rights. Information 414 on the procedures with respect to rights in RFC documents can be 415 found in BCP 78 and BCP 79. 417 Copies of IPR disclosures made to the IETF Secretariat and any 418 assurances of licenses to be made available, or the result of an 419 attempt made to obtain a general license or permission for the use of 420 such proprietary rights by implementers or users of this 421 specification can be obtained from the IETF on-line IPR repository at 422 http://www.ietf.org/ipr. 424 The IETF invites any interested party to bring to its attention any 425 copyrights, patents or patent applications, or other proprietary 426 rights that may cover technology that may be required to implement 427 this standard. Please address the information to the IETF at 428 ietf-ipr@ietf.org. 430 Acknowledgment 432 Funding for the RFC Editor function is provided by the IETF 433 Administrative Support Activity (IASA).