idnits 2.17.1 draft-ietf-v6ops-ra-guard-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3971]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 28, 2009) is 5260 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4861' is defined on line 330, but no explicit reference was found in the text Summary: 2 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: June 1, 2010 Cisco Systems 6 J. Mohacsi 7 NIIF/Hungarnet 8 November 28, 2009 10 IPv6 RA-Guard 11 13 Abstract 15 It is particularly easy to experience "rogue" routers on an unsecured 16 link [reference4]. Devices acting as a rougue router may send 17 illegitimate RAs. Section 6 of SeND [RFC3971] provides a full 18 solution to this problem, by enabling routers certification. This 19 solution does, however, require all nodes on an L2 network segment to 20 support SeND, as well as it carries some deployment challenges. End- 21 nodes must be provisioned with certificate anchors. The solution 22 works better when end-nodes have access to a Certificate Revocation 23 List server, and to a Network Time Protocol server, both typically 24 off-link, which brings some bootstrap issues. 26 When using IPv6 within a single L2 network segment it is possible and 27 sometimes desirable to enable layer 2 devices to drop rogue RAs 28 before they reach end-nodes. In order to distinguish valid from 29 rogue RAs, the L2 devices can use a spectrum of criterias, from a 30 static scheme that blocks RAs received on un-trusted ports, or from 31 un-trusted sources, to a more dynamic scheme that uses SeND to 32 challenge RA sources. 34 This document reviews various techniques applicable on the L2 devices 35 to reduce the threat of rogue RAs. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt. 55 The list of Internet-Draft Shadow Directories can be accessed at 56 http://www.ietf.org/shadow.html. 58 This Internet-Draft will expire on June 1, 2010. 60 Copyright Notice 62 Copyright (c) 2009 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the BSD License. 75 This document may contain material from IETF Documents or IETF 76 Contributions published or made publicly available before November 77 10, 2008. The person(s) controlling the copyright in some of this 78 material may not have granted the IETF Trust the right to allow 79 modifications of such material outside the IETF Standards Process. 80 Without obtaining an adequate license from the person(s) controlling 81 the copyright in such materials, this document may not be modified 82 outside the IETF Standards Process, and derivative works of it may 83 not be created outside the IETF Standards Process, except to format 84 it for publication as an RFC or to translate it into languages other 85 than English. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 90 2. Model and Applicability . . . . . . . . . . . . . . . . . . . . 4 91 3. Stateless RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6 92 4. Stateful RA-Guard . . . . . . . . . . . . . . . . . . . . . . . 6 93 4.1. State Machine . . . . . . . . . . . . . . . . . . . . . . . 6 94 4.2. SeND-based RA-Guard . . . . . . . . . . . . . . . . . . . . 7 95 5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . . 8 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 100 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 101 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 104 1. Introduction 106 When operating IPv6 in a shared L2 network segment without complete 107 SeND support by all devices connected or without the availability of 108 the infrastructure necessary to support SeND, there is always the 109 risk of facing operational problems due to rogue Router 110 Advertisements generated maliciously or unintentionally by 111 unauthorized or improperly configured routers connecting to the 112 segment. 114 There are several examples of work done on this topic which resulted 115 in several related studies [reference1] [reference2] 116 [reference3].This document describes a solution framework for the 117 rogue-RA problem where network segments are designed around a single 118 or a set of L2-switching devices capable of identifying invalid RAs 119 and blocking them. The solutions developed within this framework can 120 span the spectrum from basic (where the port of the L2 device is 121 statically instructed to forward or not to forward RAs received from 122 the connected device) to advanced (where a criteria is used by the L2 123 device to dynamically validate or invalidate a received RA, this 124 criteria can even be based on SeND mechanisms). 126 2. Model and Applicability 128 RA-Guard applies to an environment where all messages between IPv6 129 end-devices traverse the controlled L2 networking devices. It does 130 not apply to a shared media such as an Ethernet hub, when devices can 131 communicate directly without going through an RA-Guard capable L2 132 networking device. 134 Figure 1 illustrates a deployment scenario for RA-Guard. 136 Block Allow 137 +------+ incoming +---------+ incoming +--------+ 138 |Host | RA | L2 | RA | Router | 139 | |--------\--------| device |--------/------| | 140 +------+ \ +----+----+ / +--------+ 141 \ | / 142 \ |Block / 143 \ |incoming / 144 \ |RA / 145 \_______|_______/ 146 | 147 | 148 +---+---+ 149 | Host | 150 | | 151 +-------+ 153 RA-Guard does not intend to provide a substitute for SeND based 154 solutions. It actually intends to provide complementary solutions in 155 those environments where SeND might not be suitable or fully 156 supported by all devices involved. It may take time until SeND is 157 ubiquitous in IPv6 networks and some of its large scale deployment 158 aspects are sorted out such as provisioning hosts with trust anchors. 159 It is also reasonable to expect that some devices might not consider 160 implementing SeND at all such as IPv6 enabled sensors. An RA-Guard 161 implementation which SeND-validates RAs on behalf of hosts would 162 potentially simplify some of these challenges. 164 RA-Guard can be seen as a superset of SEND with regard to router 165 authorization. Its purpose is to filter Router Advertisements based 166 on a set of criterias, from a simplistic "RA disallowed on a given 167 interface" to "RA allowed from pre-defined sources" and up to full 168 fladge SeND "RA allowed from authorized sources only". 170 In addition to this granularity on the criteria for filtering out 171 Router Advertisements, RA-Guard introduces the concept of router 172 authorization proxy. Instead of each node on the link analyzing RAs 173 and making an individual decision, a legitimate node-in-the-middle 174 performs the analysis on behalf of all other nodes on the link. The 175 analysis itself is not different from what each node would do: if 176 SeND is enabled, the RA is checked against X.509 certificates. If 177 any other criteria is in use, such as known L3 (addresses) or L2 178 (link-layer address, port number) legitimate sources of RAs, the 179 node-in-the middle can use this criteria and filter out any RA that 180 does not comply. If this node-in-the-middle is a L2 device, it will 181 not change the content of the validated RA, and avoid any of the nd- 182 proxy pitfalls. 184 RA-Guard intends to provide simple solutions to the rogue-RA problem 185 in contexts where simplicity is required while leveraging SeND in an 186 context environment consisting of with a mix of SeND capable devices 187 (L2 switches and routers) and devices that do not consistently use 188 SeND. Furthermore, RA-Guard is useful to simplify SeND deployments, 189 as only the L2 switch and the routers are required to carry 190 certificates (their own and the trust anchor certificates). 192 3. Stateless RA-Guard 194 Stateless RA-Guard examines incoming RAs and decide whether to 195 forward or block them based solely on information found in the 196 message or in the L2-device configuration. Typical information 197 available in the frames received, useful for RA validation is: 199 o Link-layer address of the sender 200 o Port on which the frame was received 201 o IP source address 202 o Prefix list 204 The following configuration information created on the L2-device can 205 be made available to RA-Guard, to validate against the information 206 found in the received RA frame: 208 o Allowed/Disallowed link-layer address of RA-sender 209 o Allowed/Disallowed ports for receiving RAs 210 o Allowed/Disallowed IP source addresses of RA-sender 211 o Allowed Prefix list and Prefix ranges 212 o Router Priority 214 Once the L2 device has validated the content of the RA frame against 215 the configuration, it forwards the RA to destination, whether unicast 216 or multicast. Otherwise, the RA is dropped. 218 4. Stateful RA-Guard 220 4.1. State Machine 222 Stateful RA-Guard learns dynamically about legitimate RA senders, and 223 store this information for allowing subsequent RAs. A simple 224 stateful scheme would be for the L2-device to listen to RAs during a 225 certain period of time, then to allow subsequent RAs only on those 226 ports on which valid RAs were received during this period. A more 227 sophisticated stateful scheme is based on SeND, and is described in 228 Section 4.2. 230 The state machine for stateful RA-Guard can be global, per-interface, 231 or per-peer, depending on the scheme used for authorizing RAs. 233 When RA-Guard is SEND-based, the state machine is per-peer and 234 defined in [RFC3971]. 236 When RA-Guard is using a discovery method, the state-machine of the 237 RA-Guard capability consists of four different states: 239 o State 1: OFF 240 A device or interface in RA-Guard "OFF" state, operates as if 241 the RA-Guard capability is not available. 242 o State 2: LEARNING 243 A device or interface in the RA-Guard "Learning" state is 244 actively acquiring information about the devices connected to 245 its interfaces. The learning process takes place over a pre- 246 defined period of time by capturing router advertisements or it 247 can be event triggered. The information gathered is compared 248 against pre-defined criteria which qualify the validity of the 249 RAs. 251 In this state, the RA-Guard enabled device or interface is 252 either blocking all RAs until their validity is verified or, 253 alternatively it can temporarily forward the RAs until the 254 decision is being made. 255 o State 3: BLOCKING 256 A device or interface running RA-Guard and in Blocking state 257 will block ingress RA-messages. 258 o State 4: FORWARDING 259 A device or interface running RA-Guard and in Forwarding state 260 will accept ingress RAs and forward them to their destination/ 262 The transition between these states can be triggered by manual 263 configuration or by meeting a pre-defined criteria. 265 4.2. SeND-based RA-Guard 267 In this scenario, the L2 device is blocking or forwarding RAs based 268 on SeND considerations. Upon capturing an RA on the interface, the 269 L2-device will first verify the CGA address and the RSA signature, as 270 specified in section 5 of [RFC3971]. RA should be dropped in case of 271 failure of this verification. It will then apply host behavior as 272 described in section 6.4.6 of [RFC3971]. In particular, the L2 273 device will attempt to retrieve a valid certificate from its cache 274 for the public key referred to in the RA. If such certificate is 275 found, the L2 device will forward the RA to destination. If not, the 276 L2 device will generate a CPS, sourced with UNSPECIFIED address, to 277 query the router certificate(s). It will then capture the CPA(s), 278 and attempt to validate the certificate chain. Failure to validate 279 the chain will result in dropping the RA. Upon validation success, 280 the L2 device will forward the RA to destination and and store the 281 router certificate in its cache. 283 In order to operate in this scenario, the L2-device should be 284 provisioned with a trust anchor certificate, as specified in section 285 6 of [RFC3971]. It may also establish a layer-3 connectivity with a 286 CRL server and/or with and NTP server. Bootstrapping issue in this 287 case can be resolved by using the configuration method to specify a 288 trusted port to a first router, and send-based-ra-guard method on all 289 other ports. The first router can then be used for NTP and CRL 290 connectivity. 292 5. RA-Guard Use Considerations 294 The RA-Guard mechanism is effective only when all messages between 295 IPv6 devices in the target environment traverse controlled L2 296 networking devices. In the case of environments such as Ethernet 297 hubs, devices can communicate directly without going through an RA- 298 Guard capable L2 networking device, the RA-Guard feature cannot 299 protect against rogue-RAs. 301 RA-Guard mechanisms do not offer protection in environments where 302 IPv6 traffic is tunneled. 304 6. IANA Considerations 306 There are no extra IANA consideration for this document. 308 7. Security Considerations 310 Once RA-Guard has setup the proper criterias, for example, it 311 identified that a port is allowed to receive RAs, or it identified 312 legitimiate sources of RA, or certificate base, then there is no 313 possible instances of accidently filtered legitimate RA's assuming 314 the RA-Guard filter enforcement follows strictly the RA-Guard 315 criteria's. 317 8. Acknowledgements 319 The authors dedicate this document to the memory of Jun-ichiro Hagino 320 (itojun) for his contributions to the development and deployment of 321 IPv6. 323 9. References 325 9.1. Normative References 327 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 328 Neighbor Discovery (SEND)", RFC 3971, March 2005. 330 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 331 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 332 September 2007. 334 9.2. Informative References 336 [reference1] 337 LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol 338 Monitor (http://ndpmon.sourceforge.net/)", November 2007. 340 [reference2] 341 KAME Project, "rafixd - developed at KAME - An active 342 rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/ 343 kame/kame/kame/rafixd/)", November 2007. 345 [reference3] 346 Hagino (itojun), Jun-ichiro., "Discussion of the various 347 solutions (http://ipv6samurais.com/ipv6samurais/ 348 demystified/rogue-RA.html)", 2007. 350 [reference4] 351 Chown, Tim. and Stig. Venaas, "Rogue IPv6 Router 352 Advertisement Problem (draft-ietf-v6ops-rogue-ra-00.txt)", 353 May 2009. 355 Authors' Addresses 357 Eric Levy Abegnoli 358 Cisco Systems 359 Village d'Entreprises Green Side - 400, Avenue Roumanille 360 Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410 361 France 363 Phone: +33 49 723 2620 364 Email: elevyabe@cisco.com 365 Gunter Van de Velde 366 Cisco Systems 367 De Kleetlaan 6a 368 Diegem 1831 369 Belgium 371 Phone: +32 2704 5473 372 Email: gunter@cisco.com 374 Ciprian Popoviciu 375 Cisco Systems 376 7025-6 Kit Creek Road 377 Research Triangle Park, North Carolina NC 27709-4987 378 USA 380 Phone: +1 919 392-3723 381 Email: cpopovic@cisco.com 383 Janos Mohacsi 384 NIIF/Hungarnet 385 18-22 Victor Hugo 386 Budapest H-1132 387 Hungary 389 Phone: tbc 390 Email: mohacsi@niif.hu