BGP IPsec Tunnel Encapsulation Attribute
obsoleted by
- rfc-9012 — The BGP Tunnel Encapsulation Attribute
Extracted elements (20)
Requiring IPsec uniformly across all data packets on a given interface (rather than selectively) eliminates dependence on IPsec selector mechanisms to distinguish protected from unprotected traffic, simplifying policy and reducing the risk of misconfiguration.
RFC 5566 does not specify use of the sub-TLV types defined in RFC 5512 (such as the Encapsulation sub-TLV or Color sub-TLV) with the IPsec tunnel types it introduces; only the new IPsec Tunnel Authenticator sub-TLV (type 3) is defined for use with these tunnel types.
The IPsec Transport Mode specification from RFC 4023 for MPLS-in-IP tunnels applies equally to IP in IP tunnels with IPsec Transport Mode (tunnel type 5), meaning the same operational rules govern both tunnel type 5 and tunnel type 6.
A BGP speaker sending the IPsec Tunnel Authenticator sub-TLV with authenticator type 1 MUST be configured with a private/public key pair whose public key hash appears in the sub-TLV, and MUST either generate a self-signed certificate or be configured with a certificate for that public key.
If a BGP speaker R1 receives an Encapsulation SAFI update from R2 indicating an IPsec tunnel type, R1 MUST initiate an IPsec SA of the specified tunnel type, and all data packets for which R2 is the BGP next hop MUST be sent through that SA.
IPsec SAs for BGP-signaled tunnel types MUST typically be established using IKEv2 with public-key or pre-shared key authentication. Manual SA configuration is also permitted (MAY) and must include keys, SPI numbers, IPsec protocol, integrity/encryption algorithms, and sequence number mode.
Reciprocal processing is required: when R2 establishes an SA from R1 and R1 has advertised an IPsec Tunnel Authenticator sub-TLV type 1, R2 MUST use IKEv2 to obtain a certificate from R1, and R2 MUST NOT establish the SA unless R1's certificate public key hashes to a value in R1's sub-TLV.
Support for the IPsec Tunnel Authenticator sub-TLV MUST be implemented whenever the IPsec tunnel types defined in this document are implemented, though its use is OPTIONAL and a matter of local policy.
When an IPsec Tunnel Authenticator sub-TLV with authenticator type 1 is present, R1 MUST use IKEv2 to obtain a certificate from R2, and R2 MUST send a certificate for the public key whose hash is in the sub-TLV. R1 MUST NOT attempt to establish an SA to R2 unless the certificate's public key hashes to a value present in one of the sub-TLVs.
When R3 sends an Encapsulation SAFI indicating an IPsec tunnel type to R2, R3 SHOULD also send a corresponding IPsec Encapsulation SAFI update to R1 if both R1 and R2 may send data packets through R3 on the same interface. This ensures IPsec is required for all data packets on that interface, not just some.
When the IPsec Tunnel Authenticator sub-TLV is used, it is highly RECOMMENDED that the integrity of the BGP session itself be protected, typically via the TCP MD5 option (RFC 2385).
RFC 5566 defines four tunnel type values for the BGP Tunnel Encapsulation attribute: type 3 (Transmit tunnel endpoint), type 4 (IPsec in Tunnel-mode), type 5 (IP in IP Tunnel with IPsec Transport Mode), and type 6 (MPLS-in-IP Tunnel with IPsec Transport Mode).
The IPsec Tunnel Authenticator sub-TLV (sub-TLV type 3) is a new sub-TLV for the BGP Tunnel Encapsulation attribute. It carries an authenticator type (2 octets) and a variable-length value field used to authenticate the originating BGP speaker. One or more sub-TLVs MAY be included in any IPsec-type Encapsulation SAFI NLRI.
The 'Transmit tunnel endpoint' tunnel type (value 3) is for a BGP speaker that wishes to be only the transmitting endpoint of an IPsec tunnel, not the receiving endpoint. This allows asymmetric tunnel role advertisement.
IANA assigned four values in the 'BGP Tunnel Encapsulation Attribute Tunnel Types' registry: value 3 (Transmit tunnel endpoint), value 4 (IPsec in Tunnel-mode), value 5 (IP in IP tunnel with IPsec Transport Mode), and value 6 (MPLS-in-IP tunnel with IPsec Transport Mode), all referencing RFC 5566.
IANA assigned value 3 in the 'BGP Tunnel Encapsulation Attribute Sub-TLVs' registry for the 'IPsec Tunnel Authenticator' sub-TLV, referencing RFC 5566.
A BGP session may itself be transported over an IPsec tunnel, providing additional security to the BGP control plane. Management of such BGP-over-IPsec tunnels is outside the scope of this document.
If the BGP session's integrity is not protected, an imposter could mount a DoS attack by establishing numerous BGP sessions and forcing IPsec SA creation for each. However, since such an imposter would also threaten the entire routing system, this attack is not considered uniquely critical to the IPsec tunnel mechanism.
Modification of encapsulation header information or tunnel selection data may cause user packets to be misrouted, misdelivered, or dropped. When IPsec is in use, misdelivery is likely to result in authentication or decryption failure at the receiver, providing a built-in detection mechanism.
The IPsec Tunnel Authenticator sub-TLV encodes: Authenticator Type (2 octets), followed by Value (variable, length = sub-TLV length minus 2). For authenticator type 1 (SHA-1 hash of public key, per RFC 4306 Section 3.7), the Value field is exactly 20 octets.