idnits 2.17.1 draft-ietf-v6ops-ra-guard-00.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 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 344. 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 ([RFC4861], [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 (July 1, 2008) is 5770 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group G. Van de Velde 3 Internet-Draft E. Levy-Abegnoli 4 Expires: January 2, 2009 C. Popoviciu 5 Cisco Systems 6 J. Mohacsi 7 NIIF/Hungarnet 8 July 1, 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 January 2, 2009. 38 Abstract 40 When using IPv6 within a single L2 network segment it is neccesary to 41 ensure that all routers advertising their services within it are 42 valid. In cases where it is not convinient or possible to use SeND 43 [RFC3971] a rogue Router Advertisement (RA) [RFC4861] could be sent 44 by accident due to misconfiguraton or ill intended. Simple solutions 45 for protecting against rogue RAs are beneficial in complementing SeND 46 in securing the L2 domain for ceratin types of devices or in certain 47 transitional situations. 49 This document proposes a solution to reduce the threat of rogue RAs 50 by enabling layer 2 devices to forward only RAs received over 51 designated ports. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. RA-guard as a deployment complement to SEND . . . . . . . . . . 3 57 3. RA-Guard state-machine . . . . . . . . . . . . . . . . . . . . 4 58 3.1. RA-Guard state: OFF . . . . . . . . . . . . . . . . . . . . 4 59 3.2. RA-Guard state: LEARNING . . . . . . . . . . . . . . . . . 4 60 3.3. RA-Guard state: ACTIVE . . . . . . . . . . . . . . . . . . 5 61 4. RA-Guard interface states . . . . . . . . . . . . . . . . . . . 5 62 4.1. RA-Blocking interface . . . . . . . . . . . . . . . . . . . 5 63 4.2. RA-Forwarding interface . . . . . . . . . . . . . . . . . . 5 64 4.3. RA-Learning interface . . . . . . . . . . . . . . . . . . . 5 65 4.4. RA-Guard interface state transition . . . . . . . . . . . . 5 66 5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 70 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 72 Intellectual Property and Copyright Statements . . . . . . . . . . 9 74 1. Introduction 76 When operating IPv6 in a shared L2 network segment without complete 77 SeND support by all devices connected or without the availability of 78 the infrastructure neccesary to support SeND, there is always the 79 risk of facing operational problems due to rogue Router 80 Advertisements generated malliciously or unintentionaly by 81 unauthorized or improperly configured routers connecting to the 82 segment. 84 There are several examples of work done on this topic which resulted 85 in several related studies [reference1] [reference2] 86 [reference3].This document describes a solution framework to the 87 rogue-RA problem where network segments are designed around a single 88 or a set of L2-switching devices capable of identifying invalid RAs 89 and blocking them. The solutions developed within this framework can 90 span the spectrum from basic (where the port of the L2 device is 91 statically instructed to forward or not to forward RAs received from 92 the connected device) to advanced (where a criteria is used by the L2 93 device to dynamically validate or invalidate a received RA, this 94 criteria can even be based on SeND mechanisms). 96 2. RA-guard as a deployment complement to SEND 98 RA-guard does not intend to provide a substitute for SeND based 99 solutions. It actually intends to provide complementary solutions in 100 those environments where SeND might not be suitable or fully 101 supported by all devices involved. It may take time untill SeND is 102 ubiquitous in IPv6 networks and some of its large scale deployment 103 aspects are sorted out such as provisioning hosts with trust anchors. 104 It is also reasonable to expect that some devices might not consider 105 implementing SeND at all such as IPv6 enabled sensors. The RA-guard 106 "SeND-validating" RA on behalf of hosts would potentially simplify 107 some of these challenges. 109 RA-guard can be seen as a superset of SEND with regard to router 110 authorization. Its purpose is to filter Router Advertizements based 111 on a set of criterias, from a simplistic "RA dis-allowed on a given 112 interface" to "RA allowed from pre-defined sources" and up to full 113 SEND fledge "RA allowed from authorized sources only". 115 In addition to this granularity on the criteria for filtering out 116 Router Advertizements, RA-guard introduces the concept of router 117 authorization proxy. Instead of each node on the link analysing RAs 118 and making an individual decision, a legitimate node-in-the-middle 119 performs the analysis on behalf of all other nodes on the link. The 120 analysis itself is not different from what each node would do: if 121 SeND is enabled, the RA is checked against X.509 certificates. If 122 any other criteria is in use, such as known L3 (addresses) or L2 123 (link-layer address, port number) legitimate sources of RAs, the 124 node-in-the middle can use this criteria and filter out any RA that 125 does not comply. If this node-in-the-middle is a L2 device, it will 126 not change the content of the validated RA, and avoid any of the nd- 127 proxy pitfalls. 129 RA-guard intends to provide simple solutions to the rogue-RA problem 130 in contexts where simplicity is required while leveraging SeND in 131 context with a mix of SeND capable devices (L2 switches and routers) 132 and devices that do not consistently use SeND. Futhermore, RA-guard 133 is useful to simplify SeND deployments, as only the L2 switch and the 134 routers are required to carry certificates -their own and the trust 135 anchor certificates-. 137 3. RA-Guard state-machine 139 RA-Guard runs on devices that provide connectivity between hosts and 140 other hosts or networking devices. An example of such RA-Guard 141 capable device would be an OSI Layer-2 switch. The capability can be 142 enabled globally at device level or at interface level. 144 When RA-Guard is SEND-based, the timing of the learning phase, as 145 well as the overall behavior of the device doing RA-guard is as- 146 defined in [RFC3971]. 148 When RA-guard is using more static criterias, the state-machine of 149 the RA-Guard capability consists of three different states: 150 State 1: OFF 151 State 2: LEARNING 152 State 3: ACTIVE 154 The transition between these states can be triggered by manual 155 configuration or by meeting a pre-defined criteria. 157 3.1. RA-Guard state: OFF 159 A device or interface in RA-Guard "OFF" state, operates as if the RA- 160 Guard capability is not available. 162 3.2. RA-Guard state: LEARNING 164 A device or interface in the RA-Guard "Learning" state is actively 165 acquiring information about the devices connected to its interfaces. 166 The learning process takes place over a pre-defined period of time by 167 capturing router advertisments or it can be event triggered. The 168 information gathered is compared against pre-defined criteria which 169 qualify the validity of the RAs. 171 In this state, the RA-Guard enabled device or interface is either 172 blocking all RAs until their validity is verified or, alternatively 173 it can temporarily forward the RAs until the decision is being made. 175 3.3. RA-Guard state: ACTIVE 177 A device or interface running RA-Guard and in Active state will block 178 ingress RA-messages deemed invalid and will forward those deemed 179 valid based on a pre-defined criteria defined. 181 4. RA-Guard interface states 183 The interfaces of devices with the RA-guard capability enabled can be 184 in three possible states related to RA handling: Learning, Blocking 185 and Forwarding. 187 4.1. RA-Blocking interface 189 An interface in the RA Blocking state blocks all ingress RA messages 190 when RA-Guard capability is activated on a device. 192 4.2. RA-Forwarding interface 194 An interface in the RA Forwarding state forwards all ingress RA 195 messages deemed valid when RA-Guard capability is activated on a 196 device. 198 4.3. RA-Learning interface 200 An interface in a RA Learning state snoops all received RAs and 201 compares them against the criteria identifying valid RAs. While in 202 this state, the RAs can be blocked or forwarded until a decission is 203 taken regarding their validity. 205 4.4. RA-Guard interface state transition 207 In the simplest cases, an RA-Guard enabled interface can be manually 208 set in an RA-Blocking or RA-Forwarding state. By default, the 209 interfaces of a legitimate node-in-the-middle could be set in RA- 210 Blocking mode and enabled for forwarding by the network 211 administrator. In the more general case, the interface acquires RA 212 information during the RA Learning state and by using a pre-defined 213 validity criteria (see section 2) decides whether the analyzed RAs 214 should be forwarded or blocked. Based on this decission, the 215 interface transitions into the RA Blocking or the RA Forwarding 216 state. 218 Upon detecting new RAs, a port can transition back into an RA-Guard 219 Learning state. 221 5. RA-Guard Use Considerations 223 The RA-Guard mechanism is effective only when all mesages between 224 IPv6 devices in the target environment traverse the controlled L2 225 networking devices. When on a shared media such as an Ethernet hub, 226 devices can communicate directly without going through an RA-Guard 227 capable L2 networking device. In this scenario, the RA- Guard 228 feature cannot protect against rogue-RAs. 230 RA-Guard mecahnism does not protect against tunneled IPv6 traffic. 232 6. IANA Considerations 234 There are no extra IANA consideration for this document. 236 7. Security Considerations 238 There are no extra Security consideration for this document. 240 8. Acknowledgements 242 The authors dedicate this document to the memory of Jun-ichiro Hagino 243 (itojun) for his contributions to the development and deployment of 244 IPv6. 246 9. Normative References 248 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 249 Neighbor Discovery (SEND)", RFC 3971, March 2005. 251 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 252 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 253 September 2007. 255 [reference1] 256 LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol 257 Monitor (http://ndpmon.sourceforge.net/)", November 2007. 259 [reference2] 260 KAME Project, "rafixd - developed at KAME - An active 261 rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/ 262 kame/kame/kame/rafixd/)", November 2007. 264 [reference3] 265 Hagino (itojun), Jun-ichiro., "Discussion of the various 266 solutions (http://ipv6samurais.com/ipv6samurais/ 267 demystified/rogue-RA.html)", 2007. 269 Authors' Addresses 271 Gunter Van de Velde 272 Cisco Systems 273 De Kleetlaan 6a 274 Diegem 1831 275 Belgium 277 Phone: +32 2704 5473 278 Email: gunter@cisco.com 280 Eric Levy Abegnoli 281 Cisco Systems 282 Village d'Entreprises Green Side - 400, Avenue Roumanille 283 Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410 284 France 286 Phone: +33 49 723 2620 287 Email: elevyabe@cisco.com 289 Ciprian Popoviciu 290 Cisco Systems 291 7025-6 Kit Creek Road 292 Research Triangle Park, North Carolina NC 27709-4987 293 USA 295 Phone: +1 919 392-3723 296 Email: cpopovic@cisco.com 297 Janos Mohacsi 298 NIIF/Hungarnet 299 18-22 Victor Hugo 300 Budapest H-1132 301 Hungary 303 Phone: tbc 304 Email: mohacsi@niif.hu 306 Full Copyright Statement 308 Copyright (C) The IETF Trust (2008). 310 This document is subject to the rights, licenses and restrictions 311 contained in BCP 78, and except as set forth therein, the authors 312 retain all their rights. 314 This document and the information contained herein are provided on an 315 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 316 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 317 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 318 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 319 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 320 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 322 Intellectual Property 324 The IETF takes no position regarding the validity or scope of any 325 Intellectual Property Rights or other rights that might be claimed to 326 pertain to the implementation or use of the technology described in 327 this document or the extent to which any license under such rights 328 might or might not be available; nor does it represent that it has 329 made any independent effort to identify any such rights. Information 330 on the procedures with respect to rights in RFC documents can be 331 found in BCP 78 and BCP 79. 333 Copies of IPR disclosures made to the IETF Secretariat and any 334 assurances of licenses to be made available, or the result of an 335 attempt made to obtain a general license or permission for the use of 336 such proprietary rights by implementers or users of this 337 specification can be obtained from the IETF on-line IPR repository at 338 http://www.ietf.org/ipr. 340 The IETF invites any interested party to bring to its attention any 341 copyrights, patents or patent applications, or other proprietary 342 rights that may cover technology that may be required to implement 343 this standard. Please address the information to the IETF at 344 ietf-ipr@ietf.org.