RFC 8374
BGPsec Design Choices and Summary of Supporting Discussions
Pages: 50
Informational
Informational
Part 1 of 3 – Pages 1 to 16
Independent Submission K. Sriram, Ed. Request for Comments: 8374 USA NIST Category: Informational April 2018 ISSN: 2070-1721 BGPsec Design Choices and Summary of Supporting DiscussionsAbstract
This document captures the design rationale of the initial draft version of what became RFC 8205 (the BGPsec protocol specification). The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the arguments that aided the decision process. Where appropriate, this document also provides brief notes on design decisions that changed as the specification was reviewed and updated by the IETF SIDR Working Group and that resulted in RFC 8205. These notes highlight the differences and provide pointers to details and rationale regarding those design changes. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8374.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 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.Table of Contents
1. Introduction ....................................................4 2. Creating Signatures and the Structure of BGPsec Update Messages ........................................................5 2.1. Origin Validation Using ROAs ...............................5 2.2. Attributes Signed by an Originating AS .....................6 2.3. Attributes Signed by an Upstream AS ........................7 2.4. Attributes That Are Not Signed .............................8 2.5. Receiving Router Actions ...................................9 2.6. Prepending of ASes in AS Path .............................10 2.7. RPKI Data That Needs to Be Included in Updates ............10 3. Withdrawal Protection ..........................................11 3.1. Withdrawals Not Signed ....................................11 3.2. Signature Expire Time for Withdrawal Protection (a.k.a. Mitigation of Replay Attacks) .....................12 3.3. Should Route Expire Time be Communicated in a Separate Message? .........................................13 3.4. Effect of Expire Time Updates in BGPsec on RFD ............14 4. Signature Algorithms and Router Keys ...........................16 4.1. Signature Algorithms ......................................16 4.2. Agility of Signature Algorithms ...........................17 4.3. Sequential Aggregate Signatures ...........................18 4.4. Protocol Extensibility ....................................19 4.5. Key per Router (Rogue Router Problem) .....................20 4.6. Router ID .................................................20 5. Optimizations and Resource Sizing ..............................21 5.1. Update Packing and Repacking ..............................21 5.2. Signature per Prefix vs. Signature per Update .............22 5.3. Maximum BGPsec Update PDU Size ............................22 5.4. Temporary Suspension of Attestations and Validations ......23
6. Incremental Deployment and Negotiation of BGPsec ...............24 6.1. Downgrade Attacks .........................................24 6.2. Inclusion of Address Family in Capability Advertisement ...24 6.3. Incremental Deployment: Capability Negotiation ............25 6.4. Partial Path Signing ......................................25 6.5. Consideration of Stub ASes with Resource Constraints: Encouraging Early Adoption ...................26 6.6. Proxy Signing .............................................27 6.7. Multiple Peering Sessions between ASes ....................28 7. Interaction of BGPsec with Common BGP Features .................29 7.1. Peer Groups ...............................................29 7.2. Communities ...............................................29 7.3. Consideration of iBGP Speakers and Confederations .........30 7.4. Consideration of Route Servers in IXPs ....................31 7.5. Proxy Aggregation (a.k.a. AS_SETs) ........................32 7.6. 4-Byte AS Numbers .........................................32 8. BGPsec Validation ..............................................33 8.1. Sequence of BGPsec Validation Processing in a Receiver ....33 8.2. Signing and Forwarding Updates when Signatures Failed Validation .........................................34 8.3. Enumeration of Error Conditions ...........................35 8.4. Procedure for Processing Unsigned Updates .................36 8.5. Response to Syntactic Errors in Signatures and Recommendations for How to React to Them ..................36 8.6. Enumeration of Validation States ..........................37 8.7. Mechanism for Transporting Validation State through iBGP ..39 9. Operational Considerations .....................................41 9.1. Interworking with BGP Graceful Restart ....................41 9.2. BCP Recommendations for Minimizing Churn: Certificate Expiry/Revocation and Signature Expire Time ...42 9.3. Outsourcing Update Validation .............................42 9.4. New Hardware Capability ...................................43 9.5. Signed Peering Registrations ..............................44 10. Security Considerations .......................................44 11. IANA Considerations ...........................................44 12. Informative References ........................................44 Acknowledgements ..................................................49 Contributors ......................................................49 Author's Address ..................................................50
1. Introduction
The goal of the BGPsec effort is to enhance the security of BGP by enabling full Autonomous System (AS) path validation based on cryptographic principles. Standards work on route origin validation based on a Resource PKI (RPKI) is already completed or nearing completion in the IETF SIDR WG [RFC6480] [RFC6482] [RFC6483] [RFC6487] [RFC6811]. The BGPsec effort is aimed at taking advantage of the same RPKI infrastructure developed in the SIDR WG to add cryptographic signatures to BGP updates, so that routers can perform full AS path validation [RFC7132] [RFC7353] [RFC8205]. The BGPsec protocol specification, [RFC8205], was published recently. The key high-level design goals of the BGPsec protocol are as follows [RFC7353]: o Rigorous path validation for all announced prefixes -- not merely showing that a path is not impossible. o Incremental deployment capability -- no flag-day requirement for global deployment. o Protection of AS paths only in inter-domain routing (External BGP (eBGP)) -- not applicable to Internal BGP (iBGP) (or to IGPs). o Aiming for no increase in a provider's data exposure (e.g., not requiring any disclosure of peering relations). This document provides design justifications for the initial draft version of the BGPsec protocol specification [BGPsec-Initial]. The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the discussions that weighed in on the pros and cons and aided the decision process. Where appropriate, this document provides brief notes (starting with "Note:") on design decisions that changed from the approach taken in the initial draft version of the BGPsec protocol specification as the specification was reviewed and updated by the IETF SIDR WG. (These design decisions resulted in RFC 8205 [RFC8205].) The notes provide pointers to the details and/or discussions about the design changes.
The design choices and discussions are presented in the following sections (under the following eight broad categories, with many subtopics within each category): o Section 2 ("Creating Signatures and the Structure of BGPsec Update Messages") o Section 3 ("Withdrawal Protection") o Section 4 ("Signature Algorithms and Router Keys") o Section 5 ("Optimizations and Resource Sizing") o Section 6 ("Incremental Deployment and Negotiation of BGPsec") o Section 7 ("Interaction of BGPsec with Common BGP Features") o Section 8 ("BGPsec Validation") o Section 9 ("Operational Considerations")2. Creating Signatures and the Structure of BGPsec Update Messages
2.1. Origin Validation Using ROAs
2.1.1. Decision
Route origin validation using Route Origin Authorizations (ROAs) [RFC6482] [RFC6811] is necessary and complements AS path attestation based on signed updates. Thus, the BGPsec design makes use of the origin validation capability facilitated by the ROAs in the RPKI. Note: In the finalized BGPsec protocol specification [RFC8205], BGPsec is synonymous with cryptographic AS path attestation. Origin validation and BGPsec (path signatures) are the two key pieces of the SIDR WG solution for BGP security.2.1.2. Discussion
Route origin validation using RPKI constructs, as developed in the IETF SIDR WG, is a necessary component of BGP security. It provides cryptographic validation that the first-hop AS is authorized to originate a route for the prefix in question.
2.2. Attributes Signed by an Originating AS
2.2.1. Decision
An originating AS will sign over the Network Layer Reachability Information (NLRI) length, NLRI prefix, its own AS number (ASN), the next ASN, the signature algorithm suite ID, and a signature Expire Time (see Section 3.2) for the update. The update signatures will be carried in a new optional, non-transitive BGP attribute. Note: The finalized BGPsec protocol specification [RFC8205] differs from the above. There is no mention in RFC 8205 of a signature Expire Time field in the BGPsec update. Further, there are some additional details concerning attributes signed by the origin AS that can be found in Figure 8 in Section 4.2 of RFC 8205 [RFC8205]. In particular, the signed data also includes the Address Family Identifier (AFI) as described in RFC 8205. By adding the AFI in the data covered by a signature, a specific security concern was alleviated; see [Mandelberg1] (post to the SIDR WG Mailing List) and the discussion thread that followed on the topic. The AFI is obtained from the MP_REACH_NLRI attribute in the BGPsec update. As stated in Section 4.1 of RFC 8205, a BGPsec update message "MUST use the MP_REACH_NLRI attribute [RFC4760] to encode the prefix."2.2.2. Discussion
The next-hop ASN is included in the data covered by the signature. Without this inclusion, the AS path cannot be secured; for example, the path can be shortened (by a MITM (man in the middle)) without being detected. It was decided that only the originating AS needs to insert a signature Expire Time in the update, as it is the originator of the route. The origin AS also will re-originate, i.e., beacon, the update prior to the Expire Time of the advertisement (see Section 3.2). (For an explanation of why upstream ASes do not insert their respective signature Expire Times, please see Section 3.2.2.) Note: Expire Time and beaconing were eventually replaced by router key rollover. The BGPsec protocol [RFC8205] is expected to make use of router key rollover to mitigate replay attacks and withdrawal suppression [BGPsec-Rollover] [Replay-Protection]. It was decided that each signed update would include only one NLRI prefix. If more than one NLRI prefix were included and an upstream AS elected to propagate the advertisement for a subset of the prefixes, then the signature(s) on the update would break (see Sections 5.1 and 5.2). If a mechanism were employed to preserve
prefixes that were dropped, this would reveal information to subsequent ASes that is not revealed in normal BGP operation. Thus, a trade-off was made to preserve the level of route information exposure that is intrinsic to BGP over the performance hit implied by limiting each update to carry only one prefix. The signature data is carried in an optional, non-transitive BGP attribute. The attribute is optional because this is the standard mechanism available in BGP to propagate new types of data. It was decided that the attribute should be non-transitive because of concern about the impact of sending the (potentially large) signatures to routers that don't understand them. Also, if a router that does not understand BGPsec somehow gets an update message with path signatures (i.e., the update includes the BGPsec_PATH attribute (see Section 3 of RFC 8205)), then it would be undesirable for that router to forward the update to all of its neighbors, especially those who do not understand BGPsec and may choke if they receive many updates with large optional BGP attributes. It is envisioned that BGPsec and traditional BGP will coexist while BGPsec is deployed incrementally.2.3. Attributes Signed by an Upstream AS
In the context of BGPsec and throughout this document, an "upstream AS" simply refers to an AS that is further along in an AS path (the origin AS being the nearest to a prefix). In principle, an AS that is upstream from an originating AS would digitally sign the combined information, including the NLRI length, NLRI prefix, AS path, next ASN, signature algorithm suite ID, and Expire Time. There are multiple choices regarding what is signed by an upstream AS, as follows: o Method 1: The signature protects the combination of the NLRI length, NLRI prefix, AS path, next ASN, signature algorithm suite ID, and Expire Time, o Method 2: The signature protects just the combination of the previous signature (i.e., the signature of the neighbor AS who forwarded the update) and the next ASN, or o Method 3: The signature protects everything that was received from the preceding AS plus the next (i.e., target) ASN; thus, ASi signs over the NLRI length, NLRI prefix, signature algorithm suite ID, Expire Time, {ASi, AS(i-1), AS(i-2), ..., AS2, AS1}, AS(i+1) (i.e., the next ASN), and {Sig(i-1), Sig(i-2), ..., Sig2, Sig1}.
Note: Please see the notes in Sections 2.2.1 and 2.2.2 regarding the elimination of the Expire Time field in the finalized BGPsec protocol specification [RFC8205].2.3.1. Decision
It was decided that Method 2 will be used. Please see [BGPsec-Initial] for additional protocol details and syntax. Note: The finalized BGPsec protocol specification [RFC8205] essentially uses Method 3 (except for Expire Time). Additional details concerning attributes signed by an upstream AS can be found in Figure 8 in Section 4.2 of RFC 8205 [RFC8205]. The decision to go with Method 3 (with suitable additions to the data signed) was motivated by a security concern that was associated with Method 2; see [Mandelberg2] (post to the SIDR WG Mailing List) and the discussion thread that followed on the topic. Also, there is a strong rationale for the sequence of octets to be hashed (as shown in Figure 8 in Section 4.2 of RFC 8205); this sequencing of data is motivated by implementation efficiency considerations. See [Borchert] (post to the SIDR WG Mailing List) for an explanation.2.3.2. Discussion
The rationale for this choice (Method 2) was as follows. Signatures are performed over hash blocks. When the number of bytes to be signed exceeds one hash block, the remaining bytes will overflow into a second hash block, resulting in a performance penalty. So, it is advantageous to minimize the number of bytes being hashed. Also, an analysis of the three options noted above did not identify any vulnerabilities associated with this approach.2.4. Attributes That Are Not Signed
2.4.1. Decision
Any attributes other than those identified in Sections 2.2 and 2.3 are not signed. Examples of such attributes include the community attribute, the NO-EXPORT attribute, and Local_Pref.
2.4.2. Discussion
Any of the above-mentioned attributes that are not signed are viewed as local (e.g., do not need to propagate beyond the next hop) or lack clear security needs. NO-EXPORT is sent over a secured next hop and does not need signing. The BGPsec design should work with any transport-layer protections. It is well understood that the transport layer must be protected hop by hop (if only to prevent malicious session termination).2.5. Receiving Router Actions
2.5.1. Decision
The following example describes the expected router actions on receipt of a signed update. Consider an update that was originated by AS1 with NLRI prefix p and has traversed the AS path [AS(i-1) AS(i-2) ... AS2 AS1] before arriving at ASi. Let the Expire Time (inserted by AS1) for the signature in this update be denoted as Te. Let AlgID represent the ID of the signature algorithm suite that is in use. The update is to be processed at ASi and possibly forwarded to AS(i+1). Let the attestations (signatures) inserted by each router in the AS path be denoted by Sig1, Sig2, ..., Sig(i-2), and Sig(i-1) corresponding to AS1, AS2, ..., AS(i-2), and AS(i-1), respectively. The method (Method 2 in Section 2.3) selected for signing requires a receiving router in ASi to perform the following actions: o Validate the route origin pair (p, AS1) by performing a ROA match. o Verify that Te is greater than the clock time at the router performing these checks. o Check Sig1 with inputs {NLRI length, p, AlgID, Te, AS1, AS2}. o Check Sig2 with inputs {Sig1, AS3}. o Check Sig3 with inputs {Sig2, AS4}. o ... o ... o Check Sig(i-2) with inputs {Sig(i-3), AS(i-1)}.
o Check Sig(i-1) with inputs {Sig(i-2), ASi}.
o If the route that has been verified is selected as the best path
(for prefix p), then generate Sig(i) with inputs {Sig(i-1),
AS(i+1)}, and generate an update including Sig(i) to AS(i+1).
Note: The above description of BGPsec update validation and
forwarding differs in its details from the published BGPsec protocol
specification [RFC8205]. Please see Sections 4 and 5 of [RFC8205].
2.5.2. Discussion
See Section 8.1 for suggestions regarding efficient sequencing of
BGPsec validation processing in a receiving router. Some or all of
the validation actions may be performed by an off-board server (see
Section 9.3).
2.6. Prepending of ASes in AS Path
2.6.1. Decision
Prepending will be allowed. Prepending is defined as including more
than one instance of the AS number (ASN) of the router that is
signing the update.
Note: The finalized BGPsec protocol specification [RFC8205] uses a
pCount field associated with each AS in the path to indicate the
number of prepends for that AS (see Figure 5 in Section 3.1 of
[RFC8205]).
2.6.2. Discussion
The initial version [BGPsec-Initial] of the BGPsec specification
calls for a signature to be associated with each prepended AS. The
optimization of having just one signature for multiple prepended ASes
was pursued later. The pCount field is now used to represent AS
prepends; see Section 3.1 in RFC 8205.
2.7. RPKI Data That Needs to Be Included in Updates
2.7.1. Decision
Concerning the inclusion of RPKI data in an update, it was decided
that only the Subject Key Identifier (SKI) of the router certificate
must be included in a signed update. This information identifies the
router certificate, based on the SKI generation criteria defined in
[RFC6487].
2.7.2. Discussion
Whether or not each router public key certificate should be included in a signed update was discussed. Inclusion of this information might be helpful for routers that do not have access to RPKI servers or temporarily lose connectivity to them. It is safe to assume that in the majority of network environments, intermittent connectivity would not be a problem. So, it is best to avoid this complexity, because the majority of the use environments do not have connectivity constraints. Because the SKI of a router certificate is a hash of the public key of that certificate, it suffices to select the public key from that certificate. This design assumes that each BGPsec router has access to a cache containing the relevant data from (validated) router certificates.3. Withdrawal Protection
3.1. Withdrawals Not Signed
3.1.1. Decision
Withdrawals are not signed.3.1.2. Discussion
In the current BGP protocol, any AS can withdraw, at any time, any prefix it previously announced. The rationale for not signing withdrawals is that BGPsec assumes the use of transport security between neighboring BGPsec routers. Thus, no external entity can inject an update that withdraws a route or replay a previously transmitted update containing a withdrawal. Because the rationale for withdrawing a route is not visible to a neighboring BGPsec router, there are residual vulnerabilities associated with withdrawals. For example, a router that advertised a (valid) route may fail to withdraw that route when it is no longer viable. A router also might re-advertise a route that it previously withdrew, before the route is again viable. This latter vulnerability is mitigated by the Expire Time associated with the origin AS's signature (see Section 3.2). Repeated withdrawals and announcements for a prefix can run up the BGP Route Flap Damping (RFD) penalty [RFC2439] and may result in unreachability for that prefix at upstream routers. But what can the attacker gain from doing so? This phenomenon is intrinsic to the design and operation of RFD.
3.2. Signature Expire Time for Withdrawal Protection (a.k.a. Mitigation of Replay Attacks)
3.2.1. Decision
Note: As mentioned earlier (Section 2.2.2), the Expire Time approach to mitigation of replay attacks and withdrawal suppression was subsequently changed to an approach based on router key rollover [BGPsec-Rollover] [Replay-Protection]. Only the originating AS inserts a signature Expire Time in the update; all other ASes along an AS path do not insert Expire Times associated with their respective signatures. Further, the originating AS will re-originate a route sufficiently in advance of the Expire Time of its signature so that other ASes along an AS path will typically receive the re-originated route well ahead of the current Expire Time for that route. It is recommended that the duration of the signature Expire Time be on the order of days (preferably), but it may be on the order of hours (about 4 to 8 hours) in some cases on the basis of perceived need for extra protection from replay attacks (i.e., where extra replay protection is perceived to be critical). Each AS should stagger the Expire Time values in the routes it originates. Re-origination will be done, say, at time Tb after origination or the last re-origination, where Tb will equal a certain percentage of the Expire Time, Te (for example, Tb = 0.75 x Te). The percentage will be configurable. Additional guidance can be provided via an operational considerations document later. Further, the actual re-origination time should be jittered with a uniform random distribution over a short interval {Tb1, Tb2} centered at Tb. It is also recommended that a receiving BGPsec router detect that the only attribute change in an announcement (relative to the current best path) is the Expire Time (besides, of course, the signatures). In that case, assuming that the update is found valid, the route processor should not re-announce the route to non-BGPsec peers. (It should sign and re-announce the route to BGPsec speakers only.) This procedure will reduce BGP chattiness for the non-BGPsec border routers.
3.2.2. Discussion
Mitigation of BGPsec update replay attacks can be thought of as protection against malicious re-advertisements of withdrawn routes. If each AS along a path were to insert its own signature Expire Time, then there would be much additional BGP chattiness and an increase in BGP processing load due to the need to detect and react to multiple (possibly redundant) signature Expire Times. Furthermore, there would be no extra benefit from the point of view of mitigation of replay attacks as compared to having a single Expire Time corresponding to the signature of the originating AS. As noted in Section 3.2.1, the recommended Expire Time value is on the order of days, but 4 to 8 hours may be used in some cases on the basis of perceived need for extra protection from replay attacks. Thus, different ASes may choose different values based on the perceived need to protect against malicious route replays. (A shorter Expire Time reduces the window during which an AS can maliciously replay the route. However, shorter Expire Time values cause routes to be refreshed more often, thus causing more BGP chatter.) Even a 4-hour duration seems long enough to keep the re-origination workload manageable. For example, if 500K routes are re-originated every 4 hours, it amounts to an increase in BGP update load of 35 updates per second; this can be considered reasonable. However, further analysis is needed to confirm these recommendations. As stated in Section 3.2.1, the originating AS will re-originate a route sufficiently in advance of its Expire Time. What is considered "sufficiently in advance"? To answer this question, modeling should be performed to determine the 95th-percentile convergence time of update propagation in a BGPsec-enabled Internet. Each BGPsec router should stagger the Expire Time values in the updates it originates, especially during table dumps to a neighbor or during its own recovery from a BGP session failure. By doing this, the re-origination (i.e., beaconing) workload at the router will be dispersed.3.3. Should Route Expire Time be Communicated in a Separate Message?
3.3.1. Decision
The idea of sending a new signature Expire Time in a special message (rather than retransmitting the entire update with signatures) was considered. However, the decision was made to not do this. Re-origination to communicate a new signature Expire Time will be done by propagating a normal update message; no special type of message will be required.
3.3.2. Discussion
It was suggested that if the re-beaconing of the signature Expire Time is carried in a separate special message, then any processing load related to the update may be reduced. But it was recognized that such a re-beaconing message by necessity entails AS path and prefix information and, hence, cannot be separated from the update. It was observed that at the edge of the Internet, there are frequent updates that may result from such simple situations as a BGP session being switched from one interface to another (e.g., from primary to backup) between two peering ASes (e.g., customer and provider). With traditional BGP, these updates do not propagate beyond the two ASes involved. But with BGPsec, the customer AS will put in a new signature Expire Time each time such an event happens; hence, the update will need to propagate throughout the Internet (limited only by the process of best-path selection). It was accepted that this cost of added churn will be unavoidable.3.4. Effect of Expire Time Updates in BGPsec on RFD
3.4.1. Decision
With regard to the RFD protocol [RFC2439] [JunOS] [CiscoIOS], no differential treatment is required for Expire-Time-triggered (re-beaconed) BGPsec updates. However, it was noted that it would be preferable if these updates did not cause route churn (and perhaps did not even require any RFD-related processing), since they are identical except for the change in the Expire Time value. This can be accomplished by not assigning an RFD penalty to Expire-Time-triggered updates. If the community agrees, this could be accommodated, but a change to the BGP-RFD protocol will be required.
3.4.2. Discussion
To summarize, this decision is supported by the following observations: 1. Expire-Time-triggered updates are generally not preceded by withdrawals; hence, the path hunting and associated RFD exacerbation [Mao02] [RIPE580] problems are not anticipated. 2. Such updates would not normally change the best path (unless another concurrent event impacts the best path). 3. Expire-Time-triggered updates would have a negligible impact on RFD penalty accumulation because the re-advertisement interval is much longer relative to the half-time of RFD penalty decay. Elaborating further on the third observation above, it may be noted that the re-advertisements (i.e., beacons) of a route for a given address prefix from a given peer will be received at intervals of several hours (see Section 3.2). During that time period, any incremental contribution to the RFD penalty due to an Expire-Time- triggered update would decay sufficiently to have negligible (if any) impact on damping the address prefix in question. Additional details regarding this analysis and justification are as follows: The frequency with which RFD penalty increments may be triggered for a given prefix from a given peer is the same as the re-beaconing frequency for that prefix from its origin AS. The re-beaconing frequency is on the order of once every several hours (see Section 3.2). The incremental RFD penalty assigned to a prefix due to a re-beaconed update varies, depending on the implementation. For example, it appears that the JunOS implementation [JunOS] would assign a penalty of 1000 or 500, depending on whether the re-beaconed update is regarded as a re-advertisement or an attribute change, respectively. Normally, a re-beaconed update would be treated as an attribute change. On the other hand, the Cisco implementation [CiscoIOS] assigns an RFD penalty only in the case of an actual flap (i.e., a route is available, then unavailable, or vice versa). So, it appears that Cisco's implementation of RFD would not assign any penalty for a re-beaconed update (i.e., a route was already advertised previously and was not withdrawn, and the re-beaconed update is merely updating the Expire Time attribute). Even if one assumes that an RFD penalty of 500 is assigned (corresponding to an attribute change according to the JunOS RFD implementation), it can be illustrated that the incremental effect it would have on damping the prefix in question would be negligible: the half-time of RFD
penalty decay is normally set to 15 minutes, whereas the re-beaconing frequency is on the order of once every several hours. An incremental penalty of 500 would decay to 31.25 in 1 hour, 0.12 in 2 hours, and 3x10^(-5) in 3 hours. It may also be noted that the threshold for route suppression is 3000 in JunOS and 2000 in Cisco IOS. Based on the foregoing analysis, it may be concluded that routine re-beaconing by itself would not result in RFD suppression of routes in the BGPsec protocol.
(page 16 continued on part 2)