idnits 2.17.1 draft-vandevelde-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 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 292. 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 ([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 (November 12, 2007) is 5972 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) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '1') (Obsoleted by RFC 4861) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 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: May 15, 2008 C. Popoviciu 5 Cisco Systems 6 J. Mohacsi 7 NIIF/Hungarnet 8 November 12, 2007 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 May 15, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 When using IPv6 within a single L2 network segment it is assumed that 45 for good network behavior, the available routers attached to the 46 segment are valid routers. A rogue Router Advertisement (RA) [1] 47 however could be sent by accident by a misconfigured network device, 48 or on purpose by malicious devices. This document proposes a 49 solution to reduce the threat of rogue RAs by enabling layer 2 50 devices to provide forward RAs received over designated ports. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. RA-Guard state-machine . . . . . . . . . . . . . . . . . . . . 3 56 2.1. RA-Guard state: OFF . . . . . . . . . . . . . . . . . . . . 3 57 2.2. RA-Guard state: LEARNING . . . . . . . . . . . . . . . . . 3 58 2.3. RA-Guard state: ACTIVE . . . . . . . . . . . . . . . . . . 4 59 3. RA-Guard interface states . . . . . . . . . . . . . . . . . . . 4 60 3.1. RA-Blocking interface . . . . . . . . . . . . . . . . . . . 4 61 3.2. RA-Forwarding interface . . . . . . . . . . . . . . . . . . 4 62 3.3. RA-Learning interface . . . . . . . . . . . . . . . . . . . 4 63 3.4. RA-Guard interface state transition . . . . . . . . . . . . 4 64 4. Pittfals of RA-Guard . . . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 Intellectual Property and Copyright Statements . . . . . . . . . . 7 74 1. Introduction 76 When operating IPv6 in a shared L2 network segment there is always 77 the risk of facing operational problems due to rogue Router 78 Advertisements generated malliciously or unintentionaly by 79 unauthorized or improperly configured routers connecting to the 80 segment. If a network segment is designed around a single or a set 81 of L2-switching devices capable of identifying invalid RAs and 82 blocking them, then the impact of rogue RA's can be minimized. 84 The identification of valid RA's can be done based on various 85 criteria defined by the network administrator. 87 Previous art to minimalize the impact of rogue RA's has been 88 investigated by various people and entities. Some examples of these 89 studies are [2] [3] [4]. 91 2. RA-Guard state-machine 93 RA-Guard runs on devices that provide connectivity between hosts and 94 other hosts or networking devices. An example of such RA-Guard 95 capable device would be an OSI Layer-2 switch. The capability can be 96 enabled globally at device level or at interface level. 98 Depending on the mode of operation, the state-machine of the RA-Guard 99 capability consists of three different states: 100 State 1: OFF 101 State 2: LEARNING 102 State 3: ACTIVE 104 The transition between these states can be triggered by manual 105 configuration or by meeting a pre-defined criteria. 107 2.1. RA-Guard state: OFF 109 A device or interface in RA-Guard "OFF" state, operates as if the RA- 110 Guard capability is not available. 112 2.2. RA-Guard state: LEARNING 114 A device or interface in the RA-Guard "Learning" state is actively 115 acquiring information about the devices connected to its interfaces. 116 The learning process takes place over a pre-defined period of time by 117 capturing router advertisments. The information gathered is compared 118 against pre-defined criteria which qualify the validity of the RAs. 120 In this state, the RA-Guard enabled device or interface is either 121 blocking all RAs until their validity is verified or, alternatively 122 it can temporarily forward the RAs until the decision is being made. 124 2.3. RA-Guard state: ACTIVE 126 A device or interface running RA-Guard and in Active state will block 127 ingress RA-messages deemed invalid and will forward those deemed 128 valid based on a pre-defined criteria defined. 130 3. RA-Guard interface states 132 The interfaces of devices with the RA-guard capability enabled can be 133 in three possible states related to RA handling: Learning, Blocking 134 and Forwarding. 136 3.1. RA-Blocking interface 138 An interface in the RA Blocking state blocks all ingress RA messages 139 when RA-Guard capability is activated on a device. 141 3.2. RA-Forwarding interface 143 An interface in the RA Forwarding state forwards all ingress RA 144 messages deemed valid when RA-Guard capability is activated on a 145 device. 147 3.3. RA-Learning interface 149 An interface in a RA Learning state all ingress RAs are snooped and 150 compared against the criteria identifying valid RAs. While in this 151 state, the RAs can be blocked or forwarded until a decission is taken 152 regarding their validity. 154 3.4. RA-Guard interface state transition 156 In the simplest cases, an RA-Guard enabled interface can be manually 157 set in an RA-Blocking or RA-Forwarding state. In the more general 158 case, the interface acquires RA information during the RA Learning 159 state and by using a pre-defined validity criteria decides whether 160 the analyzed RAs should be forwarded or blocked. Based on this 161 decission, the interface transitions into the RA Blocking or the RA 162 Forwarding state. 164 Upon detecting new RAs, a port can transition back into an RA-Guard 165 Learning state. 167 4. Pittfals of RA-Guard 169 The RA-Guard mechanism relies on the assumption that all mesages 170 between IPv6 devices in the target environment traverse the 171 controlled L2 networking devices. When on a shared media such as an 172 Ethernet hub, devices can communicate directly without going through 173 an RA-Guard capable L2 networking device. In this scenario, the RA- 174 Guard feature has no additional value. 176 RA-Guard mecahnism does not protect against tunneled IPv6 traffic. 178 RA-Guard does not provide any protection against the content or IPv6 179 addresses used with RA-messages. 181 5. IANA Considerations 183 There are no extra IANA consideration for this document. 185 6. Security Considerations 187 There are no extra Security consideration for this document. 189 7. Acknowledgements 191 The authors dedicate this document to the memory of Jun-ichiro Hagino 192 (itojun) for his contributions to the development and deployment of 193 IPv6. 195 8. References 197 8.1. Normative References 199 8.2. Informative References 201 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 202 for IP Version 6 (IPv6)", RFC 2461, December 1998. 204 [2] LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol Monitor 205 (http://ndpmon.sourceforge.net/)", November 2007. 207 [3] KAME Project, "rafixd - developed at KAME - An active rogue RA 208 nullifier 209 (http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/rafixd/)", 210 November 2007. 212 [4] Hagino (itojun), Jun-ichiro., "Discussion of the various 213 solutions (http://ipv6samurais.com/ipv6samurais/demystified/ 214 rogue-RA.html)", 2007. 216 Authors' Addresses 218 Gunter Van de Velde 219 Cisco Systems 220 De Kleetlaan 6a 221 Diegem 1831 222 Belgium 224 Phone: +32 2704 5473 225 Email: gunter@cisco.com 227 Eric Levy Abegnoli 228 Cisco Systems 229 Village d'Entreprises Green Side - 400, Avenue Roumanille 230 Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410 231 France 233 Phone: +33 49 723 2620 234 Email: elevyabe@cisco.com 236 Ciprian Popoviciu 237 Cisco Systems 238 7025-6 Kit Creek Road 239 Research Triangle Park, North Carolina NC 27709-4987 240 USA 242 Phone: +1 919 392-3723 243 Email: cpopovic@cisco.com 245 Janos Mohacsi 246 NIIF/Hungarnet 247 18-22 Victor Hugo 248 Budapest H-1132 249 Hungary 251 Phone: tbc 252 Email: mohacsi@niif.hu 254 Full Copyright Statement 256 Copyright (C) The IETF Trust (2007). 258 This document is subject to the rights, licenses and restrictions 259 contained in BCP 78, and except as set forth therein, the authors 260 retain all their rights. 262 This document and the information contained herein are provided on an 263 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 264 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 265 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 266 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 267 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 268 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 270 Intellectual Property 272 The IETF takes no position regarding the validity or scope of any 273 Intellectual Property Rights or other rights that might be claimed to 274 pertain to the implementation or use of the technology described in 275 this document or the extent to which any license under such rights 276 might or might not be available; nor does it represent that it has 277 made any independent effort to identify any such rights. Information 278 on the procedures with respect to rights in RFC documents can be 279 found in BCP 78 and BCP 79. 281 Copies of IPR disclosures made to the IETF Secretariat and any 282 assurances of licenses to be made available, or the result of an 283 attempt made to obtain a general license or permission for the use of 284 such proprietary rights by implementers or users of this 285 specification can be obtained from the IETF on-line IPR repository at 286 http://www.ietf.org/ipr. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights that may cover technology that may be required to implement 291 this standard. Please address the information to the IETF at 292 ietf-ipr@ietf.org. 294 Acknowledgment 296 Funding for the RFC Editor function is provided by the IETF 297 Administrative Support Activity (IASA).