idnits 2.17.1 draft-ietf-sidr-bgpsec-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 10, 2011) is 4703 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: '3' is defined on line 1063, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Lepinski, Ed. 3 Internet-Draft BBN 4 Intended status: Standards Track June 10, 2011 5 Expires: December 12, 2011 7 BGPSEC Protocol Specification 8 draft-ietf-sidr-bgpsec-protocol-00 10 Abstract 12 This document describes BGPSEC, an extension to the Border Gateway 13 Protocol (BGP) that provides security for the AS-PATH attribute in 14 BGP update messages. BGPSEC is implemented via a new optional non- 15 transitive BGP path attribute that carries a digital signature 16 produced by each autonomous system on the AS-PATH. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [4]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 12, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. BGPSEC Negotiation . . . . . . . . . . . . . . . . . . . . . . 3 60 3. The BGPSEC_Path_Signatures Attribute . . . . . . . . . . . . . 5 61 4. Generating a BGPSEC Update . . . . . . . . . . . . . . . . . . 7 62 4.1. Originating a New BGPSEC Update . . . . . . . . . . . . . 8 63 4.2. Propagating a Route Advertisement . . . . . . . . . . . . 11 64 5. Validating a BGPSEC Update . . . . . . . . . . . . . . . . . . 13 65 5.1. Validation Algorithm . . . . . . . . . . . . . . . . . . . 14 66 6. Algorithms and Extensibility . . . . . . . . . . . . . . . . . 18 67 6.1. Algorithm Suite Considerations . . . . . . . . . . . . . . 18 68 6.2. Extensibility Considerations . . . . . . . . . . . . . . . 19 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 71 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 72 9.1. Authors . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 9.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 24 74 10. Normative References . . . . . . . . . . . . . . . . . . . . . 24 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 1. Introduction 79 This document describes BGPSEC, a mechanism for providing path 80 security for Border Gateway Protocol (BGP) [1] route advertisements. 81 That is, a BGP speaker who receives a valid BGPSEC update has 82 cryptographic assurance that the advertised route has the following 83 two properties: 85 1. The route was originated by an AS that has been explicitly 86 authorized by the holder of the IP address prefix to originate 87 route advertisements for that prefix. 89 2. Every AS listed in the AS_Path attribute of the update explicitly 90 authorized the advertisement of the route to the subsequent AS in 91 the AS_Path. 93 This document specifies a new optional (non-transitive) BGP path 94 attribute, BGPSEC_Path_Signatures. It also describes how a BGPSEC- 95 compliant BGP speaker (referred to hereafter as a BGPSEC speaker) can 96 generate, propagate, and validate BGP update messages containing this 97 attribute to obtain the above assurances. 99 BGPSEC relies on the Resource Public Key Infrastructure (RPKI) 100 certificates that attest to the allocation of AS number and IP 101 address resources. (For more information on the RPKI, see [7] and 102 the documents referenced therein.) Any BGPSEC speaker who wishes to 103 send BGP update messages to external peers (eBGP) containing the 104 BGPSEC_Path_Signatures must have an RPKI end-entity certificate (as 105 well as the associated private signing key) corresponding to the 106 BGPSEC speaker's AS number. Note, however, that a BGPSEC speaker 107 does not require such a certificate in order to validate update 108 messages containing the BGPSEC_Path_Signatures attribute. 110 2. BGPSEC Negotiation 112 This document defines a new BGP capability [3]that allows a BGP 113 speaker to advertise to its neighbors the ability to send and/or 114 receive BGPSEC update messages (i.e., update messages containing the 115 BGPSEC_Path_Signatures attribute). 117 This capability has capability code : TBD 119 The capability length for this capability MUST be set to 3. 121 The three octets of the capability value are specified as follows. 123 Capability Value: 125 0 1 2 3 4 5 6 7 126 +---------------------------------------+ 127 | Send | Receive | Reserved | Version | 128 +---------------------------------------+ 129 | AFI | 130 +---------------------------------------+ 131 | | 132 +---------------------------------------+ 134 The high order bit (bit 0) of the first octet is set to 1 to indicate 135 that the sender is able to send BGPSEC update messages, and is set to 136 zero otherwise. The next highest order bit (bit 1) of this octet is 137 set to 1 to indicate that the sender is able to receive BGPSEC update 138 messages, and is set to zero otherwise. The next two bits of the 139 capability value (bits 2 and 3) are reserved for future use. 141 The four low order bits (4, 5, 6 and 7) of the first octet indicate 142 the version of BGPSEC for which the BGP speaker is advertising 143 support. This document defines only BGPSEC version 0 (all four bits 144 set to zero). Other versions of BGPSEC may be defined in future 145 documents. A BGPSEC speaker MAY advertise support for multiple 146 versions of BGPSEC by including multiple versions of the BGPSEC 147 capability in its BGP OPEN message. 149 If there does not exist at least one version of BGPSEC that is 150 supported by both peers in a BGP session, then the use of BGPSEC has 151 not been negotiated. (That is, in such a case, messages containing 152 the BGPSEC_Path_Signatures MUST NOT be sent.) 154 If version 0 is the only version of BGPSEC for which both peers (in a 155 BGP session) advertise support, then the use of BGPSEC has been 156 negotiated and the BGPSEC peers MUST adhere to the specification of 157 BGPSEC provided in this document. (If there are multiple versions of 158 BGPSEC which are supported by both peer, then the behavior of those 159 peers is outside the scope of this document.) 161 The second two octets contain the 16-bit Address Family Identifier 162 (AFI) which indicates the address family for which the BGPSEC speaker 163 is advertising support for BGPSEC. This document only specifies 164 BGPSEC for use with two address families, IPv4 and IPv6. BGPSEC for 165 use with other address families may be specified in future documents. 166 Note that if the BGPSEC speaker wishes to use BGPSEC with two 167 different address families (i.e., IPv4 and IPv6) over the same BGP 168 session, then the speaker must include two instances of this 169 capability (one for each address family) in the BGP OPEN message. 170 Also note that a BGPSEC speaker SHOULD NOT advertise the capability 171 of BGPSEC support for IPv6 unless it has also advertised support for 172 IPv6 [2]. 174 By indicating support for receiving BGPSEC update messages, a BGP 175 speaker is, in particular, indicating that the following are true: 177 o The BGP speaker understands the BGPSEC_Path_Signatures attribute 178 (see Section 3). 180 o The BGP speaker supports 4-byte AS numbers (see RFC 4893). 182 Note that BGPSEC update messages can be quite large, therefore any 183 BGPSEC speaker announcing the capability to receive BGPSEC messages 184 SHOULD also announce support for the capability to receive BGP 185 extended messages [5]. 187 A BGP speaker MUST NOT send an update message containing the 188 BGPSEC_Path_Signatures attribute within a given BGP session unless 189 both of the following are true: 191 o The BGP speaker indicated support for sending BGPSEC update 192 messages in its open message. 194 o The peer of the BGP speaker indicated support for receiving BGPSEC 195 update messages in its open message. 197 3. The BGPSEC_Path_Signatures Attribute 199 The BGPSEC_Path_Signatures attribute is a new optional (non- 200 transitive) BGP path attribute. 202 This document registers a new attribute type code for this attribute 203 : TBD 205 The BGPSEC_Path_Signatures attribute has the following structure: 207 BGPSEC_Path_Signatures Attribute 209 +---------------------------------------------------------+ 210 | Expire Time (8 octets) | 211 +---------------------------------------------------------+ 212 | Sequence of one or two Signature-List Blocks (variable) | 213 +---------------------------------------------------------+ 215 Expire Time contains a binary representation of a time as an unsigned 216 integer number of (non-leap) seconds that have elapsed since midnight 217 UTC January 1, 1970. The Expire Time indicates the latest point in 218 time that the route advertised in the update message can possibly be 219 considered valid (see Section 5 for details on validity of BGPSEC 220 update messages). 222 The BGPSEC_Path_Signatures attribute will contain one or two 223 Signature-List Blocks, each of which corresponds to a different 224 algorithm suite. Each of the Signature-List Blocks will contain a 225 signature segment for each AS in the AS Path attribute. In the most 226 common case, the BGPSEC_Path_Signatures attribute will contain only a 227 single Signature-List Block. However, in order to enable a 228 transition from an old algorithm suite to a new algorithm suite, it 229 will be necessary to include two Signature-List Blocks (one for the 230 old algorithm suite and one for the new algorithm suite) during the 231 transition period. 233 Signature-List Block 235 +---------------------------------------------+ 236 | Algorithm Suite Identifier (1 octet) | 237 +---------------------------------------------+ 238 | Signature-List Block Length (2 octets) | 239 +---------------------------------------------+ 240 | Sequence of Signature-Segments (variable) | 241 +---------------------------------------------+ 243 An algorithm suite consists of a digest algorithm and a signature 244 algorithm. This version of BGPSEC only supports signature algorithms 245 that produce a signatures of fixed length. Future registrations of 246 algorithm suites for BGPSEC must specify the length of signatures 247 produced by the algorithm suite. This specification creates an IANA 248 registry of one-octet BGPSEC algorithm suite identifiers (see Section 249 8). 251 The Signature-List Block Length is the total number of octets in all 252 Signature-Segments (i.e., the total size of the variable-length 253 portion of the Signature-List block.) 255 A Signature-Segment has the following structure: 257 Signature Segments 259 +-------------------------------------------- + 260 | Subject Key Identifier Length (1 octet) | 261 +---------------------------------------------+ 262 | Subject Key Identifier (variable) | 263 +---------------------------------------------+ 264 | Signature (fixed by algorithm suite) | 265 +---------------------------------------------+ 267 The Subject Key Identifier Length contains the size (in octets) of 268 the value in the Subject Key Identifier field of the Signature- 269 Segment. The Subject Key Identifier contains the value in the 270 Subject Key Identifier extension of the RPKI end-entity certificate 271 that is used to verify the signature (see Section 5 for details on 272 validity of BGPSEC update messages). 274 The Signature contains a digital signature that protects the NLRI, 275 the AS_Path and the BGPSEC_Path_Signatures attribute (see Sections 4 276 and 5 for details on generating and verifying this signature, 277 respectively). The length of the Signature field is a function of 278 the algorithm suite for a given Signature-List Block. The 279 specification for each BGPSEC algorithm suite must provide the length 280 of signatures constructed using the given algorithm suite. 282 4. Generating a BGPSEC Update 284 Sections 4.1 and 4.2 cover two cases in which a BGPSEC speaker may 285 generate an update message containing the BGPSEC_Path_Signatures 286 attribute. The first case is that in which the BGPSEC speaker 287 originates a new route advertisement (Section 4.1). That is, the 288 BGPSEC speaker is constructing an update message in which the only AS 289 to appear in the AS Path attribute is the speaker's own AS (normally 290 appears once but may appear multiple times if AS prepending is 291 applied). The second case is that in which the BGPSEC speaker 292 receives a route advertisement from a peer and then decides to 293 propagate the route advertisement to an external (eBGP) peer (Section 294 4.2). That is, the BGPSEC speaker has received a BGPSEC update 295 message and is constructing a new update message for the same NLRI in 296 which the AS Path attribute will contain AS number(s) other than the 297 speaker's own AS. 299 In the remaining case where the BGPSEC speaker is sending the update 300 message to an internal (iBGP) peer, the BGPSEC speaker populates the 301 BGPSEC_Path_Signatures attribute by copying the 302 BGPSEC_Path_Signatures attribute from the received update message. 304 That is, the BGPSEC_Path_Signatures attribute is copied verbatim. 305 Note that in the case that a BGPSEC speaker chooses to forward to an 306 iBGP peer a BGPSEC update message that has not been successfully 307 validated (see Section 5), the BGPSEC_Path_Signatures attribute 308 SHOULD NOT be removed. (See Section 7 for the security ramifications 309 of removing BGPSEC signatures.) 311 The information protected by the signature on a BGPSEC update message 312 includes the AS number of the peer to whom the update message is 313 being sent. Therefore, if a BGPSEC speaker wishes to send a BGPSEC 314 update to multiple BGP peers, it MUST generate a separate BGPSEC 315 update message for each unique peer AS to which the update message is 316 sent. 318 A BGPSEC update message MUST advertise a route to only a single NLRI. 319 This is because a BGPSEC speaker receiving an update message with 320 multiple NLRI is unable to construct a valid BGPSEC update message 321 (i.e., valid path signatures) containing a subset of the NLRI in the 322 received update. If a BGPSEC speaker wishes to advertise routes to 323 multiple NLRI, then it MUST generate a separate BGPSEC update message 324 for each NLRI. 326 Note that in order to create or add a new signature to a Signature- 327 List Block for a given algorithm suite, the BGPSEC speaker must 328 possess a private key suitable for generating signatures for this 329 algorithm suite. Additionally, this private key must correspond to 330 the public key in a valid Resource PKI end-entity certificate whose 331 AS number resource extension includes the BGPSEC speaker's AS number. 332 Note also new signatures are only added to a BGPSEC update message 333 when a BGPSEC speaker is generating an update message to send to an 334 external peer (i.e., when the AS number of the peer is not equal to 335 the BGPSEC speaker's own AS number). Therefore, a BGPSEC speaker who 336 only sends BGPSEC update messages to peers within its own AS, it does 337 not need to possess any private signature keys. 339 4.1. Originating a New BGPSEC Update 341 In an update message that originates a new route advertisement (i.e., 342 an update whose AS_Path contains, possibly multiple occurrences of, a 343 single AS number), the BGPSEC speaker creates one Signature-List 344 Block for each algorithm suite that will be used. Typically, a 345 BGPSEC speaker will use only a single algorithm suite. However, to 346 ensure backwards compatibility during a period of transition from a 347 'current' algorithm suite to a 'new' algorithm suite, it will be 348 necessary to originate update messages containing Signature-List 349 Blocks for both the 'current' and the 'new' algorithm suites (see 350 Section 6.1). 352 The Resource PKI enables the legitimate holder of IP address 353 prefix(es) to issue a signed object, called a Route Origination 354 Authorization (ROA), that authorizes a given AS to originate routes 355 to a given set of prefixes (see [6]).Note that validation of a BGPSEC 356 update message will fail (i.e., the validation algorithm, specified 357 in Section 5.1, returns 'Not Good') unless there exists a valid ROA 358 authorizing the first AS in the AS PATH attribute to originate routes 359 to the prefix being advertised. Therefore, a BGPSEC speaker SHOULD 360 NOT originate a BGPSEC update advertising a route for a given prefix 361 unless there exists a valid ROA authorizing the BGPSEC speaker's AS 362 to originate routes to this prefix. 364 The Expire Time field is set to specify a time at which the route 365 advertisement specified in the update message will cease to be valid. 366 Once the Expire Time has been reached, all BGPSEC speakers who have 367 received the advertisement will treat it as invalid. The purpose of 368 this field is to protect the BGPSEC speaker against attacks in which 369 the BGPSEC speaker wishes to withdraw the route, but intermediate 370 (malicious) BGP speakers fail to propagate the withdrawal to their 371 peers. 373 It is therefore necessary for the originating BGPSEC speaker to issue 374 a new BGPSEC update prior to reaching the Expire Time. It is 375 RECOMMENDED that a BGPSEC speaker originate a new route advertisement 376 for a given NLRI at intervals equal to roughly one-third the validity 377 period of the route advertisement. (Note that it is necessary to add 378 some small amount of random jitter to the interval to avoid 379 synchronization effects.) For instance, if a BGPSEC speaker is 380 originating route advertisements that are valid for one day (i.e., 381 the Expire Time is 24 hours after the generation of the update 382 message), then it is recommended that the BGPSEC speaker re-issue new 383 a new BGPSEC update message for advertising the given prefix roughly 384 once every 8 hours (plus or minus a small random value). 386 (Editor's Note: The parameter recommendations in the previous 387 paragraph are preliminary and will need to be updated based on 388 further implementation and deployment experience.) 390 There is a natural trade-off in setting the Expire Time. Setting a 391 later Expire Time increases the amount of time by which a malicious 392 intermediate can delay a future route withdrawal. Similarly, setting 393 a later Expire Time also increases the window of opportunity for 394 malicious replay attacks in which a previous BGPSEC announcement is 395 replayed while suppressing a more recent withdrawal for the same 396 prefix. However, setting a sooner Expire Timed increases the 397 frequency with which the BGPSEC speaker needs to send new 398 announcements for the given prefix. 400 When originating a new route advertisement, each Signature-List Block 401 MUST consist of a single Signature-Segment. The following describes 402 how the BGPSEC speaker populates the fields of the Signature-List 403 Block (see Section 3 for more information on the syntax of Signature- 404 List Blocks). 406 The Subject Key Identifier field (see Section 3) is populated with 407 the identifier contained in the Subject Key Identifier extension of 408 the RPKI end-entity certificate used by the BGPSEC speaker. This 409 Subject Key Identifier will be used by recipients of the route 410 advertisement to identify the proper certificate to use in verifying 411 the signature. 413 The Subject Key Identifier Length field is populated with the length 414 (in octets) of the Subject Key Identifier. 416 The Signature field contains a digital signature that binds the NLRI, 417 AS_Path attribute and BGPSEC_Path_Signatures attribute to the RPKI 418 end-entity certificate used by the BGPSEC speaker. The digital 419 signature is computed as follows: 421 o Construct a sequence of octets by concatenating the Expire Time, 422 Target AS Number, Origin AS Number, Algorithm Suite Identifier, 423 and NLRI. The Target AS Number is the AS to whom the BGPSEC 424 speaker intends to send the update message. (Note that the Target 425 AS number is the AS number announced by the peer in the OPEN 426 message of the BGP session within which the update is sent.) The 427 Origin AS number prepend to this sequence the Target AS (the AS to 428 whom the BGPSEC speaker intends to send the update message) and 429 the Origin AS Number refers to the AS of the BGPSEC speaker who is 430 originating the route advertisement. 432 Sequence of Octets to be Signed 433 +---------------------------------------+ 434 | Expire Time (8 octets) | 435 +---------------------------------------+ 436 | Target AS Number (4 octets) | 437 +---------------------------------------+ 438 | Origin AS Number (4 octets) | 439 +---------------------------------------+ 440 | Algorithm Suite Identifier (1 octet) | 441 +---------------------------------------+ 442 | NLRI Length (1 octet) | 443 +---------------------------------------+ 444 | NLRI Prefix (variable) | 445 +---------------------------------------+ 447 o Apply to this octet sequence the digest algorithm (for the 448 algorithm suite of this Signature-List) to obtain a digest value. 450 o Apply to this digest value the signature algorithm, (for the 451 algorithm suite of this Signature-List) to obtain the digital 452 signature. Then populate the Signature Field with this digital 453 signature. 455 4.2. Propagating a Route Advertisement 457 When a BGPSEC speaker receives a BGPSEC update message containing a 458 BGPSEC_Path_Signatures algorithm (with one or more signatures) from a 459 (internal or external) peer, it may choose to propagate the route 460 advertisement by sending to its (internal or external) peers by 461 creating a new BGPSEC advertisement for the same prefix. 463 A BGPSEC speaker MUST NOT generate an update message containing the 464 BGPSEC_Path_Signatures attribute unless it has selected, as the best 465 route to the given prefix, a route that it received in an update 466 message containing the BGPSEC_Path_Signatures attribute. In 467 particular, this means that whenever a BGPSEC speaker generates an 468 update message with a BGPSEC_Path_Signatures attribute that it will 469 possess a received update message for the same prefix that also 470 contains a BGPSEC_Path_Signatures attribute. 472 Additionally, whenever a BGPSEC speaker selects as the best route to 473 a given prefix a route that it received in an update message 474 containing the BGPSEC_Path_Signatures attribute, it is RECOMMENDED 475 that if the BGPSEC speaker chooses to propagate the route that it 476 generate an update message containing the BGPSEC_Path_Signatures 477 attribute. However, a BGPSEC speaker MAY propagate a route 478 advertisement by generating a (non-BGPSEC) update message that does 479 not contain the BGPSEC_Path_Signatures attribute. (See Section 7 for 480 discussion of the security ramifications of removing BGPSEC 481 signatures.) 483 If the BGPSEC speaker is producing an update message which contains 484 an AS-SET (e.g., the BGPSEC speaker is performing proxy aggregation), 485 then the BGPSEC speaker MUST NOT include the BGPSEC_Path_Signatures 486 attribute. In such a case, the BGPSEC speaker must remove any 487 existing BGPSEC_Path_Signatures in the received advertisement(s) for 488 this prefix and produce a standard (non-BGPSEC) update message. 490 To generate the BGPSEC_Path_Signatures attribute on the outgoing 491 update message, the BGPSEC first copies the Expire Time directly from 492 the received update message to the new update message (that it is 493 constructing). Note that the BGPSEC speaker MUST NOT change the 494 Expire Time as any change to Expire Time will cause the new BGPSEC 495 update message to fail validation (see Section 5). 497 The BGPSEC speaker next removes from the BGPSEC_Path_Signatures 498 attribute any Signature-List Blocks corresponding to algorithm suites 499 that it does not support. The BGPSEC_Path_Signatures attribute for 500 the new update message SHOULD contain a Signature-List Block for 501 every algorithm suite that is both present in the received update 502 message and which is supported by the BGPSEC speaker. 504 Note that the validation algorithm (see Section 5.1) deems a BGPSEC 505 update message to be 'Good' if there is at least one supported 506 algorithm suite (and corresponding Signature-List Block) that is 507 deemed 'Good'. This means that a 'Good' BGPSEC update message may 508 contain Signature-List Blocks which are deemed 'Not Good' (e.g., 509 contain signatures that the BGPSEC is unable to verify). 510 Nonetheless, such Signature-List Blocks MUST NOT be removed. (See 511 Section 7 for a discussion of the security ramifications of this 512 design choice.) 514 For each Signature-List Block corresponding to an algorithm suite 515 that the BGPSEC speaker does support, the BGPSEC speaker then adds a 516 new Signature-Segment to the Signature-List Block. This Signature- 517 Segment is prepended to the list of Signature-Segments (placed in the 518 first position) so that the list of Signature-Segments appears in the 519 same order as the corresponding AS numbers in the AS-Path attribute. 520 The BGPSEC speaker populates the fields of this new signature-segment 521 as follows. 523 The Subject Key Identifier field in the new segment is populated with 524 the identifier contained in the Subject Key Identifier extension of 525 the RPKI end-entity certificate used by the BGPSEC speaker. This 526 Subject Key Identifier will be used by recipients of the route 527 advertisement to identify the proper certificate to use in verifying 528 the signature. 530 The Subject Key Identifier Length field is populated with the length 531 (in octets) of the Subject Key Identifier. 533 The Signature field in the new segment contains a digital signature 534 that binds the NLRI, AS_Path attribute and BGPSEC_Path_Signatures 535 attribute to the RPKI end-entity certificate used by the BGPSEC 536 speaker. The digital signature is computed as follows: 538 o Construct a sequence of octets by concatenating the signature 539 field of the most recent Signature-Segment (the one corresponding 540 to AS from whom the BGPSEC speaker's AS received the announcement) 541 with the Target AS (the AS to whom the BGPSEC speaker intends to 542 send the update message). Note that the Target AS number is the 543 AS number announced by the peer in the OPEN message of the BGP 544 session within which the BGPSEC update message is sent. 546 Sequence of Octets to be Signed 548 +-----------------------------------------------------------+ 549 | Most Recent Signature Field (fixed by algorithm suite) | 550 ------------------------------------------------------------+ 551 | Target AS Number (4 octets) | 552 +-----------------------------------------------------------+ 554 o Apply to this octet sequence the digest algorithm (for the 555 algorithm suite of this Signature-List) to obtain a digest value. 557 o Apply to this digest value the signature algorithm, (for the 558 algorithm suite of this Signature-List) to obtain the digital 559 signature. Then populate the Signature Field with this digital 560 signature. 562 5. Validating a BGPSEC Update 564 Validation of a BGPSEC update messages makes use of data from RPKI 565 certificates and signed Route Origination Authorizations (ROA). In 566 particular, to validate update messages containing the 567 BGPSEC_Path_Signatures attribute, it is necessary that the recipient 568 have access to the following data obtained from valid RPKI 569 certificates and ROAs: 571 o For each valid RPKI end-entity certificate containing an AS Number 572 extension, the AS Number, Public Key and Subject Key Identifier 573 are required 575 o For each valid ROA, the AS Number and the list of IP address 576 prefixes 578 Note that the BGPSEC speaker could perform the validation of RPKI 579 certificates and ROAs on its own and extract the required data, or it 580 could receive the same data from a trusted cache that performs RPKI 581 validation on behalf of (some set of) BGPSEC speakers. 583 To validate a BGPSEC update message containing the 584 BGPSEC_Path_Signatures attribute, the recipient performs the 585 validation steps specified in Section 5.1. The validation procedure 586 results in one of two states: 'Good' and 'Not Good'. 588 It is expected that the output of the validation procedure will be 589 used as an input to BGP route selection. However, BGP route 590 selection and thus the handling of the two validation states is a 591 matter of local policy, and shall be handled using existing local 592 policy mechanisms. It is expected that BGP peers will generally 593 prefer routes received via 'Good' BGPSEC update messages over routes 594 received via 'Not Good' BGPSEC update messages as well as routes 595 received via update messages that do not contain the 596 BGPSEC_Path_Signatures attribute. However, BGPSEC specifies no 597 changes to the BGP decision process and leaves to the operator the 598 selection of an appropriate policy mechanism to achieve the 599 operator's desired results within the BGP decision process. 601 BGPSEC validation need only be performed at eBGP edge. The 602 validation status of a BGP signed/unsigned update MAY be conveyed via 603 iBGP from an ingress edge router to an egress edge router. Local 604 policy in the AS determines the specific means for conveying the 605 validation status through various pre-existing mechanisms (e.g., 606 modifying an attribute). As discussed in Section 4, when a BGPSEC 607 speaker chooses to forward a (syntactically correct) BGPSEC update 608 message, it SHOULD be forwarded with its BGPSEC_Path_Signatures 609 attribute intact (regardless of the validation state of the update 610 message). Based entirely on local policy settings, an egress router 611 MAY trust the validation status conveyed by an ingress router or it 612 MAY perform its own validation. 614 5.1. Validation Algorithm 616 This section specifies an algorithm for validation of BGPSEC update 617 messages. A conformant implementation MUST include an BGPSEC update 618 validation algorithm that is functionally equivalent to the external 619 behavior of this algorithm. 621 First, the recipient of a BGPSEC update message performs a check to 622 ensure that the message is properly formed. Specifically, the 623 recipient performs the following checks: 625 o Check to ensure that the entire BGPSEC_Path_Signatures attribute 626 is syntactically correct (conforms to the specification in this 627 document). 629 o Check to ensure that the AS-Path attribute contains no AS-Set 630 segments. 632 o Check that each Signature-List Block contains one Signature- 633 Segment for each AS in the AS-Path attribute. (Note that the 634 entirety of each Signature-List Block must be checked to ensure 635 that it is well formed, even though the validation process may 636 terminate before all signatures are cryptographically verified.) 638 If there are two Signature-List Blocks within the 639 BGPSEC_Path_Signatures attribute and one of them is poorly formed (or 640 contains the wrong number of Signature-Segments) , then the recipient 641 should log that an error occurred, strip off that particular 642 Signature-List Block and process the update message as though it 643 arrived with a single Signature-List Block. If the 644 BGPSEC_Path_Signatures attribute contains a syntax error which is not 645 local to a single Signature-List Block, or if the AS-Path attribute 646 contains an AS-Set segment, then the recipient should log that an 647 error occurred, strip off the BGPSEC_Path_Signatures attribute and 648 process the update message as though it arrived without a 649 BGPSEC_Path_Signatures attribute. 651 Second, the BGPSEC speaker verifies that the update message has not 652 yet expired. To do this, locate the Expire Time field in the 653 BGPSEC_Path_Signatures attribute, and compare it with the current 654 time. If the current time is later than the Expire Time, the BGPSEC 655 update is 'Not Good' and the validation algorithm terminates. 657 Third, the BGPSEC speaker verifies that the origin AS is authorized 658 to advertise the prefix in question. To do this, consult the valid 659 ROA data to obtain a list of AS numbers that are associated with the 660 given IP address prefix in the update message. Then locate the last 661 (least recently added) AS number in the AS-Path. If the origin AS in 662 the AS-Path is not in the set of AS numbers associated with the given 663 prefix, then BGPSEC update message is 'Not Good' and the validation 664 algorithm terminates. 666 Finally, the BGPSEC speaker examines the Signature-List Blocks in the 667 BGPSEC_Path_Signatures attribute. Any Signature-List Block 668 corresponding to an algorithm suite that the BGPSEC speaker does not 669 support MUST be discarded. If all Signature-List Blocks are 670 discarded in this manner then the BGPSEC speaker MUST treat the 671 update message as though it arrived without a BGPSEC_Path_Signatures 672 attribute. 674 For each remaining Signature-List Block (corresponding to an 675 algorithm suite supported by the BGPSEC speaker), the BGPSEC speaker 676 iterates through the Signature-Segments in the Signature-List block, 677 starting with the most recently added segment (and concluding with 678 the least recently added segment). Note that there is a one-to-one 679 correspondence between Signature-Segments and AS numbers in the AS- 680 Path attribute, and the following steps make use of this 681 correspondence. 683 o (Step I): Locate the public key needed to verify the signature (in 684 the current Signature-Segment). To do this, consult the valid 685 RPKI end-entity certificate data and look for an SKI that matches 686 the value in the SKI field of the Signature-Segment. If no such 687 SKI value is found in the valid RPKI data then mark the entire 688 Signature-List Block as 'Not Good' and proceed to the next 689 Signature-List Block. Similarly, if the SKI exists but the AS 690 Number associated with the SKI does NOT match the AS Number (in 691 the AS-Path attribute) which corresponds to the current Signature- 692 Segment, then mark the entire Signature-List Block as 'Not Good' 693 and proceed to the next Signature-List Block. 695 o (Step II): Compute the digest function (for the given algorithm 696 suite) on the appropriate data. If the segment is not the (least 697 recently added) segment corresponding to the origin AS, then the 698 digest function should be computed on the following sequence of 699 octets: 701 Sequence of Octets to be Hashed 703 +-------------------------------------------------+ 704 | Signature Field in the Next Segment (variable) | 705 --------------------------------------------------+ 706 | AS Number of Subsequent AS (4 octets) | 707 +-------------------------------------------------+ 709 The 'Signature Field in the Next Segment' is the Signature field 710 found in the Signature-Segment that is next to be processed (that is, 711 the next most recently added Signature- Segment). 713 For the first segment to be processed (the most recently added 714 segment), the 'AS Number of Subsequent AS' is the AS number of the 715 BGPSEC speaker validating the update message. Note that if a BGPSEC 716 speaker uses multiple AS Numbers (e.g., the BGPSEC speaker is a 717 member of a confederation), the AS number used here MUST be the AS 718 number announced in the OPEN message for the BGP session over which 719 the BGPSEC update was received. 721 For each other Signature-Segment, the 'AS Number of Subsequent AS' is 722 the AS that corresponds to the Signature-Segment added immediately 723 after the one being processed. (That is, find the AS number 724 corresponding to the Signature-Segment currently being processed and 725 the 'AS Number of Subsequent AS' is the next AS number that was added 726 to the AS-Path attribute.) 728 Alternatively, if the segment being processed corresponds to the 729 origin AS, then the digest function should be computed on the 730 following sequence of octets: 732 Sequence of Octets to be Hashed 734 +----------------------------------------+ 735 | Expire Time (8 octets) | 736 -----------------------------------------+ 737 | AS Number of Subsequent AS (4 octets) | 738 +----------------------------------------+ 739 | Origin AS Number (4 octets) | 740 +----------------------------------------+ 741 | Algorithm Suite Identifier (1 octet) | 742 +----------------------------------------+ 743 | NLRI Length (1 octet) | 744 +----------------------------------------+ 745 | NLRI Prefix (variable) | 746 +----------------------------------------+ 748 The NLRI Length, NLRI Prefix, Expire Time, and Algorithm Suite 749 Identifier are all obtained in a straight forward manner from the 750 NLRI of the update message or the BGPSEC_Path_Signatures attribute 751 being validated. 753 The Origin AS Number is the same Origin AS Number that was located in 754 Step I above. (That is, the AS number corresponding to the least 755 recently added Signature-Segment.) 757 The 'AS Number of Subsequent AS' is the AS Number added to the AS- 758 Path immediately after the Origin AS Number. (That is, the second AS 759 Number that was added to the AS Path.) 761 o (Step III): Use the signature validation algorithm (for the given 762 algorithm suite) to verify the signature in the current segment. 763 That is, invoke the signature validation algorithm on the 764 following three inputs: the value of the Signature field in the 765 current segment; the digest value computed in Step II above; and 766 the public key obtained from the valid RPKI data in Step I above. 768 If the signature validation algorithm determines that the 769 signature is invalid, then mark the entire Signature-List Block as 770 'Not Good' and proceed to the next Signature-List Block. If the 771 signature validation algorithm determines that the signature is 772 valid, then continue processing Signature-Segments (within the 773 current Signature-List Block). 775 If all Signature-Segments within a Signature-List Block pass 776 validation (i.e., all segments are processed and the Signature-List 777 Block has not yet been marked 'Not Good'), then the Signature-List 778 Block is marked as 'Good'. 780 If at least one Signature-List Block is marked as 'Good', then the 781 validation algorithm terminates and the BGPSEC update message is 782 deemed to be 'Good'. (That is, if a BGPSEC update message contains 783 two Signature-List Blocks then the update message is deemed 'Good' if 784 the first Signature-List block is marked 'Good' OR the second 785 Signature-List block is marked 'Good'.) 787 6. Algorithms and Extensibility 789 6.1. Algorithm Suite Considerations 791 Note that there is currently no support for bilateral negotiation 792 between BGPSEC peers to use of a particular (digest and signature) 793 algorithm suite using BGP capabilities. This is because the 794 algorithm suite used by the sender of a BGPSEC update message must be 795 understood not only by the peer to whom he is directly sending the 796 message, but also by all BGPSEC speakers to whom the route 797 advertisement is eventually propagated. Therefore, selection of an 798 algorithm suite cannot be a local matter negotiated by BGP peers, but 799 instead must be coordinated throughout the Internet. 801 To this end, a mandatory algorithm suites document will be created 802 which specifies a mandatory-to-use 'current' algorithm suite for use 803 by all BGPSEC speakers. Additionally, the document specifies an 804 additional 'new' algorithm suite that is recommended to implement. 806 It is anticipated that in the future the mandatory algorithm suites 807 document will be updated to specify a transition from the 'current' 808 algorithm suite to the 'new' algorithm suite. During the period of 809 transition (likely a small number of years), all BGPSEC update 810 messages SHOULD simultaneously use both the 'current' algorithm suite 811 and the 'new' algorithm suite. (Note that Sections 3 and 4 specify 812 how the BGPSEC_Path_Signatures attribute can contain signatures, in 813 parallel, for two algorithm suites.) Once the transition is 814 complete, use of the old 'current' algorithm will be deprecated, use 815 of the 'new' algorithm will be mandatory, and a subsequent 'even 816 newer' algorithm suite may be specified as recommend to implement. 817 Once the transition has successfully been completed in this manner, 818 BGPSEC speakers SHOULD include only a single Signature-List Block 819 (corresponding to the 'new' algorithm). 821 6.2. Extensibility Considerations 823 This section discusses potential changes to BGPSEC that would require 824 substantial changes to the processing of the BGPSEC_Path_Signatures 825 and thus necessitate a new version of BGPSEC. Examples of such 826 changes include: 828 o A new type of signature algorithm that produces signatures of 829 variable length 831 o A new type of signature algorithm for which the number of 832 signatures in the Signature-List Block is not equal to the number 833 of ASes in the AS-PATH (e.g., aggregate signatures) 835 o Changes to the data that is protected by the BGPSEC signatures 836 (e.g., protection of attributes other than AS-PATH) 838 In the case that such a change to BGPSEC were deemed desirable, it is 839 expected that a subsequent version of BGPSEC would be created and 840 that this version of BGPSEC would specify a new BGP Path Attribute, 841 let's call it BGPSEC_PATH_SIG_TWO, which is designed to accommodate 842 the desired changes to BGPSEC. In such a case, the mandatory 843 algorithm suites document would be updated to specify algorithm 844 suites appropriate for the new version of BGPSEC. 846 At this point a transition would begin which is analogous to the 847 algorithm transition discussed in Section 6.2. During the transition 848 period all BGPSEC speakers SHOULD simultaneously include both the 849 BGPSEC_PATH_SIGNATURES attribute and the new BGPSEC_PATH_SIG_TWO 850 attribute. Once the transition is complete, the use of 851 BGPSEC_PATH_SIGNATURES could then be deprecated, at which point 852 BGPSEC speakers SHOULD include only the new BGPSEC_PATH_SIG_TWO 853 attribute. Such a process could facilitate a transition to a new 854 BGPSEC semantics in a backwards compatible fashion. 856 7. Security Considerations 858 For discussion of the BGPSEC threat model and related security 859 considerations, please see [8]. 861 A BGPSEC speaker who receives a valid BGPSEC update message, 862 containing a route advertisement for a given prefix, is provided with 863 the following security guarantees: 865 o The origin AS number corresponds to an autonomous system that has 866 been authorized by the IP address space holder to originate route 867 advertisements for the given prefix. 869 o For each subsequent AS number in the AS-Path, a BGPSEC speaker 870 authorized by the holder of the AS number selected the given route 871 as the best route to the given prefix. 873 o For each AS number in the AS Path, a BGPSEC speaker authorized by 874 the holder of the AS number intentionally propagated the route 875 advertisement to the next AS in the AS-Path. 877 That is, the recipient of a valid BGPSEC Update message is assured 878 that the AS-Path corresponds to a sequence of autonomous systems who 879 have all agreed in principle to forward packets to the given prefix 880 along the indicated path. (It should be noted BGPSEC does not offer 881 a precise guarantee that the data packets would propagate along the 882 indicated path; it only guarantees that the BGP update conveying the 883 path indeed propagated along the indicated path.) Furthermore, the 884 recipient is assured that this path terminates in an autonomous 885 system that has been authorized by the IP address space holder as a 886 legitimate destination for traffic to the given prefix. 888 Note that although BGPSEC provides a mechanism for an AS to validate 889 that a received update message has certain security properties, the 890 use of such a mechanism to influence route selection is completely a 891 matter of local policy. Therefore, a BGPSEC speaker can make no 892 assumptions about the validity of a route received from an external 893 BGPSEC peer. That is, a compliant BGPSEC peer may (depending on the 894 local policy of the peer) send update messages that fail the validity 895 test in Section 5. Thus, a BGPSEC speaker MUST completely validate 896 all BGPSEC update messages received from external peers. (Validation 897 of update messages received from internal peers is a matter of local 898 policy, see Section 5). 900 Note that there may be cases where a BGPSEC speaker deems 'Good' (as 901 per the validation algorithm in Section 5.1) a BGPSEC update message 902 that contains both a 'Good' and a 'Not Good' Signature-List Block. 903 That is, the update message contains two sets of signatures 904 corresponding to two algorithm suites, and one set of signatures 905 verifies correctly and the other set of signatures fails to verify. 906 In this case, the protocol specifies that if the BGPSEC speaker 907 propagates the route advertisement received in such an update message 908 then the BGPSEC speaker SHOULD add its signature to each of the 909 Signature-List Blocks using both the corresponding algorithm suite. 911 Thus the BGPSEC speaker creates a signature using both algorithm 912 suites and creates a new update message that contains both the 'Good' 913 and the 'Not Good' set of signatures (from its own vantage point). 915 To understand the reason for such a design decision consider the case 916 where the BGPSEC speaker receives an update message with both a set 917 of algorithm A signatures which are 'Good' and a set of algorithm B 918 signatures which are 'Not Good'. In such a case it is possible 919 (perhaps even quite likely) that some of the BGPSEC speaker's peers 920 (or other entities further 'downstream' in the BGP topology) do not 921 support algorithm A. Therefore, if the BGPSEC speaker were to remove 922 the 'Not Good' set of signatures corresponding to algorithm B, such 923 entities would treat the message as though it were unsigned. By 924 including the 'Not Good' set of signatures when propagating a route 925 advertisement, the BGPSEC speaker ensures that 'downstream' entities 926 have as much information as possible to make an informed opinion 927 about the validation status of a BGPSEC update. 929 Note also that during a period of partial BGPSEC deployment, a 930 'downstream' entity might reasonably treat unsigned messages 931 different from BGPSEC updates that contain a single set of 'Not Good' 932 signatures. That is, by removing the set of 'Not Good' signatures 933 the BGPSEC speaker might actually cause a downstream entity to 934 'upgrade' the status of a route advertisement from 'Not Good' to 935 unsigned. Finally, note that in the above scenario, the BGPSEC 936 speaker might have deemed algorithm A signatures 'Good' only because 937 of some issue with RPKI state local to his AS (for example, his AS 938 might not yet have obtained a CRL indicating that a key used to 939 verify an algorithm A signature belongs to a newly revoked 940 certificate). In such a case, it is highly desirable for a 941 downstream entity to treat the update as 'Not Good' (due to the 942 revocation) and not as 'unsigned' (which would happen if the 'Not 943 Good' Signature-List Blocks were removed). 945 A similar argument applies to the case where a BGPSEC speaker (for 946 some reason such as lack of viable alternatives) selects as his best 947 route to a given prefix a route obtained via a 'Not Good' BGPSEC 948 update message. (That is, a BGPSEC update containing only 'Not Good' 949 Signature-List Blocks.) In such a case, the BGPSEC speaker should 950 propagate a signed BGPSEC update message, adding his signature to the 951 'Not Good' signatures that already exist. Again, this is to ensure 952 that 'downstream' entities are able to make an informed decision and 953 not erroneously treat the route as unsigned. It may also be noted 954 here that due to possible differences in RPKI data at different 955 vantage points in the network, a BGPSEC update that was deemed 'Not 956 Good' at an upstream BGPSEC speaker may indeed be deemed 'Good' at 957 another BGP speaker downstream. 959 Therefore, it is important to note that when a BGPSEC speaker signs 960 an outgoing update message, it is not attesting to a belief that all 961 signatures prior to its are valid. Instead it is merely asserting 962 that: 964 1. The BGPSEC speaker received the given route advertisement with 965 the indicated NLRI and AS Path; 967 2. The BGPSEC speaker selected this route as the best route to the 968 given prefix; and 970 3. The BGPSEC speaker chose to propagate an advertisement for this 971 route to the peer (implicitly) indicated by the 'Target AS' 973 The BGPSEC update validation procedure is a potential target for 974 denial of service attacks against a BGPSEC speaker. To mitigate the 975 effectiveness of such denial of service attacks, BGPSEC speakers 976 should implement an update validation algorithm that performs 977 expensive checks (e.g., signature verification) after less expensive 978 checks (e.g., syntax checks). The validation algorithm specified in 979 Section 5.1 was chosen so as to perform checks which are likely to be 980 expensive after checks that are likely to be inexpensive. However, 981 the relative cost of performing required validation steps may vary 982 between implementations, and thus the algorithm specified in Section 983 5.1 may not provide the best denial of service protection for all 984 implementations. 986 8. IANA Considerations 988 IANA is requested to create a registry of BGPSEC algorithm suite 989 identifiers. This registry shall contain four fields, a one octet 990 Algorithm Suite Identifier, the name of the suite's digest algorithm, 991 the name of the suite's signature algorithm, and a specification 992 pointer containing a reference to the formal specification of the 993 algorithm suite. That is, entries in the registry have the following 994 form: 996 Algorithm Suite Digest Signature Specification 997 Identifier Algorithm Algorithm Pointer 998 +-----------------+--------------+----------------+---------------+ 999 | | | | | 1000 +-----------------+--------------+----------------+---------------+ 1002 The entries in this registry shall be managed by IETF consensus. 1004 9. Contributors 1006 9.1. Authors 1008 Rob Austein 1009 Internet Systems Consortium 1010 sra@hactrn.net 1012 Steven Bellovin 1013 Columbia University 1014 smb@cs.columbia.edu 1016 Randy Bush 1017 Internet Initiative Japan 1018 randy@psg.com 1020 Russ Housley 1021 Vigil Security 1022 housley@vigilsec.com 1024 Matt Lepinski 1025 BBN Technologies 1026 lepinski@bbn.com 1028 Stephen Kent 1029 BBN Technologies 1030 kent@bbn.com 1032 Warren Kumari 1033 Google 1034 warren@kumari.net 1036 Doug Montgomery 1037 USA National Institute of Standards and Technology 1038 dougm@nist.gov 1040 Kotikalapudi Sriram 1041 USA National Institute of Standards and Technology 1042 kotikalapudi.sriram@nist.gov 1043 Samuel Weiler 1044 weiler@watson.org 1045 Cobham 1047 9.2. Acknowledgements 1049 The authors would like to thank Luke Berndt, Sharon Goldberg, Ed 1050 Kern, Chris Morrow, Doug Maughan, Pradosh Mohapatra, Russ Mundy, 1051 Sandy Murphy, Keyur Patel, Mark Reynolds, Heather Schiller, Jason 1052 Schiller, John Scudder, Ruediger Volk and David Ward for their 1053 valuable input and review. 1055 10. Normative References 1057 [1] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 1058 Gateway Protocol 4", RFC 4271, January 2006. 1060 [2] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol 1061 Extensions for BGP-4", RFC 4760, January 2007. 1063 [3] Scudder, J. and R. Chandra, "Capabilities Advertisement with 1064 BGP-4", RFC 5492, February 2009. 1066 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1067 Levels", BCP 14, RFC 2119, March 1997. 1069 [5] Patel, K., Ward, D., and R. Bush, "Extended Message support for 1070 BGP", March 2011. 1072 [6] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin 1073 Authorizations", February 2011. 1075 [7] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure 1076 Internet Routing", February 2011. 1078 [8] Kent, S., "Threat Model for BGP Path Security", February 2011. 1080 Author's Address 1082 Matthew Lepinski (editor) 1083 BBN 1084 10 Moulton St 1085 Cambridge, MA 55409 1086 US 1088 Phone: +1-617-873-5939 1089 Email: mlepinski@bbn.com