idnits 2.17.1 draft-ng-sobgp-bgp-extensions-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([SOBGP-CERTIFICATE], [SOBGP-DEPLOY], [BGP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 146: '... pair of BGP speakers MAY negotiate to...' RFC 2119 keyword, line 156: '... tion SHOULD be transmitted by a spe...' RFC 2119 keyword, line 194: '... transmitted, they MUST be transmitted...' RFC 2119 keyword, line 317: '... [SOBGP-CERTIFICATE] of any certificate received MUST be compared...' RFC 2119 keyword, line 320: '...in a local database MUST be discarded....' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o All certificates received and placed in the local certificate database, and not marked as validated, should be readvertised to trusted iBGP peers; they MUST not be marked as VALIDATED. -- 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 (April 2004) is 7308 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) == Unused Reference: 'MULTIPROTOCOL-BGP' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'SOBGP-RADIUS' is defined on line 694, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2858 (ref. 'MULTIPROTOCOL-BGP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 2842 (ref. 'CAPABILITY') (Obsoleted by RFC 3392) -- No information found for draft-white-sobgp-deployment - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SOBGP-DEPLOY' == Outdated reference: A later version (-04) exists of draft-weis-sobgp-certificates-01 -- Possible downref: Normative reference to a draft: ref. 'SOBGP-CERTIFICATE' == Outdated reference: A later version (-02) exists of draft-retana-bgp-custom-decision-00 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2385 (ref. 'BGP-MD5') (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group James Ng 3 Internet Draft (editor) 4 Expiration Date: October 2004 Cisco Systems 5 File Name: draft-ng-sobgp-bgp-extensions-02.txt April 2004 7 Extensions to BGP to Support Secure Origin BGP (soBGP) 8 draft-ng-sobgp-bgp-extensions-02.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its Areas, and its Working Groups. Note that other 17 groups may also distribute working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http//www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http//www.ietf.org/shadow.html. 31 1. Contributors 33 A large number of people contributed to or provided valuable feedback 34 on this document; we've tried to include all of them here (in no 35 particular order), but might have missed a few: Russ White, Alvaro 36 Retana, Dave Cook, John Scudder, David Ward, Martin Djernaes, Chris 37 Lonvick, Brian Weiss, Tim Gage, Scott Fanning, Barry Friedman, Jim 38 Duncan, Yi Yang, Robert Adams, Tony Tauber, Iljitsch van Beijnum, and 39 Jonathan Natale. 41 2. Abstract 43 There is a great deal of concern over the security of routing systems 44 within the Internet, particularly in relation to the Border Gateway 45 Protocol [BGP], which is used to provide routing information between 46 autonomous systems. This document proposes a system where the origin 47 of any advertisement within BGP can be verified and authenticated, 48 preventing the advertisement of prefix blocks by unauthorized 49 networks, and verifying that the final destination in the path is 50 actually within the autonomous system to which the packets are being 51 routed. 53 This document does not: 55 o Attempt to provide information on how such a security system 56 could or should be deployed; readers are referenced to [SOBGP- 57 DEPLOY] for this discussion. 59 o Attempt to determine what sorts of keys should be used within 60 such a system, nor how any sort of trust relationship can or 61 should be built between the entities cooperating within the 62 routing system. These are considered in [SOBGP-CERTIFICATE]. 64 o Attempt to analyse the performance, memory utilization, or other 65 impacts on devices running this protocol; these are addressed in 66 [SOBGP-DEPLOY]. 68 o Attempt to analyse the security protection provided by the pro- 69 posed security system. 71 This document primarily focuses on extensions to the BGP protocol 72 itself to support such a security system. This document is to solve 73 several vulnerabilities within a BGP routing system given the follow- 74 ing constraints and assumptions: 76 o Any signalling which must take place to provide security should 77 be specified in as flexible a way as possible. For instance, any 78 certificates exchanged may be solely contained with the BGP pro- 79 tocol, or through some other transport/distribution mechanism. 80 [SOBGP-DEPLOY] contains more discussion on this issue. 82 o The proposed solution should be incrementally deployable, and 83 require minimal changes in a network to support it (software 84 changes only along the path where support is required, for 85 instance). 87 o The proposed solution should not rely on the routing system it 88 is securing to reach information necessary to secure the routing 89 system (reliance on an IGP to reach destinations within a rout- 90 ing domain is acceptable, but reliance on BGP to reach destina- 91 tions outside the routing domain is unacceptable). 93 o The operator may configure various levels of trust, preferring 94 faster convergence over security validtion, or more immediate 95 and stronger security validation over convergence times. 97 o All routing information received from peering relationships 98 within an autonomous system is implicitly trusted. 100 o No current optimizations in implementations of the BGP protocol 101 should be affected, if possible. 103 It's important to note that any given security system is a tradeoff 104 between several factors, including the actual security provided and 105 the difficulty entailed in deploying the system; different solutions 106 may provide different levels of protection between these, leaving 107 some parts of the problem unsolved. 109 This proposal does not protect against: 111 o Attacks through all forms of autonomous system spoofing. This 112 proposal can be subverted if an attacker is able to masquerade 113 as an autonomous system under some network conditions. It is 114 assumed that management of inter-AS connections and policy 115 implementation can resolve these possible attacks. 117 o Path Authentication. While this system allows the path any given 118 update advertises to be checked against paths known to be valid, 119 it does not ensure this particular update provides the best 120 path. It is observed that there are many possible valid paths 121 within a BGP routing system, and BGP itself is designed to find 122 the correct path among the possible paths. 124 o Authentication of path attributes, such as the community and MED 125 attributes passed with a prefix. 127 The IETF has been notified of intellectual property rights claimed in 128 regard to some or all of the specification contained in this docu- 129 ment. For more information consult the online list of claimed rights. 131 3. Definitions 133 o Entity: A participant in the internetwork routing system. 135 4. The Security Message 137 This document proposes a new message type, the SECURITY message, 138 which is to be used for carrying security information within the BGP 139 protocol. The SECURITY message is type 6. The SECURITY message is 140 used to transport the certificates described in [SOBGP-CERTIFICATE]. 142 4.1. Negotiating Security Capability 144 The ability to exchange SECURITY messages shall be negotiated at ses- 145 sion startup, as described in [CAPABILITY]. The capability code is 146 . A pair of BGP speakers MAY negotiate to 147 send messages in the SECURITY message type only (exchange no NLRI or 148 forwarding information). 150 If two BGP speakers have negotiated to exchange SECURITY messages, 151 they should exchange the certificates contained in their local data- 152 bases. 154 If two speakers have negotiated to exchange SECURITY messages and 155 NLRI messages (as described in [BGP]), no NLRI or SECURITY informa- 156 tion SHOULD be transmitted by a speaker other than a SECURITY Option 157 message until it receives a SECURITY Option message from its peer. 159 4.2. The Security Message Format 161 The SECURITY message is formatted as described in [BGP], with a type 162 code of 6. Within each message is a series of TLVs, or security mes- 163 sage blocks, formatted as: 165 0 1 2 3 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 167 +-------------------------------+-------------------------------+ 168 | Type | Length | 169 +-------------------------------+-------------------------------+ 170 | Data | 171 +--------- 173 o Type: A two octet unsigned integer describing the type of infor- 174 mation contained within the data field. 176 o Length: A two octet unsigned integer describing the length of 177 the data field, in octets. 179 o Data: The data, as described within this and other documents 180 which describe information to be carried within the SECURITY 181 message type. 183 Two TLVs are currently defined within the SECURITY message. 184 Further TLVs are defined for carrying certificates in [SOBGP- 185 CERTIFICATE]. 187 4.2.1. The SECURITY Option TLV 189 The SECURITY Option TLV provides a way for exchanging speakers to 190 inform their peers about local configurations which may pertain to 191 the peering session. SECURITY Option TLVs are encapsulated within a 192 TLV Type 1, and transmitted within the SECURITY message type. 194 If SECURITY Option TLVs are transmitted, they MUST be transmitted 195 before the transmission of any other SECURITY data. 197 0 1 2 3 198 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 199 +-------------------------------+-------------------------------+ 200 | TLV Type | Length | 201 +-------------------------------+-------------------------------+ 202 | Options | 203 +---------------------------------------------------------------+ 205 o TLV type: (2 octets), 1 (0x0001) 207 o Length: (2 octets), set to 2 209 o Options: (4 octets), a bitfield, described below 211 The options field is a 32 bit bitfield, allowing up to 32 different 212 options to be specified. 214 o Bit 0: If set, indicates that SECURITY information should be 215 sent before NLRI information on this session; if cleared, indi- 216 cates that NLRI information should be sent before SECURITY 217 information. 219 o Bit 1: If set, indicates that this peer will only transmit vali- 220 dated certificates of any type along this session (valid only on 221 iBGP sessions). 223 o Bit 2: If set, indicates that this peer will only accept vali- 224 dated certificates of any type along this session (valid only on 225 iBGP sessions). 227 Bit 0 in the option field allows the operator to configure the local 228 device so it receives all prefixes first, decreasing convergence to 229 the minimum time, or receives all SECURITY information first, allow- 230 ing all prefixes to be validated before they are installed. 232 Bits 1 and 2 allow peers along an iBGP session to trust the certifi- 233 cations they receive without validating them. If bit 1 is set on the 234 transmitting peer, and bit 2 is set on the receiving peer, the 235 receiving peer may accept all received certificates from the 236 transmitting peer as already validated. 238 4.2.2. The Request TLV 240 0 1 2 3 241 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 242 +-------------------------------+-------------------------------+ 243 | TLV Type | Request Type | 244 +-------------------------------+-------------------------------+ 245 | Length | Reserved | 246 +-------------------------------+-------------------------------+ 247 | Request Indicator SubTV | 248 +--------------------------- 250 o TLV type: (2 octets), 2 252 o Request Type: (2 octets), treated as an unsigned integer indi- 253 cating the type of the type of information requested. 255 o Length: (2 octets), set to the total length of the request in 256 octets. 258 o Reserved: (2 octets), set to 0x0000. 260 o Request Indicator: The information indicated by the request type 261 bit field. 263 The Request Type field indicates the type of certificates requested. 264 Three request types are defined in this document. 266 1 Any certificate matching the Request Indicator are requested. 268 2 EntityCerts matching the Request Indicator are requested. 270 3 ASPolicyCerts matching the Request Indicator are requested. 272 4 PrefixPolicyCerts matching the Request Indicator are requested. 274 Request indicator SubTVs restrict the set of certificates returned; 275 there may be one or more request indicator SubTVs included in a 276 request. Each SubTV consists of a two octet type field, treated as an 277 unsigned integer, and a fixed length field containing the request 278 indicator. 280 o Type 1: A four octet origin/authorized AS Number; two octet AS 281 numbers shall be right justified within this field (placed in 282 the two least significant octets). 284 o Type 2: A four octet signer/authorizer AS Number; two octet AS 285 numbers shall be right justified within this field (placed in 286 the two least significant octets). 288 o Type 3: A four octet IPv4 address is included in the request 289 indicator. 291 o Type 4: A sixteen octet IPv6 address is included in the request 292 indicator. 294 o Type 5: An eight octet starting serial number is included in the 295 request indicator. 297 o Type 6: An eight octet ending serial number is included in the 298 request indicator. 300 5. Receiving and Processing SECURITY messages 302 The section sbelow describe the receipt and processing of SECURITY 303 messages. 305 5.1. The Level of Certificate Processing 307 Each section below describes the processing of SECURITY messages 308 based on the way in which soBGP is deployed on the BGP speaker. For 309 more information on deployment options, see [SOBGP-DEPLOY]. 311 5.1.1. Full Local Certificate Processing 313 If a BGP speaker is fully processing certificates locally, for each 314 received certificate it must: 316 o The unique identifiers (described for each certificate type in 317 [SOBGP-CERTIFICATE] of any certificate received MUST be compared 318 to the unique identifiers of certificates already held in local 319 databases. Any certificate which matches a certificate already 320 held in a local database MUST be discarded. 322 o Certificates received from untrusted peers and certificates 323 received without the VALIDATED bit set SHOULD be placed in a 324 local certificate database, and processed according to [SOBGP- 325 CERTIFICATE]. 327 o Certificates received from iBGP peers which have negotiated 328 trusted certificate exchange SHOULD placed in a local certifi- 329 cate database, and processed as though they were all sucessfully 330 validated according to the process described in [SOBGP- 331 CERTIFICATE]. 333 o All certificates received and placed in the local certificate 334 database, and marked as validated, SHOULD be readvertised to all 335 iBGP peers which have a trusted peering relationship, marked as 336 VALIDATED. Signatures SHOULD be stripped from any certificate 337 advertised to an iBGP peer with a trusted peering relationship. 339 o All certificates received and placed in the local certificate 340 database, and not marked as validated, should be readvertised to 341 trusted iBGP peers; they MUST not be marked as VALIDATED. 343 o All certificates received and placed in the local certificate 344 database should be readvertised to all BGP peers which have 345 negotiated the untrusted exchange of soBGP certificates. 347 5.1.2. No Local Cryptographic Processing 349 If a BGP speaker is accepting certificates only from trusted peering 350 relationships, for each received certificate, it must: 352 o The unique identifiers (described for each certificate type in 353 [SOBGP-CERTIFICATE] of any certificate received MUST be compared 354 to the unique identifiers of certificates already held in local 355 databases. Any certificate which matches a certificate already 356 held in a local database MUST be discarded. 358 o Certificates received from iBGP peers which have negotiated 359 trusted certificate exchange and marked as VALIDATED must be 360 placed in a local certificate database, and processed as though 361 they were all sucessfully validated according to the process 362 described in [SOBGP-CERTIFICATE]. 364 o Certificates received from any BGP peer which has not negotiated 365 trusted certificate exchange, and any received certificate which 366 is not marked as VALIDATED, should be readvertised to all BGP 367 peers which have not negotiated trusted certificate exchange. 368 These certificates MUST be discarded; they must not be stored 369 locally. 371 5.1.3. No Local Certificate Processing 373 If a BGP speaker is validating routing information through direct 374 interaction with another device performing soBGP processing, and is 375 not processing or storing certificates locally, for each soBGP certi- 376 ficate received, it must readvertise all certificates received from 377 any BGP peer to all other BGP peers which have negotiated soBGP cer- 378 tificate exchange through the SECURITY message. The BGP speaker MUST 379 NOT mark the readvertised certificates as VALIDATED. 381 5.2. Filtering of Certificates 383 A BGP speaker may, for reasons of policy, filter soBGP certificates 384 received from a peer. 386 o If a BGP speaker is part of a transit AS, it SHOULD NOT filter 387 soBGP certificates. 389 o A BGP speaker MAY discard soBGP certificates which describe the 390 authorization of address space which is being filtered out of 391 the local routing information. 393 5.3. Receiving and Processing Requests 395 If a device receives a Request TLV, as described in the section "The 396 Security Message," above, it should: 398 o Examine the request to ensure it is logically consistent. For 399 instance, requesting an Entitycert based on an IPv4 address 400 range is not logically consistent, since these certificates only 401 contain an AS and a Signer AS. 403 o If the request is not logically consistent, discard it. 405 o If the request is logically consistent, examine its local data- 406 bases, and transmit the certificates requested which fulfill the 407 conditions supplied in the request indicator SubTVs. 409 o If more than one of the same request indicator is included in a 410 request message, they shall be treated as an OR condition; if 411 any of the conditions match, the certificate shall match the 412 set. 414 6. Operation and General Requirements 416 This section discusses the processing of routing updates, validation 417 of the AS_PATH contained in routing updates, general BGP requirements 418 for autonomous systems running soBGP, and requirements for BGP ses- 419 sions exchanging soBGP certificates. 421 6.1. Receiving and Validating Prefixes 423 A local database of authorized prefix/origin AS/policy triples is 424 built using the techniques described in [SOBGP-CERTIFICATE], and used 425 to validate updates as they are received (or updates which exist in 426 the AdjRIB-In), as described in this section. This local database is 427 termed the "authorization database." 429 Since one of the goals of soBGP, stated at the beginning of this 430 document, is to impact the performance of the BGP protocol as little 431 as possible, there is no requirement to perform the steps outlined in 432 this section at any particular time in the processing of received BGP 433 updates. The validation of routes received may occur as these routes 434 are received, before they are placed in the Adj-RIB-In, periodically, 435 or some time after convergence has been attained, as determined by 436 configuration on the device validating the routes received. 438 o The local authorization database is examined, and the entries 439 with the longest prefix length which encompasses the range of 440 addresses described by the prefix is chosen. 442 o This set of entries is examined to determine if the route is 443 originated from one of the AS' listed in the set of entries. 445 o If the route is not originated from one of the AS' listed in the 446 set of entries, the route is said to be invalid, and should be 447 excluded from further consideration for installation in to the 448 local RIB. 450 o If the authorization database entry indicates the Second Hop 451 must be checked, the second hop of the AS PATH should be veri- 452 fied as described in the section "Verifying the Second Hop," 453 below. If the second hop check fails, the route is said to be 454 invalid, and should be removed from further consideration for 455 installation into the local RIB. 457 o If the authorization database indicates the AS_PATH of the 458 update must be checked, the AS PATH of the route should be veri- 459 fied, as described in the section "Verifying the AS PATH," 460 below. If the AS_PATH is not validated, the route should be 461 removbed from further consideration for installation in the 462 local RIB. 464 o Other policies contained in the local authorization database 465 should be applied as directed by the policy. 467 o If there is no entry in the local authorization database which 468 encompasses the range of addresses described by the prefix, then 469 the route is said to be unverified, and should be handled 470 according to local policy (either discarded, or have its secu- 471 rity preference lowered). 473 6.2. Aggregation 475 Aggregation is a difficult problem with any method which attempts to 476 verify the origin of any given prefix, since aggregation removes the 477 relationship between prefixes originated and originators. Prefixes 478 may only be aggregated by an entity which is otherwise authorized to 479 advertise the aggregated prefix. 481 6.3. Verifying the Path 483 In order to verify the path of any given advertisement, we propose to 484 build a directed graph of all possible transit paths within the 485 Internet, and verifying the path of each advertisement against this 486 graph. Note that for any given prefix, this graph will contain a 487 superset of all valid paths for the prefix. The BGP protocol itself 488 is designed to choose the correct path out of the possible paths. 490 In order to build the directed graph, each entity within the routing 491 system may advertise the autonomous systems it is connected to using 492 the attached AS' field carried in a certificate as described in 493 [SOBGP-CERTIFICATE]. This graph is called the PATH database. 495 6.3.1. Building and Using the Directed Graph 497 Each device verifying routing information it is receiving may build a 498 directed graph from the information contained in the Policy Certifi- 499 cate for each AS (as described above), which provides a list of all 500 known valid paths through the internetwork. Each link between a pair 501 of AS' may be verified from both ends of the link (using a two way 502 connectivity check), thus ensuring that no single AS may advertise 503 itself as connected to an entity it is not connected to. 505 As routes are validated, the AS PATH contained in the route may be 506 checked against the PATH database for congruence with a known good 507 path. If the AS PATH traverses a link which cannot be verified to 508 exist in both directions (the link fails the two way connectivity 509 check), it's security preference may be lowered or the route may be 510 discarded, as local device configuration directs. 512 6.4. Verifying the Second Hop 514 As a prefix is processed by a receiving the device, the originator 515 and second hop in the AS PATH may be checked against the authorized 516 originator and the list of attached AS' advertised by that origina- 517 tor. If the second hop in the AS path (the second entry in the AS 518 PATH) does not match one of the attached AS' advertised by the origi- 519 nator, the prefix should be treated as invalid, and discarded. 521 6.5. Requirements for Systems Running soBGP 523 There are three general requirements imposed on autonomous system 524 border routers and devices running soBGP: 526 o Any peering session along the border of an autonomous system 527 running soBGP SHOULD be authenticated through some means such as 528 [BGP-MD5], IPsec ([ESP], [AH]), or through some other current, 529 effective means of protecting BGP sessions from being hijaaked, 530 or otherwise abused. 532 o Any peering session along which soBGP certificates are exchanged 533 MUST be authenticated through some means such as [BGP-MD5], 534 IPsec ([ESP, [AH]), or through some other current, effective 535 means of protecting BGP sessions from being hijaaked, or other- 536 wise abused. 538 o The AS_PATH of any routing information received from any BGP 539 peer outside the autonomous system MUST be checked to validate 540 the next hop AS is the AS the update was received from. If the 541 next hop AS in any received update does not match the configured 542 AS the route is learned from, the update MUST be discarded. 544 7. The Security Preference 546 As indicated in other sections of this document, the user has a wide 547 range of flexibility when determining the level of security to be 548 applied to each prefix. The level of security may be translated into 549 a Security Preference and used to influence the route selection pro- 550 cess [BGP]. 552 To determine the Secuirty Preference of a prefix, the following algo- 553 rithm may be used: 555 1 A Security Preference is assigned to each prefix indicating neu- 556 tral trust. The neutral value is locally significant to the 557 autonomous system, and all routers in it MUST use the same 558 value. 560 2 The Security Preference SHOULD be lowered for any of the follow- 561 ing cases: 563 o The AS_PATH verification failed at a link other than the 564 second hop. 566 o The Second Hop verification failed. 568 o The prefix is unverified. 570 o The prefix is invalid. 572 Each of these cases represents a different degree of failure in 573 the validation and verification process. The amount by which 574 the Security Preference is lowered is locally significant to the 575 autonomous system, and all routers in it MUST use the same 576 value. If the local policy determines that a prefix may be used 577 (even if it may have failed the validation and verification pro- 578 cess), it is recommended that the Security Preference be lowered 579 such that a lower value is assigned to invalid paths. 581 3 The Security Preference SHOULD be increased for any of the 582 following cases: 584 o The prefix is validated. 586 o The Second Hop verification passed. 588 o The AS_PATH verification passed for the whole path. 590 The amount by which the Security Preference is increased is 591 locally significant to the autonomous system, and all routers in 592 it MUST use the same value. It is recommended that the Security 593 Preference be increased such that a higher value is assigned to 594 paths that pass all the validation and verification steps. 596 The resulting Security Preference value may be used to select among 597 different routes for the same prefix; the higher value MUST be pre- 598 ferred. Any of the following methods may be used: 600 A Consider the Security Preference prior to calculating the degree 601 of preference [BGP] for a prefix. 603 B Assign the value of the Security Preference to any of the attri- 604 butes used in the Decision Process [BGP]. Care must be taken 605 with attributes for which the lower value is preferred. 607 C Use a Cost Community [COST] and its associated methods to con- 608 sider the Security Preference at any step in the Decision Pro- 609 cess [BGP] without overloading other attributes. Care must be 610 taken as the lowest value in a Cost Community is preferred. 612 The method selected MUST be consistent through the local Autonomous 613 System. 615 8. Security Considerations 617 This document defines extensions to BGP that address specific secu- 618 rity concerns for the protocol. While it adds functionality, the 619 flexilibty allows it to not introduce any new security concerns. 621 9. IANA Considerations 623 This document defines the Security Message for BGP, which contains a 624 series of TLVs. IANA is expected to maintain a registry of all the 625 values defined, as follows: 627 The SECURITY message Type field : 629 o Type value 0 is reserved. 631 o Type values 1 and 2 are assigned in this document. 633 o Type values 3 through 16575 MUST be assigned using the "IETF 634 Consensus" policy defined in RFC2434 [RFC2434]. 636 o Type values 16576 through 32895 SHOULD be assigned using the 637 "Specification Required" policy defined in RFC2434 [RFC2434]. 639 o Type values 32896 through 65535 are for "Private Use" as defined 640 in RFC2434 [RFC2434]. 642 Request TLV Request Type Field: 644 o Bits 1 through 3 are assigned in this document. 646 o Bits 4 thru 8 MUST be assigned using the "IETF Consensus" pol- 647 icy defined in RFC2434 [RFC2434]. 649 o Bits 9 thru 16 are for "Private Use" as defined in RFC2434 650 [RFC2434]. 652 10. Normative References 654 [BGP] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 655 RFC 1771, March 1995. 657 [MULTIPROTOCOL-BGP] 658 Bates, T., Chandra, R., Katz, D., and Rekhter, Y., "Multiproto- 659 col Extensions for BGP-4", RFC 2858, June 2000 661 [CAPABILITY] 662 Chandra, R., Scudder, J., "Capabilities Advertisement with BGP- 663 4", RFC2842, May 2000 665 [SOBGP-DEPLOY] 666 White, R. (editor), "Architecture and Deployment Considerations 667 for Secure Origin BGP (soBGP) Deployment", draft-white-sobgp- 668 deployment-02, April 2004 670 [SOBGP-CERTIFICATE] 671 Weiss, Brian (editor), "Secure Origin BGP (soBGP) Certificates", 672 draft-weis-sobgp-certificates-01.txt, October 2003 674 11. Informative References 676 [COST] 677 Retana, A., White, R., "BGP Custom Decision Process", draft- 678 retana-bgp-custom-decision-00, October 2002. 680 [RFC2434] 681 Narten, T., Alvestrand, H., "Guidelines for Writing an IANA Con- 682 siderations Section in RFCs", RFC 2434, October 1998. 684 [BGP-MD5] 685 Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Sig- 686 nature Option", RFC2385, August 1998 688 [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload", 689 RFC 2406, November 1998. 691 [AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, 692 November 1998. 694 [SOBGP-RADIUS] 695 Lovnick, C, "RADIUS Attributes for soBGP Support", draft- 696 lonvick-sobgp-radius-04.txt, February 2004 698 12. Editor's Address 700 James Ng (Editor) 701 Cisco Systems 702 7025 Kit Creek Road 703 Research Triangle Park, NC 27709 704 jamng@cisco.com