FC-BGP Protocol Specification

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Definitions, and Acronyms

The following terms are used with a specific meaning:¶

BGP neighbor:

Also just 'neighbor'. Two BGP speakers that communicate using the BGP protocol are neighbors. It can be divided into iBGP neighbors and eBGP neighbors.¶

BGP speaker:

A device, usually a router, exchanges routes with other BGP speakers using the BGP protocol.¶

BGP UPDATE:

The message is generated with several path attributes to advertise routes.¶

iBGP:

iBGP neighbor, internal BGP neighbor, or internal neighbor. Internal neighbors are in the same AS.¶

eBGP:

eBGP neighbor, external BGP neighbor, or external neighbor. External neighbors are in different ASs.¶

Router:

In this document, the router always refers to a BGP speaker.¶

In addition to the list above, the following terms are used in this document:¶

FC:

Forwarding Commitment, i.e., an FC segment. It contains several fields and a digital signature that together certify a three-hop pathlet, identified by the triplet <Previous AS Number, Current AS Number, Nexthop AS Number>, and bind that pathlet to the AS_PATH attribute and the prefix of the route being advertised.¶

FCList:

An ordered list of FC segments that protects the AS_PATH attribute in the BGP UPDATE message. The order of the FC segments follows the order of the AS numbers in the AS_PATH attribute: the FC segment added most recently is placed at the front of the FCList and corresponds to the AS number at the front of the AS_PATH (the ASN most recently prepended). The formal correspondence is defined as the FC-to-AS_PATH Mapping in Section 7.¶

FC path attribute:

The optional, transitive, extended-length path attribute defined in this document that carries the FCList.¶

FC-BGP UPDATE:

A BGP UPDATE message that carries the FC path attribute.¶

FC-BGP speaker:

A BGP speaker that enables the FC-BGP feature. It can generate, propagate, and validate FC-BGP UPDATE messages. See also FC-capable, FC-enabled, and FC-required below.¶

FC-capable:

A BGP speaker that implements the processing of the FC path attribute as specified in this document.¶

FC-enabled:

An FC-capable BGP speaker, or an AS, or a BGP session, for which the FC-BGP feature is actually activated and for which FC segments are being generated. An AS that is FC-capable is not necessarily FC-enabled on every BGP session or for every prefix.¶

FC-required:

An AS for which, given a particular route propagation scenario and the deployment state defined in Section 3, the protocol requires that an FC segment be present in the FC path attribute for the FC coverage of the path to be complete.¶

FC-to-AS_PATH Mapping:

The deterministic correspondence between the FC segments in an FCList and the AS numbers in the AS_PATH attribute of the same BGP UPDATE message, as defined in Section 7.¶

Prepending Count (PC):

A 1-octet field in an FC segment that records the number of consecutive occurrences of the Current AS Number (CASN) in the AS_PATH attribute that this single FC segment represents, and that is covered by the FC segment's signature.¶

Valid:

The validation result for an FC-BGP UPDATE message when all applicable protocol checks, including the FC-to-AS_PATH Mapping check and all signature verifications, have passed.¶

Invalid:

The validation result for an FC-BGP UPDATE message when a protocol violation, an FC-to-AS_PATH Mapping failure, or a cryptographic verification failure has been detected.¶

Not Validated:

An internal validation state indicating that the validation of an FC-BGP UPDATE message has been started but has not yet finished (for example, because validation has been deferred). It is not a security statement.¶

Unsupported:

The validation result for an FC-BGP UPDATE message that contains an algorithm or a protocol feature that the FC-BGP speaker cannot process.¶

Incomplete:

The validation result for an FC-BGP UPDATE message whose FC path attribute authenticates only part of the AS_PATH (for example, because the path traverses ASes that are not FC-required). Incomplete does not imply that the authenticated portion is invalid; see Section 3 and Section 8.2.1.¶

3.1. Sources of Deployment State

The only public and verifiable signal of FC support is the existence of a valid RPKI router certificate for the relevant AS number [RFC8209]. Such a certificate establishes that the certificate holder is FC-capable: it demonstrates that the holder possesses the private key associated with the certificate and is able to generate FC segments. A valid router certificate does not, by itself, prove any of the following:¶

• that the AS is FC-enabled on a particular BGP session;¶

• that the AS generates FC segments for a particular prefix or address family;¶

• that the AS generated FC segments at the time the UPDATE message was transmitted;¶

• that an FC segment, once generated, was not removed by an intermediate AS;¶

• that the AS's routing behavior matches what its certificate would allow.¶

The FC-enabled state and the set of prefixes, address families, and sessions for which FCs are generated (the "coverage configuration") MAY be communicated out of band, for example by an operator agreement, a routing registry, or administrative configuration. Absent such information, a receiver MUST apply the default determination rules defined below.¶

3.2. Determining Whether an AS Is FC-required

An AS is FC-required for a given route if and only if ALL of the following conditions hold:¶

1. The AS is FC-enabled on the BGP session over which the route is propagated (or, for the origin AS, over which the route was originated toward the next hop); and¶

2. The route falls within the coverage configuration of that AS, considering at least the prefix, the address family, the SAFI, and the propagation scenario; and¶

3. The AS is expected to propagate the FC path attribute, i.e., it is not an AS that is only forwarding the attribute as an optional transitive attribute without generating FCs.¶

A validating FC-BGP speaker MUST determine whether an AS on the AS_PATH attribute is FC-required as follows:¶

• An AS on the AS_PATH attribute that has a valid RPKI router certificate for its AS number is considered FC-required for a route unless local configuration or out-of-band information establishes that the AS is not FC-enabled for the session over which that AS received or forwarded the route, or that the route is outside the AS's coverage configuration.¶

• An AS on the AS_PATH attribute without a valid RPKI router certificate is not FC-required.¶

3.3. FC Coverage Scenarios

The following scenarios determine how the absence of an FC segment is treated. For each scenario, the indicated handling MUST be followed.¶

3.4. FC Path Attribute Wholly Absent

If an UPDATE message carries no FC path attribute, there is no FC to validate. The FC-BGP validation state is 'Not Validated' (see Section 8.2.1), and the route MAY be processed as an ordinary BGP UPDATE message. An operator whose coverage policy requires FCs for the route MAY additionally apply a locally configured route policy (for example, to reject such routes). FC-BGP itself MUST NOT mark the route 'Invalid' solely because the attribute is absent, because absence is also what partial deployment produces when a legacy AS does not propagate the optional transitive attribute.¶

3.5. Missing FC: Detectability and Attack

Whether the absence of an FC segment can be detected and whether it indicates an attack are two distinct questions:¶

• The absence is DETECTABLE when the FC-required determination above can be made independently of the FC path attribute in the received UPDATE message, i.e., from public signals and configuration.¶

• The absence INDICATES AN ATTACK, or at least a protocol violation by the FC-required AS, when the AS was FC-required for the route and the corresponding FC segment is absent (scenario 1 above).¶

• When the AS is not FC-required (scenarios 2 and 3 above), the absence is expected and MUST NOT be treated as an attack.¶

In particular, the mere presence of a valid router certificate does not prove that an FC should have been generated for a specific route. Therefore, when an AS is FC-capable but its FC-required status for the route cannot be established, the absence of an FC segment MUST NOT be treated as a violation.¶

3.6. Security Guarantees per Deployment State

4.1. FC Signature Input Construction

This section defines the canonical serialization of the data that is covered by the signature of an FC segment. The signature MUST be computed over exactly the byte string defined here, so that different implementations produce and verify identical inputs.¶

All fields are concatenated in the order listed below, and each integer field is encoded in network byte order (big-endian):¶

FC-Signature-Input =
    Domain-Separation       (8 octets)
 || Version                 (1 octet)
 || PASN                    (4 octets)
 || CASN                    (4 octets)
 || NASN                    (4 octets)
 || SKI                     (20 octets)
 || Algorithm ID            (1 octet)
 || Flags                   (1 octet)
 || Canonical Sig Length    (2 octets, always 0)
 || PC                      (1 octet)
 || RESERVED                (3 octets)
 || AFI                     (2 octets)
 || SAFI                    (1 octet)
 || Prefix                  (4 or 16 octets)
 || Prefix Length           (1 octet)

The individual components are defined as follows:¶

Domain-Separation:

8 octets containing the ASCII encoding of the string "FC-BGP" followed by two 0x00 octets. The Domain-Separation string prevents a signature computed for FC-BGP from being valid for a different protocol that signs similar data.¶

Version:

1 octet, the value of the Version field of the FC segment (Figure 2). The current value is 1. Because the Version value both appears in a positionally fixed field of the FC segment and is covered by the FC segment's signature, a receiver can detect an unknown segment version before cryptographic verification and handle it as 'Unsupported' without treating the segment as authenticated (Section 8.2.2), and an on-path attacker cannot change the signer's Version without breaking the signature.¶

PASN, CASN, NASN:

The three AS numbers of the FC segment, each encoded as 4 octets as defined in Figure 2.¶

SKI:

The Subject Key Identifier of the RPKI router certificate used for verification, encoded as 20 octets as defined in Figure 2.¶

Algorithm ID:

1 octet, the value of the Algorithm ID field.¶

Flags:

1 octet, the value of the Flags field.¶

Canonical Sig Length:

2 octets, fixed to 0. This is the canonical value of the Signature Length field used for signature computation. It is fixed so that the signer does not need to modify the wire-format field to compute the signature, and so that the same signature can be reproduced given the same FC segment content.¶

PC:

1 octet, the value of the Prepending Count field.¶

RESERVED:

3 octets, the value of the RESERVED field of the FC segment (Figure 2). For the version of the FC segment format defined in this document, the value MUST be 0. Future allocations from the RESERVED field MUST preserve its 3-octet size so that the FC Signature Input defined here remains stable; see Section 11.¶

AFI and SAFI:

The Address Family Identifier (2 octets) and Subsequent Address Family Identifier (1 octet) of the prefix being announced, as carried in the MP_REACH_NLRI attribute [RFC4760]. This document supports only unicast IPv4 (AFI 1, SAFI 1) and unicast IPv6 (AFI 2, SAFI 1). The same prefix announced under a different AFI or SAFI yields a different signature input and therefore a different signature, which prevents signatures from being replayed across address families.¶

Prefix:

The network prefix, encoded in network byte order using the full address length: 4 octets for IPv4 and 16 octets for IPv6.¶

Prefix Length:

1 octet, the length of the prefix in bits.¶

The signature for Algorithm ID 1 is ECDSA over P-256 using SHA-256, as defined in [RFC8208]. The Signature field carries the ECDSA signature in DER format. Only the DER encoding produced by the algorithms of [RFC8208] is considered valid; a signature that is not valid DER MUST cause the FC segment to be handled as specified in Section 8.2.2.¶

Test vectors for the FC Signature Input are provided in Appendix A.2.¶

5.1. Generation

This part defines the generation of the FC path attribute and the FC segment. An FC-BGP speaker SHOULD generate a new FC segment or even a new FC path attribute when it propagates a route to its external neighbors. For internal neighbors, the FC path attribute in the BGP UPDATE message remains unchanged.¶

Because the FC path attribute carries several variable-length signatures, it SHOULD be placed as the last path attribute in the BGP UPDATE message.¶

The FC-BGP speaker follows a specific process to create the FC path attribute for the ongoing UPDATE message. First, it generates a new FC Segment containing the information described below and adds it to the FCList of the outer format defined in Figure 1. If the FC-BGP speaker is not the origin AS and an FC path attribute already exists in the UPDATE message, the speaker MUST prepend the new FC segment to the FCList, in the same way that an AS number is prepended to the AS_PATH attribute. This keeps the FCList ordered in the same direction as the AS_PATH attribute, so that the first FC segment in the FCList corresponds to the first AS number (the most recently prepended ASN) in the AS_PATH; see Section 7. Otherwise, if the speaker is the origin AS, it generates the FC path attribute defined in Figure 1 and inserts it into the UPDATE message.¶

There are three AS numbers in one FC segment, as Figure 2 shows. The populating of the Current AS number (CASN) within the FC segment is like the AS number in BGPsec; it MUST match the AS number in the Subject field of the RPKI router certificate that will be used to verify the FC segment constructed by this FC-BGP speaker (see Section 3.1.1 of [RFC8209] and [RFC6487]). The Previous AS number (PASN) is typically set to the AS number from which the UPDATE message is received. However, if the FC-BGP speaker is located in the origin AS, the PASN SHOULD be filled with 0. The Nexthop AS number (NASN) is set to the AS number of the peer to whom the route is advertised. So if there are several neighbors, the FC-BGP speaker should generate separate FCs for different neighbors. But it would never generate a new FC segment for the iBGP neighbor.¶

The Subject Key Identifier field (SKI) within the new FC segment is populated with the identifier found in the Subject Key Identifier extension of the RPKI router certificate associated with the FC-BGP speaker. This identifier serves as a crucial piece of information for recipients of the route advertisement. It enables them to identify the appropriate certificate to employ when verifying the signatures in FC segments attached to the route advertisement. This practice adheres to the guidelines outlined in [RFC8209].¶

The Version field MUST be set to 1 by an FC-BGP speaker that implements this version of the protocol; see Section 11 and Section 9.1. Typically, the Flags field is set to 0 and the PC field is set to 1. The PC field is set to a value greater than 1 only when AS Path Prepending is used, as described below.¶

A route server (RS) is a third-party brokering system that interconnects three or more BGP-speaking routers using eBGP in IXPs [RFC7947]. Typically, an RS behaves like a transit AS except that it does not insert its AS number into the AS_PATH attribute. An RS can also participate in FC-BGP. If the RS is FC-enabled, it adds its FC segment with the Flags-RS bit set to 1 when its AS number does not appear in the AS_PATH attribute; when its AS number is inserted into the AS_PATH attribute, the Flags-RS bit MUST be set to 0. A non-FC RS propagates the FC-BGP UPDATE message directly without adding an FC segment. Note that the AS number of an RS is used in the FC segment whether or not it appears in the AS_PATH attribute; how the resulting FC-to-AS_PATH Mapping is established is defined in Section 6.¶

Typically, the route server does not insert its ASN into the AS_PATH. Take Figure 3 as an example, where AS A advertises a BGP UPDATE to AS C and the RS connects AS A and AS B. When the RS supports FC-BGP, AS A adds its FC segment FC(NULL, A, RS), the RS adds FC(A, RS, B) with Flags-RS set to 1, and AS B adds FC(RS, B, C). If the RS does not support FC-BGP, FC(A, RS, B) is missing from the FCList; this is the partial-deployment case for Route Servers, and its treatment is defined in Section 6 and Section 3.¶

+--------+     +--------+     +--------+     +--------+
|  AS A  | --> |   RS   | --> |  AS B  | --> |  AS C  |
+--------+     +--------+     +--------+     +--------+

AS Path Prepending is a traffic-engineering mechanism in BGP in which the local AS number is prepended to the AS_PATH attribute multiple times to deprioritize a route [ASPP]. To minimize the number of signatures, an FC-BGP speaker MUST NOT generate multiple consecutive FC segments whose CASN is the same. Instead, the speaker MUST generate a single FC segment and set the PC field to the number of consecutive occurrences of the CASN in the AS_PATH attribute. For example, if the path segment contributed by the local AS is "65001 65002 65002 65002 65003", the speaker that represents AS 65002 sets PC to 3. The PC value is covered by the FC segment's signature, so a downstream receiver can detect any modification of the number of consecutive occurrences; see Section 7 and Section 8.2.3.¶

The Algorithm ID field for FC-BGP is set to 1. FC-BGP supports the same algorithm suite as BGPsec in this document, as defined in [RFC8208]: the signature algorithm MUST be the Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256, and the hash algorithm MUST be SHA-256. Algorithm transitions are governed by Section 9.1, and AS number migration is governed by Section 9.7.¶

The Signature Length field is populated with the length, in octets, of the value in the Signature field.¶

The Signature field in the new FC segment is a variable-length field. It contains a digital signature in DER format that binds the pathlet identified by the triplet <PASN, CASN, NASN>, together with the PC, the RESERVED field, the SKI, the Algorithm ID, the Flags, and the prefix, to the RPKI router certificate of the FC-BGP speaker. The signature is computed over the canonical FC Signature Input defined in Section 4.1.¶

The signatures within the FC segments of an FC-BGP UPDATE message ensure the protection of crucial information, including the AS number of the neighbor involved in the message exchange. This information is explicitly included in the generated FC segment. Consequently, if an FC-BGP speaker intends to transmit an FC-BGP UPDATE message to multiple BGP neighbors, it MUST generate a distinct FC-BGP UPDATE message for each unique neighbor AS to whom the UPDATE message is being sent.¶

Indeed, an FC-BGP UPDATE message is REQUIRED to advertise a route to just one prefix. This is because if an FC-BGP speaker receives an UPDATE message containing multiple prefixes, it would be unable to construct a valid FC-BGP UPDATE message, including valid path signatures, with a subset of the received prefixes. To advertise routes to multiple prefixes, the FC-BGP speaker MUST generate individual FC-BGP UPDATE messages for each prefix. This ensures the proper construction of valid path signatures for each advertised prefix.¶

All FC-BGP 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 [RFC4271] MUST be followed.¶

5.2. Propagation

Any BGP speaker should propagate the optional transitive FC path attribute encapsulated in the FC-BGP UPDATE message, even though they do not support the FC-BGP feature. However, it is important to note that an FC-BGP speaker SHOULD NOT make any attestation regarding the validation state of the FC-BGP UPDATE message it receives. They MUST verify the FC path attribute themselves.¶

To incorporate or create a new FC segment for an FC-BGP UPDATE message using a specific algorithm suite, the FC-BGP speaker MUST possess an appropriate private key capable of generating signatures for that particular algorithm suite. Moreover, this private key MUST correspond to the public key found in a valid RPKI End Entity (EE) certificate. The AS number resource extension within this certificate should include the FC-BGP speaker's AS number as specified in [RFC8209]. It is worth noting that these new segments are only prepended to an FC-BGP UPDATE message when the FC-BGP speaker generates the UPDATE message for transmission to an external neighbor. In other words, this occurs when the AS number of the neighbor differs from the AS number of the FC-BGP speaker.¶

The RPKI allows the legitimate holder of IP address prefix(es) to issue a digitally signed object known as a Route Origin Authorization (ROA). This ROA authorizes a specific AS to originate routes for a particular set of prefixes [RFC6482]. It is anticipated that most Relying Parties (RPs) will combine FC-BGP with origin validation [RFC6483] and [RFC6811]. Therefore, it is strongly RECOMMENDED that an FC-BGP speaker only advertises a route for a given prefix in an FC-BGP UPDATE message if there is a valid ROA that authorizes the FC-BGP speaker's AS to originate routes for that specific prefix.¶

If an FC-BGP router receives a non-FC-BGP UPDATE message from an external neighbor, meaning that the origin BGP speaker does not support FC-BGP, the router processes the UPDATE message as a regular BGP UPDATE message typically. In this case, it SHOULD NOT add its own FC segment to the UPDATE message. On the other hand, when the FC-BGP speaker advertises routes belonging to its local AS and receives them from an internal neighbor, it MUST add its FC segment to the UPDATE message if it decides to propagate those routes. Furthermore, if the FC-BGP router receives an FC-BGP UPDATE message from a neighbor for a specific prefix and chooses to propagate that neighbor's route for the prefix, it MUST propagate the route as an FC-BGP UPDATE message containing the FC path attribute.¶

When an FC-BGP speaker sends an FC-BGP UPDATE message to an iBGP (internal BGP) neighbor, the process is straightforward. When the FC-BGP speaker originates a new route advertisement and sends it to an iBGP neighbor, it MUST NOT include the FC path attribute of the UPDATE message. In other words, the FC-BGP speaker omits the FC path attribute. Similarly, when an FC-BGP speaker decides to forward an FC-BGP UPDATE message to an iBGP neighbor, it MUST refrain from adding a new FC segment to the FC-BGP UPDATE message.¶

When an FC-BGP speaker receives an FC-BGP UPDATE message containing an FC path attribute (with one or more FC segments) from an (internal or external) neighbor, it may choose to propagate the route advertisement by sending it to its other (internal or external) neighbors. When sending the route advertisement to an internal FC-BGP-speaking neighbor, the FC path attribute SHALL NOT be modified. When sending the route advertisement to an external FC-BGP-speaking neighbor, the following procedures are used to form or update the FC path attribute.¶

5.3. iBGP Propagation and Validation Semantics

Within an AS, iBGP is used to convey an FC-BGP route and its validation state from an ingress edge router to an egress edge router. The cryptographic validation of the FC path attribute and its propagation within the AS are distinct concerns; this section defines both, and the conditions under which a validation result remains valid inside an AS.¶

1. Attribute integrity. The FC path attribute MUST NOT be modified, re-ordered, or deleted when an FC-BGP UPDATE message is propagated over an iBGP session. No FC segment is added over iBGP, and an iBGP speaker MUST NOT re-sign or edit the FC path attribute before propagating it further. In particular, the FC path attribute SHALL NOT be modified when the route is sent to an internal FC-BGP-speaking neighbor (see Section 5).¶

2. Revalidation. An iBGP speaker MUST NOT assume that a route received over iBGP has already been validated unless it can attribute a validation result to the identical FC path attribute, the identical AS_PATH attribute, the identical prefix, and an unchanged RPKI certificate state. An implementation MAY reuse a validation result under those conditions, as described in Section 9.2; otherwise it MUST re-run the validation of Section 8.2.3. A validation result remains valid across multiple internal routers only while the FC path attribute, the AS_PATH attribute, the prefix, and the certificate state are unchanged.¶

3. Propagation of the validation state. The validation state (Section 8.2.1) MAY be conveyed to other routers within the AS by a mechanism local to the AS, or each internal router MAY re-run the validation itself; the protocol does not mandate a particular mechanism. A router MUST NOT report a validation state as authoritative for a route over iBGP if it did not itself complete the validation of the FC path attribute, or if the state was computed over inputs that are not known to be identical to the route it is propagating.¶

4. Route reflectors, confederations, and ordinary iBGP. Route reflectors and ordinary iBGP speakers MUST obey the same rules with respect to the FC path attribute: they MUST NOT modify, re-order, or delete the FC path attribute, and they MUST NOT add FC segments. The treatment of the eBGP sessions between AS Confederation members is defined separately in Section 5; the Flags-CS checks of Section 8.2.3 apply to those sessions.¶

5.4. Route Aggregation and Multi-Prefix UPDATE Messages

Each FC-BGP UPDATE message announces exactly one route prefix. This is an explicit protocol limitation: because the Prefix and the Prefix Length are covered by the signature of every FC segment (Section 4.1), a single FCList cannot attest to multiple prefixes with different path semantics. An FC-BGP speaker MUST NOT include more than one route prefix in the NLRI of an FC-BGP UPDATE message that carries an FC path attribute. When multiple prefixes are to be announced, the FC-BGP speaker MUST generate a separate FC-BGP UPDATE message for each prefix, each with its own FC path attribute.¶

An UPDATE message that carries an FC path attribute and more than one NLRI cannot be bound to a single Prefix and Prefix Length and MUST be handled as malformed per Section 8.2.2.¶

Route aggregation changes the prefix that is announced. Because the aggregated prefix has a new Prefix and Prefix Length, the existing FC segments cannot be reused for the aggregated route. An FC-BGP speaker that aggregates routes MUST either (a) generate a fresh FC path attribute for the aggregated route in accordance with Section 5, or (b) remove the FC path attribute from the aggregated UPDATE message and propagate the route as an ordinary BGP UPDATE message. An FC-BGP speaker MUST NOT merge the FC path attributes of the aggregated UPDATE messages.¶

Because FC-BGP does not use AS_SET or AS_CONFED_SET (Section 4), an UPDATE message that contains both an FC path attribute and an AS_SET or AS_CONFED_SET segment in its AS_PATH attribute is malformed and MUST be handled per Section 8.2.2. A speaker that receives an UPDATE message containing an AS_SET or AS_CONFED_SET MUST NOT add an FC segment to it. When propagating such a route, the speaker MUST either generate a fresh, valid FC path attribute for a route whose AS_PATH attribute contains only AS_SEQUENCE segments, or propagate the route without the FC path attribute.¶

5.5. Processing Instructions for AS Confederation Members

Members of AS Confederation [RFC5065] MUST additionally follow the instructions in this section for processing FC-BGP UPDATE messages.¶

When an FC-BGP speaker in an AS confederation receives an FC-BGP UPDATE message from a neighbor that is external to the confederation and chooses to propagate the UPDATE message within the confederation, it first adds an FC segment and the signature signed to its own Member-AS (i.e., the 'Current AS Number' is the FC-BGP speaker's Member-AS Number). In this internally modified UPDATE message, the newly added FC segment contains the public AS number (i.e., Confederation Identifier), and the segment's Confed_Segment flag is set to 1. The newly added signature is generated using a private key corresponding to the public AS number of the confederation. The FC-BGP speaker propagates the modified UPDATE message to its peers within the confederation. (Note: In this document, intra-Member-AS peering is regarded as iBGP, and inter-Member-AS peering is regarded as eBGP. The latter is also known as confederation-eBGP.)¶

Within a confederation, the verification of FC-BGP signatures added by other members of the confederation is optional. Note that if a confederation chooses not to verify digital signatures within the confederation, then FC-BGP is not able to provide any assurances about the integrity of the Member-AS Numbers placed in FC segments where the Confed_Segment flag is set to 1.¶

When a confederation member receives an FC-BGP UPDATE message from a peer within the confederation and propagates it to a peer outside the confederation, it needs to remove all of the FC segments added by confederation members when it removes all path segments of the AS_PATH with the type of AS_CONFED_SEQUENCE or AS_CONFED_SET. To do this, the confederation members propagated the route outside the confederation as follows:¶

1. Starting with the most recently added FC segment, remove FC segments whose Flags-CS bit is 1. Stop this process once an FC segment that has its Confed_Segment flags set to 0 is reached.¶

2. Add an FC segment containing, in the CASN field, the AS Confederation Identifier (the public AS number of the confederation). Note that all fields other than the CASN field are populated.¶

Finally, as discussed above, an AS confederation MAY optionally decide that its members will not verify digital signatures added by members. In such a confederation, when an FC-BGP speaker runs the algorithm in Section 8.2.3, the FC-BGP speaker, during the process of signature verifications, first checks whether the Confed_Segment flag in an FC segment is set to 1. If the flag is set to 1, the FC-BGP speaker skips verification for the corresponding signature and proceeds immediately to the next FC segment. It is an error when an FC-BGP speaker receives, from a neighbor who is not in the same AS confederation, an FC-BGP UPDATE message containing a Confed_Segment flag set to 1.¶

5.6. Processing Instructions for BGP Route Leak Prevention

The BGP routing system is susceptible to numerous vulnerabilities. The systemic vulnerability of the BGP routing system is known as "route leaks" [RFC7908]. There are 6 types of route leaks defined in [RFC7908].¶

[RFC9234] can detect and prevent BGP route leaks by adding a new BGP OPEN Role capability and OTC transitive path attribute. However, it may be forged.¶

When using BGP route leak prevention with FC-BGP, it SHOULD tell the neighbor its BGP Role as Section 4 of [RFC9234]. If the peer's role is Customer or RS-Client, the Flags-P2C MUST be set to 1 on route advertisement. If the peer's role is peer, the Flags-P2P MUST be set to 1 on the route advertisement. Then, the route SHOULD subsequently go only to the Customers. It is worth noting that if the recently added FC Segment already set the Flags-P2C or Flags-P2P flags to 1, it MUST NOT be propagated to Providers, Peers, or RSes.¶

6.1. AS Numbers That Do Not Appear in the AS_PATH

The AS number of a route server can appear in an FC segment (as the Current AS Number) without appearing in the AS_PATH attribute. The following four combinations MUST be distinguished:¶

When the Flags-RS bit is set to 1, the FC segment does not consume any path node in the FC-to-AS_PATH Mapping (Section 7); it bridges the two data-path hops that are adjacent in the AS_PATH attribute. The identity of the route server is authenticated by its RPKI router certificate, exactly as for any other AS.¶

6.2. Route Server Neighbor Adjacency

For the FC segment added by a route server with Flags-RS set to 1:¶

• the Previous AS Number MUST be the AS number of the upstream sender (the AS from which the route server received the UPDATE message);¶

• the Nexthop AS Number MUST be the AS number of the downstream receiver (the AS to which the route server sends the UPDATE message);¶

• the Previous and Nexthop AS numbers MUST be adjacent in the AS_PATH attribute in the sense of Section 7 (the data-path hops that the route server bridges are exactly two consecutive path-node groups, or the receiver and the first path node).¶

When multiple customers share the same route server, each propagation leg is a separate data-path hop. A route server that is FC-enabled MUST generate a separate FC segment for each (upstream, downstream) pair, just as any FC-BGP speaker generates a distinct FC segment for each unique next hop (see Section 5). The FC segments of different customers are therefore kept distinct by their PASN and NASN fields, and the Flags-RS bit does not by itself distinguish one customer from another.¶

6.3. Non-FC Route Server

A route server that does not support FC-BGP propagates the FC-BGP UPDATE message without adding an FC segment (see Section 5). A downstream receiver then observes a gap in the FCList where the route server's FC segment would be. Whether this is expected behavior or the result of the FC segment being deleted is determined by the FC-required determination of Section 3:¶

• If the route server is not FC-required for the propagation leg (e.g., it has no valid router certificate, or it is not FC-enabled), the absence is expected and the FC coverage is 'Incomplete' (Section 8.2.1).¶

• If the route server is FC-required for the leg but its FC segment is absent, the FC-to-AS_PATH Mapping cannot be completed, and the UPDATE message is 'Invalid' per Section 8.2.2.¶

Note that because a route server does not appear in the AS_PATH attribute, the receiver MUST NOT require an FC segment for the route server unless it can independently establish, per Section 3, that the route server was FC-required for the leg. The Flags-RS bit alone does not create such a requirement.¶

7.1. Direction and Ordering

For any two FC segments f(i) and f(j) with i < j, the path nodes covered by f(i) MUST all be closer to the receiver than the path nodes covered by f(j). The FCList is never in the reverse order of the AS_PATH attribute. An FC segment that is out of order, or an FC segment whose group overlaps the group of another FC segment, is a Mapping failure.¶

7.2. Data-Path Adjacency

The FC segments describe a chain of data-path hops, each of which is a three-hop pathlet <PASN, CASN, NASN>. Consecutive FC segments MUST be adjacent in this chain, where f(j) denotes the FC segment at wire position j, f(0) being the most recently added FC segment:¶

• For each j in [0, k-2], the Previous AS Number of f(j) MUST equal the Current AS Number of f(j+1): the issuer of f(j) received the UPDATE message from the issuer of f(j+1).¶

• For each j in [1, k-1], the Nexthop AS Number of f(j) MUST equal the Current AS Number of f(j-1): the issuer of f(j) sent the UPDATE message to the issuer of f(j-1).¶

• The Nexthop AS Number of f(0) MUST equal the AS number of the local FC-BGP speaker that validates the message; this is the receiver boundary (see below).¶

A violation of either adjacency rule is a Mapping failure. These two rules are the two directions of the same adjacency requirement; both MUST be checked so that a broken or spliced chain is detected.¶

7.3. Receiver and Origin Boundaries

• The Nexthop AS Number of f0 MUST equal the AS number of the local FC-BGP speaker that validates the message (the AS number announced in the BGP OPEN of the session over which the UPDATE message was received); see Section 10.4.1.¶

• The Previous AS Number of the FC segment whose group includes the origin path node MUST be 0 (AS 0), because there is no previous hop Section 10.4.1.¶

7.4. Coverage of Path Nodes

Each path node is covered by at most one FC segment. A compliant implementation MUST construct the mapping by processing F in wire order while walking P from front to back, as follows:¶

1. Set a cursor i over P to 0 and an index j over F to 0.¶

2. While j < k:¶

   a. If the Flags-RS bit of f(j) is 0 (a normal FC segment), let n be the Prepending Count (PC) of f(j). This FC segment MUST cover n consecutive path nodes starting at i: - If i + n is greater than m, or if i + n exceeds the end of P, the Mapping fails. - Every path node p(i) ... p(i+n-1) MUST equal the Current AS Number of f(j); otherwise the Mapping fails. - If two consecutive normal FC segments have the same Current AS Number (which is a non-canonical encoding, because they MUST have been merged into a single FC segment with PC greater than 1 per Section 5), the Mapping fails. - Mark the nodes covered by f(j) and set i := i + n.¶

   b. If the Flags-RS bit of f(j) is 1 (an FC segment of a route server), the FC segment does not consume any path node; the route server's AS number does not appear in the AS_PATH attribute. This FC segment bridges two path-node groups (or, when the route server is the immediate neighbor, the receiver and the first path node): - If i is 0, then the Previous AS Number of f(j) MUST equal p0 and the Nexthop AS Number of f(j) MUST equal the AS number of the local FC-BGP speaker. - Otherwise, the Previous AS Number of f(j) MUST equal p(i) and the Nexthop AS Number of f(j) MUST equal p(i-1). - Any violation is a Mapping failure. No node is consumed.¶

3. After processing all FC segments:¶

   • If i is equal to m (every path node is covered) and every path node whose AS is FC-required (Section 3) was covered by a normal FC segment, the Mapping is complete.¶

   • If i is less than m, the uncovered path nodes are the origin-ward tail of the path. If every uncovered path node is not FC-required (Section 3), the Mapping is complete with respect to the FC coverage, and the FC coverage is partial. If any uncovered path node is FC-required, the corresponding FC segment is missing and the Mapping fails.¶

Any Mapping failure is a protocol violation. It is handled as 'Invalid' per Section 8.2.2 and MUST NOT be downgraded to a mere missing-FC case.¶

7.5. Repeated Current AS Numbers

The handling of repeated Current AS Numbers is fully determined by the PC field and the rules above:¶

• Consecutive occurrences of the same AS number in the AS_PATH attribute (AS Path Prepending, [ASPP]) are expressed by a single FC segment whose PC equals the number of consecutive occurrences. The PC is covered by the FC segment's signature (Section 4.1) and MUST equal the number of consecutive occurrences, which is verified by the coverage walk above. A malicious change of the number of consecutive occurrences therefore either breaks the signature (if the PC is changed) or breaks the coverage walk (if consecutive occurrences are inserted or removed).¶

• Two consecutive normal FC segments with the same Current AS Number are a non-canonical encoding and are a Mapping failure.¶

• Non-consecutive occurrences of the same AS number in the FCList are a Mapping failure: a well-formed BGP path contains an AS number at most once (loop prevention, [RFC4271]), so a repeated CASN indicates an invalid AS_PATH attribute or a misplaced or replayed FC segment.¶

7.6. Treatment on Generation

On generation, an FC-BGP speaker constructs the FCList so that the FC-to-AS_PATH Mapping holds by construction: it prepends each new FC segment to the front of the FCList in the same order in which the corresponding AS number is prepended to the AS_PATH attribute, and it sets the PASN, CASN, NASN, and PC fields according to the rules above (see Section 5).¶

8.1. Overview

When receiving an FC-BGP UPDATE message from an external BGP neighbor carrying the FC path attribute, an FC-BGP speaker SHOULD first validate the message to determine the authenticity of the path information. Same as BGPsec, an FC-BGP speaker will wish to perform origin validation (see [RFC6483] and [RFC6811]) on an incoming FC-BGP UPDATE message, but such validation is independent of the validation described in this section.¶

After the validation, the FC-BGP speaker may want to send the FC-BGP UPDATE message to neighbors according to local route policies. Then it SHOULD update the FC path attributes and continue advertising the BGP route.¶

For the origin AS that launches the advertisement, the FC-BGP speaker only needs to generate the FC-BGP UPDATE message without the validation.¶

The FC-BGP speaker stores the router certificates in the RPKI repository, and any changes in the RPKI state can impact the validity of the UPDATE messages. That means the validity of FC-BGP UPDATE messages relies on the current state of the RPKI repository. When an FC-BGP speaker becomes aware of a change in the RPKI state, such as through an RPKI validating cache using the RTR protocol (as specified in [RFC8210]), it is REQUIRED to rerun validation on all affected UPDATE messages stored in its Adj-RIB-In [RFC4271]. For instance, if a specific RPKI router certificate becomes invalid due to expiration or revocation, all FC-BGP UPDATE messages containing an FC segment with an SKI matching the SKI in the affected certificate must be reassessed to determine their current validity. If the reassessment reveals a change in the validity state of an UPDATE message, the FC-BGP speaker, depending on its local policy, SHOULD rerun the best path selection process. This allows for the appropriate handling of the updated information and ensures that the most valid and suitable paths are chosen for routing purposes.¶

8.2. Validation

When verifying the authenticity of an FC-BGP UPDATE message, information from the RPKI router certificates is utilized. The RPKI router certificates provide the data, including the triplet <AS Number, Public Key, Subject Key Identifier>, to verify the AS_PATH and FC path attributes. As a prerequisite, the recipient MUST have access to these RPKI router certificates.¶

Note that the existence of a valid RPKI router certificate for an AS makes that AS FC-capable; it does not, by itself, make the AS FC-enabled on a particular BGP session or FC-required for a particular route (see Section 3). Whether the absence of an FC segment is a protocol violation is determined by the FC-required determination of Section 3, and the resulting handling is defined in Section 7 and Section 8.2.2. The validation process MUST ensure that a malicious on-path AS cannot remove FC segments without detection when the corresponding AS is FC-required.¶

Note that the FC-BGP speaker could perform the validation of RPKI router certificates on its own and extract the required data, or it could receive the same data from a trusted cache that performs RPKI validation on behalf of (some set of) FC-BGP speakers. (For example, the trusted cache could deliver the necessary validity information to the FC-BGP speaker by using the Router Key PDU (Protocol Data Unit) for the RPKI-Router protocol [RFC8210].)¶

The recipient validates an FC-BGP UPDATE message containing the FC path attribute and obtains exactly one of the validation states defined in Section 8.2.1: 'Valid', 'Invalid', 'Not Validated', 'Unsupported', or 'Incomplete'. We will describe the validation procedure in Section 8.2.3 in this document. The validation result will be used at BGP route selection, thus it will be discussed at Section 9.5.¶

As the FC-BGP UPDATE message is generated at the eBGP router, the FC-BGP validation needs only to be performed at the eBGP router. The iBGP route plays a crucial role in the FC-BGP UPDATE message propagation and distribution. The function of iBGP is to convey the validation status of an FC-BGP UPDATE message from an ingress edge router to an egress edge router within an AS. The specific mechanisms used to convey the validation status can vary depending on the implementation and local policies of the AS. By propagating this information through iBGP, the eBGP router and other routers within the AS can be aware of the validation status of the FC-BGP UPDATE messages and make routing decisions accordingly. As stated in Section 5, when an FC-BGP speaker decides to forward a syntactically correct FC-BGP UPDATE message, it is RECOMMENDED to do so while preserving the FC path attribute. This recommendation applies regardless of the validation state of the UPDATE message.¶

Ultimately, the decision to forward the FC-BGP UPDATE message with the FC path intact and the choice to perform independent validation at the egress router are both determined by local policies implemented within the AS. Note that the decision to perform validation on the received FC-BGP UPDATE message is left to the discretion of the egress router, which is the router receiving the message within its own AS. The egress router has the freedom to choose whether or not it wants to independently validate the FC path attribute based on its local policy, even if the FC path attribute has already been validated by the ingress router. This additional validation performed at the egress router helps ensure the integrity and security of the received FC-BGP UPDATE message.¶

The rules governing whether an iBGP speaker may modify or delete the FC path attribute, whether validation MUST be re-run, how the validation state is conveyed within an AS, and how route reflectors and confederation member speakers behave, are defined uniformly in Section 5.3.¶

9.1. Algorithms and Extensibility

The content of Algorithm Suite Considerations defined in Section 6.1 of [RFC8205] and the content of Considerations for the SKI Size defined in Section 6.2 of [RFC8205] apply to FC-BGP, with the difference that each FC segment carries its own Algorithm ID field. This document registers the Algorithm ID 1, whose suite is ECDSA over P-256 with SHA-256, as defined in [RFC8208] (see Section 11).¶

The following rules govern algorithm registration, transition, and deprecation:¶

• An Algorithm ID MUST be registered with IANA before it is used in FC segments (see Section 11).¶

• An FC-BGP speaker MUST NOT generate an FC segment with an Algorithm ID for which it has not placed the corresponding router certificate in the RPKI repository.¶

• During a transition between algorithm suites, a speaker MAY generate FC segments with different Algorithm IDs for different FC segments, provided that the private key and certificate for each Algorithm ID are available. Each FC segment's Algorithm ID is covered by that FC segment's own signature (Section 4.1), so mixed-Algorithm-ID FC lists are cryptographically self-contained.¶

• An FC-BGP speaker that encounters an FC segment whose Algorithm ID it does not recognize MUST NOT verify that FC segment and MUST handle it per Section 8.2.2: the UPDATE message becomes 'Unsupported' (or 'Invalid' if another failure is present) per Section 8.2.1. An unsupported algorithm MUST NOT cause the UPDATE message to be silently treated as an ordinary unsigned BGP route.¶

• An algorithm MUST NOT be removed from use without a documented transition plan. Before deprecating an algorithm, operators MUST stop generating FC segments under it, allow enough time for the remaining FC segments signed under it to expire from the network, and then remove the Algorithm ID from the registry.¶

• The Version field (Figure 2) is the first field of the FC segment, in a positionally fixed location, and is also included in the FC Signature Input (Section 4.1). A receiver that does not recognize the Version value handles the FC segment as 'Unsupported' per Section 8.2.2; the signed value prevents the version from being altered in transit.¶

9.2. Speedup and Early Termination of Signature Verification

It is advantageous for an implementation to establish a parallel verification process for FC-BGP if the router's processor supports such operations. As each FC segment contains the integral data that needs to be verified, parallel verification can significantly enhance the efficiency and speed of the validation process. By utilizing parallel processing capabilities, an implementation can simultaneously verify multiple FC segments, thereby reducing the overall verification time. This is particularly beneficial in scenarios where the FC path attribute contains a substantial number of segments or in high-traffic networks with a large volume of FC-BGP UPDATE messages. Implementations that leverage parallel verification take advantage of the processing power available in modern router processors. This allows for more efficient and faster verification, ensuring that the FC-BGP UPDATE messages are promptly validated and routed accordingly.¶

However, it's important to note that the feasibility of parallel verification depends on the specific capabilities and constraints of the router's processor. Implementations SHOULD consider factors such as available resources, concurrency limitations, and the impact on overall system performance when implementing parallel verification processes. Overall, setting up a parallel verification process for FC-BGP, if feasible, can contribute to improved performance and responsiveness in validating FC segments, further enhancing the reliability and efficiency of the FC-BGP protocol.¶

During the validation of an FC-BGP UPDATE message, route processor performance speedup can be achieved by incorporating the following observations. These observations provide valuable insights into optimizing the validation process and reducing the workload on the route processor. One of the key observations is that the FC-BGP UPDATE message can be marked 'Valid' only if all FC segments are marked as 'Valid' in the validation steps. This means that if an FC segment is marked as 'Invalid' or 'Unsupported', there is no need to continue verifying the remaining unverified FC segments. This optimization can significantly reduce the processing time and workload on the route processor. Furthermore, when the FC-BGP UPDATE message is selected as the best path, the FC-BGP speaker appends its own FC segment, including the appropriate signature generated with the corresponding algorithm, to the FC path attribute. This ensures that the updated path is propagated correctly.¶

Additionally, an FC-BGP UPDATE message is 'Invalid' if at least one signature in an FC segment is invalid. Thus, the verification process for an FC segment can terminate early as soon as the first invalid signature is encountered. There is no need to continue validating the remaining signatures in that FC segment.¶

By incorporating these observations, an FC-BGP implementation can achieve significant performance improvements and reduce the computational burden on the route processor. It allows for more efficient validation of FC-BGP UPDATE messages, ensuring the integrity and security of the routing information while maximizing system resources.¶

9.3. Signature Generation Load and Performance Metrics

A single FC-BGP speaker generates one FC segment per (prefix, next-hop AS, propagation leg) for each route it propagates to external neighbors (see Section 5). Because the Prefix and the Nexthop AS Number are covered by the signature (Section 4.1), the number of signatures generated by a speaker grows with the number of prefixes and with the number of distinct externally reachable next hops. This is a design property that bounds the amount of path information each signature covers; operators MUST account for this growth when dimensioning the control plane.¶

Where the path semantics are identical, an implementation MAY reuse a signature or a validation result: for the same prefix, the same next-hop AS, the same FCList, and the same set of FC fields, the signature computation is deterministic and MAY be cached and reused, provided that the reused signature is valid for the same FC Signature Input (Section 4.1). Batch or parallel verification, and caching of verification results, MUST NOT change the validation state produced by the algorithm of Section 8.2.3; they are performance optimizations only.¶

To support capacity planning, FC-BGP implementations SHOULD expose, at a minimum, the following metrics:¶

• the number of FC-BGP UPDATE messages processed per second;¶

• the signature generation latency per UPDATE message;¶

• the signature verification latency for FCList of different lengths;¶

• the CPU utilization attributable to FC generation and FC verification;¶

• the additional octets contributed by the FC path attribute to the UPDATE message;¶

• the BGP convergence time with FC-BGP enabled; and¶

• the memory footprint growth with the size of the RIB and of the RPKI dependency index (Section 9.9).¶

9.4. Deferring Validation

When an FC-BGP speaker receives an exceptionally large number of UPDATE messages simultaneously, though it can use parallel verification to speed up the validation, it can be beneficial to defer the validation of incoming FC-BGP UPDATE messages. The decision to defer the validation process may depend on the local policy of the FC-BGP speaker, taking into account factors such as available resources and system load.¶

By deferring the validation of these messages, the FC-BGP speaker can prioritize its processing power and resources to handle other critical tasks or ongoing operations. Deferring the validation allows the FC-BGP speaker to temporarily postpone the resource-intensive validation process until it can allocate sufficient resources to handle the influx of incoming messages effectively.¶

The implementation SHOULD provide visibility to the operator regarding the deferment of validation and the status of the deferred messages. This visibility enables the operator to have awareness of the deferred messages and understand the current state of the system. This information is crucial for monitoring and managing the FC-BGP speaker's behavior, ensuring that the operator can make informed decisions based on the system's status.¶

The validation of an FC-BGP UPDATE message proceeds through the following states:¶

 Received
    |
    v
 Syntax Check
    |
    v
 Pending Validation
    |
    +------> Valid
    |
    +------> Invalid
    |
    +------> Unsupported

The following rules apply while an UPDATE message is in the 'Pending Validation' state:¶

• A route in the 'Pending Validation' state MAY be admitted to the candidate route set as an ordinary BGP route by local policy, but MUST NOT be reported as validated (see Section 8.2.1).¶

• An FC-BGP speaker MAY forward a route in the 'Pending Validation' state, provided that it does not claim a definitive validation state for it.¶

• The time an UPDATE message MAY remain in the 'Pending Validation' state is bounded by local policy; on timeout, the implementation SHOULD re-evaluate the route and keep the 'Pending Validation' state visible to the operator.¶

• Validation MAY be cancelled (for example, when the UPDATE message is withdrawn, when its route is no longer in the candidate set, or on session reset). Cancellation MUST NOT leave the route reported with a definitive validation state; the affected routes MUST be re-queued or reported as 'Not Validated'.¶

• When the validation of a previously pending UPDATE message completes, the FC-BGP speaker SHOULD re-run the best path selection process for routes affected by the new state (see Section 9.5).¶

• When resources are exhausted, an FC-BGP speaker MAY rate-limit the validation of UPDATE messages received from specific neighbors, but MUST NOT silently treat unvalidated messages as validated (see Section 8.2.1).¶

9.5. BGP Route Selection

While FC-BGP does modify the BGP route selection result, it is not the primary intention of FC-BGP to modify the BGP route selection process itself. Instead, FC-BGP focuses on providing an additional layer of validation and verification for BGP UPDATE messages. The validation state produced by Section 8.2.3 (see Section 8.2.1) is an input to route selection; the protocol does not prescribe a single mapping from validation states to routing decisions. The per-state route-selection behavior that the protocol requires and permits is defined in Section 8.2.1.¶

However, the handling of FC-BGP validation states, as well as the integration of FC-BGP with the BGP route selection, is indeed a matter of local policy. FC-BGP implementations SHOULD provide mechanisms that allow operators to define and configure their own local policies on a per-session basis. This flexibility enables operators to customize the behavior of FC-BGP based on their specific requirements and preferences.¶

By allowing operators to set local policies, FC-BGP implementations empower them to control how the validation status of FC-BGP UPDATE messages influences the BGP route selection process. Operators may choose to treat FC-BGP validation status differently for UPDATE messages received over different BGP sessions, based on their network's needs and security considerations.¶

To ensure consistency and interoperability, it is RECOMMENDED that FC-BGP implementations treat the priority of FC-BGP UPDATE messages at the same level as Route Origin Validation (ROV). This means that the validation status of FC-BGP UPDATE messages should be considered alongside other route selection criteria, such as path attributes, AS path length, and local preference.¶

9.6. Non-deterministic Signature Algorithms

The non-deterministic nature of many signature algorithms can introduce variations in the signatures produced, even when signing the same data with the same key. This means that if an FC-BGP router receives two FC-BGP UPDATE messages from the same peer, for the same prefix, with the same FC path attribute except the signature fields, the signature fields MAY differ when using a non-deterministic signature algorithm. Note that if the sender caches and reuses the previous signature, the two sets of signature fields will not differ. This applies specifically to deterministic signature algorithms, where the signature fields between the two UPDATE messages MUST be identical.¶

Considering these observations, an FC-BGP implementation MAY incorporate optimizations in the UPDATE validation processing. These optimizations can take advantage of the non-deterministic nature of signature algorithms to reduce computational overhead. For example, if an FC-BGP router has already validated an FC segment and its corresponding signature in a previous UPDATE message from the same peer, it may choose to cache and reuse the previous validation result. This can help avoid redundant computations for subsequent UPDATE messages with the same FC path attribute and SKIs, as long as the sender does not generate new signatures.¶

By incorporating such optimizations, an implementation can reduce the computational load and processing time needed for validating FC-BGP UPDATE messages. However, it is important to ensure that the implementation adheres to the requirements and specifications of the FC-BGP protocol while considering the performance benefits of these optimizations.¶

9.7. AS Number Processing

This section defines how FC-BGP handles AS number changes and special cases, and which cases remain inside the FC-BGP protection scope. The process for Private AS Numbers used in BGPsec speakers defined in Section 7.5 of [RFC8205] applies, with the additions below.¶

9.8. Robustness Considerations for Accessing RPKI Data

As there is a mature RPKI to Router protocol [RFC8210], the implementation is REQUIRED to use this protocol to access the RPKI data. The content defined in Section 7.6 of [RFC8205] also applies here.¶

9.9. Dependency Handling on RPKI State Change

When the state of a router certificate changes, the validity of every FC segment that references that certificate can change. To make revalidation on RPKI state change scalable, an FC-BGP speaker SHOULD maintain a dependency index keyed by the Subject Key Identifier (SKI) and, where a SKI is shared, by the Current AS Number (CASN) of the FC segments:¶

• a key (SKI, CASN) maps to the set of FC segments whose SKI and CASN fields match; and¶

• each such FC segment maps to the FC-BGP UPDATE messages that contain it.¶

When the state of a router certificate changes, the FC-BGP speaker MUST:¶

1. locate the (SKI, CASN) entries affected by the certificate change;¶

2. identify the FC segments that reference the affected certificate through those entries;¶

3. locate the FC-BGP UPDATE messages that contain those FC segments;¶

4. re-run the signature validation and, if needed, the FC-to-AS_PATH Mapping for the affected UPDATE messages (Section 8.2.3); and¶

5. update the FC validation state and, if the state of an UPDATE message changed, re-run the best path selection process according to local policy (see Section 9.5).¶

The following certificate state changes have distinct semantics:¶

• Revocation: the certificate MUST no longer be used to verify FC segments; affected FC segments become 'Invalid' (Section 8.2.1).¶

• Expiration: same as revocation once the certificate's validity period has ended.¶

• Replacement (a new certificate for the same AS number): new FC segments MUST be signed with the new certificate; FC segments signed under the replaced certificate are handled as signatures whose key is no longer valid, per Section 8.2.2.¶

• Key rollover: until the new key is valid and the old key has expired or been revoked, the same AS MAY have FC segments signed with either key; the SKI identifies which key to use (Section 5).¶

9.10. Graceful Restart

During Graceful Restart (GR), restarting and receiving FC-BGP speakers MUST follow the procedures specified in [RFC4724] for restarting and receiving BGP speakers, respectively. In particular, the behavior of retaining the forwarding state for the routes in the Loc-RIB [RFC4271] and marking them as stale, as well as not differentiating between stale routing information and other information during forwarding, will be the same as the behavior specified in [RFC4724].¶

9.11. Robustness of Secret Random Number in ECDSA

As both FC-BGP and BGPsec use ECDSA, the content of Robustness of Secret Random Number in ECDSA defined in Section 7.8 of [RFC8205] applies here.¶

9.12. Incremental/Partial Deployment Considerations

The core difference between FC-BGP and BGPsec is that BGPsec is a path-level authentication approach, whereas FC-BGP is a pathlet-driven authentication approach.¶

In design, FC-BGP does not modify the AS_PATH attribute. It defines a new transitive path attribute to transport the FC segments so that the legacy ASs can forward this attribute to their peers. Thus, FC-BGP is natively compatible with BGP and supports partial deployment. It differs from BGPsec, which replaces the AS_PATH attribute with a new Secure_Path information of the BGPsec_Path attribute.¶

As for incremental/partial deployment considerations, in Section 5.1.1 of [FC-ARXIV], we have proved that the adversary cannot forge a valid AS path when FC-BGP is universally deployed. Section 5.1.2 of [FC-ARXIV] analyzes the benefits of FC-BGP in the case of partial deployment. The results show that FC-BGP provides more benefits than BGPsec in partial deployment. As a result, attackers are forced to pretend to be at least two hops away from the destination AS, which reduces the probability of successful path hijacks.¶

9.13. Co-existence with BGPsec

BGPsec and FC-BGP are two different mechanisms for authenticating the path of a BGP UPDATE message. This section defines their behavior when they are enabled on the same speaker or on neighboring speakers. Three cases are distinguished:¶

1. Only FC-BGP is in use:

   The FC path attribute is generated and validated against the AS_PATH attribute, as defined in Section 5 and Section 7. The BGPsec_Path attribute is absent.¶

2. Only BGPsec is in use:

   The BGP speaker follows [RFC8205]; the FC path attribute is absent and no FC processing is performed.¶

3. Both BGPsec and FC-BGP are in use:

   The BGP speaker processes the BGPsec UPDATE message first, then processes the FC-BGP UPDATE message, as described below. It is NOT RECOMMENDED that both be enabled together except during a migration period.¶

When both mechanisms are enabled on the same speaker, the BGPsec_Path attribute is the authoritative path representation: the BGP speaker SHOULD generate the FC segments from the BGPsec_Path and MP_REACH_NLRI attributes, and SHOULD validate the FC segments against the BGPsec_Path and MP_REACH_NLRI attributes, of the same UPDATE message, rather than against the AS_PATH attribute. The receiver MUST use the same path representation (BGPsec_Path or AS_PATH) for both generation and validation; using one representation at generation and the other at validation results in an FC-to-AS_PATH Mapping failure (Section 7) or a signature mismatch and MUST be treated as 'Invalid' per Section 8.2.2.¶

When the BGPsec validation of an UPDATE message fails, the UPDATE message is 'Invalid' for BGPsec. The FC-BGP validation of the same UPDATE message MAY still be performed; however, the FC path attribute does not repair the BGPsec failure. Whether an UPDATE message whose BGPsec validation failed may still be selected on the basis of the FC-BGP validation result is a matter of local policy under Section 9.5; the protocol does not provide a default that silently ignores the BGPsec failure. In all cases, a BGPsec-enabled speaker that propagates a route whose BGPsec_Path attribute it removed because BGPsec validation failed MUST follow the rules of [RFC8205] and MUST NOT attach an FC path attribute that was validated against the removed BGPsec_Path attribute.¶

In summary, an implementation SHOULD be able to process a coexistence UPDATE message; the priority is that the FC segments and the path representation used for their generation and validation are always consistent, and that a BGPsec failure is never silently overridden by FC-BGP validation.¶

10.1. Security Guarantees

This section states the security guarantees that FC-BGP provides and the conditions (preconditions) under which each guarantee holds. Each guarantee is conditional: it holds only when the stated preconditions are met. All of the guarantees below are control-plane guarantees about the FC path attribute; none of them, by itself, constrains the data plane.¶

FC-BGP allows an AS to independently prove its BGP routing decisions with publicly verifiable cryptography commitments, based on which any on-path AS can verify the authenticity of a BGP path. The security benefits of FC-BGP are not binary, i.e., secure or non-secure; they increase monotonically with the deployment rate of FC-BGP, that is, the percentage of ASes that are upgraded to support FC-BGP. In partial deployment, the FC coverage is reflected in the 'Incomplete' validation state (Section 8.2.1), so that the authenticated portion of a path can be distinguished from the unauthenticated portion.¶

10.2. Mitigation of Denial-of-Service Attacks

The FC-BGP UPDATE process, due to its involvement in numerous cryptographic operations, becomes vulnerable to Denial-of-Service (DoS) attacks targeting FC-BGP speakers. This section addresses the mitigation strategies tailored for the specific DoS threats the FC-BGP protocol poses. To prevent the Denial-of-Service (DoS) attacks faced by the FC-BGP control plane mechanism, there is no need to put in more effort than BGPsec.¶

To reduce the impact of DoS attacks, FC-BGP speakers SHOULD employ an UPDATE validation algorithm that prioritizes inexpensive checks (such as syntax checks) before proceeding to more resource-intensive operations (like signature verification). The validation algorithm described in Section 8.2.3 is designed to sequence checks in order of likely expense, starting with less costly operations. However, the actual cost of executing these validation steps can vary across different implementations, and the algorithm in Section 8.2.3 may not offer the optimal level of DoS protection for all cases.¶

Moreover, the transmission of UPDATE messages with the FC path attribute, which entails a multitude of signatures, is a potential vector for denial-of-service attacks. To counter this, implementations of the validation algorithm must cease signature verification immediately upon encountering an invalid signature. This prevents prolonged sequences of invalid signatures from being exploited for DoS purposes. Additionally, implementations can further mitigate such attacks by limiting validation efforts to only those UPDATE messages that, if found to be valid, would be chosen as the best path. In other words, if an UPDATE message includes a route that would be disqualified by the best path selection process for some reason (such as an excessively long AS path), it is OPTIONALLY to determine its FC-BGP validity status.¶

10.3. Route Server

When the Route Server populates its FC Segment into the FC path attribute, it is secure as the path is fully deployed.¶

When the Route Server fails to insert the FC Segment, no matter whether its ASN is listed in the AS path, it is considered a partial deployment, which poses a risk of path forgery.¶

10.4. Additional Security Considerations

10.5. Threat Model

This section presents a systematic threat model for FC-BGP. It complements the BGPsec threat model of [RFC7132]; the security considerations of [RFC4272] also apply to FC-BGP. For each threat, the table states the assumed attacker capability, the attacker's goal, whether FC-BGP can detect the attack, the deployment conditions required for detection, the behavior when detection fails, and the mechanisms that complement FC-BGP.¶

12.1. Normative References

[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/rfc/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/rfc/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/rfc/rfc4760>.

[RFC5656]

Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, DOI 10.17487/RFC5656, December 2009, <https://www.rfc-editor.org/rfc/rfc5656>.

[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/rfc/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/rfc/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/rfc/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/rfc/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/rfc/rfc6793>.

[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/rfc/rfc7606>.

[RFC7947]

Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, <https://www.rfc-editor.org/rfc/rfc7947>.

[RFC8205]

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

[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/rfc/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/rfc/rfc8209>.

[RFC8210]

Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, <https://www.rfc-editor.org/rfc/rfc8210>.

[RFC8635]

Bush, R., Turner, S., and K. Patel, "Router Keying for BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, <https://www.rfc-editor.org/rfc/rfc8635>.

[RFC9234]

Azimov, A., Bogomazov, E., Bush, R., Patel, K., and K. Sriram, "Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages", RFC 9234, DOI 10.17487/RFC9234, May 2022, <https://www.rfc-editor.org/rfc/rfc9234>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

12.2. Informative References

[RFC4272]

Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <https://www.rfc-editor.org/rfc/rfc4272>.

[RFC5065]

Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <https://www.rfc-editor.org/rfc/rfc5065>.

[RFC5492]

Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/rfc/rfc5492>.

[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/rfc/rfc6472>.

[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/rfc/rfc6811>.

[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/rfc/rfc7132>.

[RFC7607]

Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 Processing", RFC 7607, DOI 10.17487/RFC7607, August 2015, <https://www.rfc-editor.org/rfc/rfc7607>.

[RFC7908]

Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 2016, <https://www.rfc-editor.org/rfc/rfc7908>.

[RFC8206]

George, W. and S. Murphy, "BGPsec Considerations for Autonomous System (AS) Migration", RFC 8206, DOI 10.17487/RFC8206, September 2017, <https://www.rfc-editor.org/rfc/rfc8206>.

[RFC8416]

Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified Local Internet Number Resource Management with the RPKI (SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018, <https://www.rfc-editor.org/rfc/rfc8416>.

[ASPP]

McBride, M., Madory, D., Tantsura, J., Raszuk, R., Li, H., Heitz, J., and G. S. Mishra, "AS Path Prepending", Work in Progress, Internet-Draft, draft-ietf-grow-as-path-prepending-19, 14 April 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-path-prepending-19>.

[ASPA-Profile]

Snijders, J., Azimov, A., Uskov, E., Bush, R., Housley, R., and B. Maddison, "A Profile for Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-profile-29, 29 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-29>.

[ASPA-Verification]

Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-verification-28, 24 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-28>.

[Deprecation-AS_SET-AS_CONFED_SET]

Kumari, W., Sriram, K., Hannachi, L., and J. Haas, "Deprecation of AS_SET and AS_CONFED_SET in BGP", Work in Progress, Internet-Draft, draft-ietf-idr-deprecate-as-set-confed-set-18, 7 March 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set-18>.

[FC-ARXIV]

"Secure Inter-domain Routing and Forwarding via Verifiable Forwarding Commitments", September 2023, <https://arxiv.org/abs/2309.13271>.

A.1. Comparison to Other Technologies

AS(1) --- AS(2) -...- AS(k-1) ---- AS(k) -...- AS(n)
                             \               /
                              \--- AS(m) ---/

A.2. Test Vectors

This section specifies the interoperability test cases for FC-BGP validation. Each row gives the input, the expected validation state (per Section 8.2.1), the expected route behavior, and the error handling (per Section 8.2.2). Implementers SHOULD reproduce these cases in their test suites. Concrete byte-level vectors, including the wire encoding of the FC path attribute, the exact FC Signature Input of Section 4.1, and the digital signatures, are published together with the implementation described in Appendix A.3.¶

The byte-level test vectors for IPv4, IPv6, AS Path Prepending, invalid DER, and tampered fields are derived from the canonical FC Signature Input defined in Section 4.1 and MUST be reproducible from the wire encoding of the FC path attribute and of the UPDATE message alone. Any two conforming implementations MUST compute the same FC Signature Input and MUST obtain the same validation state for a given input.¶

A.3. Implementation Status

We implement the FC-BGP mechanism with FRR version 9.0.1. The implementation includes verifying the FC path attribute upon receiving BGP UPDATE messages and adding and signing the FC path attribute when sending BGP UPDATE messages. The development and testing of this implementation were conducted on Ubuntu 22.04 with OpenSSL 3.X installed.¶

GitHub repository: https://github.com/fcbgp/fcbgp-implementation.¶

A.4. An Example

AS(65536) --> AS(65537) --> AS(65538)
                      \
                       \--> AS(65539)

It is important to note that this example only introduces important steps here and see Section 8.2 for details. What's more, here ASs are global AS and not RS or AS Confederation. No ASPP is taken into consideration.¶

For the sake of discussion, we assume that AS 65537 receives an FC-BGP UPDATE message for prefix 192.0.2.0/24 from AS 65536 and will send the route to AS 65538 and AS 65539 as Figure 6 shows. An FC-BGP speaker SHOULD propagate an FC-BGP UPDATE message to downstream ASs only after completing the validation and best route path selection.¶

When the FC-BGP speaker in AS 65536 plans to propagate routes to its downstream AS 65537, it fills the FC path attribute first. The PASN is 0/NULL, the CASN is 65536, and the NASN is 65537. Then it calculates the signature, fills the FC, and forms the FC path attribute and FC-BGP UPDATE message. Then, it sends the UPDATE message out.¶

When receiving an UPDATE message from AS 65536, the FC-BGP speaker in AS 65537 retrieves the FC path attribute and extracts the FC list. It then finds the FC with CASN == 65536 as the AS_PATH has only one AS(65536) and checks whether PASN is 0 as well as NASN is 65537. If so, it uses the SKI field to find the public key and calculates the signature using the algorithm specified in the Algorithm ID. If the calculated signature matches the signature in the FC segment, then the AS-Path hop associated with the AS 65536 is verified. This process repeats for all FCs and AS-Paths in the FC list if it has other ASs in AS_PATH. However, if AS 65537 does not support FC-BGP, the BGP speaker of AS 65537 simply forwards the BGP UPDATE to its neighbors when propagating this FC-BGP route without validating the FC path attribute.¶

FC-BGP speakers need to generate different UPDATE messages for different neighbors. Each UPDATE announcement contains only one route prefix and cannot be aggregated. This is because different route prefixes may have different announcement paths due to different routing policies. Multiple aggregated route prefixes may cause FC generation and verification errors. When multiple route prefixes need to be announced, the FC-BGP speaker needs to generate different UPDATE messages for each route prefix. Thus, the FC-BGP speaker of AS 65537 generates different UPDATE messages for AS 65538 and AS 65539 separately. The biggest difference is that the NASN is 65538 for AS 65538 and 65539 for AS 65539 in the FC segment generated by AS 65537.¶

Take AS 65538 as the next hop. The FC-BGP speaker in AS 65537 will encapsulate each prefix to be sent to AS 65538 in a single UPDATE message, add the FC path attribute, and sign the path content using its private key to fill a new FC segment. The FC path attribute and the FC segment use the message format shown in Figure 1 and Figure 2 separately. When signing, the FC-BGP speaker constructs the canonical FC Signature Input defined in Section 4.1 (which covers the Domain-Separation, Version, PASN, CASN, NASN, SKI, Algorithm ID, Flags, canonical signature length, PC, RESERVED, AFI/SAFI, Prefix, and Prefix Length), computes the SHA-256 hash over that byte string, signs the digest with ECDSA, and then fills in the Signature field and the other FC fields. After that, AS 65537 prepends its own FC on top of the FC List. At this point, the processing of FC path attributes by the FC-BGP speaker is complete. The subsequent processing of BGP messages follows the standard BGP process.¶

Acknowledgments

The authors would like to thank Keyur Patel, Jeffery Hass, Randy Bush, Maria Matejka, Tobias Fiebig, Nan Geng, Tom Strickx, Susan Hares, Rüdiger Volk, Jun Zhang, Kotikalapudi Sriram, John Scudder, Job Snijders, Russ Housley, and Andrew for their review and valuable comments.¶