4.  Signature Algorithms and Router Keys

4.1.  Signature Algorithms

4.1.1.  Decision

   Initially, the Elliptic Curve Digital Signature Algorithm (ECDSA)
   with curve P-256 and SHA-256 will be used for generating BGPsec path
   signatures.  One other signature algorithm, e.g., RSA-2048, will also
   be used during prototyping and testing.  The use of a second
   signature algorithm is needed to verify the ability of the BGPsec
   implementations to change from a current algorithm to the next
   algorithm.

   Note: The BGPsec cryptographic algorithms document [RFC8208]
   specifies only the ECDSA with curve P-256 and SHA-256.

4.1.2.  Discussion

   Initially, the RSA-2048 algorithm for BGPsec update signatures was
   considered as a choice because it is being used ubiquitously in the
   RPKI system.  However, the use of ECDSA P-256 was decided upon
   because it yields a smaller signature size; hence, the update size
   and (in turn) the RIB size needed in BGPsec routers would be much
   smaller [RIB_size].

   Using two different signature algorithms (e.g., ECDSA P-256 and
   RSA-2048) to test the transition from one algorithm to the other will
   increase confidence in prototype implementations.

   Optimizations and specialized algorithms (e.g., for speedups) built
   on Elliptic Curve Cryptography (ECC) algorithms may have active IPR
   (intellectual property rights), but at the time of publication of
   this document no IPR had been disclosed to the IETF for the basic
   (unoptimized) algorithms.  (To understand this better, [RFC6090] can
   be useful as a starting point.)

   Note: Recently, even open-source implementations have incorporated
   certain cryptographic optimizations and demonstrated significant
   performance speedup [Gueron].  Researchers continue to devote
   significant effort toward demonstrating substantial speedup for the
   ECDSA as part of BGPsec implementations [Mehmet1] [Mehmet2].

4.2.  Agility of Signature Algorithms

4.2.1.  Decision

   During the transition period from one algorithm (i.e., the current
   algorithm) to the next (new) algorithm, the updates will carry two
   sets of signatures (i.e., two Signature_Blocks), one corresponding to
   each algorithm.  Each Signature_Block will be preceded by its
   type-length field and an algorithm suite identifier.  A BGPsec
   speaker that has been upgraded to handle the new algorithm should
   validate both Signature_Blocks and then add its corresponding
   signature to each Signature_Block for forwarding the update to the
   next AS.  A BGPsec speaker that has not been upgraded to handle the
   new algorithm will strip off the Signature_Block of the new algorithm
   and then will forward the update after adding its own signature to
   the Signature_Block of the current algorithm.

   It was decided that there will be at most two Signature_Blocks per
   update.

   Note: BGPsec path signatures are carried in the Signature_Block,
   which is an attribute contained in the BGPsec_PATH attribute (see
   Section 3.2 in [RFC8205]).  The algorithm agility scheme described in
   the published BGPsec protocol specification is consistent with the
   above; see Section 6.1 of [RFC8205].

4.2.2.  Discussion

   A length field in the Signature_Block allows for delineation of the
   two signature blocks.  Hence, a BGPsec router that doesn't know about
   a particular algorithm suite (and, hence, doesn't know how long
   signatures were for that algorithm suite) could still skip over the
   corresponding Signature_Block when parsing the message.

   The overlap period between the two algorithms is expected to last
   2 to 4 years.  The RIB memory and cryptographic processing capacity
   will have to be sized to cope with such overlap periods when updates
   would contain two sets of signatures [RIB_size].

   The lifetime of a signature algorithm is anticipated to be much
   longer than the duration of a transition period from the current
   algorithm to a new algorithm.  It is fully expected that all ASes
   will have converted to the required new algorithm within a certain
   amount of time that is much shorter than the interval in which a
   subsequent newer algorithm may be investigated and standardized for
   BGPsec.  Hence, the need for more than two Signature_Blocks per
   update is not envisioned.

4.3.  Sequential Aggregate Signatures

4.3.1.  Decision

   There is currently weak or no support for the Sequential Aggregate
   Signature (SAS) approach.  Please see Section 4.3.2 for a brief
   description of what the SAS is and what its pros and cons are.

4.3.2.  Discussion

   In the SAS method, there would be only one (aggregated) signature per
   signature block, irrespective of the number of AS hops.  For example,
   ASn (the nth AS) takes as input the signatures of all previous ASes
   [AS1, ..., AS(n-1)] and produces a single composite signature.  This
   composite signature has the property that a recipient who has the
   public keys for AS1, ..., ASn can verify (using only the single
   composite signature) that all of the ASes actually signed the
   message.  The SAS could potentially result in savings in bandwidth
   and in Protocol Data Unit (PDU) size, and maybe in RIB size, but the
   signature generation and validation costs will be higher as compared
   to one signature per AS hop.

   SAS schemes exist in the literature, typically based on RSA or its
   equivalent.  For a SAS with RSA and for the cryptographic strength
   needed for BGPsec signatures, a 2048-bit signature size (RSA-2048)
   would be required.  However, without a SAS, the ECDSA with a 512-bit
   signature (256-bit key) would suffice for equivalent cryptographic
   strength.  The larger signature size of RSA used with a SAS
   undermines the advantages of the SAS, because the average hop count,
   i.e., the number of ASes, for a route is about 3.8.  In the end, it
   may turn out that the SAS has more complexity and does not provide
   sufficient savings in PDU size or RIB size to merit its use.  Further
   exploration of this is needed to better understand SAS properties and
   applicability for BGPsec.  There is also a concern that the SAS is
   not a time-tested cryptographic technique, and thus its adoption is
   potentially risky.

4.4.  Protocol Extensibility

   There is clearly a need to specify a transition path from a current
   protocol specification to a new version.  When changes to the
   processing of the BGPsec path signatures are required, a new version
   of BGPsec will be required.  Examples of this include changes to the
   data that is protected by the BGPsec signatures or adoption of a
   signature algorithm in which the number of signatures in the
   signature block may not correspond to one signature per AS in the
   AS path (e.g., aggregate signatures).

4.4.1.  Decision

   This protocol-version transition mechanism is analogous to the
   algorithm transition discussed in Section 4.2.  During the transition
   period from one protocol version (i.e., the current version) to the
   next (new) version, updates will carry two sets of signatures (i.e.,
   two Signature_Blocks), one corresponding to each version.  A
   protocol-version identifier is associated with each Signature_Block.
   Hence, each Signature_Block will be preceded by its type-length field
   and a protocol-version identifier.  A BGPsec speaker that has been
   upgraded to handle the new version should validate both
   Signature_Blocks and then add its corresponding signature to each
   Signature_Block for forwarding the update to the next AS.  A BGPsec
   speaker that has not been upgraded to handle the new protocol version
   will strip off the Signature_Block of the new version and then will
   forward the update with an attachment of its own signature to the
   Signature_Block of the current version.

   Note: The details of protocol extensibility (i.e., transition to a
   new version of BGPsec) in the published BGPsec protocol specification
   (see Section 6.3 in [RFC8205]) differ somewhat from the above.  In
   particular, the protocol-version identifier is not part of the BGPsec
   update.  Instead, it is negotiated during the BGPsec capability
   exchange portion of BGPsec session negotiation.

4.4.2.  Discussion

   In the case that a change to BGPsec is deemed desirable, it is
   expected that a subsequent version of BGPsec would be created and
   that this version of BGPsec would specify a new BGP path attribute
   (let's call it "BGPsec_PATH_TWO") that is designed to accommodate the
   desired changes to BGPsec.  At this point, a transition would begin
   that is analogous to the algorithm transition discussed in
   Section 4.2.  During the transition period, all BGPsec speakers will
   simultaneously include both the BGPsec_PATH (current) attribute (see
   Section 3 of RFC 8205) and the new BGPsec_PATH_TWO attribute.  Once
   the transition is complete, the use of BGPsec_PATH could then be

   deprecated, at which point BGPsec speakers will include only the new
   BGPsec_PATH_TWO attribute.  Such a process could facilitate a
   transition to new BGPsec semantics in a backwards-compatible fashion.

4.5.  Key per Router (Rogue Router Problem)

4.5.1.  Decision

   Within each AS, each individual BGPsec router can have a unique pair
   of private and public keys [RFC8207].

4.5.2.  Discussion

   Given a unique key pair per router, if a router is compromised, its
   key pair can be revoked independently, without disrupting the other
   routers in the AS.  Each per-router key pair will be represented in
   an end-entity certificate issued under the certification authority
   (CA) certificate of the AS.  The Subject Key Identifier (SKI) in the
   signature points to the router certificate (and thus the unique
   public key) of the router that affixed its signature, so that a
   validating router can reliably identify the public key to use for
   signature verification.

4.6.  Router ID

4.6.1.  Decision

   The router certificate subject name will be the string "ROUTER"
   followed by a decimal representation of a 4-byte ASN followed by the
   router ID.  (Note: The details are specified in Section 3.1 in
   [RFC8209].)

4.6.2.  Discussion

   Every X.509 certificate requires a subject name [RFC6487].  The
   stylized subject name adopted here is intended to facilitate
   debugging by including the ASN and router ID.

5.  Optimizations and Resource Sizing

5.1.  Update Packing and Repacking

   With traditional BGP [RFC4271], an originating BGP router normally
   packs multiple prefix announcements into one update if the prefixes
   all share the same BGP attributes.  When an upstream BGP router
   forwards eBGP updates to its peers, it can also pack multiple
   prefixes (based on the shared AS path and attributes) into one
   update.  The update propagated by the upstream BGP router may include
   only a subset of the prefixes that were packed in a received update.

5.1.1.  Decision

   Each update contains exactly one prefix.  This avoids a level of
   complexity that would otherwise be inevitable if the origin had
   packed and signed multiple prefixes in an update and an upstream AS
   decided to propagate an update containing only a subset of the
   prefixes in that update.  BGPsec recommendations regarding packing
   and repacking may be revisited when optimizations are considered in
   the future.

5.1.2.  Discussion

   Currently, with traditional BGP, there are, on average, approximately
   four prefixes announced per update [RIB_size].  So, the number of BGP
   updates (carrying announcements) is about four times fewer, on
   average, as compared to the number of prefixes announced.

   The current decision is to include only one prefix per secured update
   (see Section 2.2.2).  When optimizations are considered in the
   future, the possibility of packing multiple prefixes into an update
   can also be considered.  (Please see Section 5.2 for a discussion of
   signature per prefix vs. signature per update.)  Repacking could be
   performed if signatures were generated on a per-prefix basis.
   However, one problem regarding this approach -- multiple prefixes in
   a BGP update but with a separate signature for each prefix -- is that
   the resulting BGP update violates the basic definition of a BGP
   update: the different prefixes will have different signatures and
   Expire Time attributes, while a BGP update (by definition) must have
   the same set of shared attributes for all prefixes it carries.

5.2.  Signature per Prefix vs. Signature per Update

5.2.1.  Decision

   The initial design calls for including exactly one prefix per update;
   hence, there is only one signature in each secured update (modulo
   algorithm transition conditions).

5.2.2.  Discussion

   Some notes to assist in future optimization discussions follow:

   In the general case of one signature per update, multiple prefixes
   may be signed with one signature together with their shared AS path,
   next ASN, and Expire Time.  If the "signature per update" technique
   is used, then there are potential savings in update PDU size as well
   as RIB memory size.  But if there are any changes made to the
   announced prefix set along the AS path, then the AS where the change
   occurs would need to insert an Explicit Path Attribute (EPA)
   [Secure-BGP].  The EPA conveys information regarding what the prefix
   set contained prior to the change.  There would be one EPA for each
   AS that made such a modification, and there would be a way to
   associate each EPA with its corresponding AS.  This enables an
   upstream AS to know and verify what was announced and signed by prior
   ASes in the AS path (in spite of changes made to the announced prefix
   set along the way).  The EPA adds complexity to processing (signature
   generation and validation); further increases the size of updates
   and, thus, of the RIB; and exposes data to downstream ASes that would
   not otherwise be exposed.  Not all of the pros and cons of packing
   and repacking in the context of signature per prefix vs. signature
   per update (with packing) have been evaluated.  But the current
   recommendation is for having only one prefix per update (no packing),
   so there is no need for the EPA.

5.3.  Maximum BGPsec Update PDU Size

   The current BGP update message PDU size is limited to 4096 bytes
   [RFC4271].  The question was raised as to whether or not BGPsec would
   require a larger update PDU size.

5.3.1.  Decision

   The current thinking is that the maximum PDU size should be increased
   to 64 KB [BGP-Ext-Msg] so that there is sufficient room to
   accommodate two Signature_Blocks (i.e., one block with a current
   algorithm and another block with a new signature algorithm during a
   future transition period) for long AS paths.

   Note: RFC 8205 states the following: "All BGPsec UPDATE messages MUST
   conform to BGP's maximum message size.  If the resulting message
   exceeds the maximum message size, then the guidelines in Section 9.2
   of RFC 4271 [RFC4271] MUST be followed."

5.3.2.  Discussion

   The current maximum message size for BGP updates is 4096 octets.  An
   effort is underway in the IETF to extend it to a larger size
   [BGP-Ext-Msg].  BGPsec will conform to whatever maximum message size
   is available for BGP while adhering to the guidelines in Section 9.2
   of RFC 4271 [RFC4271].

   Note: Estimates for the average and maximum sizes anticipated for
   BGPsec update messages are provided in [MsgSize].

5.4.  Temporary Suspension of Attestations and Validations

5.4.1.  Decision

   If a BGPsec-capable router needs to temporarily suspend/defer signing
   and/or validation of BGPsec updates during periods of route processor
   overload, the router may do so even though such suspension/deferment
   is not desirable; the specification does not forbid it.  Following
   any temporary suspension, the router should subsequently send signed
   updates corresponding to the updates for which validation and signing
   were skipped.  The router also may choose to skip only validation but
   still sign and forward updates during periods of congestion.

5.4.2.  Discussion

   In some situations, a BGPsec router may be unable to keep up with the
   workload of performing signing and/or validation.  This can happen,
   for example, during BGP session recovery when a router has to send
   the entire routing table to a recovering router in a neighboring AS
   (see [CPUworkload]).  So, it is possible that a BGPsec router
   temporarily pauses performing the validation or signing of updates.
   When the workload eases, the BGPsec router should clear the
   validation or signing backlog and send signed updates corresponding
   to the updates for which validation and signing were skipped.  During
   periods of overload, the router may simply send unsigned updates
   (with signatures dropped) or may sign and forward the updates with
   signatures (even though the router itself has not yet verified the
   signatures it received).

   A BGPsec-capable AS may request (out of band) that a BGPsec-capable
   peer AS never downgrade a signed update to an unsigned update.
   However, in partial-deployment scenarios, it is not possible for a
   BGPsec router to require a BGPsec-capable eBGP peer to send only
   signed updates, except for prefixes originated by the peer's AS.

   Note: If BGPsec has not been negotiated with a peer, then a BGPsec
   router forwards only unsigned updates to that peer; the sending
   router does so by following the reconstruction procedure in
   Section 4.4 of [RFC8205] to generate an AS_PATH attribute
   corresponding to the BGPsec_PATH attribute in a received signed
   update.  If the above-mentioned temporary suspension is ever applied,
   then the same AS_PATH reconstruction procedure should be utilized.

6.  Incremental Deployment and Negotiation of BGPsec

6.1.  Downgrade Attacks

6.1.1.  Decision

   No attempt will be made in the BGPsec design to prevent downgrade
   attacks, i.e., a BGPsec-capable router sending unsigned updates when
   it is capable of sending signed updates.

6.1.2.  Discussion

   BGPsec allows routers to temporarily suspend signing updates (see
   Section 5.4).  Therefore, it would be contradictory if we were to try
   to incorporate in the BGPsec protocol a way to detect and reject
   downgrade attacks.  One proposed way to detect downgrade attacks was
   considered, based on signed peering registrations (see Section 9.5).

6.2.  Inclusion of Address Family in Capability Advertisement

6.2.1.  Decision

   It was decided that during capability negotiation, the address family
   for which the BGPsec speaker is advertising support for BGPsec will
   be shared using the Address Family Identifier (AFI).  Initially, two
   address families would be included, namely, IPv4 and IPv6.  BGPsec
   for use with other address families may be specified in the future.
   Simultaneous use of the two (i.e., IPv4 and IPv6) address families
   for the same BGPsec session will require that the BGPsec speaker
   include two instances of this capability (one for each address
   family) during BGPsec capability negotiation.

6.2.2.  Discussion

   If new address families are supported in the future, they will be
   added in future versions of the specification.  A comment was made
   that too many version numbers are bad for interoperability.
   Renegotiation on the fly to add a new address family (i.e., without
   changeover to a new version number) is desirable.

6.3.  Incremental Deployment: Capability Negotiation

6.3.1.  Decision

   BGPsec will be incrementally deployable.  BGPsec routers will use
   capability negotiation to agree to run BGPsec between them.  If a
   BGPsec router's peer does not agree to run BGPsec, then the BGPsec
   router will run only traditional BGP with that peer, i.e., it will
   not send BGPsec (i.e., signed) updates to the peer.

   Note: See Section 7.9 of [RFC8205] for a discussion of incremental /
   partial-deployment considerations.  Also, Section 6 of [RFC8207]
   describes how edge sites (stub ASes) can sign updates that they
   originate but can receive only unsigned updates.  This facilitates a
   less expensive upgrade to BGPsec in resource-limited stub ASes and
   expedites incremental deployment.

6.3.2.  Discussion

   The partial-deployment approach to incremental deployment will result
   in "BGPsec islands".  Updates that originate within a BGPsec island
   will generally propagate with signed AS paths to the edges of that
   island.  As BGPsec adoption grows, the BGPsec islands will expand
   outward (subsuming non-BGPsec portions of the Internet) and/or pairs
   of islands may join to form larger BGPsec islands.

6.4.  Partial Path Signing

   "Partial path signing" means that a BGPsec AS can be permitted to
   sign an update that was received unsigned from a downstream neighbor.
   That is, the AS would add its ASN to the AS path and sign the
   (previously unsigned) update to other neighboring (upstream)
   BGPsec ASes.

6.4.1.  Decision

   It was decided that partial path signing in BGPsec will not be
   allowed.  A BGPsec update must be fully signed, i.e., each AS in the
   AS path must sign the update.  So, in a signed update, there must be
   a signature corresponding to each AS in the AS path.

6.4.2.  Discussion

   Partial path signing (as described above) implies that the AS path is
   not rigorously protected.  Rigorous AS path protection is a key
   requirement of BGPsec [RFC7353].  Partial path signing clearly
   reintroduces the following attack vulnerability: if a BGPsec speaker
   is allowed to sign an unsigned update and if signed (i.e., partially
   or fully signed) updates would be preferred over unsigned updates,
   then a faulty, misconfigured, or subverted BGPsec speaker can
   manufacture any unsigned update it wants (by inserting a valid origin
   AS) and add a signature to it to increase the chance that its update
   will be preferred.

6.5.  Consideration of Stub ASes with Resource Constraints: Encouraging
      Early Adoption

6.5.1.  Decision

   The protocol permits each pair of BGPsec-capable ASes to
   asymmetrically negotiate the use of BGPsec.  Thus, a stub AS (or
   downstream customer AS) can agree to perform BGPsec only in the
   transmit direction and speak traditional BGP in the receive
   direction.  In this arrangement, the ISP's (upstream) AS will not
   send signed updates to this stub or customer AS.  Thus, the stub AS
   can avoid the need to hardware-upgrade its route processor and RIB
   memory to support BGPsec update validation.

6.5.2.  Discussion

   Various other options were also considered for accommodating a
   resource-constrained stub AS, as discussed below:

   1.  An arrangement that can be effected outside of the BGPsec
       specification is as follows.  Through a private arrangement
       (invisible to other ASes), an ISP's AS (upstream AS) can truncate
       the stub AS (or downstream AS) from the path and sign the update
       as if the prefix is originating from the ISP's AS (even though
       the update originated unsigned from the customer AS).  This way,
       the path will appear fully signed to the rest of the network.
       This alternative will require the owner of the prefix at the stub
       AS to issue a ROA for the upstream AS, so that the upstream AS is
       authorized to originate routes for the prefix.

   2.  Another type of arrangement that can also be effected outside of
       the BGPsec specification is as follows.  The stub AS does not
       sign updates, but it obtains an RPKI (CA) certificate and issues
       a router certificate under that CA certificate.  It passes on the
       private key for the router certificate to its upstream provider.

       That ISP (i.e., the second-hop AS) would insert a signature on
       behalf of the stub AS using the private key obtained from the
       stub AS.  This arrangement is called "proxy signing" (see
       Section 6.6).

   3.  An extended ROA is created that includes the stub AS as the
       originator of the prefix and the upstream provider as the
       second-hop AS, and partial signatures would be allowed (i.e., the
       stub AS need not sign the updates).  It is recognized that this
       approach is also authoritative and not trust based.  It was
       observed that the extended ROA is not much different from what is
       done with the ROA (in its current form) when a Provider-
       Independent (PI) address is originated from a provider's AS.
       This approach was rejected due to possible complications with the
       creation and use of a new RPKI object, namely, the extended ROA.
       Also, the validating BGPsec router has to perform a level of
       indirection with this approach, i.e., it must detect that an
       update is not fully signed and then look for the extended ROA to
       validate.

   4.  Another method, based on a different form of indirection, would
       be as follows.  The customer (stub) AS registers something like a
       Proxy Signer Authorization, which authorizes the second-hop
       (i.e., provider) AS to sign on behalf of the customer AS using
       the provider's own key [Dynamics].  This method allows for fully
       signed updates (unlike the approach based on the extended ROA).
       But this approach also requires the creation of a new RPKI
       object, namely, the Proxy Signer Authorization.  In this
       approach, the second-hop AS and validating ASes have to perform a
       level of indirection.  This approach was also rejected.

   The various inputs regarding ISP preferences were taken into
   consideration, and eventually the decision in favor of asymmetric
   BGPsec was reached (Section 6.5.1).  An advantage for a stub AS that
   does asymmetric BGPsec is that it only needs to minimally upgrade to
   BGPsec so it can sign updates to its upstream AS while it receives
   only unsigned updates.  Thus, it can avoid the cost of increased
   processing and memory needed to perform update validations and to
   store signed updates in the RIBs, respectively.

6.6.  Proxy Signing

6.6.1.  Decision

   An ISP's AS (or upstream AS) can proxy-sign BGP announcements for a
   customer (downstream) AS, provided that the customer AS obtains an
   RPKI (CA) certificate, issues a router certificate under that CA
   certificate, and passes on the private key for that certificate to

   its upstream provider.  That ISP (i.e., the second-hop AS) would
   insert a signature on behalf of the customer AS using the private key
   provided by the customer AS.  This is a private arrangement between
   the two ASes and is invisible to other ASes.  Thus, this arrangement
   is not part of the BGPsec protocol specification.

   BGPsec will not make any special provisions for an ISP to use its own
   private key to proxy-sign updates for a customer's AS.  This type of
   proxy signing is considered a bad idea.

6.6.2.  Discussion

   Consider a scenario when a customer's AS (say, AS8) is multihomed to
   two ISPs, i.e., AS8 peers with AS1 and AS2 of ISP-1 and ISP-2,
   respectively.  In this case, AS8 would have an RPKI (CA) certificate;
   it issues two separate router certificates (corresponding to AS1 and
   AS2) under that CA certificate, and it passes on the respective
   private keys for those two certificates to its upstream providers AS1
   and AS2.  Thus, AS8 has a proxy-signing service from both of its
   upstream ASes.  In the future, if AS8 were to disconnect from ISP-2,
   then it would revoke the router certificate corresponding to AS2.

6.7.  Multiple Peering Sessions between ASes

6.7.1.  Decision

   No problems are anticipated when BGPsec-capable ASes have multiple
   peering sessions between them (between distinct routers).

6.7.2.  Discussion

   In traditional BGP, multiple peering sessions between different pairs
   of routers (between two neighboring ASes) may be simultaneously used
   for load sharing.  Similarly, BGPsec-capable ASes can also have
   multiple peering sessions between them.  Because routers in an AS can
   have distinct private keys, the same update, when propagated over
   these multiple peering sessions, will result in multiple updates that
   may differ in their signatures.  The peer (upstream) AS will apply
   its normal procedures for selecting a best path from those multiple
   updates (and updates from other peers).

   This decision regarding load balancing (vs. using one peering session
   as the primary for carrying data and another as the backup) is
   entirely local and is up to the two neighboring ASes.

7.  Interaction of BGPsec with Common BGP Features

7.1.  Peer Groups

   In traditional BGP, the idea of peer groups is used in BGP routers to
   save on processing when generating and sending updates.  Multiple
   peers for whom the same policies apply can be organized into peer
   groups.  A peer group can typically have tens of ASes (and maybe as
   many as 300) in it.

7.1.1.  Decision

   It was decided that BGPsec updates are generated to target unique AS
   peers, so there is no support for peer groups in BGPsec.

7.1.2.  Discussion

   BGPsec router processing can make use of peer groups preceding the
   signing of updates to peers.  Some of the update processing prior to
   forwarding to members of a peer group can be done only once per
   update, as is done in traditional BGP.  Prior to forwarding the
   update, a BGPsec speaker adds the peer's ASN to the data that needs
   to be signed and signs the update for each peer AS in the group
   individually.

   If updates were to be signed per peer group, information about the
   forward AS set that constitutes a peer group would have to be
   divulged (since the ASN of each peer would have to be included in the
   update).  Some ISPs do not like to share this kind of information
   globally.

7.2.  Communities

   The need to provide protection in BGPsec for the community attribute
   was discussed.

7.2.1.  Decision

   Community attribute(s) will not be included in any message that is
   signed in BGPsec.

7.2.2.  Discussion

   From a security standpoint, the community attribute, as currently
   defined, may be inherently defective.  A substantial amount of work
   on the semantics of the community attribute is needed, and additional
   work on its security aspects also needs to be done.  The community
   attribute is not necessarily transitive; it is often used only

   between neighbors.  In those contexts, transport-security mechanisms
   suffice to provide integrity and authentication.  (There is no need
   to sign data when it is passed only between peers.)  It was suggested
   that one could include only the transitive community attributes in
   any message that is signed and propagated (across the AS path).  It
   was noted that there is a flag available (i.e., unused) in the
   community attribute, and it might be used by BGPsec (in some
   fashion).  However, little information is available at this point
   about the use and function of this flag.  It was speculated that this
   flag could potentially be used to indicate to BGPsec whether or not
   the community attribute needs protection.  For now, community
   attributes will not be secured by BGPsec path signatures.

7.3.  Consideration of iBGP Speakers and Confederations

7.3.1.  Decision

   An iBGP speaker that is also an eBGP speaker and that executes BGPsec
   will by necessity carry BGPsec data and perform eBGPsec functions.
   Confederations are eBGP clouds for administrative purposes and
   contain multiple Member-ASes.  A Member-AS is not required to sign
   updates sent to another Member-AS within the same confederation.
   However, if BGPsec signing is applied in eBGP within a confederation,
   i.e., each Member-AS signs to the next Member-AS in the path within
   the confederation, then upon egress from the confederation, the
   Member-AS at the boundary must remove any and all signatures applied
   within the confederation.  The Member-AS at the boundary of the
   confederation will sign the update to an eBGPsec peer using the
   public ASN of the confederation and its private key.  The BGPsec
   specification will not specify how to perform this process.

   Note: In RFC 8205, signing a BGPsec update between Member-ASes within
   a confederation is required if the update were to propagate with
   signatures within the confederation.  A Confed_Segment flag exists in
   each Secure_Path segment, and when set, it indicates that the
   corresponding signature belongs to a Member-AS.  At the confederation
   boundary, all signatures with Confed_Segment flags set are removed
   from the update.  RFC 8205 specifies in detail how all of this is
   done.  Please see Figure 5 in Section 3.1 of [RFC8205], as well as
   Section 4.3 of [RFC8205], for details.

7.3.2.  Discussion

   This topic may need to be revisited to flesh out the details
   carefully.

7.4.  Consideration of Route Servers in IXPs

7.4.1.  Decision

   [BGPsec-Initial] made no special provisions to accommodate route
   servers in Internet Exchange Points (IXPs).

   Note: The above decision subsequently changed: RFC 8205 allows the
   accommodation of IXPs, especially for transparent route servers.  The
   pCount (AS prepend count) field is set to zero for transparent route
   servers (see Section 4.2 of [RFC8205]).  The operational guidance for
   preventing the misuse of pCount=0 is given in Section 7.2 of
   RFC 8205.  Also, see Section 8.4 of RFC 8205 for a discussion of
   security considerations concerning pCount=0.

7.4.2.  Discussion

   There are basically three methods that an IXP may use to propagate
   routes: (A) direct bilateral peering through the IXP, (B) BGP peering
   between clients via peering with a route server at the IXP (without
   the IXP inserting its ASN in the path), and (C) BGP peering with an
   IXP route server, where the IXP inserts its ASN in the path.
   (Note: The IXP's route server does not change the NEXT_HOP attribute
   even if it inserts its ASN in the path.)  It is very rare for an IXP
   to use Method C because it is less attractive for the clients if
   their AS path length increases by one due to the IXP.  A measure of
   the extent of the use of Method A vs. Method B is given in terms of
   the corresponding IP traffic load percentages.  As an example, at a
   major European IXP, these percentages are about 80% and 20% for
   Methods A and B, respectively (this data is based on private
   communication with IXPs circa 2011).  However, as the IXP grows (in
   terms of number of clients), it tends to migrate more towards
   Method B because of the difficulties of managing up to n x (n-1)/2
   direct interconnections between n peers in Method A.

   To the extent that an IXP is providing direct bilateral peering
   between clients (Method A), that model works naturally with BGPsec.
   Also, if the route server in the IXP plays the role of a regular
   BGPsec speaker (minus the routing part for payload) and inserts its
   own ASN in the path (Method C), then that model would also work well
   in the BGPsec Internet and this case is trivially supported in
   BGPsec.

7.5.  Proxy Aggregation (a.k.a. AS_SETs)

7.5.1.  Decision

   Proxy aggregation (i.e., the use of AS_SETs in the AS path) will not
   be supported in BGPsec.  There is no provision in BGPsec to sign an
   update when an AS_SET is part of an AS path.  If a BGPsec-capable
   router receives an update that contains an AS_SET and also finds that
   the update is signed, then the router will consider the update
   malformed (i.e., a protocol error).

   Note: Section 5.2 of RFC 8205 specifies that a receiving BGPsec
   router "MUST handle any syntactical or protocol errors in the
   BGPsec_PATH attribute by using the 'treat-as-withdraw' approach as
   defined in RFC 7606 [RFC7606]."

7.5.2.  Discussion

   Proxy aggregation does occur in the Internet today, but it is very
   rare.  Only a very small fraction (about 0.1%) of observed updates
   contain AS_SETs in the AS path [ASset].  Since traditional BGP
   currently allows for proxy aggregation with the inclusion of AS_SETs
   in the AS path, it is necessary that BGPsec specify what action a
   receiving router must take if such an update is received with
   attestation.  BCP 172 [RFC6472] recommends against the use of AS_SETs
   in updates, so it is anticipated that the use of AS_SETs will
   diminish over time.

7.6.  4-Byte AS Numbers

   Not all (currently deployed) BGP speakers are capable of dealing with
   4-byte ASNs [RFC6793].  The standard mechanism used to accommodate
   such speakers requires a peer AS to translate each 4-byte ASN in the
   AS path to a reserved 2-byte ASN (23456) before forwarding the
   update.  This mechanism is incompatible with the use of BGPsec, since
   the ASN translation is equivalent to a route modification attack and
   will cause signatures corresponding to the translated 4-byte ASNs to
   fail validation.

7.6.1.  Decision

   BGP speakers that are BGPsec capable are required to process
   4-byte ASNs.

7.6.2.  Discussion

   It is reasonable to assume that upgrades for 4-byte ASN support will
   be in place prior to the deployment of BGPsec.