idnits 2.17.00 (12 Aug 2021) /tmp/idnits17182/draft-ietf-v6ops-ra-guard-08.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 02, 2010) is 4272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4158' is defined on line 357, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group E. Levy-Abegnoli 3 Internet-Draft G. Van de Velde 4 Intended status: Informational C. Popoviciu 5 Expires: March 6, 2011 Cisco Systems 6 J. Mohacsi 7 NIIF/Hungarnet 8 September 02, 2010 10 IPv6 Router Advertisement Guard 11 13 Abstract 15 Routed protocols are often susceptible to spoof attacks. The 16 canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a 17 solution that is non-trivial to deploy. This document proposes a 18 light-weight alternative and complement to SEND based on filtering in 19 the layer-2 network fabric, using a variety of filtering criteria, 20 including, for example, SEND status. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 6, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Model and Applicability . . . . . . . . . . . . . . . . . . . 4 70 3. Stateless RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Stateful RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 7 73 4.2. SEND-based RA-Guard . . . . . . . . . . . . . . . . . . . 8 74 5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . 9 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 When operating IPv6 in a shared L2 network segment without complete 86 SEND support by all devices connected or without the availability of 87 the infrastructure necessary to support Secure Neighbor Discovery 88 (SEND) [RFC3971], there is always the risk of facing operational 89 problems due to rogue Router Advertisements generated maliciously or 90 unintentionally by unauthorized or improperly configured routers 91 connecting to the segment. 93 There are several examples of work done on this topic which resulted 94 in several related studies [reference1] [reference2] 95 [reference3].This document describes a solution framework for the 96 rogue-RA problem where network segments are designed around a single 97 or a set of L2-switching devices capable of identifying invalid RAs 98 and blocking them. The solutions developed within this framework can 99 span the spectrum from basic (where the port of the L2 device is 100 statically instructed to forward or not to forward RAs received from 101 the connected device) to advanced (where a criteria is used by the L2 102 device to dynamically validate or invalidate a received RA, this 103 criteria can even be based on SEND mechanisms). 105 2. Model and Applicability 107 RA-Guard applies to an environment where all messages between IPv6 108 end-devices traverse the controlled L2 networking devices. It does 109 not apply to a shared media, when devices can communicate directly 110 without going through an RA-Guard capable L2 networking device. 112 Figure 1 illustrates a deployment scenario for RA-Guard. 114 Block Allow 115 +------+ incoming +---------+ incoming +--------+ 116 |Host | RA | L2 | RA | Router | 117 | |----------------| device |--------------| | 118 +------+ +----+----+ +--------+ 119 | 120 |Block 121 |incoming 122 |RA 123 | 124 | 125 | 126 +---+---+ 127 | Host | 128 | | 129 +-------+ 131 Figure 1 133 RA-Guard does not intend to provide a substitute for SEND based 134 solutions. It actually intends to provide complementary solutions in 135 those environments where SEND might not be suitable or fully 136 supported by all devices involved. It may take time until SEND is 137 ubiquitous in IPv6 networks and some of its large scale deployment 138 aspects are sorted out such as provisioning hosts with trust anchors. 139 It is also reasonable to expect that some devices might not consider 140 implementing SEND at all such as IPv6 enabled sensors. An RA-Guard 141 implementation which SEND-validates RAs on behalf of hosts would 142 potentially simplify some of these challenges. 144 RA-Guard can be seen as a superset of SEND with regard to router 145 authorization. Its purpose is to filter Router Advertisements based 146 on a set of criteria, from a simplistic "RA disallowed on a given 147 interface" to "RA allowed from pre-defined sources" and up to full 148 fledge SEND "RA allowed from authorized sources only". 150 In addition to this granularity on the criteria for filtering out 151 Router Advertisements, RA-Guard introduces the concept of router 152 authorization proxy. Instead of each node on the link analyzing RAs 153 and making an individual decision, a legitimate node-in-the-middle 154 performs the analysis on behalf of all other nodes on the link. The 155 analysis itself is not different from what each node would do: if 156 SEND is enabled, the RA is checked against X.509 certificates 157 [RFC4861]. If any other criteria is in use, such as known L3 158 (addresses) or L2 (link-layer address, port number) legitimate 159 sources of RAs, the node-in-the middle can use this criteria and 160 filter out any RA that does not comply. If this node-in-the-middle 161 is a L2 device, it will not change the content of the validated RA, 162 and avoid any of the ND-proxy pitfalls. 164 RA-Guard intends to provide simple solutions to the rogue-RA problem 165 in contexts where simplicity is required while leveraging SEND in an 166 context environment consisting of with a mix of SEND capable devices 167 (L2 switches and routers) and devices that do not consistently use 168 SEND. Furthermore, RA-Guard is useful to simplify SEND deployments, 169 as only the L2 switch and the routers are required to carry 170 certificates (their own and the trust anchor certificates). 172 3. Stateless RA-Guard 174 Stateless RA-Guard examines incoming RAs and decide whether to 175 forward or block them based solely on information found in the 176 message or in the L2-device configuration. Typical information 177 available in the frames received, useful for RA validation is: 179 o Link-layer address of the sender 180 o Port on which the frame was received 181 o IP source address 182 o Prefix list 184 The following configuration information created on the L2-device can 185 be made available to RA-Guard, to validate against the information 186 found in the received RA frame: 188 o Allowed/Disallowed link-layer address of RA-sender 189 o Allowed/Disallowed ports for receiving RAs 190 o Allowed/Disallowed IP source addresses of RA-sender 191 o Allowed Prefix list and Prefix ranges 192 o Router Priority 194 Once the L2 device has validated the content of the RA frame against 195 the configuration, it forwards the RA to destination, whether unicast 196 or multicast. Otherwise, the RA is dropped. 198 An example of a very simple stateless RA-Guard implementation could 199 be a small L2-switch for which there is one interface "statically- 200 configured" as the interface connecting to a router, while all other 201 interfaces are for non-router devices. With his small static setup 202 the only interface forwarding RAs will be the pre-assigned router 203 interface, while the non-router interfaces block all RAs. 205 4. Stateful RA-Guard 206 4.1. State Machine 208 Stateful RA-Guard learns dynamically about legitimate RA senders, and 209 store this information for allowing subsequent RAs. A simple 210 stateful scheme would be for the L2-device to listen to RAs during a 211 certain manual determined period of time, where the start of the 212 listening-period and the duration of the listening-period for a 213 single instance is controled by the manual intervention. As result 214 the L2-device can then allow subsequent RAs only on those ports on 215 which valid RAs were received during this period. Often the LEARNING 216 state will only be activated by manual configuration when a new IPv6 217 router is provisioned on the L2-network. 219 A more sophisticated stateful scheme is based on SEND, and is 220 described in Section 4.2. 222 The state machine for stateful RA-Guard can be global, per-interface, 223 or per-peer, depending on the scheme used for authorizing RAs. 225 When RA-Guard is SEND-based, the state machine is per-peer and 226 defined in [RFC3971]. 228 When RA-Guard is using a discovery method, the state-machine of the 229 RA-Guard capability consists of four different states: 231 o State 1: OFF 232 A device or interface in RA-Guard "OFF" state, operates as if 233 the RA-Guard capability is not available. 234 o State 2: LEARNING 235 A device or interface in the RA-Guard "Learning" state is 236 actively acquiring information about the IPv6 routing devices 237 connected. The learning process takes place over a pre-defined 238 unique period in time, set by manual configuration or it can be 239 event triggered. The information gathered is compared against 240 pre-defined criteria; criteria similar as the stateless RA- 241 Guard rules to qualify the validity of the RAs. 242 In this state, the RA-Guard enabled device or interface is 243 either blocking "all" RAs until their validity is verified or, 244 alternatively it can temporarily forward "all" the RAs until 245 their validity is verified. 246 Once the L2-device has identified through "Learning" the valid 247 IPv6 routers and hence also identified the valid RAs, it 248 transtions each interface from "LEARNING" into either BLOCKING 249 state if there was no valid IPv6 router discovered at the 250 interface, or transitions the interface into FORWARDING state 251 if there was a valid IPv6 router discovered. 253 o State 3: BLOCKING 254 A device or interface running RA-Guard and in Blocking state 255 will block ingress RA-messages. 256 An interface can transition from BLOCKING state into FORWARDING 257 state directly if explicitly instructed by the L2-device 258 operator. 259 An interface can transition from BLOCKING state into LEARNING 260 state if either explicitly told by the L2-device operator or by 261 a triggered event. 262 o State 4: FORWARDING 263 A device or interface running RA-Guard and in Forwarding state 264 will accept valid ingress RAs and forward them to their 265 destination. 266 An interface can transition from FORWARDING state into BLOCKING 267 state directly if explicitly instructed by the L2-device 268 operator. 269 An interface can transition from FORWARDING state into LEARNING 270 state if either explicitly told by the L2-device operator or by 271 a triggered event. 273 The transition between these states can be triggered by manual 274 configuration or by meeting a pre-defined criteria. 276 4.2. SEND-based RA-Guard 278 In this scenario, the L2 device is blocking or forwarding RAs based 279 on SEND considerations. Upon capturing an RA on the interface, the 280 L2-device will first verify the Cryptographically Generated Addresses 281 (CGA) [RFC3971] address and the RSA (Rivest, Shamir and Adleman 282 algorithm for public-key cryptography) signature, as specified in 283 section 5 of [RFC3971]. RA should be dropped in case of failure of 284 this verification. It will then apply host behavior as described in 285 section 6.4.6 of [RFC3971]. In particular, the L2 device will 286 attempt to retrieve a valid certificate from its cache for the public 287 key referred to in the RA. If such certificate is found, the L2 288 device will forward the RA to destination. If not, the L2 device 289 will generate a Certification Path Solicitation (CPS) [RFC3971], 290 sourced with UNSPECIFIED address, to query the router certificate(s). 291 It will then capture the Certification Path Advertisements (CPA) 292 [RFC3971], and attempt to validate the certificate chain. Failure to 293 validate the chain will result in dropping the RA. Upon validation 294 success, the L2 device will forward the RA to destination and and 295 store the router certificate in its cache. 297 In order to operate in this scenario, the L2-device should be 298 provisioned with a trust anchor certificate, as specified in section 299 6 of [RFC3971]. It may also establish a layer-3 connectivity with a 300 Certificate Revocation List (CRL) Certification Path Advertisement 301 server and/or with and NTP server. Bootstrapping issue in this case 302 can be resolved by using the configuration method to specify a 303 trusted port to a first router, and SEND-based RA-Guard method on all 304 other ports. The first router can then be used for Network Time 305 Protocol (NTP) [RFC5905] and CRL connectivity. 307 5. RA-Guard Use Considerations 309 The RA-Guard mechanism is effective only when all messages between 310 IPv6 devices in the target environment traverse controlled L2 311 networking devices. In the case of environments such as Ethernet 312 hubs, devices can communicate directly without going through an RA- 313 Guard capable L2 networking device, the RA-Guard feature cannot 314 protect against rogue-RAs. 316 RA-Guard mechanisms do not offer protection in environments where 317 IPv6 traffic is tunneled. 319 6. IANA Considerations 321 There are no extra IANA consideration for this document. 323 7. Security Considerations 325 Once RA-Guard has setup the proper criteria, for example, it 326 identified that a port is allowed to receive RAs, or it identified 327 legitimate sources of RA, or certificate base [RFC4861], then there 328 is no possible instances of accidently filtered legitimate Router 329 advertisements assuming the RA-Guard filter enforcement follows 330 strictly the RA-Guard set criteria. 332 in Section 4.1 a simple mechanism to learn dynamical the valid IPv6 333 routers connected to a L2-device is explained. It is important that 334 this LEARN state is only entered intentionally by manual 335 configuration. The list of learned IPv6 routers should be verified 336 by the network manager to make sure that it corresponds with the 337 expected valid RA list. This procedure will make sure that either 338 accidently or intentionally rogue RAs are blocked by RA-guard. 340 8. Acknowledgements 342 The authors dedicate this document to the memory of Jun-ichiro Hagino 343 (itojun) for his contributions to the development and deployment of 344 IPv6. 346 9. References 348 9.1. Normative References 350 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 351 Neighbor Discovery (SEND)", RFC 3971, March 2005. 353 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 354 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 355 September 2007. 357 [RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R. 358 Nicholas, "Internet X.509 Public Key Infrastructure: 359 Certification Path Building", RFC 4158, September 2005. 361 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 362 Time Protocol Version 4: Protocol and Algorithms 363 Specification", RFC 5905, June 2010. 365 9.2. Informative References 367 [reference1] 368 LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol 369 Monitor (http://ndpmon.sourceforge.net/)", November 2007. 371 [reference2] 372 KAME Project, "rafixd - developed at KAME - An active 373 rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/ 374 kame/kame/kame/rafixd/)", November 2007. 376 [reference3] 377 Hagino (itojun), Jun-ichiro., "Discussion of the various 378 solutions (http://ipv6samurais.com/ipv6samurais/ 379 demystified/rogue-RA.html)", 2007. 381 [reference4] 382 Chown, Tim. and Stig. Venaas, "Rogue IPv6 Router 383 Advertisement Problem (draft-ietf-v6ops-rogue-ra-00.txt)", 384 May 2009. 386 Authors' Addresses 388 Eric Levy Abegnoli 389 Cisco Systems 390 Village d'Entreprises Green Side - 400, Avenue Roumanille 391 Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410 392 France 394 Phone: +33 49 723 2620 395 Email: elevyabe@cisco.com 397 Gunter Van de Velde 398 Cisco Systems 399 De Kleetlaan 6a 400 Diegem 1831 401 Belgium 403 Phone: +32 2704 5473 404 Email: gunter@cisco.com 406 Ciprian Popoviciu 407 Cisco Systems 408 7025-6 Kit Creek Road 409 Research Triangle Park, North Carolina NC 27709-4987 410 USA 412 Phone: +1 919 392-3723 413 Email: cpopovic@cisco.com 415 Janos Mohacsi 416 NIIF/Hungarnet 417 18-22 Victor Hugo 418 Budapest H-1132 419 Hungary 421 Phone: tbc 422 Email: mohacsi@niif.hu