idnits 2.17.1 draft-ietf-v6ops-ra-guard-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 390. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (September 10, 2008) is 5704 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4861' is defined on line 297, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 Expires: March 14, 2009 C. Popoviciu 5 Cisco Systems 6 J. Mohacsi 7 NIIF/Hungarnet 8 September 10, 2008 10 IPv6 RA-Guard 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 14, 2009. 38 Abstract 40 It is particularly easy to experience "rogue" routers on an unsecured 41 link. Devices acting as a rougue router may send illegitimate RAs. 42 Section 6 of SeND [RFC3971] provides a full solution to this problem, 43 by enabling routers certification. This solution does, however, 44 require all nodes on an L2 network segment to support SeND, as well 45 as it carries some deployment challenges. End-nodes must be 46 provisioned with certificate anchors. The solution works better when 47 end-nodes have access to a Certificate Revocation List server, and to 48 a Network Time Protocol server, both typically off-link, which brings 49 some bootstrap issues. 51 When using IPv6 within a single L2 network segment it is possible and 52 sometimes desirable to enable layer 2 devices to drop rogue RAs 53 before they reach end-nodes. In order to distinguish valid from 54 rogue RAs, the L2 devices can use a spectrum of criterias, from a 55 static scheme that blocks RAs received on un-trusted ports, or from 56 un-trusted sources, to a more dynamic scheme that uses SeND to 57 challenge RA sources. 59 This document reviews various techniques applicable on the L2 devices 60 to reduce the threat of rogue RAs. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Model and Applicability . . . . . . . . . . . . . . . . . . . 3 66 3. Stateless RA-Guard . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Stateful RA-Guard . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 5 69 4.2. SeND-based RA-Guard . . . . . . . . . . . . . . . . . . . 6 70 5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 74 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 76 Intellectual Property and Copyright Statements . . . . . . . . . . 10 78 1. Introduction 80 When operating IPv6 in a shared L2 network segment without complete 81 SeND support by all devices connected or without the availability of 82 the infrastructure necessary to support SeND, there is always the 83 risk of facing operational problems due to rogue Router 84 Advertisements generated maliciously or unintentionally by 85 unauthorized or improperly configured routers connecting to the 86 segment. 88 There are several examples of work done on this topic which resulted 89 in several related studies [reference1] [reference2] 90 [reference3].This document describes a solution framework for the 91 rogue-RA problem where network segments are designed around a single 92 or a set of L2-switching devices capable of identifying invalid RAs 93 and blocking them. The solutions developed within this framework can 94 span the spectrum from basic (where the port of the L2 device is 95 statically instructed to forward or not to forward RAs received from 96 the connected device) to advanced (where a criteria is used by the L2 97 device to dynamically validate or invalidate a received RA, this 98 criteria can even be based on SeND mechanisms). 100 2. Model and Applicability 102 RA-Guard applies to an environment where all messages between IPv6 103 end-devices traverse the controlled L2 networking devices. It does 104 not apply to a shared media such as an Ethernet hub, when devices can 105 communicate directly without going through an RA-Guard capable L2 106 networking device. 108 Figure 1 illustrates a deployment scenario for RA-Guard. 110 Block Allow 111 +------+ incoming +---------+ incoming +--------+ 112 |Host | RA | L2 | RA | Router | 113 | |--------\--------| device |--------/------| | 114 +------+ \ +----+----+ / +--------+ 115 \ | / 116 \ |Block / 117 \ |incoming / 118 \ |RA / 119 \_______|_______/ 120 | 121 | 122 +---+---+ 123 | Host | 124 | | 125 +-------+ 127 RA-Guard does not intend to provide a substitute for SeND based 128 solutions. It actually intends to provide complementary solutions in 129 those environments where SeND might not be suitable or fully 130 supported by all devices involved. It may take time until SeND is 131 ubiquitous in IPv6 networks and some of its large scale deployment 132 aspects are sorted out such as provisioning hosts with trust anchors. 133 It is also reasonable to expect that some devices might not consider 134 implementing SeND at all such as IPv6 enabled sensors. An RA-Guard 135 implementation which SeND-validates RAs on behalf of hosts would 136 potentially simplify some of these challenges. 138 RA-Guard can be seen as a superset of SEND with regard to router 139 authorization. Its purpose is to filter Router Advertisements based 140 on a set of criterias, from a simplistic "RA disallowed on a given 141 interface" to "RA allowed from pre-defined sources" and up to full 142 fladge SeND "RA allowed from authorized sources only". 144 In addition to this granularity on the criteria for filtering out 145 Router Advertisements, RA-Guard introduces the concept of router 146 authorization proxy. Instead of each node on the link analyzing RAs 147 and making an individual decision, a legitimate node-in-the-middle 148 performs the analysis on behalf of all other nodes on the link. The 149 analysis itself is not different from what each node would do: if 150 SeND is enabled, the RA is checked against X.509 certificates. If 151 any other criteria is in use, such as known L3 (addresses) or L2 152 (link-layer address, port number) legitimate sources of RAs, the 153 node-in-the middle can use this criteria and filter out any RA that 154 does not comply. If this node-in-the-middle is a L2 device, it will 155 not change the content of the validated RA, and avoid any of the nd- 156 proxy pitfalls. 158 RA-Guard intends to provide simple solutions to the rogue-RA problem 159 in contexts where simplicity is required while leveraging SeND in an 160 context environment consisting of with a mix of SeND capable devices 161 (L2 switches and routers) and devices that do not consistently use 162 SeND. Furthermore, RA-Guard is useful to simplify SeND deployments, 163 as only the L2 switch and the routers are required to carry 164 certificates (their own and the trust anchor certificates). 166 3. Stateless RA-Guard 168 Stateless RA-Guard examines incoming RAs and decide whether to 169 forward or block them based solely on information found in the 170 message or in the L2-device configuration. Typical information 171 available in the frames received, useful for RA validation is: 173 o Link-layer address of the sender 174 o Port on which the frame was received 175 o IP source address 176 o Prefix list 178 The following configuration information created on the L2-device can 179 be made available to RA-Guard, to validate against the information 180 found in the received RA frame: 182 o Allowed/Disallowed link-layer address of RA-sender 183 o Allowed/Disallowed ports for receiving RAs 184 o Allowed/Disallowed IP source addresses of RA-sender 185 o Allowed Prefix list and Prefix ranges 186 o Router Priority 188 Once the L2 device has validated the content of the RA frame against 189 the configuration, it forwards the RA to destination, whether unicast 190 or multicast. Otherwise, the RA is dropped. 192 4. Stateful RA-Guard 194 4.1. State Machine 196 Stateful RA-Guard learns dynamically about legitimate RA senders, and 197 store this information for allowing subsequent RAs. A simple 198 stateful scheme would be for the L2-device to listen to RAs during a 199 certain period of time, then to allow subsequent RAs only on those 200 ports on which valid RAs were received during this period. A more 201 sophisticated stateful scheme is based on SeND, and is described in 202 Section 4.2. 204 The state machine for stateful RA-Guard can be global, per-interface, 205 or per-peer, depending on the scheme used for authorizing RAs. 207 When RA-Guard is SEND-based, the state machine is per-peer and 208 defined in [RFC3971]. 210 When RA-Guard is using a discovery method, the state-machine of the 211 RA-Guard capability consists of four different states: 213 o State 1: OFF 214 A device or interface in RA-Guard "OFF" state, operates as if 215 the RA-Guard capability is not available. 216 o State 2: LEARNING 217 A device or interface in the RA-Guard "Learning" state is 218 actively acquiring information about the devices connected to 219 its interfaces. The learning process takes place over a pre- 220 defined period of time by capturing router advertisements or it 221 can be event triggered. The information gathered is compared 222 against pre-defined criteria which qualify the validity of the 223 RAs. 225 In this state, the RA-Guard enabled device or interface is 226 either blocking all RAs until their validity is verified or, 227 alternatively it can temporarily forward the RAs until the 228 decision is being made. 229 o State 3: BLOCKING 230 A device or interface running RA-Guard and in Blocking state 231 will block ingress RA-messages. 232 o State 4: FORWARDING 233 A device or interface running RA-Guard and in Forwarding state 234 will accept ingress RAs and forward them to their destination/ 236 The transition between these states can be triggered by manual 237 configuration or by meeting a pre-defined criteria. 239 4.2. SeND-based RA-Guard 241 In this scenario, the L2 device is blocking or forwarding RAs based 242 on SeND considerations. Upon capturing an RA on the interface, the 243 L2-device will first verify the CGA address and the RSA signature, as 244 specified in section 5 of [RFC3971]. RA should be dropped in case of 245 failure of this verification. It will then apply host behavior as 246 described in section 6.4.6 of [RFC3971]. In particular, the L2 247 device will attempt to retrieve a valid certificate from its cache 248 for the public key referred to in the RA. If such certificate is 249 found, the L2 device will forward the RA to destination. If not, the 250 L2 device will generate a CPS, sourced with UNSPECIFIED address, to 251 query the router certificate(s). It will then capture the CPA(s), 252 and attempt to validate the certificate chain. Failure to validate 253 the chain will result in dropping the RA. Upon validation success, 254 the L2 device will forward the RA to destination and and store the 255 router certificate in its cache. 257 In order to operate in this scenario, the L2-device should be 258 provisioned with a trust anchor certificate, as specified in section 259 6 of [RFC3971]. It may also establish a layer-3 connectivity with a 260 CRL server and/or with and NTP server. Bootstrapping issue in this 261 case can be resolved by using the configuration method to specify a 262 trusted port to a first router, and send-based-ra-guard method on all 263 other ports. The first router can then be used for NTP and CRL 264 connectivity. 266 5. RA-Guard Use Considerations 268 The RA-Guard mechanism is effective only when all messages between 269 IPv6 devices in the target environment traverse controlled L2 270 networking devices. In the case of environments such as Ethernet 271 hubs, devices can communicate directly without going through an RA- 272 Guard capable L2 networking device, the RA-Guard feature cannot 273 protect against rogue-RAs. 275 RA-Guard mechanisms do not offer protection in environments where 276 IPv6 traffic is tunneled. 278 6. IANA Considerations 280 There are no extra IANA consideration for this document. 282 7. Security Considerations 284 There are no extra Security consideration for this document. 286 8. Acknowledgements 288 The authors dedicate this document to the memory of Jun-ichiro Hagino 289 (itojun) for his contributions to the development and deployment of 290 IPv6. 292 9. Normative References 294 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 295 Neighbor Discovery (SEND)", RFC 3971, March 2005. 297 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 298 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 299 September 2007. 301 [reference1] 302 LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol 303 Monitor (http://ndpmon.sourceforge.net/)", November 2007. 305 [reference2] 306 KAME Project, "rafixd - developed at KAME - An active 307 rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/ 308 kame/kame/kame/rafixd/)", November 2007. 310 [reference3] 311 Hagino (itojun), Jun-ichiro., "Discussion of the various 312 solutions (http://ipv6samurais.com/ipv6samurais/ 313 demystified/rogue-RA.html)", 2007. 315 Authors' Addresses 317 Eric Levy Abegnoli 318 Cisco Systems 319 Village d'Entreprises Green Side - 400, Avenue Roumanille 320 Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410 321 France 323 Phone: +33 49 723 2620 324 Email: elevyabe@cisco.com 326 Gunter Van de Velde 327 Cisco Systems 328 De Kleetlaan 6a 329 Diegem 1831 330 Belgium 332 Phone: +32 2704 5473 333 Email: gunter@cisco.com 334 Ciprian Popoviciu 335 Cisco Systems 336 7025-6 Kit Creek Road 337 Research Triangle Park, North Carolina NC 27709-4987 338 USA 340 Phone: +1 919 392-3723 341 Email: cpopovic@cisco.com 343 Janos Mohacsi 344 NIIF/Hungarnet 345 18-22 Victor Hugo 346 Budapest H-1132 347 Hungary 349 Phone: tbc 350 Email: mohacsi@niif.hu 352 Full Copyright Statement 354 Copyright (C) The IETF Trust (2008). 356 This document is subject to the rights, licenses and restrictions 357 contained in BCP 78, and except as set forth therein, the authors 358 retain all their rights. 360 This document and the information contained herein are provided on an 361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 363 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 364 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 365 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 368 Intellectual Property 370 The IETF takes no position regarding the validity or scope of any 371 Intellectual Property Rights or other rights that might be claimed to 372 pertain to the implementation or use of the technology described in 373 this document or the extent to which any license under such rights 374 might or might not be available; nor does it represent that it has 375 made any independent effort to identify any such rights. Information 376 on the procedures with respect to rights in RFC documents can be 377 found in BCP 78 and BCP 79. 379 Copies of IPR disclosures made to the IETF Secretariat and any 380 assurances of licenses to be made available, or the result of an 381 attempt made to obtain a general license or permission for the use of 382 such proprietary rights by implementers or users of this 383 specification can be obtained from the IETF on-line IPR repository at 384 http://www.ietf.org/ipr. 386 The IETF invites any interested party to bring to its attention any 387 copyrights, patents or patent applications, or other proprietary 388 rights that may cover technology that may be required to implement 389 this standard. Please address the information to the IETF at 390 ietf-ipr@ietf.org.