BGPsec Protocol Specification
updated by
- rfc-8206 — BGPsec Considerations for Autonomous System (AS) Migration
Extracted elements (26)
BGPsec algorithm suite selection cannot be negotiated bilaterally between peers because the chosen suite must be understood by all BGPsec speakers along the entire propagation path, not just the direct peer. Therefore, a single mandatory-to-use algorithm suite is coordinated Internet-wide via RFC 8208 rather than per-session.
To transition between algorithm suites without a flag day, all BGPsec UPDATE messages SHOULD include two Signature_Blocks (one for the current and one for the new suite) during the transition period. A message is 'Valid' if either block is valid, allowing incremental rollout of the new suite.
When a stub customer uses a private AS number, the ISP's edge BGPsec speaker MUST strip the private AS from the AS_PATH or Secure_Path and re-originate the prefix—using its own signature for BGPsec peers—only if a valid ROA in the Global RPKI authorizes the ISP's AS to originate the prefix.
A BGPsec speaker MUST be configured to permit pCount=0 from an IXP (route server) peer. If a peer not expected to set pCount=0 sends a Secure_Path Segment with pCount=0, the UPDATE message MUST be treated as an error.
A BGPsec speaker MUST NOT announce the BGPsec capability unless it also supports the BGP multiprotocol extension (RFC 4760) and MUST NOT advertise BGPsec support for a particular AFI unless it has also advertised the multiprotocol extension capability for that AFI.
A BGPsec UPDATE message MUST advertise a route to only a single prefix, encoded using the MP_REACH_NLRI attribute (RFC 4760). This constraint exists because a receiver cannot construct valid path signatures for a subset of prefixes from a multi-prefix UPDATE.
Any BGP speaker that announces the BGPsec capability MUST also announce the capability for 4-byte AS number support (RFC 6793). If the 4-byte AS capability is absent, BGPsec has not been successfully negotiated and UPDATE messages containing BGPsec_PATH MUST NOT be sent.
If a BGPsec speaker receives a BGPsec UPDATE with two Signature_Blocks and supports both algorithm suites, the new outgoing UPDATE MUST include both Signature_Blocks. If only one suite is supported, the unsupported block MUST be removed. If no supported suite exists, the route MUST NOT be propagated with BGPsec_PATH.
If the UPDATE message was received from a BGPsec peer not in the speaker's AS confederation, validation MUST check that no Secure_Path Segment has the Confed_Segment flag set to 1. Conversely, if received from a confederation peer, the corresponding Secure_Path Segment MUST have Confed_Segment set to 1.
The SKI field in the Signature Segment has a fixed size of 20 octets. If the RPKI certificate's SKI is longer than 20 octets, use only the leftmost 20 octets (excluding tag and length). If shorter, pad with zero bytes on the right to reach 20 octets.
To create or add a signature, a BGPsec speaker MUST possess a private key corresponding to the public key in a valid RPKI end entity certificate (RFC 8209) whose AS number resource extension includes the speaker's AS number. It is RECOMMENDED that origination only occur if a valid ROA authorizes the AS.
UPDATE messages containing the BGPsec_PATH attribute MUST NOT contain the AS_PATH attribute, and vice versa. A BGPsec speaker MUST generate a separate BGPsec UPDATE message for each unique peer AS to which the UPDATE is sent, because the peer AS number is included in the signed data.
Validation checks include: syntactic correctness; the most-recently-added Secure_Path Segment AS matches the peer's AS from OPEN; Signature_Block count of Signature Segments equals count of Secure_Path Segments; no AS_PATH present; and AS loop detection. BGPsec speakers MUST handle errors using 'treat-as-withdraw' (RFC 7606).
When a confederation member propagates a BGPsec UPDATE to a peer outside the confederation, it MUST remove all Secure_Path Segments with Confed_Segment flag set to 1 (and the same count of Signature Segments), then add a new Secure_Path Segment with the confederation's public AS number and a corresponding signature.
When the RPKI state changes (e.g., a router certificate expires or is revoked), a BGPsec speaker MUST rerun validation on all affected UPDATE messages in its Adj-RIB-In. All UPDATE messages whose SKI matches a newly invalid certificate MUST be reassessed.
The BGPsec_PATH attribute is an optional non-transitive BGP path attribute that replaces AS_PATH in BGPsec UPDATE messages. It consists of one Secure_Path (carrying AS path information) and one or two Signature_Blocks (each corresponding to a different algorithm suite).
The data hashed for each signature (Figure 8) is a precisely ordered sequence: Target AS Number, then alternating Signature Segment N-1 / Secure_Path Segment N pairs for each hop from N down to 1, followed by Algorithm Suite Identifier, AFI, SAFI, and NLRI (with trailing prefix bits zeroed).
The pCount field in a Secure_Path Segment specifies the number of repetitions of the AS number that the signature covers, enabling AS prepending semantics without multiple signatures. Route servers may set pCount=0 to participate in BGPsec without inflating AS path length.
This document registers BGPsec_PATH as a new BGP Path Attribute type code in the IANA 'BGP Path Attributes' registry, and registers capability code 7 in the 'Capability Codes' registry for the BGPsec Capability. Algorithm Suite Identifiers are maintained in a separate registry defined in RFC 8208.
BGPsec validation is computationally expensive (public-key cryptography per AS hop). Implementations should rate-limit validation, and operators SHOULD monitor for anomalous UPDATE volumes. A BGPsec speaker MAY temporarily defer validation under exceptional load, but deferred status SHOULD be visible to operators.
Removing BGPsec signatures when propagating a route (i.e., downgrading to an unsigned UPDATE) is NOT RECOMMENDED because it allows any on-path AS to strip path security without detection; downstream receivers cannot distinguish a legitimate downgrade from an attack. Stripping is only acceptable when forwarding to a peer that did not advertise BGPsec receive capability.
When used with origin validation, a valid BGPsec UPDATE provides two guarantees: (1) the origin AS is authorized by the IP address space holder to originate the prefix, and (2) each AS on the path intentionally chose to propagate the route advertisement to the next AS. BGPsec does not guarantee that data packets flow along the indicated path.
BGPsec UPDATE validation produces one of two states: 'Valid' or 'Not Valid'. A Signature_Block is 'Valid' if all its Signature Segments pass cryptographic verification. The UPDATE message is deemed 'Valid' if at least one Signature_Block is marked 'Valid'; otherwise it is 'Not Valid'.
Each Signature_Block begins with a 2-octet length, a 1-octet Algorithm Suite Identifier, and a sequence of Signature Segments. Each Signature Segment contains a fixed 20-octet Subject Key Identifier (SKI), a 2-octet Signature Length, and a variable-length Signature field.
The BGPsec Capability has capability code 7 and a fixed length of 3 octets. The first octet contains a 4-bit Version field, a 1-bit Direction bit (0=receive, 1=send), and 3 unassigned bits. The second and third octets contain the 16-bit AFI.
The Secure_Path begins with a 2-octet length field (inclusive of itself), followed by one or more 6-octet Secure_Path Segments. Each Segment contains a 1-octet pCount, a 1-octet Flags field (Confed_Segment flag in the MSB, 7 bits unassigned), and a 4-octet AS Number.