Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8374

Informational
Pages: 50
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: ~rtg

BGPsec Design Choices and Summary of Supporting Discussions

Part 1 of 3, p. 1 to 16
None       Next Section

 


Top       ToC       Page 1 
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 Discussions

Abstract

   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.

Top      ToC       Page 2 
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

Top      ToC       Page 3 
   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

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
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

Top      ToC       Page 7 
   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}.

Top      ToC       Page 8 
   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.

Top      ToC       Page 9 
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)}.

Top      ToC       Page 10 
   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].

Top      ToC       Page 11 
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.

Top      ToC       Page 12 
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.

Top      ToC       Page 13 
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.

Top      ToC       Page 14 
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.

Top      ToC       Page 15 
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

Top      ToC       Page 16 
   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)

Next Section