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