idnits 2.17.1 draft-murphy-bgp-secr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 1998) is 9384 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) -- Looks like a reference, but probably isn't: 'ASk' on line 366 -- Looks like a reference, but probably isn't: 'ASi' on line 400 -- Looks like a reference, but probably isn't: 'AS0' on line 395 ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1583 (ref. '4') (Obsoleted by RFC 2178) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1826 (ref. '7') (Obsoleted by RFC 2402) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sandra Murphy 3 INTERNET DRAFT Trusted Information Systems 4 draft-murphy-bgp-secr-01.txt August 1998 6 BGP Security Analysis 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference material 18 or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 23 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 24 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 BGP, along with a host of other infrastructure protocols designed before 29 the Internet environment became perilous, is designed with little 30 consideration for protection of the data it communicates or of its own 31 behavior. There are no mechanisms in BGP to protect against attacks 32 that modify, delete, forge, or replay data, any of which has the 33 potential to be destructive of overall network routing behavior. 35 This internet draft discusses some of the security issues with BGP 36 routing data dissemination, and possible security solutions and the 37 costs of those solutions. This internet draft does not discuss security 38 issues with forwarding of packets. 40 Table of Contents 42 Status of this Memo .............................................. 1 43 Abstract ......................................................... 1 44 1 Introduction .................................................... 4 45 2 Vulnerabilities ................................................. 5 46 3 Possible Protections ............................................ 5 47 3.1 Threats from non-BGP peers .................................... 5 48 3.1.1 IP level protection ......................................... 6 49 3.1.2 TCP level protection ........................................ 6 50 3.1.3 BGP level protection ........................................ 6 51 3.2 Threats from BGP peers ........................................ 7 52 3.3 Sign Originating AS ........................................... 7 53 3.4 Sign Originating AS and Predecessor Information ............... 8 54 3.5 Sign Originating AS and AS_PATH ............................... 9 55 3.5.1 Special Considerations ...................................... 11 56 3.6 Rely on Registries ............................................ 12 57 4 Security Costs .................................................. 13 58 4.1 Protecting the Peer-Peer Link ................................. 13 59 4.2 Sign Originating AS ........................................... 14 60 4.3 Sign Originating AS and Predecessor Information ............... 14 61 4.4 Sign Originating AS and AS_PATH ............................... 14 62 4.5 Rely on Registries ............................................ 14 63 5 Authentication vs Authorization ................................. 15 64 5.1 Authentication without Authorization .......................... 15 65 5.2 Authorization without Authentication .......................... 15 66 6 Security Considerations ......................................... 16 67 7 References ...................................................... 16 68 8 Author's Address ................................................ 16 69 A Appendix A - Vulnerabilities .................................... 18 70 A.1 OPEN .......................................................... 18 71 A.2 KEEPALIVE ..................................................... 18 72 A.3 NOTIFICATION .................................................. 18 73 A.4 UPDATE ........................................................ 18 74 A.4.1 Unfeasible Routes Length, Total Path Attribute Length ....... 18 75 A.4.2 Withdrawn Routes ............................................ 19 76 A.4.3 Path Attributes ............................................. 19 77 Attribute Flags, Attribute Type Codes, Attribute Length .......... 19 78 ORIGIN ........................................................... 19 79 AS_PATH .......................................................... 20 80 Originating Routes ............................................... 20 81 NEXT_HOP ......................................................... 21 82 MULTI_EXIT_DISC .................................................. 21 83 LOCAL_PREF ....................................................... 21 84 ATOMIC_AGGREGATE ................................................. 21 85 AGGREGATOR ....................................................... 22 86 A.4.4 NLRI ........................................................ 22 87 1. Introduction 89 The inter-domain routing protocol BGP was created when the Internet 90 environment had not yet reached the present contentious state. 91 Consequently, the BGP protocol was not designed with protection against 92 deliberate or accidental errors causing disruptions of routing behavior. 94 We here discuss the vulnerabilities of BGP, based on the BGP RFC [1]. 95 We propose several different security solutions to protect these 96 vulnerabilities, discuss the benefits derived from each solution and its 97 cost. 99 It is clear that the Internet is vulnerable to attack through its 100 routing protocols. BGP is no exception. Faulty, misconfigured or 101 deliberately malicious sources can disrupt overall Internet behavior by 102 injecting bogus routing information into the BGP distributed routing 103 database (by modifying, forging, or replaying BGP packets). The same 104 methods can also be used to disrupt local and overall network behavior 105 by breaking the distributed communication of information between BGP 106 peers. The sources of bogus information can be either non-BGP peers or 107 true BGP peers. 109 As an IP protocol, BGP is subject to all the IP attacks, like IP 110 spoofing, session stealing, SYN attacks, etc. Under the present BGP 111 design, any non-BGP peer source can inject believable BGP packets into 112 the communication between BGP peers and thereby inject bogus routing 113 information or break the peer to peer connection. With IP spoofing, the 114 non-BGP peer sources of bogus BGP information can reside anywhere in the 115 world. Furthermore, non-BGP peer sources can disrupt communications 116 between BGP peers by breaking their TCP connection with spoofed RST 117 packets. BGP speakers themselves can inject bogus routing information 118 masquerading as information from any other legitimate BGP speaker. 119 Bogus information from either non-BGP or BGP sources can affect routing 120 behavior in the Internet over a wide, possibly unbounded, area. 122 Bogus routing information can have many different effects on routing 123 behavior. If the bogus information removes routing information for a 124 particular network, that network can become unreachable for the portion 125 of the Internet that accepts the bogus information. If the bogus 126 information changes the route to a network, then packets destined for 127 that network may be forwarded by a sub-optimal path, or a path that does 128 not follow the expected policy, or a path that will not forward the 129 traffic. Traffic to that network could be delayed or the network could 130 become unreachable from areas where the bogus information is accepted. 131 If the bogus information makes it appear that an autonomous system 132 originates a network when it does not, then packets for that network may 133 not be deliverable for the portion of the Internet that accepts the 134 bogus information. A false announcement that an autonomous systems 135 originates a network may also fragment aggregated address blocks in 136 other parts of the Internet and cause routing problems for other 137 networks. 139 2. Vulnerabilities 141 There are four different BGP message types - OPEN, KEEPALIVE, 142 NOTIFICATION, and UPDATE. A discussion of the vulnerabilities arising 143 from each message and the ability of non-BGP peers or BGP peers to 144 exploit the vulnerabilities is contained in Appendix A. Suffice it to 145 say here that non-BGP peers can use bogus OPEN, KEEPALIVE, or 146 NOTIFICATION messages to disrupt the BGP peer-peer connections and can 147 use bogus UPDATE messages to disrupt routing. Non-BGP peers can also 148 disrupt BGP peer-peer connections by inserting bogus TCP RST packets. 149 BGP peers themselves are permitted to break peer-peer connections at any 150 time, and so they cannot be said to be issuing "bogus" OPEN, KEEPALIVE 151 or NOTIFICATION messages. However, BGP peers can disrupt routing by 152 issuing bogus UPDATE messages. In particular, bogus ATOMIC_AGGREGATE 153 and AS_PATH attributes and bogus NLRI in UPDATE messages can disrupt 154 routing. 156 3. Possible Protections 158 3.1. Threats from non-BGP peers 160 Non-BGP peers can be prevented from disrupting routing by providing 161 cryptographic protection of the BGP peer-peer connection. The 162 cryptography chosen should protect the source authenticity and integrity 163 of the message and should also protect against replay. As the 164 protection is only of the peer-peer communications, asymmetric 165 cryptography is not needed. Protection against spoofing in the peer- 166 peer connection could be provided by: 168 IP level protection as defined by IPSEC [7] 170 TCP level protection as defined by [8] 172 BGP level protection as defined by [9] 174 Prevention of IP spoofing completely removes any risk associated with 175 bogus OPEN, KEEPALIVE, or NOTIFICATION messages, as the only 176 vulnerabilities from these messages come from non-BGP peers. It also 177 protects against all threats from bogus UPDATE messages and from bogus 178 TCP messages arising from non-BGP peers. 180 3.1.1. IP level protection 182 Protection as specified for the IPSEC AH header [7] can be used to 183 provide connectionless integrity, data origin authentication, and an 184 optional anti-replay service. 186 3.1.2. TCP level protection 188 It is possible to protect the peer-peer connection by applying 189 cryptographic protection at the TCP level to provide connectionless 190 integrity and data origin authentication. This has been in use with 191 some vendors for some time as specified in [8]. Note, however, that the 192 protections specified in [8] were put in place some time ago. The IPSEC 193 protections have advanced since that time. In particular, the 194 protections of [8] use MD5 directly, where the IPSEC protections mandate 195 the use of HMAC-MD5 because of recently publicized concerns of 196 collisions in MD5. Also, [8] does not have the provisions for anti- 197 reply found in IPSEC. The TCP sequence numbers do provide some 198 protection against replay. But as some packets, notably a RST packet, 199 need only be within the receive window to be accepted, the TCP sequence 200 number protection is not complete. Finally, [8] has no provisions for 201 multiple keys to be used in rekeying. As these are pairwise keys used 202 for long-lived sessions, the inability to specify multiple keys may not 203 cause operational difficulties. 205 Although the TCP level protection specified in [8] has deficiencies when 206 compared with the protection of IPSEC [7], it is vastly preferable to a 207 unprotected connection. If IPSEC is not available, then the TCP level 208 protection of [8] should definitely be used. When IPSEC is available, 209 IPSEC is preferable. 211 3.1.3. BGP level protection 213 Cryptographic protection of the peer-peer connection at the BGP level is 214 specified in [9]. Note that applying the cryptographic protection 215 within BGP does not provide the same protection as applying it within 216 TCP, as TCP information other than the payload (BGP) data, particularly 217 the RST field, could still be spoofed in ways that would harm the 218 connection. 220 3.2. Threats from BGP peers 222 Protection of the communication between BGP peers does nothing to 223 protect against errors introduced by the BGP speakers themselves. BGP 224 speakers can introduce bogus routing information, e.g., invalid 225 AS_PATHs, incorrect announcements of NLRI, etc., at any time. 226 Furthermore, detecting the BGP peer of bogus information (if and when 227 the bogus-ness is detected) can be difficult if not impossible. 229 There are several possible solutions to prevent a BGP speaker from 230 inserting bogus information in its advertisements to its peers. 232 (1) sign the originating AS. 234 (2) sign the originating AS and predecessor information 236 (3) sign the originating AS, and nest signatures of AS_PATHs to the 237 number of consecutive bad routers you want to prevent from causing 238 damage. 240 (4) rely on a registry to say if AS_PATH and originating AS are valid 242 3.3. Sign Originating AS 244 It would be beneficial to know which AS has first advertised a route to 245 a NLRI. This could be done by including a new field which would contain 246 the originating AS number and the originating AS's digital signature [3] 247 of that plus the NLRI advertised. A digital signature is required 248 because the number and identities of all eventual recipients could not 249 be known and because non-repudiation would be desired. This field could 250 be verified against an Internet registry, if a complete and accurate 251 registry existed. If routing was disturbed by the presence of this 252 advertisement, then the culprit could be determined. 254 If a structure exists representing ownership of network addresses, then 255 the owner as well as the advertiser could sign. A representation of an 256 owner could be useful when Internet service providers transfer sub- 257 blocks of their owned addresses to smaller ISP's. The ISP's could 258 advertise NLRI but the ownership of the network could still be 259 determined. 261 If routes are aggregated by a BGP speaker and the aggregated route 262 advertised, then the idea of "originator" and "owner" become less 263 useful. There might be several "originators" and "owners" represented 264 among the aggregated routes. We suggest that the AGGREGATOR field 265 become mandatory and that an aggregating BGP speaker append its 266 signature of the AGGREGATOR field and the aggregated NLRI. 267 Unfortunately, aggregation prevents identification of the specific 268 culprit should it be discovered that a network is being originated in 269 error. 271 3.4. Sign Originating AS and Predecessor Information 273 Reference [2] suggests several different types of cryptographic 274 protection of BGP. The suggested protection against possibly faulty BGP 275 speakers introduces some link state topology information (see [4]) that 276 can be used to verify AS_PATHs. 278 To obviate the need to trust BGP speakers regarding NLRI information not 279 specific to their own AS, [2] suggests adding the following information 280 to the UPDATE message: 282 - the AS originating the information (either the aggregator or the 283 advertiser of a direct route) and 285 - the predecessor of the originating AS (i.e., the neighbor to which 286 the NLRI is first advertised). 288 This field is digitally signed along with the NLRI, the 289 ATOMIC_AGGREGATE, and other fields of the UPDATE message. The signature 290 and the predecessor information must be included as the route in the 291 UPDATE message propagates across the network, i.e., it is transitive. 293 This information distributes a bit of link state topology information, 294 concerning just the last hop before the destination network's AS, into 295 the usual BGP distance vector (some say "path vector") protocol. Each 296 BGP speaker, even those who are transit only and originate no UPDATE 297 messages with NLRI contained in their own AS, will transmit this 298 "predecessor" information. From all the signed predecessor information 299 received, it would be possible to verify that each of the adjacencies 300 represented in an AS_PATH is legitimate. When a segment of an AS_PATH 301 is a sequence, each adjacent pair in the sequence must correspond to a 302 received signed predecessor tuple. 304 The protection provided by the signed predecessor information becomes 305 more difficult to use past an aggregation point where a BGP speaker 306 advertises a less specific route which includes the NLRI. In 307 particular, the rules for verifying an AS_PATH containing a segment that 308 is a set would be either very lenient or very complex. 310 While this predecessor information assures that each adjacency in a 311 sequence of an AS_PATH is valid, it does not ensure that the AS_PATH as 312 a whole is valid. Each AS's decision regarding routes it will advertise 313 and traffic it will transit is individual and totally unconstrained. 314 The fact that a valid path of ASs exists to a destination does not 315 ensure that the corresponding AS_PATH is valid. This mechanism also 316 does not assure that any information which comes from one router alone 317 (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. A router, then, 318 can still falsely announce that its neighbor should be forwarded the 319 traffic for an NLRI. 321 3.5. Sign Originating AS and AS_PATH 323 A protection against possibly faulty BGP speakers that does provide some 324 assurance that the AS_PATH is valid involves nested digital signatures 325 of the AS_PATH. 327 Each BGP speaker would receive signed AS_PATH information (including the 328 ATOMIC_AGGREGATE attribute and NLRI) from its peer. After making its 329 routing decision, it would augment the chosen AS_PATH with its own AS 330 and sign the resulting route (NLRI + AS_PATH) and ATOMIC_AGGREGATE. The 331 BGP speaker would pass to its peers the augmented AS_PATH, its 332 signature, and the signature it received from its peer which covers the 333 base AS_PATH from which the augmented AS_PATH was formed. The peer 334 receiving this information can verify that the received AS_PATH was 335 indeed constructed with some basis in reality by verifying the signature 336 of the BGP speaker's peer over the tail of the received AS_PATH. The 337 BGP speaker's signature will be passed on by the peer to provide similar 338 assurance that it constructed its advertised AS_PATH legitimately. 340 This procedure as described protects against one consecutive faulty 341 router in the path. If it is desired to protect against more possibly 342 faulty routers in the path, then the procedure can be nested 343 arbitrarily. To protect against K consecutive faulty routers, each 344 router would receive signed AS_PATH information from its neighbor along 345 with K signatures of the preceding K BGP speakers in the path, each 346 successive signature covering a shorter suffix of the AS_PATH. It would 347 pass on a newly constructed AS_PATH along with its own signature, its 348 neighbor's signature and K-1 of the included nested signatures. 350 A BGP speaker could snip out a suffix of the data it received as well as 351 the associated signatures and pass those on as the proof that its 352 AS_PATH was based on reality. To prevent this, the signatures generated 353 should cover not only the route information but the intended receiver as 354 well. 356 For example, consider a case where it was decided to protect against 357 only one faulty BGP speaker. Suppose AS1 receives an AS_PATH from AS2 358 of 'AS2 AS3 ... ASk'. (In this discussion as well as the next, 359 ATOMIC_AGGREGATE will be included in the signature, but is omitted for 360 brevity.) Then AS1 should also receive AS2's signature of "AS1, 'AS2 AS3 361 ... ASk', Ni" and AS3's signature of "AS2, 'AS3 ... ASk', Ni". AS1 362 would compute a path as 'AS1 AS2 AS3 ... ASk', and pass on to AS0 this 363 path along with its signature of "AS0, 'AS1 AS2 AS3 ... ASk', Ni" and 364 AS2's signature of "AS1, 'AS2 AS3 ... ASk', Ni". 366 The procedure in its full glory is as follows, where sign(A,B,C)[ASk] 367 means the signature of the data A,B,C generated with the key belonging 368 to ASk: 370 Given that it has been decided to protect against K faulty BGP 371 speakers: 373 When AS0 receives an UPDATE with AS_PATH 'ASi ... ASj' for NLRI N, 374 it 376 - verifies the signature from the UPDATE: 378 sign(AS0,'ASi ... ASj', N)[ASi], 380 this is a sanity check 382 - verifies the K signatures from the UPDATE: 384 sign(ASi,'ASi+1 ... ASj', N)[ASi+1], 385 sign(ASi+1,'ASi+2 ... ASj', N)[ASi+2], ... , 386 sign(ASi+K-1, 'ASi+K ... ASj', N)[ASi+K] 388 If any signature fails to validate, then ASi did not have a 389 valid basis for the route sent to AS0. AS0 should drop the 390 route. 392 When AS0 chooses the AS_PATH 'ASi ... ASj' for NLRI N to send to 393 its neighbor ASn, it 395 - signs (ASn, 'AS0 ASi ... ASj', N)[AS0] and includes it in the 396 UPDATE 398 - sends the K signatures in the UPDATE: 400 sign(AS0,'ASi ... ASj', N)[ASi], 401 sign(ASi,'ASi+1 ... ASj', N)[ASi+1], ... , 402 sign(ASi+K-2, 'ASi+K-1 ... ASj', N)[ASi+K-1] 404 This discussion is predicated on the use of asymmetric cryptography. 405 Each autonomous system would be required to possess an asymmetric key 406 pair. The public key would have to be accessible to all recipients of 407 the digital signature. The private key would have to be available to 408 all BGP speakers in the autonomous system, but protected from exposure. 409 Alternatively, each BGP speaker could possess its own asymmetric key 410 pair, at the cost of further complicating the protocol. The protocol 411 would have to be altered to include the identity of the BGP speaker 412 within the AS who produces the AS_PATH and signature so that the 413 signature verification procedure could choose the correct public key to 414 use. Each BGP speaker with N peers needs to generate N signatures for 415 each route announced, one for each peer. 417 Symmetric cryptography could be used to protect the information by using 418 a keyed cryptographic hash instead of a digital signature. However, in 419 order to provide the same level of protection against faulty routing, 420 each BGP speaker would have to share a different secret key with each of 421 its neighbors and each of its neighbors' neighbors. For N peers, each 422 with M peers, this means N*M+N keys and N*M+M keyed cryptographic hashes 423 of each update. (In the case that it is desired to protect against k>1 424 faulty BGP speakers, the number of keys would grow exponentially - a 425 different key with all neighbors, 2-hops-away neighbors, 3-hops-away 426 neighbors, and k+1-hop-away neighbors.) This is obviously not a scalable 427 solution. It may also require autonomous systems to reveal their 428 peering agreements where they would not wish to do so. 430 3.5.1. Special Considerations 432 Note that this scheme becomes more complicated when one of the BGP 433 speakers performs aggregation of a set of routes. To assure recipients 434 of the validity of the aggregated route, it would be necessary to pass 435 on the text and signatures of each of the aggregated component routes. 436 This means an enormous increase in transmission bandwidth at each 437 aggregation point and a similar increase in verification time at each 438 verification point's peers. This cost would not have to be passed on to 439 further neighbors further than K (the nesting level of signatures) hops 440 away, but it does violate the spirit of aggregation. Alternatively, an 441 aggregation point could be treated as another type of origination point, 442 and signatures and verification would stop at that point. 443 Unfortunately, that provides a mechanism for malicious BGP peers to 444 announce bogus routes, simply by claiming to have aggregated the 445 information. Aggregation also prevents identification of the specific 446 culprit should it be discovered that a network is being originated in 447 error. 449 Note that this scheme does not assure that the received route is the 450 best route the peer could have computed. In particular, it does not 451 guard against a peer that does not announce the best result of its 452 decision process - a peer that replays previous announcements, perhaps, 453 or does not change its announcements when it receives withdrawn routes, 454 or replays withdrawal information after a route is reestablished. These 455 are a matter for the internal correct operation of the router and cannot 456 be precluded by security protection. This mechanism also does not 457 assure that any information which comes from one router alone 458 (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. With these 459 fields, a router can still falsely announce that its neighbor should be 460 forwarded the traffic for an NLRI. 462 Note that the verification process chooses the key to use based on the 463 AS's mentioned in the AS_PATH. If it is valid for a BGP speaker not to 464 prepend its own AS to the AS_PATH before transmitting it to a peer, i.e. 465 if a BGP speaker is allowed to pass on an AS_PATH in which it's own AS 466 is not the first in the PATH, then the AS's mentioned in the AS_PATH are 467 not necessarily the AS's that produced the signature. In that case, 468 this verification process could be using the wrong key. This signature 469 scheme would have to be complicated by requiring either 471 that the sender's AS be included in the UPDATE message and the 472 signature (so that the verification process could find the 473 appropriate key for the signature) 475 or that each sender know the private key of the first AS in the 476 AS_PATH (so that the signature and verification processes would be 477 using the same key). 479 Sharing keys between AS's makes those AS's indistinguishable to the 480 cryptography; the second alternative design should only be chosen with 481 that caution clearly understood. 483 3.6. Rely on Registries 485 The Internet registries can provide data that will help to assure that 486 AS_PATHS and NLRI origination data are correct. If the data registered 487 in the Internet registries can be assumed to be correct, then the 488 peering information in the database can be used to verify each pair of 489 AS's in an AS_PATH sequence segment are truly peers. Depending on the 490 sophistication of the information recorded in the registry, the 491 registries might also be used to verify that the AS_PATH as a whole was 492 valid. 494 The assurance provided by this protection would rely on the completeness 495 of the registry, on the authenticity of the registry data and on the 496 protection it received in storage and transit. The protection is useful 497 if data from the registry is either available locally or retrievable 498 with an acceptable lag time. 500 The assurance provided by this protection also relies on the openness of 501 the data recorded in the registries. To be truly useful, each 502 autonomous system's policy would have to be recorded in the registry, in 503 order that the AS_PATH as a whole can be verified to be valid. 504 Information about policy, however, can be sensitive to an autonomous 505 system and not openly available to every other autonomous system. Any 506 restrictions on the availability of information stored in the registry 507 will restrict its applicability as a protection mechanism. 509 4. Security Costs 511 Choosing the protection to apply in any situation depends on the 512 perception of the risk of attack, of the damage that can result, of the 513 benefits derived from providing the protection, and of the cost of 514 providing the protection. This section discusses the cost of each of 515 the protection options mentioned above. 517 4.1. Protecting the Peer-Peer Link 519 The cost of this protection is the processing required for the 520 cryptography and the need to establish and manage the cryptographic 521 keys. The cryptography need not be computationally expensive; HMAC or 522 similar algorithms can be used. Shared secret keys are adequate for 523 this protection, as the protection applies only to the communication 524 between peers, so the key management cost is low. Ideally, a separate 525 key should be used for each BGP peering. One key might be used for 526 multiple peerings with a reduction in the level of protection that is 527 provided. However, it is best to remember that apocryphally, the more 528 places know a secret, the more chances it will be exposed. 530 This level of protection is low cost and protects against the vast 531 number of possible adversaries (i.e., any non-BGP speaker in the 532 internet). 534 4.2. Sign Originating AS 536 The cost of signing the originating AS of each route is the cost of 537 providing a public key infrastructure to generate an asymmetric key pair 538 for each autonomous system and to distribute and maintain the public 539 keys associated with each autonomous system. 541 4.3. Sign Originating AS and Predecessor Information 543 This scheme requires the same public key infrastructure as is needed if 544 one simply signs the originating AS information. It also requires that 545 each adjacency for a BGP speaker be signed (the "predecessor" 546 information) and transmitted along with an AS_PATH. Essentially, each 547 BGP speaker must announce its peers, something that does not currently 548 occur in the BGP protocol. Each BGP speaker must compute one signature 549 for each NLRI in each UPDATE message transmitted and must verify one 550 signature for each NLRI in each UPDATE message received. (Each UPDATE 551 message must be separately signed because the mechanism described in [2] 552 includes a sequence number, the Withdrawn Routes and the Unfeasible 553 Route Length fields, so the information to be signed changes with each 554 message. These fields are protected from non-BGP peers by the peer-peer 555 communication protection and so do not need to be digitally signed. If 556 only the NLRI, ATOMIC_AGGREGATE and predecessor information were signed 557 each time, then the signature might not have to be computed with each 558 new UPDATE message, i.e., AS_PATH changes would not induce new signature 559 computations.) The predecessor information in each route must be stored 560 by the recipient indefinitely. Each route received must be verified by 561 comparison to the store of predecessor information previously received 562 in UPDATE messages from all AS sources. 564 4.4. Sign Originating AS and AS_PATH 566 This scheme requires the same public key infrastructure as is needed if 567 one simply signs the originating AS information. For each UPDATE 568 message received, K signatures (the level of protection from consecutive 569 faulty routers) must be verified per NLRI included in the UPDATE. For 570 each UPDATE message transmitted, one signature must be computed for each 571 NLRI per recipient. As discussed before, prevention of cut and paste 572 attacks requires that the signature include the recipient, so computing 573 one signature per AS_PATH and NLRI announced is insufficient. 575 4.5. Rely on Registries 577 The cost of relying on registries would vary considerably depending on 578 the protection provided to the information in storage and in transit. 580 Any latency, above that caused by the use of cryptography, would depend 581 on the mechanism used to protect the registry information (e.g., 582 anything from frequent complete download to real-time query and 583 response). 585 5. Authentication vs Authorization 587 5.1. Authentication without Authorization 589 Each of the schemes described above provide authentication of the 590 information received. This is not sufficient for secure operation - the 591 BGP participants also need assurance that a BGP announcing a route is 592 authorized to announce that route. Signing the predecessor information, 593 nesting signatures of the AS_PATH, or consulting the registry for AS 594 peering arrangements help to prove that a BGP peer has a valid authority 595 for announcing a route (either that the connectivity exists or that the 596 peer based the route on a valid route from its peer). None of the 597 schemes provide any assurance that a BGP speaker originating an NLRI is 598 authorized to advertise that NLRI. 600 Authorization implies an authority to which one can refer. To prove the 601 authority to originate an NLRI, there must be an infrastructure for 602 assigning NLRI to autonomous systems. The Internet registries could 603 serve as this authority, providing the registry itself contained valid 604 information, the communication with the registry was secure, etc. Work 605 is ongoing to provide assurance about information contained in the 606 registries using RPS [5]. Other proposals suggest using the DNS inverse 607 lookup tree as a distributed mechanism for maintaining authorization 608 information [6]. 610 5.2. Authorization without Authentication 612 Schemes have been proposed to provide authorization for AS announcements 613 of NLRI. As mentioned above, work is ongoing to provide for 614 authorization and authentication of network assignments to autonomous 615 systems, of peering agreements, transit policies, etc., for those 616 Internet registries employing the RPS [5]. Another scheme proposes to 617 use the DNS reverse lookup tree, CNAMES and a new AS resource record to 618 associate networks with autonomous systems [6]. These mechanisms 619 provide assurance that the AS announcing an NLRI is authorized to do so, 620 but they will not provide assurance of the authenticity of the source of 621 the announcement. This provides protection against misconfigured or 622 faulty BGP speakers accidentally announcing bogus direct connections to 623 NLRI, but not against malicious BGP speakers making deliberate bogus 624 announcements. Protected Internet registries can also be used to verify 625 authorization for AS_PATH information, as long as autonomous systems 626 maintain complete information of their peering agreements and transit 627 policies in the registries. 629 6. Security Considerations 631 This entire memo is about security considerations. 633 7. References 635 [1] RFC1771, A Border Gateway Protocol 4 (BGP-4). Y. Rekhter & T. Li. 636 March 1995. 638 [2] B. Smith and J.J. Garcia-Luna-Aceves, ``Securing the Border Gateway 639 Routing Protocol,'' Proc. Global Internet'96, London, UK, 20-21 640 November 1996. 642 [3] Bruce Schneier. Applied Cryptography Protocols, Algorithms, and 643 Source Code in C, John Wiley & Sons, Inc 1994. 645 [4] RFC 1583, OSPF Version 2. John Moy. March 1994. 647 [5] Curtis. Villamizar, Cenzig. Alaettinoglu, David. Meyer, Sandy. 648 Murphy and Carol. Orange. "Routing Policy System Security", May 649 15, 1998. Work in progress, available as <> at Internet-Drafts Shadow Directories. 652 [6] Tony Bates, Randy Bush, Tony Li and Yakov Rekhter. "DNS-based NLRI 653 origin AS verification in BGP", February 6, 1998. Work in 654 progress, available as <> 655 at Internet-Drafts Shadow Directories. 657 [7] RFC1826, IP Authentication Header. R. Atkinson. August 1995. 659 [8] RFCnnn, Protection of BGP Sessions via the TCP MD5 Signature 660 Option. A. Heffernan. August 1998. 662 [9] T. Przygienda, "BGP-4 MD5 Authentication", 5 November 1997. Work 663 in progress, available as <> at 664 Internet-Drafts Shadow Directories. 666 8. Author's Address 668 Sandra Murphy 669 Trusted Information Systems 670 3060 Washington Road 671 Glenwood, MD 21738 672 EMail: Sandy@tis.com 673 A. Appendix A - Vulnerabilities 675 Each message introduces certain different vulnerabilities: 677 A.1. OPEN 679 Because receipt of a new OPEN message in the Established state will 680 cause the close of the BGP peering session and thereby induce the 681 release of all resources and deletion of all associated routes, the 682 ability to spoof this message can lead to a severe disruption of 683 routing. 685 A.2. KEEPALIVE 687 Receipt of a KEEPALIVE message when the peering connection is in the 688 OpenSent state can lead to a failure to establish a connection. The 689 ability to spoof this message is a vulnerability. To exploit this 690 vulnerability deliberately, the KEEPALIVE must be carefully timed in the 691 sequence of messages exchanged between the peers or it causes no damage. 693 A.3. NOTIFICATION 695 Receipt of a NOTIFICATION message will cause the close of the BGP 696 peering session and thereby induce the release of all resources and 697 deletion of all associated routes. Therefore, the ability to spoof this 698 message can lead to a severe disruption of routing. 700 A.4. UPDATE 702 The Update message carries the routing information. The ability to 703 spoof any part of this message can lead to a disruption of routing. 705 A.4.1. Unfeasible Routes Length, Total Path Attribute Length 707 There is a vulnerability arising from the ability to modify these 708 fields. If a length is modified, the message is not likely to parse 709 properly, resulting in an error, the transmission of a NOTIFICATION 710 message and the close of the connection. As a true BGP speaker is 711 always able to close a connection at any time, this vulnerability 712 represents an additional risk only when the source is a non-BGP speaker, 713 i.e., it presents no additional risk from BGP sources. 715 A.4.2. Withdrawn Routes 717 A non-BGP peer could cause the elimination of existing legitimate routes 718 by forging or modifying this field. A non-BGP peer could also cause the 719 elimination of reestablished routes by replaying this withdrawal 720 information from earlier packets. 722 A BGP speaker could "falsely" withdraw feasible routes using this field. 723 However, as the BGP speaker is authoritative for the routes it will 724 announce, it is allowed to withdraw any previously announced routes that 725 it wants. As the receiving BGP speaker will only withdraw routes 726 associated with the sending BGP speaker, there is no opportunity for a 727 BGP speaker to withdraw another BGP speaker's routes. Therefore, there 728 is no additional vulnerability from BGP peers via this field. 730 A.4.3. Path Attributes 732 The path attributes present many different vulnerabilities. 734 Attribute Flags, Attribute Type Codes, Attribute Length 736 A BGP peer or a non-BGP peer could modify the attribute length or 737 attribute type (flags and type codes) so they did not reflect the 738 attribute values that followed. If the length were modified, the likely 739 result would be that the UPDATE message would not parse correctly. If 740 the flags were modified, the flags and type code could become 741 incompatible (i.e., a mandatory attribute marked as partial), or a 742 optional attribute could be interpreted as a mandatory attribute or vice 743 versa. Modifying the type code could cause the attribute value to be 744 interpreted as if it were the data type and value of a different 745 attribute. The most likely result from modifying the attribute flags or 746 type code would be a parse error of the UPDATE message. A parse error 747 from any modification would cause the transmission of a NOTIFICATION 748 message and the close of the connection. As a true BGP speaker is 749 always able to close a connection at any time, this vulnerability 750 represents an additional risk only when the source is a non-BGP peer, 751 i.e., it presents no additional risk from BGP peer. 753 ORIGIN 755 This field indicates whether the information was learned from IGP or EGP 756 information. If the route is used in inter-AS multicast routing, a 757 values of INCOMPLETE may be used. This field is not used in making 758 routing decisions, so there are no vulnerabilities arising from this 759 field, either from BGP peers or non-BGP peers. 761 AS_PATH 763 A BGP peer or non-BGP peer could announce an AS_PATH that was not 764 accurate for the associated NLRI. Forwarding for the NLRI associated 765 with the AS_PATH could potentially be induced to follow a sub-optimal 766 path, a path that did not follow some intended policy, or even a path 767 that would not forward the traffic. 769 It is not clear how far an inaccurate AS_PATH could deviate from the 770 true AS_PATH. It may be that the first AS in the AS_PATH, at least, 771 must be a legal hop. The RFC states that a BGP speaker prepends its own 772 AS to an AS_PATH before announcing it to a neighbor. If the BGP speaker 773 must prepend its own AS, then a BGP speaker that produced a bogus 774 AS_PATH could end up receiving the traffic for the associated NLRI. 775 This could be desirable if the error was deliberate and the intent was 776 to receive traffic that would not otherwise be received. Receiving the 777 mis-routed traffic could be undesirable for the faulty BGP speaker if it 778 were not prepared to handle the extra (mis-routed) traffic. So, if a 779 BGP peer must prepend its own AS to the AS_PATH, it might be encouraged 780 or discouraged from inventing an arbitrary AS_PATH, depending on its 781 resources and intent. If BGP peers need not prepend its own AS, then a 782 malicious BGP peer could announce a path that begins with the AS of any 783 BGP speaker with little impact on itself. 785 Whether such an arbitrary AS_PATH is a vulnerability would depend on 786 whether BGP implementations check the AS_PATH (to see if the first AS is 787 the neighbor) and would catch the error. If there are legitimate 788 situations in which a BGP speaker could pass an AS_PATH to a neighbor 789 without putting its own AS at the head of the AS_PATH, then there is no 790 way for implementations to detect totally bogus AS_PATHs. 792 Originating Routes 794 A special case of announcing a false AS_PATH occurs when the AS_PATH 795 advertises a direct connection to a specific network address. An BGP 796 peer or non-BGP peer could disrupt routing to the network(s) listed in 797 the NLRI field by falsely advertising a direct connection to the 798 network. The NLRI would become unreachable to the portion of the 799 network that accepted this false route, unless the ultimate AS on the 800 AS_PATH undertook to tunnel the packets it was forwarded for this NLRI 801 on toward their true destination AS by a valid path. But even when the 802 ultimate AS tunnels the packets on to the correct destination AS, the 803 route followed may not be optimal or may not follow the intended policy. 804 Additionally, routing for other networks in the Internet could be 805 affected if the false advertisement fragmented an aggregated address 806 block. 808 NEXT_HOP 810 The NEXT_HOP attribute defines the IP address of the border router that 811 should be used as the next hop when forwarding the NLRI listed in the 812 UPDATE message. If the recipient is an external peer, then the 813 recipient and the NEXT_HOP address must share a subnet. It is clear 814 that a non-BGP peer modifying this field could disrupt the forwarding of 815 traffic between the two AS's. 817 In the case that the NEXT_HOP address is an inter-AS peer and the 818 recipient of the message is an inter-AS peer of a different AS (this is 819 one of two forms of "third party" NEXT_HOP), then the BGP speaker 820 advertising the route has the opportunity to direct the recipient to 821 forward traffic to a BGP speaker (the NEXT_HOP peer) that may not be 822 able to continue forwarding the traffic. It is unclear whether this 823 would also require the advertising BGP speaker to construct an AS_PATH 824 mentioning the NEXT_HOP inter-AS peer's AS. 826 MULTI_EXIT_DISC 828 The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted 829 between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an 830 inter-AS peer may be propagated within an AS, it may not be propagated 831 to other AS's. Consequently, this field is only used in making routing 832 decisions internal to one AS. Modifying this field, whether by an non- 833 BGP peer or an BGP peer, could influence routing within an AS to be 834 sub-optimal, but the effect should be limited in scope. 836 LOCAL_PREF 838 The LOCAL_PREF attribute must be included in all messages with internal 839 peers and excluded from messages with external peers. Consequently, 840 modification of the LOCAL_PREF could effect the routing process within 841 the AS only. Note that there is no requirement in the BGP RFC that the 842 LOCAL_PREF be consistent among the internal BGP speakers of an AS. As 843 BGP peers are free to choose the LOCAL_PREF as they wish, modification 844 of this field is a vulnerability with respect to non-BGP peers only. 846 ATOMIC_AGGREGATE 848 The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way 849 has received a more specific and a less specific route to the NLRI and 850 installed the aggregated route. This route cannot be de-aggregated 851 because it is not certain that the route to more specific prefixes will 852 follow the listed AS_PATH. Consequently, BGP speakers receiving a route 853 with ATOMIC_AGGREGATE are restricted from making the NLRI any more 854 specific. Removing the ATOMIC_AGGREGATE attribute would remove the 855 restriction, possibly causing traffic intended for the more specific 856 NLRI to be routed incorrectly. Adding the ATOMIC_AGGREGATE attribute 857 when no aggregation was done would have little effect, beyond 858 restricting the un-aggregated NLRI from being made more specific. This 859 vulnerability exists whether the source is a BGP peer or a non-BGP peer. 861 AGGREGATOR 863 This field may be included by a BGP speaker who has computed the routes 864 represented in the UPDATE message from aggregation of other routes. The 865 field contains the AS number and IP address of the last aggregator of 866 the route. It is not used in making any routing decisions, so it does 867 not represent a vulnerability. 869 A.4.4. NLRI 871 By modifying or forging this field, either a non-BGP peer or BGP peer 872 source could cause disruption of routing to the announced network, 873 overwhelm a router along the announced route, cause data loss when the 874 announced route will not forward traffic to the announced network, route 875 traffic by a sub-optimal route, etc.