idnits 2.17.1 draft-vandevelde-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 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 318. 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 ([2], [1]), 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 (January 28, 2008) is 5933 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 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: July 31, 2008 C. Popoviciu 5 Cisco Systems 6 J. Mohacsi 7 NIIF/Hungarnet 8 January 28, 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 July 31, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 When using IPv6 within a single L2 network segment it is neccesary to 45 ensure that all routers advertising their services within it are 46 valid. In cases where it is not convinient or possible to use SeND 47 [1] a rogue Router Advertisement (RA) [2] could be sent by accident 48 due to misconfiguraton or ill intended. Simple solutions for 49 protecting against rogue RAs are beneficial in complementing SeND in 50 securing the L2 domain for ceratin types of devices or in certain 51 transitional situations. 53 This document proposes a solution to reduce the threat of rogue RAs 54 by enabling layer 2 devices to forward only RAs received over 55 designated ports. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. RA-guard as a deployment complement to SEND . . . . . . . . . . 3 61 3. RA-Guard state-machine . . . . . . . . . . . . . . . . . . . . 3 62 3.1. RA-Guard state: OFF . . . . . . . . . . . . . . . . . . . . 4 63 3.2. RA-Guard state: LEARNING . . . . . . . . . . . . . . . . . 4 64 3.3. RA-Guard state: ACTIVE . . . . . . . . . . . . . . . . . . 4 65 4. RA-Guard interface states . . . . . . . . . . . . . . . . . . . 4 66 4.1. RA-Blocking interface . . . . . . . . . . . . . . . . . . . 4 67 4.2. RA-Forwarding interface . . . . . . . . . . . . . . . . . . 5 68 4.3. RA-Learning interface . . . . . . . . . . . . . . . . . . . 5 69 4.4. RA-Guard interface state transition . . . . . . . . . . . . 5 70 5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . . 5 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 74 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 76 Intellectual Property and Copyright Statements . . . . . . . . . . 8 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 neccesary to support SeND, there is always the 83 risk of facing operational problems due to rogue Router 84 Advertisements generated malliciously or unintentionaly 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 [3] [4] [5].This document describes a 90 solution framework to the rogue-RA problem where network segments are 91 designed around a single or a set of L2-switching devices capable of 92 identifying invalid RAs and blocking them. The solutions developed 93 within this framework can span the spectrum from basic (where the 94 port of the L2 device is statically instructed to forward or not to 95 forward RAs received from the connected device) to advanced (where a 96 criteria is used by the L2 device to dynamically validate or 97 invalidate a received RA, this criteria can even be based on SeND 98 mechanisms). 100 2. RA-guard as a deployment complement to SEND 102 RA-guard does not intend to provide a substitute for SeND based 103 solutions. It actually intends to provide complementary solutions in 104 those environments where SeND might not be suitable or fully 105 supported by all devices involved. It may take time untill SeND is 106 ubiquitous in IPv6 networks and some of its large scale deployment 107 aspects are sorted out such as provisioning hosts with trust anchors. 108 It is also reasonable to expect that some devices might not consider 109 implementing SeND at all such as IPv6 enabled sensors. The RA-guard 110 "SeND-validating" RA on behalf of hosts would potentially simplify 111 some of these challenges. 113 RA-guard intends to provide simple solutions to the rogue-RA problem 114 in such contexts and while in some cases it will do that through a 115 simple solution, in others it leverages SEND between capable devices 116 (L2 and routers) to provide protection to devices that do not 117 consistently use SEND. 119 3. RA-Guard state-machine 121 RA-Guard runs on devices that provide connectivity between hosts and 122 other hosts or networking devices. An example of such RA-Guard 123 capable device would be an OSI Layer-2 switch. The capability can be 124 enabled globally at device level or at interface level. 126 Depending on the mode of operation, the state-machine of the RA-Guard 127 capability consists of three different states: 128 State 1: OFF 129 State 2: LEARNING 130 State 3: ACTIVE 132 The transition between these states can be triggered by manual 133 configuration or by meeting a pre-defined criteria. 135 3.1. RA-Guard state: OFF 137 A device or interface in RA-Guard "OFF" state, operates as if the RA- 138 Guard capability is not available. 140 3.2. RA-Guard state: LEARNING 142 A device or interface in the RA-Guard "Learning" state is actively 143 acquiring information about the devices connected to its interfaces. 144 The learning process takes place over a pre-defined period of time by 145 capturing router advertisments or it can be event triggered. The 146 information gathered is compared against pre-defined criteria which 147 qualify the validity of the RAs. 149 In this state, the RA-Guard enabled device or interface is either 150 blocking all RAs until their validity is verified or, alternatively 151 it can temporarily forward the RAs until the decision is being made. 153 3.3. RA-Guard state: ACTIVE 155 A device or interface running RA-Guard and in Active state will block 156 ingress RA-messages deemed invalid and will forward those deemed 157 valid based on a pre-defined criteria defined. 159 4. RA-Guard interface states 161 The interfaces of devices with the RA-guard capability enabled can be 162 in three possible states related to RA handling: Learning, Blocking 163 and Forwarding. 165 4.1. RA-Blocking interface 167 An interface in the RA Blocking state blocks all ingress RA messages 168 when RA-Guard capability is activated on a device. 170 4.2. RA-Forwarding interface 172 An interface in the RA Forwarding state forwards all ingress RA 173 messages deemed valid when RA-Guard capability is activated on a 174 device. 176 4.3. RA-Learning interface 178 An interface in a RA Learning state snoops all received RAs and 179 compares them against the criteria identifying valid RAs. While in 180 this state, the RAs can be blocked or forwarded until a decission is 181 taken regarding their validity. 183 4.4. RA-Guard interface state transition 185 In the simplest cases, an RA-Guard enabled interface can be manually 186 set in an RA-Blocking or RA-Forwarding state. By default, the 187 interfaces of the L2 switch could be set in RA-Blocking mode and 188 enabled for forwarding by the network administrator. In the more 189 general case, the interface acquires RA information during the RA 190 Learning state and by using a pre-defined validity criteria decides 191 whether the analyzed RAs should be forwarded or blocked. Based on 192 this decission, the interface transitions into the RA Blocking or the 193 RA Forwarding state. 195 Upon detecting new RAs, a port can transition back into an RA-Guard 196 Learning state. 198 5. RA-Guard Use Considerations 200 The RA-Guard mechanism is effective only when all mesages between 201 IPv6 devices in the target environment traverse the controlled L2 202 networking devices. When on a shared media such as an Ethernet hub, 203 devices can communicate directly without going through an RA-Guard 204 capable L2 networking device. In this scenario, the RA- Guard 205 feature cannot protect against rogue-RAs. 207 RA-Guard mecahnism does not protect against tunneled IPv6 traffic. 209 6. IANA Considerations 211 There are no extra IANA consideration for this document. 213 7. Security Considerations 215 There are no extra Security consideration for this document. 217 8. Acknowledgements 219 The authors dedicate this document to the memory of Jun-ichiro Hagino 220 (itojun) for his contributions to the development and deployment of 221 IPv6. 223 9. Normative References 225 [1] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 226 Neighbor Discovery (SEND)", RFC 3971, March 2005. 228 [2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor 229 Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 231 [3] LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol Monitor 232 (http://ndpmon.sourceforge.net/)", November 2007. 234 [4] KAME Project, "rafixd - developed at KAME - An active rogue RA 235 nullifier 236 (http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/rafixd/)", 237 November 2007. 239 [5] Hagino (itojun), Jun-ichiro., "Discussion of the various 240 solutions (http://ipv6samurais.com/ipv6samurais/demystified/ 241 rogue-RA.html)", 2007. 243 Authors' Addresses 245 Gunter Van de Velde 246 Cisco Systems 247 De Kleetlaan 6a 248 Diegem 1831 249 Belgium 251 Phone: +32 2704 5473 252 Email: gunter@cisco.com 253 Eric Levy Abegnoli 254 Cisco Systems 255 Village d'Entreprises Green Side - 400, Avenue Roumanille 256 Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410 257 France 259 Phone: +33 49 723 2620 260 Email: elevyabe@cisco.com 262 Ciprian Popoviciu 263 Cisco Systems 264 7025-6 Kit Creek Road 265 Research Triangle Park, North Carolina NC 27709-4987 266 USA 268 Phone: +1 919 392-3723 269 Email: cpopovic@cisco.com 271 Janos Mohacsi 272 NIIF/Hungarnet 273 18-22 Victor Hugo 274 Budapest H-1132 275 Hungary 277 Phone: tbc 278 Email: mohacsi@niif.hu 280 Full Copyright Statement 282 Copyright (C) The IETF Trust (2008). 284 This document is subject to the rights, licenses and restrictions 285 contained in BCP 78, and except as set forth therein, the authors 286 retain all their rights. 288 This document and the information contained herein are provided on an 289 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 290 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 291 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 292 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 293 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 294 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 296 Intellectual Property 298 The IETF takes no position regarding the validity or scope of any 299 Intellectual Property Rights or other rights that might be claimed to 300 pertain to the implementation or use of the technology described in 301 this document or the extent to which any license under such rights 302 might or might not be available; nor does it represent that it has 303 made any independent effort to identify any such rights. Information 304 on the procedures with respect to rights in RFC documents can be 305 found in BCP 78 and BCP 79. 307 Copies of IPR disclosures made to the IETF Secretariat and any 308 assurances of licenses to be made available, or the result of an 309 attempt made to obtain a general license or permission for the use of 310 such proprietary rights by implementers or users of this 311 specification can be obtained from the IETF on-line IPR repository at 312 http://www.ietf.org/ipr. 314 The IETF invites any interested party to bring to its attention any 315 copyrights, patents or patent applications, or other proprietary 316 rights that may cover technology that may be required to implement 317 this standard. Please address the information to the IETF at 318 ietf-ipr@ietf.org. 320 Acknowledgment 322 Funding for the RFC Editor function is provided by the IETF 323 Administrative Support Activity (IASA).