idnits 2.17.1 draft-dai-sidr-bgp-advertisement-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 398. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 418), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 25, 2006) is 6423 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) == Missing Reference: 'RFC-2119' is mentioned on line 54, but not defined == Unused Reference: 'RFC1208' is defined on line 319, but no explicit reference was found in the text == Unused Reference: 'RFC1812' is defined on line 322, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'BGP' is defined on line 332, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1208 ** Obsolete normative reference: RFC 2401 (ref. 'IPsec') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2385 (ref. 'TCPMD5') (Obsoleted by RFC 5925) == Outdated reference: A later version (-02) exists of draft-white-sobgp-architecture-01 == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-13 Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIDR Working Group Dai GuangMing 2 Internet Draft Z. Ye 3 Expires: March 2007 Huawei Technologies 4 FEKI Ines 5 France Telecom 6 September 25, 2006 8 BGP UPDATE Advertisement Restriction 9 draft-dai-sidr-bgp-advertisement-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 25, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). All Rights Reserved. 39 Abstract 41 SIDR working group is working on an extended architecture for 42 interdomain routing security framework. One of the functions that 43 this architecture should provide is origin authentication of prefixes 44 for BGP, i.e. a BGP speaker must be able to determine whether an AS 45 (autonomous system) is authorized to originate certain prefixes. This 46 draft documents some ideas from the perspective of internal control 47 in order to alleviate this problem. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC-2119] 55 Table of Contents 57 1. Introduction................................................2 58 1.1. Problem Description.....................................2 59 1.2. Existing solutions......................................3 60 1.3. Internal control ideas..................................3 61 1.4. Proposed solution.......................................3 62 2. Threat Model................................................3 63 3. Solution....................................................4 64 3.1. Framework..............................................5 65 3.2. Operation..............................................5 66 3.2.1. Policy maintaining.................................5 67 3.2.2. Policy deployment..................................5 68 3.2.3. Violation Response.................................6 69 4. Future Work...................................................7 70 5. Security Considerations......................................7 71 6. Acknowledgements............................................7 72 7. References..................................................7 73 7.1. Normative References....................................7 74 7.2. Informative References..................................8 75 Author's Addresses.............................................9 76 Intellectual Property Statement.................................9 77 Disclaimer of Validity.........................................9 78 Copyright Statement...........................................10 79 Acknowledgment................................................10 81 1. Introduction 83 1.1. Problem Description 85 It has been observed that BGP is vulnerable to several types of 86 attacks (refer to [VULN]). Because of lacking inherent security 87 mechanisms, a UPDATE message receiver can not tell whether the origin 88 AS listed in AS_PATH is authorized to originate the prefixes. Because 89 of misconfiguration or deliberate attacks, wrong prefixes may be 90 propagated through UPDATE messages which may cause traffic 91 redirection, black hole and some other problems. 93 1.2. Existing solutions 95 [SBGP] proposes an autonomous system numbers and prefix allocation 96 based PKI to provide an authentication infrastructure to solve this 97 problem. 99 [SoBGP] solves it in a similar ways except that it uses web-of-trust 100 model for AS identity authentication. 102 [IRR] is a global distributed database where routing information is 103 stored . The purpose is to ensure stability and consistency of the 104 Internet-wide routing. One can consult the database to obtain the 105 origin AS of a prefix. 107 1.3. Internal control ideas 109 Some research projects have focused on internal control of an AS. 110 [RCC] is a configuration analysis tool. Network operators can use it 111 to verify whether network configurations satisfy a prior anticipation. 113 [RCP] offers a proposal which introduces a routing control plane and 114 mainly focuses on internal problems within an AS, such as protocol 115 oscillation, forwarding loops, blackholes and so on. 117 1.4. Proposed solution 119 This draft proposes a solution to alleviate the problem. Since the 120 root cause of the problem is mistake on advertisements, it is 121 necessary to check the outbound advertisements besides of validating 122 received UPDATE. This draft proposes methods to make sure that origin 123 of routes is consistent with the anticipated configuration. 125 This solution is not brand-new, but it is low cost and incrementally 126 deployable. The solution can be applied alone or be part of a future 127 total solution about BGP security. When an AS has too limited 128 resource to support an expensive security mechanism, this proposal 129 may also be beneficial. 131 2. Threat Model 133 Basically, the threat will occur in following two situations. 135 1 In a deliberate attack situation 137 An attacker may intercept BGP protocol traffic and modify the 138 information of the traffic. Authentication mechanism can counter the 139 attack of this type, and [IPsec], [TLS] or [TCPMD5] can be applied to 140 provide such authentication. 142 An attacker may also compromise a BGP border router and advertises 143 vicious prefixes through it. 145 2 In a misconfiguration situation 147 BGP provides no inherent measure to control or monitor route 148 advertisements. Misconfigurations will not be checked or trigger any 149 alarm either. With the size of the AS growing, manual configuration 150 may increase the probability of configuration error. In many known 151 problems, the wrong prefixes have been advertised were mainly caused 152 by misconfiguration. Deliberate attacks are similar to 153 misconfiguration and attacks were reported relatively rarely. 155 A number of reasons (for example, the complexity of network and its 156 configuration, manual configuration and absence of unified bound to 157 apply AS-level strategy) leads to the fact that the actual network 158 operation is not consistent with the anticipation. 160 3. Solution 162 The proposal suggests mechanisms to avoid advertising a wrong message 163 from the inside of an AS and to avoid the mistake in the first place. 165 The main obstacles [IRR] faces are how to keep the database up-to- 166 date and complete, which limit its use. Conversely, for an AS the 167 range of prefixes that originate from it is a prior knowledge. 168 Therefore, it is possible to validate and restrict the advertisement 169 behavior of the AS. Technically, attacks caused by compromised device 170 are similar to those by misconfiguration, so the solution is also 171 effective to mitigate such attacks. 173 This solution can be incrementally deployed. Prefixes originating 174 from AS are filtered inside of the AS and EBGP sessions between ASes 175 will not be affected. Besides, received advertisements are also 176 filtered on the basis of a legitimacy level associated with an AS. It 177 is considered as its legitimacy to originate prefixes. This level is 178 inferred from IRR and received advertisements. 180 This solution is compatible with [SBGP] and [SoBGP]. Introduced 181 infrastructure in these proposals, such as PKI, can be used to 182 provide trust, when restricting advertised prefixes. 184 3.1. Framework 186 +-------+ ------> +-------+ 188 | | (policy) | | 190 | PS |---------- | RA | 192 | | <------ | | 194 +-------+ (alarm) +-------+ 196 Figure 1: System Architecture 198 Figure 1 is the framework of the system. RA is a border router in a 199 single AS and PS is a policy station in that AS. 201 One task of PS is to maintain a uniform advertising policy and to 202 deploy the policy inside the whole AS. Another task is to collect 203 alarms of inconsistent behavior from border routers inside the AS. 205 As a border router, such as RA in figure 1, before prefixes being 206 advertised out of the AS, they should check them against the policy 207 to determine whether the prefixes are consistent with the policy. 209 3.2. Operation 211 3.2.1. Policy maintaining 213 A policy station in an AS is responsible for maintaining a prefixes 214 advertisement policy. A policy station could be a dedicated host or a 215 router who has implemented additional functions of policy maintaining. 217 Conceptually a policy defines the range of prefixes which originate 218 from the AS. The policy may be established by manual configuration or 219 introduced into an AS through some external mechanism. For example, 220 for the address PKI proposed by [SBGP], the policy may be introduced 221 by utilizing Address Attestation (AA). In any case, the most 222 important thing is to ensure the accuracy of the range of prefixes, 223 i.e. to ensure the advertised prefixes originating from some AS is 224 properly authorized. 226 3.2.2. Policy deployment 228 There are two types of deployment model according to participation of 229 a router. 231 o Distributed deployment model 233 In this scenario, the advertisement policy should be deployed in 234 every BGP speaker in an AS. A policy station could use a BGP-based 235 mechanism to distribute the policy, such as a new type of BGP message 236 or some technology similar to [ORF]. The policy could also be 237 distributed in an "out-of-band" channel. 239 In this model, border routers are responsible for the policy 240 execution. The policy may be implemented with some filtering 241 mechanisms. Before distributing static or IGP routes into RIB of BGP, 242 the routes should be checked. 244 Since the policy is deployed inside an AS, transport security of the 245 policy may not be a serious problem. It is important to keep policy 246 deployment reliable and on time. 248 o Centralized deployment model 250 In this model, border routers need not execute security policies. A 251 policy station can make use of IBGP, as mentioned in [RCP], to obtain 252 advertised routes and check them against the deployed policy. In this 253 way, the policy station is able to determine whether a route is 254 consistent with the policy. If not, it triggers an alarm to a 255 management system. 257 Because a policy check occurs at a single host, a policy station is 258 supposed to keep online and analyze the alteration of routes in time. 260 3.2.3. Violation Response 262 When local routes violate the deployed policy, there are two kind of 263 possible measures to be taken: 265 o A loose measure 267 If a router uses a loose measure, violating routes will still be 268 advertised. However, an event should be reported to a management 269 system immediately, so an administrator could perform a proper 270 counter measure in time. 272 o A strict measure 274 If a router uses a strict measure, violating routes will be filtered 275 and will not be spread out of the AS. This is an active measure and 276 can prevent false route from being advertised, which may be caused by 277 misconfiguration. 279 If this security measure is implemented as a mandatory option, 280 attacks made by a compromised router may also be detected. 282 4. Future Work 284 This application framework is more fit for BGP stub ASes which do not 285 provide transitive services and for the ASes whose devices are with 286 limited resource. 288 As to upper ASes, frequent changes of internet route must be 289 considered. In such situation, a policy station is supposed to know 290 these changes, so it should be [s|so|ps]BGP-aware and could get 291 credible routing and authorization information from outside security 292 systems. 294 Furthermore, the policy station could be enhanced to process more 295 complicated semantic validation, such as AS_PATH validation. 297 To sum up, in this framework only a few devices in an AS are required 298 to participate in security validation. In this way most BGP router 299 could meet security requirements without update hardware. 301 5. Security Considerations 303 This draft focuses on preventing sending and receiving BGP false 304 advertisements incurred by misconfiguration. Since attack may also be 305 a potential cause of the problem, the proposal is a security 306 mechanism for BGP in the same time. 308 A policy station is the key element of the solution. Since it is 309 located in the domain of an AS, launching an attack toward it may be 310 difficult. If strict security requirements are needed, operators may 311 take more strict access control to the policy station. 313 6. Acknowledgements 315 7. References 317 7.1. Normative References 319 [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", 320 RFC 1208, March 1991. 322 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 323 1812, June 1995. 325 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 326 E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, 327 February 1996. 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 equirement Levels", BCP 14, RFC 2119, March 1997. 332 [BGP] Y. Rekhter, T. Li, S. Hares, "A Border Gateway Protocol 4 333 (BGP-4)", RFC 4271, January 2006. 335 [IPsec] Kent, S. and R. Atkinson, "Security Architecture for the 336 Internet Protocol", RFC 2401, November 1998. 338 [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 339 January 1999. 341 [TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 342 Signature Option", RFC 2385, August 1998. 344 7.2. Informative References 346 [VULN] S. Murphy, "BGP Security Vulnerabilities Analysis", RFC 4272, 347 January 2006. 349 [SBGP] Charles Lynn, Joanne Mikkelson, Karen Seo, "Secure BGP (S- 350 BGP)", draft-clynn-s-bgp-protocol-01.txt, June 2003. 352 [SoBGP] R. White, "Architecture and Deployment Considerations for 353 Secure Origin BGP (soBGP)", draft-white-sobgp-architecture-01.txt, 354 May 24, 2005. 356 [IRR] "Internet Routing Registry", http://www.irr.net. 358 [RCC] MIT, "Routing Configuration Checker", 359 http://nms.lcs.mit.edu/bgp/rcc/#status. 361 [RCP] Matthew Caesar, Donald Caldwell, Nick Feamster, Jennifer 362 Rexford, Aman Shaikh, Jacobus van der Merwe, "Design and 363 Implementation of a Routing Control Platform". 365 [ORF] Enke Chen, Yakov Rekhter, "Cooperative Route Filtering 366 Capability for BGP-4", draft-ietf-idr-route-filter-13.txt. 368 Author's Addresses 370 Dai Guangming 371 Huawei Technologies 372 No.3, Xinxi Road, Shangdi Information Industry Base 373 Haidian District, Beijing City 100085 374 Email: daigm@huawei.com 376 Zhao Ye 377 Huawei Technologies 378 No.3, Xinxi Road, Shangdi Information Industry Base 379 Haidian District, Beijing City 100085 380 Email: yezhao@huawei.com 382 Intellectual Property Statement 384 The IETF takes no position regarding the validity or scope of any 385 Intellectual Property Rights or other rights that might be claimed to 386 pertain to the implementation or use of the technology described in 387 this document or the extent to which any license under such rights 388 might or might not be available; nor does it represent that it has 389 made any independent effort to identify any such rights. Information 390 on the procedures with respect to rights in RFC documents can be 391 found in BCP 78 and BCP 79. 393 Copies of IPR disclosures made to the IETF Secretariat and any 394 assurances of licenses to be made available, or the result of an 395 attempt made to obtain a general license or permission for the use of 396 such proprietary rights by implementers or users of this 397 specification can be obtained from the IETF on-line IPR repository at 398 http://www.ietf.org/ipr. 400 The IETF invites any interested party to bring to its attention any 401 copyrights, patents or patent applications, or other proprietary 402 rights that may cover technology that may be required to implement 403 this standard. Please address the information to the IETF at 404 ietf-ipr@ietf.org 406 Disclaimer of Validity 408 This document and the information contained herein are provided on an 409 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 410 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 411 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 412 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 413 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 414 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 416 Copyright Statement 418 Copyright (C) The Internet Society (2006). 420 This document is subject to the rights, licenses and restrictions 421 contained in BCP 78, and except as set forth therein, the authors 422 retain all their rights. 424 Acknowledgment 426 Funding for the RFC Editor function is currently provided by the 427 Internet Society.