wdiff rfc8374.original rfc8374.txt

Independent Submission K. Sriram, Ed.
Internet-Draft
Request for Comments: 8374 USA NIST
Intended status:
Category: Informational January 19, 2018
Expires: July 23, April 2018
ISSN: 2070-1721

BGPsec Design Choices and Summary of Supporting Discussions
draft-sriram-bgpsec-design-choices-16

Abstract

This document captures the design rationale of the initial draft
version of
the what became RFC 8205 (the BGPsec protocol specification. 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, resulting Working Group and that resulted in RFC 8205. These notes
highlight the differences and provide pointers to details and
rationale about regarding those design changes.

Status of This Memo

This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.

Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not candidates for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list Standard;
see Section 2 of RFC 7841.

Information about the current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 23, 2018.
https://www.rfc-editor.org/info/rfc8374.

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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 ....................................................4
2. Creating Signatures and the Structure of BGPsec Update
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 4 ........................................................5
2.1. Origin Validation Using ROA . . . . . . . . . . . . . . . 4 ROAs ...............................5
2.2. Attributes Signed by an Originating AS . . . . . . . . . 5 .....................6
2.3. Attributes Signed by an Upstream AS . . . . . . . . . . . 6 ........................7
2.4. What Attributes That Are Not Signed . . . . . . . . . . . . . 7 .............................8
2.5. Receiving Router Actions . . . . . . . . . . . . . . . . 8 ...................................9
2.6. Prepending of ASes in AS Path . . . . . . . . . . . . . . 9 .............................10
2.7. What RPKI Data Need be That Needs to Be Included in Updates . . . . . . . 9 ............10
3. Withdrawal Protection . . . . . . . . . . . . . . . . . . . . 10 ..........................................11
3.1. Withdrawals Not Signed . . . . . . . . . . . . . . . . . 10 ....................................11
3.2. Signature Expire Time for Withdrawal Protection
(a.k.a. Mitigation of Replay Attacks) . . . . . . . . . . . . . . 10 .....................12
3.3. Should Route Expire Time be Communicated in a
Separate
Message . . . . . . . . . . . . . . . . . . . . . . . . . 12 Message? .........................................13
3.4. Effect of Expire-Time Expire Time Updates in BGPsec on RFD . . . . . 13 ............14
4. Signature Algorithms and Router Keys . . . . . . . . . . . . 14 ...........................16
4.1. Signature Algorithms . . . . . . . . . . . . . . . . . . 14 ......................................16
4.2. Agility of Signature Algorithms . . . . . . . . . . . . . 15 ...........................17
4.3. Sequential Aggregate Signatures . . . . . . . . . . . . . 16 ...........................18
4.4. Protocol Extensibility . . . . . . . . . . . . . . . . . 17 ....................................19
4.5. Key Per per Router (Rogue Router Problem) . . . . . . . . . . 18 .....................20
4.6. Router ID . . . . . . . . . . . . . . . . . . . . . . . . 18 .................................................20
5. Optimizations and Resource Sizing . . . . . . . . . . . . . . 18 ..............................21
5.1. Update Packing and Repacking . . . . . . . . . . . . . . 19 ..............................21
5.2. Signature Per per Prefix vs. Signature Per per Update . . . . . . 19 .............22
5.3. Maximum BGPsec Update PDU Size . . . . . . . . . . . . . 20 ............................22
5.4. Temporary Suspension of Attestations and Validations . . 21 ......23
6. Incremental Deployment and Negotiation of BGPsec . . . . . . 22 ...............24
6.1. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 22 .........................................24
6.2. Inclusion of Address Family in Capability Advertisement . 22 ...24
6.3. Incremental Deployment: Capability Negotiation . . . . . 23 ............25
6.4. Partial Path Signing . . . . . . . . . . . . . . . . . . 23 ......................................25
6.5. Consideration of Stub ASes with Resource
Constraints: Encouraging Early Adoption . . . . . . . . . . . . . . . 24 ...................26
6.6. Proxy Signing . . . . . . . . . . . . . . . . . . . . . . 25 .............................................27
6.7. Multiple Peering Sessions Between between ASes . . . . . . . . . 26 ....................28
7. Interaction of BGPsec with Common BGP Features . . . . . . . 26 .................29
7.1. Peer Groups . . . . . . . . . . . . . . . . . . . . . . . 26 ...............................................29
7.2. Communities . . . . . . . . . . . . . . . . . . . . . . . 27 ...............................................29
7.3. Consideration of iBGP Speakers and Confederations . . . . 28 .........30
7.4. Consideration of Route Servers in IXPs . . . . . . . . . 28 ....................31
7.5. Proxy Aggregation (a.k.a. AS_SETs) . . . . . . . . . . . 29 ........................32
7.6. 4-Byte AS Numbers . . . . . . . . . . . . . . . . . . . . 30 .........................................32
8. BGPsec Validation . . . . . . . . . . . . . . . . . . . . . . 30 ..............................................33
8.1. Sequence of BGPsec Validation Processing in a Receiver . 30 ....33
8.2. Signing and Forwarding Updates when Signatures
Failed Validation . . . . . . . . . . . . . . . . . . . . . . . 32 .........................................34
8.3. Enumeration of Error Conditions . . . . . . . . . . . . . 32 ...........................35
8.4. Procedure for Processing Unsigned Updates . . . . . . . . 33 .................36
8.5. Response to Syntactic Errors in Signatures and
Recommendation
Recommendations for Reaction . . . . . . . . . . . . . . . 34 How to React to Them ..................36
8.6. Enumeration of Validation States . . . . . . . . . . . . 35 ..........................37
8.7. Mechanism for Transporting Validation State through iBGP 36 ..39
9. Operational Considerations . . . . . . . . . . . . . . . . . 38 .....................................41
9.1. Interworking with BGP Graceful Restart . . . . . . . . . 38 ....................41
9.2. BCP Recommendations for Minimizing Churn:
Certificate Expiry/Revocation and Signature Expire Time . . . . . . . 39 ...42
9.3. Outsourcing Update Validation . . . . . . . . . . . . . . 39 .............................42
9.4. New Hardware Capability . . . . . . . . . . . . . . . . . 40 ...................................43
9.5. Signed Peering Registrations . . . . . . . . . . . . . . 40 ..............................44
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 .......................................44
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 ...........................................44
12. Informative References . . . . . . . . . . . . . . . . . . . 41 ........................................44
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46 ..................................................49
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47 ......................................................49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 ..................................................50

1. Introduction

The goal of the BGPsec effort is to enhance the security of BGP by
enabling full AS Autonomous System (AS) path validation based on
cryptographic principles. Standards work on route origin validation
based on a Resource
certificate PKI (RPKI) is already completed or nearing
completion in the IETF SIDR WG. 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 RFC specification, [RFC8205], was published recently [RFC8205]. recently. The key
high-level design goals of the BGPsec protocol are as follow follows
[RFC7353]:

o Rigorous path validation for all announced prefixes; prefixes -- not merely
showing that a path is not impossible.

o Incremental deployment capability; capability -- no flag-day requirement for
global deployment.

o Protection of AS paths only in inter-domain routing (eBGP); (External BGP
(eBGP)) -- not applicable to iBGP Internal BGP (iBGP) (or to IGPs).

o Aim Aiming for no increase in a provider's data exposure (e.g., require no not
requiring any disclosure of peering relations, etc.). relations).

This document provides design justifications for the initial draft
version of the BGPsec protocol specification [I-D.lepinski-bgpsec-protocol]. [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 working group, resulting WG. (These design decisions resulted in [RFC8205]. RFC 8205
[RFC8205].) The notes provide pointers to the details and/or discussion
discussions about the design changes.

The design choices and discussions are presented under in the following
sections (under the following eight broad categories (with categories, with many
subtopics within each category):
(1) Creating

o Section 2 ("Creating Signatures and the Structure of BGPsec Update Messages,
(2) Withdrawal Protection, (3) Signature
Messages")

o Section 3 ("Withdrawal Protection")

o Section 4 ("Signature Algorithms and Router Keys,
(4) Optimizations Keys")

o Section 5 ("Optimizations and Resource Sizing, (5) Incremental Sizing")

o Section 6 ("Incremental Deployment and Negotiation of BGPsec, (6) Interaction BGPsec")

o Section 7 ("Interaction of BGPsec with Common BGP
Features, (7) BGPsec Validation, and (8) Operational Considerations. 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 ROA ROAs

2.1.1. Decision

Route origin validation using Route Origin Authorization (ROA) 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 constructs, as developed in the
IETF SIDR WG WG, is a necessary component of BGP security. It provides
cryptographic validation that the first hop 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 NLRI 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 in RFC 8205. 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 SIDR
list post [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. It is As
stated in Section 4.1 of RFC 8205 that 8205, a BGPsec update message MUST "MUST use
the MP_REACH_NLRI attribute [RFC4760] to encode the prefix. prefix."

2.2.2. Discussion

The next hop next-hop ASN is included in the data covered by the signature.
Without that this inclusion, the AS path cannot be secured; for example, it
the path can be shortened (by a MITM) 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 against replay attacks and withdrawal
suppression [I-D.ietf-sidrops-bgpsec-rollover]
[I-D.sriram-replay-protection-design-discussion]. [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, 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
Section
Sections 5.1 and Section 5.2). If a mechanism were employed to preserve
prefixes that were dropped, this would reveal info information to later
subsequent ASes that is not revealed in normal BGP operation. Thus,
a tradeoff trade-off was made to preserve the level of route info 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 doesn't does not understand BGPsec somehow gets a an update message with the
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 signatures 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 co-exist 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
(origin (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
information, including the NLRI length, NLRI prefix, AS path, next
ASN, signature algorithm suite ID, and Expire Time. There are
multiple choices for regarding what is signed by an upstream AS AS, as follows.
follows:

o Method 1: Signature The signature protects the combination of the NLRI
length, NLRI prefix, AS path, next ASN, signature algorithm suite
ID, and Expire
Time; or Time,

o Method 2: Signature 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; ASN, or

o Method 3: Signature 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., AS(i+1)
(i.e., the next ASN), and {Sig(i-1), Sig(i-2), ..., Sig2, Sig1}.

Note: Please see the notes in Section Sections 2.2.1 and Section 2.2.2 about regarding the
elimination of the Expire Time field in the finalized BGPsec protocol
specification [RFC8205].

2.3.1. Decision

It was decided that that Method 2 will be used. Please see
[I-D.lepinski-bgpsec-protocol]
[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 SIDR list post [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) and 8205); this sequencing of data is
motivated by implementation efficiency considerations; see SIDR list post 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, then the remaining bytes will overflow into
a second hash block, which results resulting in a performance penalty. So 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. What Attributes That Are Not Signed

2.4.1. Decision

Any attributes other than those identified in Section Sections 2.2 and
Section 2.3
are not signed. Examples of such attributes are
Community Attribute, include the community
attribute, the NO-EXPORT Attribute, Local_Pref, etc. attribute, and Local_Pref.

2.4.2. Discussion

The above stated

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 next hop and
does not need signing. The BGPsec design should work with any transport layer
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 are
described by the following example. 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 (#2 (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 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, 5 in Section 3.1 of
[RFC8205]).

2.6.2. Discussion

The draft-00 initial version [BGPsec-Initial] of the protocol BGPsec specification
calls for a signature to be associated with each prepended AS. The
optimization of having just one signature for multiple prepended ASes will be
was pursued later (i.e., beyond draft-00 specification). If such
optimization later. The pCount field is used, a replication count would be included (in the
signed update) now used to specify how many times an represent AS was prepended.

2.7. What RPKI Data Need be
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 cert certificate
must be included in a signed update. This info information identifies the
router certificate, based on the SKI generation criteria defined in
[RFC6487].

2.7.2. Discussion

It was discussed if

Whether or not each router public key certificate should be included
in a signed update. 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 So, it is best to avoid this complexity 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 value in an AS path associated with the origin AS's
signature (see Section 3.2).

Repeated withdrawals and announcements for a prefix can run up the
BGP RFD 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 in Section 2.2.2, (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
[I-D.ietf-sidrops-bgpsec-rollover]
[I-D.sriram-replay-protection-design-discussion].
[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.

The

It is recommended that the duration of the signature Expire Time is recommended to be
on the order of days (preferably) (preferably), but it may be on the order of
hours (about 4 to 8 hours) in some cases, cases on the basis of perceived
need for extra protection from replay attacks (i.e., where extra
replay protection is perceived to be critical. 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 and additional configurable. Additional guidance can be provided
via an operational considerations document later. Further, the
actual re-origination time should to 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 should detect
if that the
only attribute change in an announcement (relative to the current
best path) is the expire time 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 only BGPsec
speakers.) speakers only.) This
procedure will reduce BGP chattiness for the non-
BGPsec non-BGPsec border
routers.

3.2.2. Discussion

Mitigation of BGPsec update replay attacks can be thought of as
protection against malicious re-advertisement 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.

The

As noted in Section 3.2.1, the recommended Expire Time value is on
the order of days 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,
and thus causes causing more BGP
chatter.) Even a 4 hours 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.

It was

As stated above that in Section 3.2.1, the originating AS will re-originate a
route sufficiently in advance of its Expire Time. What is considered
sufficiently
"sufficiently in advance? For this, advance"? To answer this question, modeling should
be performed to determine the 95th-percentile convergence time of
update propagation in BGPsec enabled 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 Message?

3.3.1. Decision

The idea of sending a new signature expire time Expire Time in a special message
(rather than re-transmitting retransmitting the entire update with signatures) was
considered. However, it the decision was decided not made to not do this.
Re-origination to communicate a new signature Expire Time will be
done by
propagation of 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 update any
processing load related to the update may be reduced. But it was
recognized that such a re-beaconing message
necessarily by necessity entails AS
path and prefix information, and hence 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 like 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, and hence happens; hence, the
update will need to propagate throughout the Internet (limited only
by best path selection process). the process of best-path selection). It was accepted that this
cost of added churn will be unavoidable.

3.4. Effect of Expire-Time Expire Time Updates in BGPsec on RFD

3.4.1. Decision

With regard to the Route Flap Damping (RFD) RFD protocol
[RFC2439][JunOS][CiscoIOS], [RFC2439] [JunOS] [CiscoIOS], no
differential treatment is required for
Expire-Time triggered 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
RFD-related processing), since they are identical except for the
change in the Expire Time value. The way this This can be accomplished is by not
assigning an RFD penalty to Expire-Time triggered Expire-Time-triggered updates. If the
community agrees, this could be accommodated, but a change to the
BGP-RFD protocol specification will be required.

3.4.2. Discussion

Summary:

The

To summarize, this decision is supported by the following
observations: (1) Expire
Time-triggered

1. Expire-Time-triggered updates are generally not preceded by withdrawals, and
hence
withdrawals; hence, the path hunting and associated RFD
exacerbation
[Mao02][RIPE580] [Mao02] [RIPE580] problems are not anticipated; (2) anticipated.

2. Such updates would not normally change the best path (unless
another concurrent event impacts the best path); (3) Expire Time-triggered path).

3. Expire-Time-triggered updates would have a negligible impact on
RFD penalty accumulation because the re-
advertisement re-advertisement interval is
much longer relative to the half-time of
decay of RFD penalty. penalty decay.

Elaborating further on reason #3 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 a few or
several hours (see Section 3.2). During that time period, any
incremental contribution to the RFD penalty due to a Expire
Time-triggered an Expire-Time-
triggered update would decay sufficiently to have negligible (if any)
impact on damping the address prefix in consideration. question.

Additional details of regarding this analysis and justification can be found
below.

Further Details of the 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 few or several hours (see
Section 3.2). The incremental RFD penalty assigned to a prefix due
to a re-beaconed update varies varies, depending on the implementation. For
example, it appears that the JunOS implementation [JunOS] would
assign a penalty of 1000 or 500 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 a case of an
attribute change. The On the other hand, the Cisco implementation
[CiscoIOS] on the other
hand assigns an RFD penalty only in the case of an actual flap
(i.e., a route is available, then unavailable, or vice versa). So So,
it appears that Cisco Cisco's implementation of RFD would not assign any
penalty for a re-beaconed update (i.e., a route was already
advertised
previously; previously and was not withdrawn; withdrawn, and the re-beaconed
update is merely updating the expire time Expire Time attribute). Even if one
assumes that an RFD penalty of 500 is assigned (corresponding to an
attribute change in according to the JunOS RFD implementation), it can
be illustrated that the incremental
affect effect it would have on damping
the prefix in consideration question would be
negligible. The reason for this is as follows. The 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 few or several hours. An
incremental penalty of 500 would decay to 31.25 in one hour; 1 hour, 0.12 in
two hours;
2 hours, and 3x10^(-5) in three 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.

4. Signature Algorithms and Router Keys

4.1. Signature Algorithms

4.1.1. Decision

Initially, ECDSA with 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 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 curve P-256 and SHA-256.

4.1.2. Discussion

Initially, choice of 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 algorithm was decided upon
because it yields a smaller signature size, and hence size; hence, the update size
and in turn (in turn) the RIB size needed in BGPsec routers would be much
smaller [RIB_size].

Testing with

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

For Elliptic Curve Cryptography (ECC) algorithms, according to
[RFC6090], optimizations

Optimizations and specialized algorithms (e.g., for speed-
ups) speedups) built
on Elliptic Curve Cryptography (ECC) algorithms may have active IPR, 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 do not
have IPR encumbrances. algorithms. (To understand this better, [RFC6090] can
be useful as a starting point.)
Note: Recently, even open source open-source implementations have incorporated
certain cryptographic optimizations and demonstrated significant
performance speedup [Gueron]. Researchers continue to devote
significant efforts to demonstrate 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., algorithm (i.e., the current
algorithm,
algorithm) to the next (new) algorithm, the updates will carry two
sets of signatures (i.e., two Signature-List Blocks), Signature_Blocks), one corresponding to
each algorithm. Each Signature-List Block Signature_Block will be preceded by its
type-length field and an algorithm-suite algorithm suite identifier. A BGPsec
speaker that has been upgraded to handle the new algorithm should
validate both Signature-List Blocks, Signature_Blocks and then add its corresponding
signature to each Signature-List Block 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-
List Block Signature_Block of the new algorithm, algorithm
and then will forward the update after adding its own sig signature to
the Signature-List Block Signature_Block of the current algorithm.

It was decided that there will be at most two Signature-List Blocks Signature_Blocks per
update.

Note: Signature-List Block BGPsec path signatures are carried in the Signature_Block,
which is Signature_Block an attribute contained in RFC 8205. 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-List Block 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 (and, hence, doesn't know how long
signatures were for that algorithm suite) could still skip over the
corresponding Signature-List Block Signature_Block when parsing the message.

The overlap period between the two algorithms is expected to last two
2 to four 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-List Blocks 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 in the discussion section below 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 Sequential Aggregate Signature (SAS) the SAS method, there would be only one (aggregated) signature per
signature block, irrespective of the number of AS hops. For example,
ASn (nth (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, PDU bandwidth
and in Protocol Data Unit (PDU) size, and maybe in RIB size 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 technique, and thus its adoption is
potentially risky.

4.4. Protocol Extensibility

There is a 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, that will
require a new version
of BGPsec. 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
AS path (e.g., aggregate signatures).

4.4.1. Decision

The

This protocol-version transition mechanism here 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-List Blocks), Signature_Blocks), one corresponding to each version. A
protocol-version identifier is associated with each Signature-List
Block. Signature_Block.
Hence, each Signature-List Block 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-List Blocks,
Signature_Blocks and then add its corresponding signature to each Signature-List Block
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-List Block Signature_Block of the new version, version and then will
forward the update with an attachment of its own signature to the Signature-List Block
Signature_Block of the current version.

Note: Signature-List Block is Signature_Block in RFC 8205. 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
during the 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 path attribute
(let's call it BGPsec_PATH_SIG_TWO, which "BGPsec_PATH_TWO") that is designed to accommodate the
desired changes to BGPsec. At this point point, a transition would begin which
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_Signatures BGPsec_PATH (current) attribute (see
Section 3 of RFC 8205) and the new BGPsec_PATH_SIG_TWO BGPsec_PATH_TWO attribute. Once
the transition is complete, the use of BGPsec_Path_Signatures BGPsec_PATH could then be
deprecated, at which point BGPsec speakers will include only the new BGPsec_PATH_SIG_TWO
BGPsec_PATH_TWO attribute. Such a process could facilitate a
transition to a new BGPsec semantics in a backwards compatible backwards-compatible fashion.

4.5. Key Per 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 key pair will be represented in
an end-entity certificate issued under the CA cert 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 subject name will be the string "router" "ROUTER"
followed by a decimal representation of a 4-byte AS number ASN followed by the
router ID. See the current RFCs for preferred standard
textual representations for 4-byte ASNs [RFC5396] and router IDs
[RFC6891]. (Note: The details are specified in Section 3.1 in
[RFC8209].)

4.6.2. Discussion

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

5. Optimizations and Resource Sizing

5.1. Update Packing and Repacking

With traditional BGP protocol [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 the a level of
complexity that would be 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 recommendation recommendations regarding packing
and repacking may be
be revisited when optimizations are considered in
the future.

5.1.2. Discussion

Currently, with traditional BGP, there are, on average, approximately
4
four prefixes announced per update [RIB_size]. So So, the number of BGP
updates (carrying announcements) is about 4 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 and Section 2.3). 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 per-prefix basis.
However, one problem regarding this approach, i.e., approach -- multiple prefixes in
a BGP update but with a separate signature for each prefix, prefix -- is that
the resulting BGP update violates the basic definition of a BGP
update. That is because
update: the different prefixes will have different
signature signatures and expire-time
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 per Prefix vs. Signature Per per Update

5.2.1. Decision

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

5.2.2. Discussion

Some notes to assist in future optimization discussions: 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 signature the "signature per update update" technique
is used, then there are potentially 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)[I-D.draft-clynn-s-bgp]. (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 be able to know and
to 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), validation); further increases the size of updates
and, thus thus, of the
RIB, 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); packing),
so there is no need for the EPA attribute. 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 if as to whether or not BGPsec would
require a larger update PDU size.

5.3.1. Decision

The current thinking is that the max maximum PDU size should be increased
to 64 KB [I-D.ietf-idr-bgp-extended-messages] [BGP-Ext-Msg] so that there is sufficient room to
accommodate two signature-list blocks 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 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.
There is An
effort is underway in the IETF to extend it to a larger size
[I-D.ietf-idr-bgp-extended-messages].
[BGP-Ext-Msg]. BGPsec will conform to whatever maximum message size that
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 desirable; the specification does not forbid that. 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 So, it is possible that a BGPsec router
temporarily pauses performing the validation or signing of updates.
When the work load workload eases, the BGPsec router should clear the
validation or signing backlog, 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), 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) (out of band) that a BGPsec-capable
peer AS never to downgrade a signed update to an unsigned update.
However, in partial deployment 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. For this, peer; the sending
router follows does so by following the reconstruction procedure of in
Section 4.4 in of [RFC8205] to generate an AS_PATH attribute
corresponding to the BGPsec_PATH attribute in a received signed
update. If the above
mentioned 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 for detecting 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 must
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. Re-
negotiation
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 incremental /
partial-deployment considerations. Also, see Section 6 of [RFC8207]
where it is described that
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, ASes and
expedites incremental deployment.

6.3.2. Discussion

During partial deployment, there will be BGPsec islands as a result
of this

The partial-deployment approach to incremental deployment. 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

"Partial path signing 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. It was decided that this should not be permitted.

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
AS path must sign the update. So So, in a signed update 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 re-
introduces
reintroduces the following attack vulnerability: If if a BGPsec speaker
is allowed to sign an unsigned update, update and if signed (i.e., partially
or fully signed) updates would be preferred to over unsigned updates,
then a faulty, misconfigured misconfigured, or subverted BGPsec speaker can
manufacture any unsigned update it wants (with insertion of (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
BGPsec the use asymmetrically. 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 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, 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 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. Stub The stub AS does not
sign
updates updates, but it obtains an RPKI (CA) certificate, 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 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 "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
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 PI 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 if that an
update is not fully signed and then look for the extended ROA to
validate.

4. Another method method, based on a different form of indirection indirection, would
be as follows: Customer follows. The customer (stub) AS registers something like a
Proxy Signer Authorization, which authorizes the second hop 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 Extended ROA approach based approach). 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 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). A An advantage for a stub AS that
does asymmetric BGPsec has the advantage 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 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 proxy-sign BGP announcements for a
customer (downstream) AS AS, provided that the customer AS obtains an
RPKI (CA) certificate, issues a router certificate under that CA
certificate, and it passes on the private key for that certificate to
its upstream provider. That ISP (i.e., the second hop 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, 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 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 multi-homed multihomed to
two ISPs, i.e., AS8 peers with AS1 and AS2 of ISP-1 and ISP-2,
respectively. In this case case, AS8 would have an RPKI (CA) certificate;
it issues two separate router certificates (corresponding to AS1 and
AS2) under that CA certificate; certificate, and it passes on the respective
private keys for those two certificates to its upstream providers AS1
and AS2. Thus,AS8 Thus, AS8 has proxy signing a proxy-signing service from both of its
upstream ASes. In the future, if the customer AS8 disconnects were to disconnect from ISP-2,
then it would revoke the router certificate corresponding to AS2.

6.7. Multiple Peering Sessions Between between ASes

6.7.1. Decision

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

6.7.2. Discussion

In traditional BGP, multiple peering sessions, sessions between different pairs
of routers (between two neighboring ASes) may be simultaneously used
for load sharing. Similarly, BGPsec capable BGPsec-capable ASes can also have
multiple peering sessions between them. Because routers in an AS can
have distinct private keys, the same update update, when propagated over
these multiple peering sessions 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 the 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 (maybe of ASes (and maybe as high
many as 300) of ASes 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
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, that would require
divulging information about the
forward AS-set 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 what any message that is
signed in BGPsec.

7.2.2. Discussion

The

From a security standpoint, the community attribute - in its current definition - attribute, as currently
defined, may be inherently defective, from a security standpoint. defective. A substantial amount of work is needed
on the semantics of the community attribute, 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 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 what
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
potentially this
flag could potentially be used to indicate to BGPsec if 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, speaker and that executes
BGPsec, BGPsec
will necessarily 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 external eBGPsec peer using the
public AS number 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 (Figure 5) and of [RFC8205], as well as
Section 4.3 in [RFC8205] of [RFC8205], for
the 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 (individual draft-00) makes

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

Note: The above decision changed subsequently. subsequently changed: RFC 8205 allows the
accommodation for of IXPs, especially for the case of transparent route servers. The
pCount (AS prepend count) field is set to 0 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 direct bilateral peering through the IXP, (B) BGP peering
between clients via a 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, B because of the difficulties of managing up to n x (n-1)/2
direct inter-connections 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 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: In Section 5.2 of RFC 8205, it is specified 8205 specifies that a receiving BGPsec
router MUST "MUST handle any syntactical or protocol errors in the
BGPsec_PATH attribute by using the "treat-as-withdraw" 'treat-as-withdraw' approach as
defined in RFC 7606 [RFC7606]. [RFC7606]."

7.5.2. Discussion

Proxy aggregation does occur in the Internet today, but is 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 in case 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 [RFC4893]. [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 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.

8. BGPsec Validation

8.1. Sequence of BGPsec Validation Processing in a Receiver

It is natural to ask in what sequence a receiver must perform BGPsec
update validation so that if a failure were to occur (i.e., the
update was determined to be invalid) the processor would have spent
the least amount of processing or other resources.

8.1.1. Decision

There was agreement that the following sequence of receiver
operations is quite meaningful, and meaningful; the following steps are included in the individual
draft-00 BGPsec specification [I-D.lepinski-bgpsec-protocol].
[BGPsec-Initial]. However, the ordering of validation these validation-
processing steps is not a normative part of the BGPsec specification.

1. Verify that the signed update is syntactically correct. For
example, check to see if the number of signatures match with matches the
number of ASes in the AS path (after duly accounting for AS
prepending).

2. Verify that the origin AS is authorized to advertise the prefix
in question. This verification is based on data from ROAs, ROAs and
does not require any crypto cryptographic operations.

3. Verify that the advertisement has not yet expired.

4. Verify that the target ASN in the signature data matches the ASN
of the router that is processing the advertisement. Note that
the target ASN target-ASN check is also a non-crypto non-cryptographic operation and
is fast.

5. Validate the signature data starting from the most recent AS to
the origin.

6. Locate the public key for the router from which the advertisement
was received, using the SKI from the signature data.

7. Hash the data covered by the signature algorithm. Invoke the
signature validation algorithm on the following three inputs: the
locally computed hash, the received signature, and the public
key. There will be one output: valid or invalid.

8. Repeat steps 5 and 6 for each preceding signature in the
Signature-List Block,
Signature_Block until (a) the signature data for the origin AS is
encountered and processed, processed or until (b) either of these steps fails.

Note: Significant refinements to the above list occurred in the
progress towards RFC 8205. The detailed syntactic error syntactic-error checklist is
presented and explained in Section 5.2 of [RFC8205]. Also, a logical
sequence of steps to be followed in the validation of
Signature_Blocks is described in Section 5.2 of [RFC8205].

8.1.2. Discussion

The suggested sequence of receiver operations described above were
discussed and are viewed as appropriate, if

If the goal is to minimize computational costs associated with
cryptographic operations. operations, the sequence of receiver operations that is
suggested above is viewed as appropriate. One additional interesting
suggestion was that when there are two
Signature-List Blocks Signature_Blocks in an update,
the validating router can first verify whichever which of the two algorithms is cheaper
cheaper, to save on processing. If that Signature-List Block Signature_Block verifies,
then the router can skip validating the other Signature-List Block. Signature_Block.

8.2. Signing and Forwarding Updates when Signatures Failed Validation

8.2.1. Decision

A BGPsec router should sign and forward a signed update to upstream
peers if it selected the update as the best path, regardless of
whether the update passed or failed validation (at this router).

8.2.2. Discussion

The availability of RPKI data at different routers (in the same AS or
different ASes) may differ, depending on the sources used to acquire
RPKI data. Hence Hence, an update may fail validation in one AS AS, and the
same update may pass validation in another AS. Also, an update may
fail validation at one router in an AS AS, and the same update may pass
validation at another router in the same AS.

A BCP may be published later in which that will identify some update-failure
conditions of update
failure are identified which that may be present unambiguous cases for rejecting the update, in
update (in which case the router must would not select the AS path in the update.
update). These cases are TBD. "TBD" (to be determined).

8.3. Enumeration of Error Conditions

Enumeration of error conditions and the recommendations for reactions how to
react to them are still under discussion.

8.3.1. Decision

TBD. Also, please see Section 8.5 for the decision and discussion
specifically related to syntactic errors in signatures.

Note: Section 5.2 of RFC 8205 describes the detection of syntactic
and protocol errors in BGPsec updates as well as how the updates with
such errors are to be handled.

8.3.2. Discussion

The following list here is a first cut at attempt to provide some possible error
conditions and recommended receiver reactions in response to the
detection of those errors. Refinements will follow after further
discussions.

E1 Abnormalities that where a peer (i.e., the preceding AS) should
definitely not have propagated to a receiving eBGPsec router. Examples:
For example, (A)
The the number of signatures does not match the
number of ASes in the AS path (after accounting for AS prepending);
prepending), (B) There there is an AS_SET in the received update and
the update has signatures; signatures, or (C)
Other other syntactic errors with signatures.
signatures have occurred.

Reaction: See Section 8.5.

E2 Situations where a receiving eBGPsec router cannot find the cert
certificate for an AS in the AS_PATH. AS path.

Reaction: Mark the update as "Invalid". It is acceptable to
consider the update in best path the best-path selection. If it is chosen,
then the router should sign and propagate the update.

E3 Situations where a receiving eBGPsec router cannot find a ROA for
the {prefix, origin} pair in the update.

Reaction: Same as in (E2) above.

E4 The Situations where the receiving eBGPsec router verifies signatures
and finds that the update is Invalid "Invalid" (even though its peer
might not have known, e.g., due to RPKI skew).

Reaction: Same as in (E2) above.

In some networks, best path selection the best-path-selection policy may specify
choosing an unsigned update over one with invalid signature(s).
Hence, the signatures must not be stripped even if the update is
"Invalid". No evil bit is set in the update (when it is Invalid)
"Invalid") because an upstream peer may not get that same answer
when it tries to validate.

8.4. Procedure for Processing Unsigned Updates

An update may come in unsigned from an eBGP peer or internally (e.g.,
as an iBGP update). In the latter case, the route is being
originated from within the AS in consideration. question.

8.4.1. Decision

If an unsigned route is received from an eBGP peer, peer and if it is
selected, then the route will be forwarded unsigned to other eBGP
peers,
peers -- even BGPsec-capable peers. If the route originated in this
AS (IGP or iBGP) and is unsigned, then it should be signed and
announced to external BGPsec-capable peers.

8.4.2. Discussion

There

It is also a possibility possible that an update received in IGP (or iBGP) may have
private AS numbers ASNs in the AS path. These private AS numbers ASNs would normally
appear in the right most rightmost portion of the AS path. It was noted that in
this case, case the private AS numbers ASNs to the right would be removed (as done in
traditional BGP), and then the update will be signed by the
originating AS and announced to BGPsec-capable eBGP peers.

Note: See Section 7.5 of [RFC8205] for operational considerations for
BGPsec in the context of private AS numbers. ASNs.

8.5. Response to Syntactic Errors in Signatures and Recommendation Recommendations for
Reaction
How to React to Them

Note: The contents in of this subsection (i.e., Section 8.5) differ
substantially from the syntactic and protocol error handling recommendations for BGPsec in RFC 8205. 8205 regarding the
handling of syntactic errors and protocol errors. Hence, the reader
may skip
reading this subsection and instead read Section 5.2 of [RFC8205].
This section subsection (Section 8.5) is kept here for the sake of archival
value concerning design discussions.

Different types of error conditions were discussed in Section 8.3.
Here
Here, the focus is only on syntactic error syntactic-error conditions in signatures.

8.5.1. Decision

If there are syntactic error syntactic-error conditions such as (a) (A) AS_SET and
Signature-List Block (or Signature_Block per RFC 8205)
BGPsec_PATH both appear appearing in an update, or (b) (B) the number of signatures does
not match matching the number of ASes (after accounting for any AS
prepending), or (c) (C) a parsing issue occurs occurring with the BGPsec_Path_Signatures BGPsec_PATH
attribute, then the update (with the signatures stripped) will still
be considered in the
best path selection algorithm best-path-selection algorithm. (**Note: This is
not true in RFC
8205**). 8205**.) If the update is selected as the best path,
then the update will be propagated unsigned. The error condition
will be logged locally.

A BGPsec router will follow whatever the current IETF (IDR WG)
recommendations are for notifying a peer that it is sending malformed
messages.

In the case when there are two Signature-List Blocks Signature_Blocks in an update, and one
or more syntactic errors are found to occur within one of them but
the other one is free of any syntactic errors, then the update will
still be considered in the best path selection best-path-selection algorithm after the
syntactically bad Signature-List Block Signature_Block has been removed removed. (**Note: This is
not true in RFC 8205**). 8205**.) If the update is selected as the best path,
then the update will be propagated with only one (i.e., the
error-free) Signature-List Block. Signature_Block. The error condition will be logged
locally.

8.5.2. Discussion

As stated above, a BGPsec router will follow whatever the current
IETF (IDR WG) recommendations are for notifying a peer that it is
sending malformed messages. Question: If the error is persistent, persistent and there is
a full BGP table dump occurring, occurs, then would there be 500K such errors
resulting in 500K notify "notify" messages sent to the erring
peer? The answer was peer that rate is
generating the errors? Answer: Rate limiting would be applied to the
notify messages which and should prevent any overload due to these
messages.

8.6. Enumeration of Validation States

Various validation conditions are possible which that can be mapped to
validation states for possible input to the BGPsec decision process.
These conditions can be related to whether an update is signed,
Expire Time is checked, route origin validation is checked against a
ROA,
signatures signature verification passed, etc.

8.6.1. Decision

It was decided that BGPsec validation outcomes will be mapped to one
of only two validation states: (1) Valid - -- passed all validation
checks (i.e., Expire Time check, route origin and Signature-List
Block validation), Signature_Block
validation) and (2) Invalid - -- all other possibilities. "Invalid"
would include situations such as (1) did not perform
validation due the following:

1. Due to a lack of RPKI data or insufficient RPKI data, (2) validation
was not performed.

2. The signature Expire Time check failed, (3) route failed.

3. Route origin validation failed, and (4)
signature failed.

4. Signature checks were performed performed, and one or more of them failed.

Note: Expire Time is obsolete (see the notes in Section Sections 2.2.1 and
Section
2.2.2). RFC 8205 uses the states 'Valid' "Valid" and 'Not Valid', "Not Valid", but only
with respect to AS path validation (i.e., not including the result of
origin validation); see Section 5.1 of [RFC8205]). 'Not
Valid' [RFC8205]. "Not Valid"
includes all conditions in which path validation was attempted but a 'Valid'
"Valid" result could not be reached (note: path reached. (Note: Path validation is not
attempted in the case of syntactic or protocol errors in a BGPsec
update; see Section 5.2 of [RFC8205]). [RFC8205].) Each Relying Party (RP) is
expected to devise its own policy to suitably factor in the results
from of
origin validation [RFC6811] and path validation [RFC8205] in into its
path selection
path-selection decision.

8.6.2. Discussion

It may be noted that the result of update validation is just an
additional input for the BGP decision process. The router's local
policy ultimately has control over what action (regarding BGP path
selection) is taken.

Initially, four validation states were considered: (1) Update

1. The update is not
signed; (2) Update signed.

2. The update is signed signed, but the router does not have corresponding
RPKI data to perform a validation check.

3. The validation check; (3) Invalid (validation check
performed was performed, and failed); (4) Valid (validation the check performed failed
(Invalid).

4. The validation check was performed, and
passed). Later, the check passed (Valid).

As stated above, it was later decided that BGPsec validation outcomes
will be mapped to one of only two validation states as stated above. states. It was observed
that an update can be invalid for many different reasons. To begin
to differentiate these numerous reasons and to try to enumerate
different flavors of the Invalid state is will not likely to be
constructive in route selection decision, route-selection decisions and may even introduce
to new vulnerability
vulnerabilities in the system. However, some questions remain remain, such
as the following. following:

Question: Is there a need to define a separate validation state for
the case when an update is not signed but the {prefix, origin} pair matched
with
matches the ROA information? This question was discussed, and After some discussion, a tentative
conclusion was that reached: this is in principle similar to validation
based on partial path signatures and that signing (which was ruled out earlier (see out; see Section 6.4). So
So, there is no need to add another validation state for this case;
treat it as "Unverified" (i.e., "Invalid") "Invalid", considering that it is unsigned. Questions still remain, e.g., would

Another remaining question: Would the relying
party RP want to give the update in consideration a
higher preference over another unsigned update that failed origin
validation or over a signed update that failed both signature and ROA
validation?

8.7. Mechanism for Transporting Validation State through iBGP

8.7.1. Decision

BGPsec validation need be performed only at eBGP edges. The
validation status of a BGP signed/unsigned update may be conveyed via
iBGP from an ingress edge router to an egress edge router. Local
policy in the AS will determine how the validation status is conveyed
internally, using various pre-existing preexisting mechanisms, e.g., setting a BGP
community, or modifying a metric value such as Local_Pref or MED. A
signed update that cannot be validated (except those with syntax
errors) should be forwarded with signatures from the ingress router
to the egress router, where it is signed when propagated towards
other eBGPsec speakers in neighboring ASes. Based entirely on local
policy settings, an egress router may trust the validation status
conveyed by an ingress router router, or it may perform its own validation.
The latter approach may be used at an operator's discretion, under
circumstances when RPKI skew is known to happen at different routers
within an AS.

Note: An extended community for carrying the origin validation state
in iBGP has been specified in RFC 8097 [RFC8097]). [RFC8097].

8.7.2. Discussion

The attribute used to represent the validation state can be carried
between ASes ASes, if desired. ISPs may like to carry it over their eBGP
links between their own ASes (e.g., sibling ASes). A peer (or
customer) may receive it over an eBGP link from a provider, provider and may
want to use it to shortcut their own validation check. However, the
peer (or customer) should be aware that this validation-state
attribute is just a preview of a neighbor's validation and must
perform their own validation check to be sure of the actual state of
the update's validation. Question: Should validation state validation-state
propagation be protected by attestation in case cases where it has utility is useful
for diagnostics purposes? It The decision was decided not made to not protect the validation state
validation-state information using signatures.

The following are intended only as suggestions to be considered by AS
operators.

The following Validation validation states may be needed for propagation via
iBGP between edge routers in an AS:

o Validation states communicated in iBGP for an unsigned update
(route origin validation result): (1) Valid, (2) Invalid,
(3) 'Not
Found' NotFound (see [RFC6811]), (4) Validation Deferred.

* An update could be unsigned for either of the following two reasons
reasons, but they need not be distinguished: (a) Because it had no
signatures (came (i.e., came in unsigned from an eBGP peer), peer) or
(b) Signatures signatures were present but stripped.

o Validation states communicated in iBGP for a Signed signed update:
(1) Valid, (2) Invalid, (3) Validation Deferred.

The reason for conveying the additional "Validation Deferred" state
may be stated illustrated as follows. An ingress edge Router A receiving an
update from an eBGPsec peer may not attempt to validate signatures
(e.g., in a processor overload situation), and in that case Router A
should convey "Validation Deferred" state for that signed update (if
selected for best path) in iBGP to other edge routers. Then an An egress
edge Router B B, upon receiving the update from ingress Router A A, would
then be able to perform its own validation (origin validation for an
unsigned update or origin/signature validation for a signed update).
As stated before, the egress Router router (Router B in this example) may
always choose to perform its own validation when it receives an
update from iBGP (independent (independently of the update's validation status
conveyed in iBGP) to account for the possibility of RPKI data skew at
different routers. These various choices are local and entirely up to operator at
the operator's discretion.

9. Operational Considerations

Note: Significant thought has been devoted to operations and
management considerations post publication of individual draft-00 of
BGPsec specification. For this, subsequent to the writing of
[BGPsec-Initial]. The reader is referred to [RFC8207] and Section 7
of [RFC8205]. [RFC8205] for details.

9.1. Interworking with BGP Graceful Restart

BGP Graceful Restart (BGP-GR) [RFC4724] is a mechanism currently used
to facilitate non-stop nonstop packet forwarding when the control plane is
recovering from a fault (i.e., the BGP session is restarted), restarted) but the
data plane is functioning. A question was asked regarding if Two questions were raised: Are there
are any
special concerns about how BGP-GR works while BGPsec is operational?
Also, what happens if the BGP router operation transitions from
traditional BGP operation to BGP-GR to BGPsec, in that order?

9.1.1. Decision

No decision was made relative to this issue (at the time of
publication of individual draft-00 of BGPsec specification). that
[BGPsec-Initial] was written).

Note: See Section 7.7 of [RFC8205] for comments concerning the
operation of Graceful Restart BGP-GR with BGPsec. They are consistent with the
discussion below.

9.1.2. Discussion

BGP-GR can be implemented with BGPsec BGPsec, just as it is currently
implemented with traditional BGP. The Restart State bit, Forwarding
State bit, End-of-RIB marker, Staleness staleness marker (in RIB-in), the Adj-RIB-In),
and Selection_Deferral_Timer are key parameters associated with
BGP-GR [RFC4724]. These parameters would apply to BGPsec BGPsec, just as
they do
with apply to traditional BGP.

Regarding what happens if the BGP router transitions from traditional
BGP to BGP-GR to BGPsec, the answer would simply be as follows. If
there is a software upgrade to BGPsec during BGP-GR (assuming that
the upgrade is being done on a live BGP speaker), then the BGP-GR
session should be terminated before a BGPsec session is initiated.
Once the eBGPsec peering session is established, then the receiving
eBGPsec speaker will see signed updates from the sending (newly
upgraded) eBGPsec speaker. There is no apparent harm (it may, in
fact, be desirable) if the receiving speaker continues to use previously-learned
previously learned unsigned BGP routes from the sending speaker until
they are replaced by new BGPsec routes. However, if the Forwarding
State bit is set to zero by the sending speaker (i.e., the newly
upgraded speaker) during BGPsec session negotiation, then the
receiving speaker would mark all
previously-learned previously learned unsigned BGP
routes from that sending speaker as
"Stale" "stale" in its RIB-in. Adj-RIB-In. Then,
as BGPsec updates are received (possibly interspersed with unsigned
BGP updates), the "Stale" "stale" routes will be replaced or refreshed.

9.2. BCP Recommendations for Minimizing Churn: Certificate Expiry/
Revocation and Signature Expire Time

9.2.1. Decision

This

Work related to this topic is still work in progress.

9.2.2. Discussion

BCP recommendations for minimizing churn in BGPsec have been
discussed. There are potentially various potential strategies on how routers
should react to events such events as certificate expiry/revocation, expiry/revocation and
signature Expire Time exhaustion, etc. exhaustion [Dynamics]. The details will be
documented in the near future after additional work is completed.

9.3. Outsourcing Update Validation

9.3.1. Decision

Update signature validation and signing can be outsourced to an off-
board
off-board server or processor.

9.3.2. Discussion

Possibly

Possibly, an off-router box (one or more per AS) can be used that
performs path validation. For example, these capabilities might be
incorporated into a route reflector. At an ingress router, one needs
the RIB-in Adj-RIB-In entries validated; validated but not the RIB-out entries. So So,
the off-
router off-router box is probably unlike the traditional route
reflector; it sits at the network edge and validates all incoming
BGPsec updates.
Thus,it Thus, it appears that each router passes each BGPsec
update it receives to the off-router box and receives a validation
result before it stores the route in the RIB-in. Adj-RIB-In. Question: What
about failure modes here? They The failure modes would be dependent on (1)
the following:

1. How much of the control plane is outsourced; (2) Reliability of outsourced.

2. How reliable the off-router box is (or, equivalently equivalently,
communication to and from it); and (3) it).

3. How centralized vs. distributed is this arrangement? arrangement is.

When any kind of outsourcing is done, the user needs to be watchful
and ensure that the outsourcing does not cross trust/security
boundaries.

9.4. New Hardware Capability

9.4.1. Decision

It is assumed that BGPsec routers (PE (Provider Edge (PE) routers and
route reflectors) will require significantly upgraded hardware - --
much more memory for RIBs and hardware crypto cryptographic assistance.
However, stub ASes would not need to make such upgrades because they
can negotiate asymmetric BGPsec capability with their upstream ASes,
i.e., they sign updates to the upstream AS but receive only unsigned
BGP updates (see Section 6.5).

9.4.2. Discussion

It is accepted that it might take several years to go beyond test
deployment of BGPsec, BGPsec because of the need for additional route
processor CPU and memory. However, because BGPsec deployment will be
incremental,
incremental and because signed updates are not sent outside of a set
of contiguous BGPsec-enabled ASes, it is not clear how much
additional (RIB) memory will be required during initial deployment.
See (see [RIB_size]) [RIB_size] for preliminary results on modeling and estimation of
BGPsec RIB size and its projected growth. Hardware cryptographic
support reduces the computation burden on the route
processor, processor and
offers good security for router private keys. However, given the incremental deployment
incremental-deployment model, it also is not clear how substantial a
cryptographic processing load will be incurred,
initially. incurred in the early phases of
deployment.

Note: There are recent detailed studies that considered software
optimizations for BGPsec. In [Mehmet1] and [Mehmet2], computational
optimizations for cryptographic processing (i.e., ECDSA speedup) are
considered for BGPsec implementations on general purpose general-purpose CPUs. In
[V_Sriram], software optimizations at the level of update processing
and path selection are proposed and quantified for BGPsec
implementations.

9.5. Signed Peering Registrations

9.5.1. Decision

The idea of signed BGP peering registrations (for the purpose of path
validation) was rejected.

9.5.2. Discussion

The idea of using a secure map of AS relationships to "validate"
updates was discussed and rejected. The reason for not pursuing rejected: such solutions was that were not pursued
because they cannot provide strong guarantees about regarding the validity
of updates. Using these techniques, one can say only that an update
is 'plausible', but "plausible"; one cannot say that it is 'definitely' "definitely" valid (based
on signed peering relations alone).

10. Security Considerations

This document requires no security considerations. See [RFC8205] for
security considerations for the BGPsec protocol.

11. IANA Considerations

This document includes has no request to IANA. IANA actions.

12. Informative References

[ASset] Sriram, K. and D. Montgomery, "Measurement Data on AS_SET
and AGGREGATOR: Implications for {Prefix, Origin}
Validation Algorithms", IETF SIDR WG presentation,
IETF 78, July 2010, <http://www.nist.gov/itl/antd/upload/
AS_SET_Aggregator_Stats.pdf>.

[BGP-Ext-Msg]
Bush, R., Patel, K., and D. Ward, "Extended Message
support for BGP", Work in Progress, draft-ietf-idr-bgp-
extended-messages-24, November 2017.

[BGPsec-Initial]
Lepinski, M., "BGPSEC Protocol Specification", Work in
Progress, draft-lepinski-bgpsec-protocol-00, March 2011.

[BGPsec-Rollover]
Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
Certificate Rollover", Work in Progress, draft-ietf-
sidrops-bgpsec-rollover-04, December 2017.

[Borchert]
Borchert, O. and M. Baer, "Subject: Modification Modifiation [sic]
request: draft-ietf-sidr-bgpsec-protocol-14", message to
the IETF SIDR WG Mailing List, 10 February 2016,
<https://www.ietf.org/mail-archive/web/sidr/current/
msg07509.html>.

[CiscoIOS]
"Cisco IOS RFD implementation",
<http://www.cisco.com/en/US/docs/ios/12_2/ip/
configuration/guide/1cfbgp.html#wp1002395>. IOS: Configuring Route Dampening", February 2014,
<https://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/
configuration/guide/fipr_c/1cfbgp.html>.

[CPUworkload]
Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on
a Router", Presented at RIPE-63; also at IETF-83 IETF 83 SIDR WG
Meeting, March 2012,
<http://www.ietf.org/proceedings/83/slides/
slides-83-sidr-7.pdf>. <https://www.ietf.org/proceedings/
83/slides/slides-83-sidr-7.pdf>.

[Dynamics]
Sriram, K. K., Montgomery, D., Borchert, O., Kim, O., and et al., P.
Gleichmann, "Potential Impact of BGPSEC Mechanisms on
Global BGP Dynamics", December 2009, <Work
in progress, Presentation slides available on request>. to the BGPsec
authors/designers team, October 2009,
<https://www.nist.gov/file/448631>.

[Gueron] Gueron, S. and V. Krasnov, "Fast and side channel
protected implementation of the NIST P-256 Elliptic Curve
for x86-64 platforms", OpenSSL patch ID 3149,
October 2013, <https://rt.openssl.org/>.

[I-D.draft-clynn-s-bgp]
Lynn, C., Mukkelson, J., and K. Seo, "Secure BGP (S-BGP)",
June 2003, <http://tools.ietf.org/html/
draft-clynn-s-bgp-protocol-01>.

[I-D.ietf-idr-bgp-extended-messages]
Bush, R., Patel, K., and D. Ward, "Extended Message
support for BGP", draft-ietf-idr-bgp-extended-messages-24
(work in progress), November 2017.

[I-D.ietf-sidrops-bgpsec-rollover]
Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
Certificate Rollover", draft-ietf-sidrops-bgpsec-
rollover-04 (work in progress), December 2017.

[I-D.lepinski-bgpsec-protocol]
Lepinski, M., "BGPSEC Protocol Specification", draft-
lepinski-bgpsec-protocol-00 (work in progress), March
2011.

[I-D.sriram-replay-protection-design-discussion]
Sriram, K. and D. Montgomery, "Design Discussion and
Comparison of Protection Mechanisms for Replay Attack and
Withdrawal Suppression in BGPsec", draft-sriram-replay-
protection-design-discussion-09 (work in progress),
October 2017. <https://rt.openssl.org/Ticket/
Display.html?id=3149&user=guest&pass=guest>.

[JunOS] "Juniper JunOS RFD implementation",
<http://www.juniper.net/techpubs/en_US/junos10.4/topics/
usage-guidelines/policy-using-routing-policies-to-damp-
bgp-route-flapping.html>. JunOS: Using Routing Policies to Damp BGP Route
Flapping", November 2010, <http://www.juniper.net/
techpubs/en_US/junos10.4/topics/usage-guidelines/
policy-using-routing-policies-to-damp-bgp-route-
flapping.html>.

[Mandelberg1]
Mandelberg, D., "Subject: wglc for draft-ietf-sidr-bgpsec-
protocol-11 (Specific topic: Include Address Family
Identifier in the data protected under signature -- to
alleviate a security concern)", message to the IETF SIDR
WG Mailing List, 10 February 2015, <https://www.ietf.org/
mail-archive/web/sidr/current/msg06930.html>.

[Mandelberg2]
Mandelberg, D., "Subject: draft-ietf-sidr-bgpsec-protocol-
13's draft-ietf-sidr-bgpsec-
protocol-13's security guarantees (Specific topic: Sign
all of the preceding signed data (rather than just the
immediate, previous signature) -- to alleviate a security
concern)", message to the IETF SIDR WG Mailing List,
26 August 2015,
<https://www.ietf.org/mail-archive/web/sidr/current/
msg07241.html>. <https://www.ietf.org/mail-archive/
web/sidr/current/msg07241.html>.

[Mao02] Mao, Z. and Z., et al., "Route-flap "Route Flap Damping Exacerbates Internet
Routing Convergence", August 2002,
<http://www.eecs.umich.edu/~zmao/Papers/sig02.pdf>.

[Mehmet1] Adalier, M., "Efficient and Secure Elliptic Curve
Cryptography Implementation of Curve P-256", NIST Workshop
on ECC Standards , Standards, June 2015,
<http://csrc.nist.gov/groups/ST/ecc-workshop-2015/papers/
session6-adalier-Mehmet.pdf>.

[Mehmet2] Adalier, M., Sriram, K., Borchert, O., Lee, K., and D.
Montgomery, "High Performance BGP Security: Algorithms and
Architectures", North American Network Operator Operators Group
Meeting NANOG-69, NANOG69, February 2017,
<https://www.nanog.org/meetings/abstract?id=3043>.

[MsgSize] Sriram, K., "Decoupling BGPsec Documents and Extended
Messages draft", Presented in at the IETF SIDROPS WG
Meeting, IETF-98, IETF 98, March 2017,
<https://www.ietf.org/proceedings/98/slides/slides-98-
sidrops-decoupling-bgpsec-documents-and-extended-messages-
draft-00.pdf>.
<https://www.ietf.org/proceedings/98/slides/
slides-98-sidrops-decoupling-bgpsec-documents-and-
extended-messages-draft-00.pdf>.

[Replay-Protection]
Sriram, K. and D. Montgomery, "Design Discussion and
Comparison of Protection Mechanisms for Replay Attack and
Withdrawal Suppression in BGPsec", Work in Progress,
draft-sriram-replay-protection-design-discussion-10,
April 2018.

[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Flap Damping", RFC 2439, DOI 10.17487/RFC2439,
November 1998, <https://www.rfc-editor.org/info/rfc2439>.

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>.

[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005,
<https://www.rfc-editor.org/info/rfc4055>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.

[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
DOI 10.17487/RFC4724, January 2007,
<https://www.rfc-editor.org/info/rfc4724>.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.

[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007,
<https://www.rfc-editor.org/info/rfc4893>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.

[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of
Autonomous System (AS) Numbers", RFC 5396,
DOI 10.17487/RFC5396, December 2008,
<https://www.rfc-editor.org/info/rfc5396>.

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.

[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
<https://www.rfc-editor.org/info/rfc6090>.

[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using
AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472,
DOI 10.17487/RFC6472, December 2011,
<https://www.rfc-editor.org/info/rfc6472>.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.

[RFC6483] Huston, G. and G. Michaelson, "Validation of Route
Origination Using the Resource Certificate Public Key
Infrastructure (PKI) and Route Origin Authorizations
(ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
<https://www.rfc-editor.org/info/rfc6483>.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>.

[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>.

[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.

[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.

[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security",
RFC 7132, DOI 10.17487/RFC7132, February 2014,
<https://www.rfc-editor.org/info/rfc7132>.

[RFC7353] Bellovin, S., Bush, R., and D. Ward, "Security
Requirements for BGP Path Validation", RFC 7353,
DOI 10.17487/RFC7353, August 2014,
<https://www.rfc-editor.org/info/rfc7353>.

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.

[RFC8097] Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R.
Bush, "BGP Prefix Origin Validation State Extended
Community", RFC 8097, DOI 10.17487/RFC8097, March 2017,
<https://www.rfc-editor.org/info/rfc8097>.

[RFC8205] Lepinski, M., Ed. Ed., and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205,
September 2017, <https://www.rfc-editor.org/info/rfc8205>.

[RFC8207] Bush, R., "BGPsec Operational Considerations", BCP 211,
RFC 8207, DOI 10.17487/RFC8207, September 2017,
<https://www.rfc-editor.org/info/rfc8207>.

[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8208,
DOI 10.17487/RFC8208, September 2017,
<https://www.rfc-editor.org/info/rfc8208>.

[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", RFC 8209,
DOI 10.17487/RFC8209, September 2017,
<https://www.rfc-editor.org/info/rfc8209>.

[RIB_size]
Sriram, K. and K., et al., "RIB Size Estimation for BGPSEC",
June
May 2011, <http://www.nist.gov/itl/antd/upload/
BGPSEC_RIB_Estimation.pdf>.

[RIPE580] Bush, R. and R., et al., "RIPE-580: RIPE Routing Working Group
Recommendations on Route-flap Route Flap Damping", January 2013,
<http://www.ripe.net/ripe/docs/ripe-580>.

[Secure-BGP]
Lynn, C., Mikkelson, J., and K. Seo, "Secure BGP (S-BGP)",
Work in Progress, draft-clynn-s-bgp-protocol-01,
June 2003.

[V_Sriram]
Sriram, V. and D. Montgomery, "Design and analysis of
optimization algorithms to minimize cryptographic
processing in BGP security protocols", Computer
Communications, Vol. 106, pp. 75-85,
DOI 10.1016/j.comcom.2017.03.007, July 2017,
<http://www.sciencedirect.com/science/article/pii/
<https://www.sciencedirect.com/science/article/pii/
S0140366417303365>.

Acknowledgements

The authors author would like to thank Jeff Haas and Wes George for serving
as reviewers for this document for the Independent Submissions
stream. The authors are author is grateful to Nevil Brownlee for shepherding
this document through the Independent Submissions review process.
Many thanks are also due to Michael Baer, Oliver Borchert, David
Mandelberg, Sean Turner, Alvaro Retana, Matthias Waehlisch, Tim Polk,
Russ Mundy, Wes Hardaker, Sharon Goldberg, Ed Kern, Chris Hall, Shane
Amante, Luke Berndt, Doug Maughan, Pradosh Mohapatra, Mark Reynolds,
Heather Schiller, Jason Schiller, Ruediger Volk, and David Ward for
their review, comments, and suggestions during the course of
this work.

Contributors

The following people have made significant contributions to this document
and should be considered co-authors:

Rob Austein
Dragon Research Labs
Email: sra@hactrn.net

Steven Bellovin
Columbia University
Email: smb@cs.columbia.edu

Randy Bush
Internet Initiative Japan, Inc.
Email: randy@psg.com

Russ Housley
Vigil Security, LLC
Email: housley@vigilsec.com
Stephen Kent
BBN Technologies
Independent
Email: kent@alum.mit.edu

Warren Kumari
Google
Email: warren@kumari.net

Matt Lepinski
New College of Florida
Email: mlepinski@ncf.edu

Doug Montgomery
USA National Institute of Standards and Technology
Email: dougm@nist.gov

Chris Morrow
Google, Inc.
Email: morrowc@google.com

Sandy Murphy
SPARTA, Inc., a Parsons Company
Parsons, Inc.
Email: sandy@tislabs.com

Keyur Patel
Arrcus
Email: keyur@arrcus.com

John Scudder
Juniper Networks
Email: jgs@juniper.net

Samuel Weiler
W3C/MIT
Email: weiler@csail.mit.edu

Author's Address

Kotikalapudi Sriram (editor)
USA NIST National Institute of Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899
USA
United States of America

Email: ksriram@nist.gov