| Internet-Draft | BGP Color Threat Model | July 2026 |
| Yuan, et al. | Expires 2 January 2027 | [Page] |
The BGP Color Extended Community carries a user-defined Color value that is configured locally and has no globally standardized semantics. Although this design is suitable for local policy expression, it raises security concerns when Color values are propagated across Autonomous System (AS) boundaries and used to influence forwarding behavior in another domain.¶
This document describes a threat model for that context, following the structure used by RFC 7132. It defines relevant terminology, characterizes the classes of adversaries considered to be threats, examines the classes of attacks that those threats are able to effect against Color-based forwarding, and concludes with a discussion of residual vulnerabilities. It does not revisit attacks against unprotected BGP, and it defines no new protocol mechanism.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The BGP Color Extended Community [RFC9012] carries a 32-bit, user-defined Color value that is locally configured to express forwarding intent, but the attribute does not identify or authenticate the AS that originated the value.¶
The locally configured nature of Color values creates a security concern when they are used across administrative boundaries. Several technologies carry a Color value across AS boundaries and use it to select a forwarding treatment in a remote domain:¶
In each case the receiving AS maps the received Color value onto a local forwarding construct based solely on the value itself. The Color Extended Community carries no information identifying the AS that injected the value, and there is no binding between the Color and the AS_PATH attribute. Consequently, a receiving AS cannot determine where along the propagation path a Color was originated or altered, and it implicitly trusts the value as received.¶
This document describes the security context in which Color-based forwarding operates across AS boundaries. Following the approach of [RFC7132], it characterizes the classes of adversaries considered to be threats and the classes of attacks they may launch against Color-based forwarding, and it concludes with residual vulnerabilities. The security focus of this document is the integrity and authenticity of the Color value and the ability of a receiving AS to attribute a Color value to an authorized origin.¶
This document does not revisit attacks against unprotected BGP, which are addressed in [RFC4271] and [RFC4272], nor attacks on the BGP transport session, which are addressed by existing session-protection mechanisms. It defines no new protocol mechanism and does not, by itself, address any of the threats it describes.¶
The security model adopted here does not assume an oracle with global visibility of all Color values originated and propagated by every AS. It is an AS-centric model, consistent with the AS-centric model that BGP employs for routing: each AS reasons locally about whether a received Color value is legitimate.¶
The following security and routing terminology is used in this document. Security terms follow the usage in [RFC7132].¶
An entity that is perceived as malicious relative to the security policy of a system. It is common to describe classes of adversaries with similar capabilities or motivations rather than specific individuals or organizations.¶
An action that attempts to violate the security policy of a system, e.g., by exploiting a vulnerability.¶
A set of one or more IP networks operated by a single administrative entity.¶
The BGP path attribute that records the sequence of ASes through which a route has passed [RFC4271].¶
A path vector protocol used to convey reachability information among ASes in support of inter-domain routing [RFC4271].¶
The transitive opaque extended community defined in Section 4.3 of [RFC9012] that carries a 32-bit Color value.¶
The 32-bit, user-defined value carried in the Color Extended Community, used to express forwarding intent.¶
The AS at which a particular Color value was first associated with a route. The Color Origin is not necessarily the route origin recorded in the AS_PATH, and it is not carried in any attribute.¶
A procedure or technique that thwarts an attack, preventing it from succeeding.¶
A local resource onto which a receiving AS maps a Color value, such as an SR Policy candidate path [RFC9256], a color-aware transport path [RFC9871], or a forwarding treatment associated with a colored prefix [RFC9723].¶
An entity able to examine and modify traffic between two or more parties on a communication path.¶
An entity that manages an AS and thus emits (E)BGP updates.¶
A motivated, capable adversary. An adversary that is not motivated to launch an attack is not a threat, and an adversary that is motivated but not capable of launching an attack is also not a threat.¶
A flaw or weakness in the design, implementation, or operation of a system that could be exploited to violate the security policy of that system.¶
As defined in Section 2, a threat is a motivated, capable adversary. The classes below represent adversaries viewed as relevant to Color-based forwarding across AS boundaries. Because a Color value is an ordinary path attribute, any entity in a position to originate or forward a BGP route is in a position to set, alter, or remove the Color Extended Community on that route.¶
A network operator may be a threat. An operator controls the BGP speakers in its AS and can therefore attach, change, or strip a Color value on routes it originates or forwards. An operator may be motivated to color or recolor routes so that traffic from other domains is steered onto paths that are economically advantageous to it, onto paths it is able to observe, or off paths that another domain intended for compliance, filtering, or accounting. Misconfigured or faulty speakers controlled by an operator can produce the same effects without malicious intent; the receiving AS cannot distinguish the two cases, and so this class also encompasses non-malicious error.¶
Hackers are considered a threat. A hacker who assumes control of a router, an SR Policy headend, or a management system can act as a rogue operator (see above) for the affected AS. Hackers are generally not assumed to be capable of MITM attacks on arbitrary links between ASes.¶
Criminals may be a threat. Criminals might coerce a network operator into acting as a rogue operator, or coerce the staff of a transport provider into enabling a MITM attack on an inter-AS link. Motivations include extorting operators or their customers by degrading service through adverse steering, or concealing the source of other activity by manipulating the path that traffic follows.¶
A nation may be a threat. A nation may control or compel operators within its territory to act as rogue operators, and may possess an active wiretapping capability that enables MITM attacks on inter-AS traffic. National motivations include steering traffic onto paths that can be monitored, or diverting traffic destined for other nations.¶
This section describes classes of attacks against Color-based forwarding. Attacks are classified by their target. The attacks of interest are those that violate the integrity or authenticity of the Color value or the authenticity of its origin.¶
Throughout this section, behavior that is fully explained by a receiving or forwarding AS's own local policy is not classified as an attack, because such behavior is within the purview of each AS and is beyond what any Color origin mechanism could be expected to detect as unauthorized. For example, a receiving AS that declines to act on a Color value, or that maps it to a different forwarding construct than the originator intended, is exercising local policy. Likewise, an AS that, by its own configuration, sets a Color on routes it originates for its own customers is behaving normally.¶
An adversary positioned as a MITM on the link carrying a BGP session can forge, modify, or suppress any attribute in transit, including the Color Extended Community. Remote attacks against the session and MITM attacks are addressed by the session-protection mechanisms available to BGP, such as TCP-AO and IPsec, and the corresponding countermeasures are described in [RFC4272]. This document therefore does not address such attacks further, except to note that protecting the session does not protect against a peer that is itself the adversary (Section 4.2).¶
Any speaker that originates or forwards a route is able to manipulate the Color Extended Community on that route. Because no mechanism binds a Color value to an authorized origin AS, and because the Color Extended Community is not covered by AS_PATH integrity mechanisms, the receiving AS generally cannot detect the manipulations below. The list illustrates attacks of this class.¶
A speaker attaches a Color value to a route whose legitimate origin did not color it, or colors it with a value the origin did not intend. The receiving AS maps the value onto a local forwarding construct and steers traffic accordingly. This is the central attack addressed by this document; there is no information in the route by which the receiver can attribute the Color to an authorized origin. The consequence is that traffic may be steered onto a path not intended by the legitimate originator, potentially bypassing paths designated for compliance, filtering, or accounting, or onto a constrained or overloaded path resulting in degraded service. This attack has the broadest potential impact of the attacks described in this subsection.¶
A transit speaker changes the Color value on a route it forwards. [RFC9012] specifies that the Color value is not to be modified during propagation, but this is a requirement on conforming implementations, not an enforced property. BGPsec [RFC8205] protects the AS_PATH attribute but does not extend protection to extended communities, so recoloring by a malicious, compromised, or misconfigured speaker is not detectable by the receiver. The impact is equivalent to that of Color Injection at the point of modification: all downstream ASes receive and act on the altered value, multiplying the effect across any AS that subsequently maps the Color to a forwarding construct.¶
A speaker removes the Color Extended Community so that a route is no longer steered and falls back to default forwarding. At an AS boundary where the operator's policy is to remove extended communities, this is local policy and not an attack. Within a domain across which the Color is intended to remain transitive, an on-path speaker that silently removes the Color contrary to that intent is effecting an attack, which the receiver experiences as the absence of intended steering. The impact is a silent degradation: traffic follows a default path rather than the intended one, which may violate service, compliance, or accounting requirements without producing any error condition visible to the originating AS.¶
The Color Extended Community carries no freshness, lifetime, or sequence information. As a result, a receiving AS cannot distinguish a Color value that was recently attached from one that was previously attached and later re-presented on another route.¶
In the current protocol, however, such behavior does not create a separate class of attack beyond unauthorized Color attachment or modification. If a speaker attaches a previously observed Color value to a route, the relevant attack is Color Injection. If a speaker replaces one Color value with a previously observed value, the relevant attack is Color Recoloring.¶
This document therefore does not treat replay as an independent attack class. If a future mechanism defines a validity interval, sequence number, or other freshness property for Color values, then use of an expired or stale Color value would need to be reconsidered as a distinct attack.¶
An adversary may attack the systems an operator uses to manage Color semantics rather than the routes directly: the controllers that define Color-to-policy mappings, that program SR Policy candidate paths, or that configure which Color values are originated, accepted, or filtered at boundaries. An adversary who compromises such a system can change these mappings, causing traffic to be steered onto unintended constructs. Externally, this appears as rogue-operator behavior and cannot be distinguished by other ASes from a deliberate local policy decision.¶
The following vulnerabilities are not addressed by mechanisms available today and appear likely to remain outside the scope of point fixes.¶
This document is, by its nature, security-centric. Like any threat model, it neither creates nor purports to resolve security problems. It postulates a set of threats, examines the classes of attacks those threats can effect against Color-based forwarding, and notes which attacks existing mechanisms do and do not address.¶
The central residual vulnerability is the absence of any means for a receiving AS to verify the origin of a received Color value. The consequences include traffic being steered onto a path not intended by the legitimate originator, off a path intended for compliance, filtering, or accounting, or onto a constrained or overloaded path, resulting in congestion or service degradation.¶
Two directions for future work follow from this analysis. First, a mechanism that binds a Color value to an authorized origin AS would address Color Injection and Color Recoloring directly. Such a mechanism might take the form of a signed object associating a Color value with an originating AS, analogous to the Route Origin Authorization (ROA) used in RPKI [RFC6482], or an extension to BGPsec [RFC8205] that extends AS_PATH integrity protection to cover the Color Extended Community. Second, a mechanism that associates a validity interval, sequence number, or other freshness property with a Color value would make stale or replayed Color values detectable, which the current protocol does not support.¶
Operational countermeasures, including filtering and rewriting of extended communities at eBGP boundaries, remain the principal means of limiting exposure in deployments where Color values are not intended to cross AS boundaries. As noted in Section 5, these countermeasures are ineffective where Color values are intended to remain transitive across AS boundaries, which is precisely the deployment model assumed by [RFC9256], [RFC9723], and [RFC9871]. In those deployments, the threats described in this document are not mitigated by any mechanism available today.¶
This document has no IANA actions.¶
The authors would like to thank TBD for their reviews and contributions to this document. The structure of this document follows the threat model in [RFC7132].¶