| RFC | Community Origin Authentication | March 2024 |
| Liu, et al. | Expires 26 September 2024 | [Page] |
BGP community usage has continued to increase during the past decade. Unfortunately, while BGP community is a seemingly innocuous feature, it can be used to influence routing in unintended ways. Existing defense mechanisms are insufficient to prevent community-based attacks. This document describes some of the scenarios that may be used to launch these attacks and make recommendations on practices that may defend them. In particular, this document proposes SecCommunity, an extension to the Border Gateway Protocol (BGP) that can authenticate the ASes who added action community values on the announcements.¶
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 26 September 2024.¶
Copyright (c) 2024 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.¶
BGP community is a group of destinations which share some common property [RFC1997]. It is an optional transitive BGP attribute used to tag meta-data in route announcements. It provides the ability to signal opaque information within separate namespaces to aid in routing management [RFC8092].¶
Roughly speaking, BGP community is used by Autonomous Systems (ASes) mainly for two kinds of purposes [RFC8195], i.e., labeling the routes that have particular attributes (named as informational community) or notifying upstream ASes to conduct some actions (named as action community) [DB08]. Informational community values are used by an AS to label the routes that have particular attributes, including business relationship, the geographical locations of original prefixes and inter-AS interconnections, or simply the ASN of next-hop AS. Action community values are used by an AS to notify other ASes to conduct specific actions for it, such as tuning local preference, selective announcement, AS path prepending, and remotely triggered blackholing.¶
Because action communities can be used to notify upstream ASes to conduct some actions, their values must be negotiated between the AS who tags these community values and the AS who takes actions. A simple way is that one AS (usually the larger one) defines the actions associated with specific community values and the other AS just tags values according to the definitions to notify that AS.¶
Currently, BGP communities provide one of the most convenient way for signaling information between ASes and are an essential component for realizing routing policies [SF18]. Yet, any AS on the forwarding path can add any of the community values to a routing announcement. The recipient of a routing announcement with community values cannot determine which AS on the path added any of the community values [SF18]. As stated in [RFC7999], "BGP contains no specific mechanism to prevent the unauthorized modification of information by the forwarding agent." BGP community values may be used intentionally or accidentally by other ASes who do not negotiate with the definer to attack routing behaviors.¶
According to [RFC8092], BGP community attribute provides a mechanism to signal opaque information. The semantics of defined values might be privacy between the community value definer and the community value tagger. However, some ASes catalog the semantics of their community values in Internet Routing Registry (IRR) database [irrdatabase] or webpages [gtt] publicly, which makes the semantics of their community values transparent to anyone else. It increases the risk of being attacked by ASes who do not negotiate with the community value definers through community-based attacks.¶
The necessity of restricting the usage of BGP community has been noticed in [RFC5635] and [RFC7999], which point out that "BGP announcements carrying the BLACKHOLE community should only be accepted and honored if the neighboring network is authorized to advertise the prefix". However, they only focus on one type of BGP community, i.e., blackholing, and do not explicitly specify how to implement the rules. Furthermore, measurements in [GV17] showed that almost 30% of the blackholing community values traveled more than one hop, which indicates that the receiver of an announcement cannot know who tags the community value on the announcement and then it is incapable of judging whether the tagger is authorized to ask for blackholing the prefix. The measurment result suggests that community-based attacks can be launched several hops away from the AS who defines the action community values. We highlight some cases of community-based attacks in Section 3.¶
As BGP community-based attacks do not modify AS_PATH attribute, existing hijacking defense methods including Resource Public Key Infrastructure (RPKI) [RFC6480] and BGPsec [RFC8205] are insufficient to prevent community-based attacks. For this reason, this document suggests to take the origin authentication of BGP community into consideration. We propose a BGP extension to authenticate the ASes who adds a community value on the announcement. See Section 5 for more details.¶
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.¶
It is assumed that the reader understands BGP [RFC4271], BGP communities [RFC1997], Remotely Triggered Blackholing [RFC5635] [RFC7999], RPKI [RFC6480], and BGPsec [RFC8205].¶
We introduced the risk that BGP action community can be used to attack routing in unintended ways though it seems harmless in Section 1. In this section, we will highlight different cases where transitive community propagation can be used to launch community-based attacks.¶
As defined in [RFC8195], "action community values are added as labels to request that a route be treated in a particular way within an AS. The operator of the AS defines a routing policy that adjusts path attributes based on the community. For example, the route's propagation characteristics, the LOCAL_PREF (local preference), the next hop, or the number of AS_PATH prepends to be added when it is received or propagated can be changed." From it, we can see there are four kinds of action communities which are generally used.¶
These four kinds of action communities can be classified into two categories according to their impact on the community value definer. The first category of action community values can directly change the priority of the community value definer on the routes that they are tagged on, including RTBH community values and TLP community values. In other words, this category of community values can influence the best route selection process and force the community value definer to choose a backup path that is harmful to itself. Attacks launched using this category of action community values can directly attack the community value definer and take effect without a deep understanding of its topology and routing policies. The second category of action community values can only enable the community value definer to modify the AS path length or propagation range of the routes that they are tagged on, including selective NO_EXPORT community values and selective AS_PATH prepending community values. In other words, this category of community values can influence the best route selection process of the community value definer's upstream ASes. Attacks launched using this category of community values may affect many upstream ASes of the community value definer and require familiarity with topology and routing policies of the community value definer and its upstream ASes to take effect. These attacks are more demanding on the attackers and environment than attacks launched using the first category of action community values, so they are more difficult to occur in reality. Therefore, we mainly introduce the community-based attacks launched by using RTBH community values and TLP community values in the following paragraphs.¶
Distributed Denial of Service attacks can heavily degrade network performance and even make the services unavailable [AM17]. One mitigation option is blackholing, i.e., dropping all traffic going to a destination under attack, which makes the victim prefix become intentionally unreachable. Many networks enable blackholing by leveraging BGP community attribute as a signaling mechanism [RFC7999]. The AS who provides remotely triggered blackholing service defines an action community value. Other ASes trigger blackholing requests by sending BGP announcements to the RTBH service provider for specific destination prefixes with the chosen blackholing value.¶
In order to prevent community-based attacks using blackholing community values, the usage scope is strictly limited in previous RFCs. As defined in RFC 5635 [RFC5635] and RFC 7999 [RFC7999], an operator configured with RTBH filtering MUST only accept announcements from the neighboring network for prefixes that it is authorized to advertise. Moreover, a BGP speaker receiving an announcement tagged with the blackholing community values SHOULD add the NO_ADVERTISE or NO_EXPORT community values [RFC1997], or a similar community value, to prevent propagation of the prefix outside the local AS [RFC7999]. If all the ASes obey the rules defined in [RFC5635] and [RFC7999], blackholing community values cannot be used by networks that are unauthorized to advertise the prefix to launch attacks.¶
Nonetheless, many studies suggest that these recommendations are not respected by a number of networks. Some ASes may offer RTBH service to other ASes that are several hops away. According to [GV17], in 30% of the blackholing events they observed that the blackholed prefix is propagated at least one hop away from the blackholing service provider. Measurements in [SF18] showed that around 50% of the blackholing community values traveled more than one hop and about 20% traveled up to four hops.¶
We define unauthorized usage of blackholing community values as "RTBH-based attacks". The attackers launching RTBH-based attacks could be in the ASes that are several hops away from the RTBH service provider, whether they are on the best path or the backup path.¶
Figure 1 illustrates an attack conducted by an AS on the best path. In this figure, AS1 is the origin AS of prefix p and AS3 offers RTBH service. AS3 receives two paths to AS1 for p. The first path is via path "AS2, AS1" and the second is via path "AS4, AS5, AS1". Let us assume AS3 prefers the first path since it is the shorter one. In this example, if AS2 adds the blackholing community value defined by AS3 (i.e., AS3:666 ) [RFC7999] to its announcement for p to AS3, traffic to p would be dropped at AS3. Compared with that AS2 (the attacker) directly drops the traffic to p at its own network by itself, RTBH-based attacks can prevent AS3 from selecting the backup path "AS4, AS5, AS1" to reach AS1.¶
+-------+
+---| AS3 |--+
| +-------+ |
AS3:666 | |
| |
+-------+ +-------+
+--| AS2 | | AS4 |
| +-------+ +-------+
| |
| |
| +-------+
| | AS5 |
| +-------+
+-------+ |
| AS1 |---------------+
+-------+
Figure 2 illustrates an attack conduceted by an AS on one backup path. In this figure, AS1 is the origin AS of prefix p and AS4 offers RTBH service. AS4 receives three candidate paths to AS1 for p as follows.¶
The business relationship between any two neighboring ASes are annotated on each link in Figure 2. In general, AS4 selects path (1) as the best path, because it is learned from its customer AS2 and has a shorter path length than path (2).¶
The attacker can be an AS in the customer cone of the RTBH service provider on the backup path, e.g. AS3. In this example, if AS3, the customer of AS4, tags the blackholing community values of AS4 on the announcement to AS4 for p, AS4 will prefer path (2) rather than path (1). This case is already discussed in [SF18]. The reason is that routers often treat community values before best path selection, which is shown in the Cisco router configuration sample in [RFC5635]. The router might set the local preference of an announcement to a value above the value for general customer routes if the announcement is tagged with blackholing community values. Then in the best route selection phase, the router will select this announcement as the best route and set the next-hop of the announcement to a discard interface. Therefore, ASes on a backup path can tag blackholing community values on the announcement to make the RTBH service provider select the backup path as the best and then drop all the traffic to the blackholed prefix.¶
It should be emphasized that the attacker on the backup path can be out of the customer cone of the RTBH service provider, e.g. AS6. In the example in Figure 2, if AS6, the attacker, tags the blackholing community values of AS4 on the announcement to AS5 for p. Similar as the previous example, AS4 might increase the local preference of path (3) above the paths learned from customers. As a result, AS4 may select the path (3) as the best path and drop the traffic to the prefix p in AS1. This example demonstrates that community-based attacks can be launched from a wide range of ASes on the backup path.¶
provider +-------+ provider
+-----| AS5 |----+
AS4:666 | +-------+ |
| customer |
+---------+ |
| AS4 | | AS4:666
+---------+ |
AS4:666 provider | | provider |
customer | | | customer
+-------+ | +-------+
| AS3 | | | AS6 |
+-------+ | +-------+
provider | | | provider
| | |
customer | | | customer
+-------+ | customer +-------+
| AS2 |--+ | AS7 |
+-------+ +-------+
| provider | provider
| |
| customer |
+-------+ |
| AS1 |------------------+
+-------+ customer
In summary, attackers can blackhole the traffic from the RTBH service provider to the destination by launching RTBH-based attacks, whether they are on the best path or backup paths. For the attackers on the best path, they can achieve the same result by simply dropping the traffic to the destination at their own networks, but the usage of RTBH community values can help the attackers prevent the RTBH provider from selecting any backup path. But for the attackers on backup paths, it is impossible for them to block the traffic from the RTBH service provider to the destination without launching RTBH-based attacks. RTBH-based attacks make them capable of unauthorized blackholing the traffic to the prefixes at the RTBH service provider.¶
According to [RFC8195], as part of an agreement between two peering ASes, AS1 might expose BGP traffic-engineering functions to AS2. One such BGP traffic-engineering function might allow AS2 to manipulate the value of the LOCAL_PREF attribute of routes learned from AS2 within AS1. It not only simplifies the implementation and configuration of routing policies in the multi-provider Internet, but also gives the potential for the customer to control its own routing policy with respect to its service provider [RFC1998]. Although RFC 8195 [RFC8195] recommends operators should take special care when using action community values to tune local preference, some of the unintended BGP states might arise. We define the unauthorized usage of community values to tune local preference as "TLP-based attacks".¶
The TLP service provider could allow an eBGP speaker to affect the LOCAL_PREF value within itself. [RFC8195] states "the typical LOCAL_PREF values could be classified as a hierarchy" and defines five preference classes used in TLP service, including normal customer route, backup customer route, peering route, upstream transit route and fallback route. Some Internet service providers, e.g. AS 174, further defines a preference class "above customer route" in TLP service [onestep]. Figure 3 shows the six preference classes of routes in the order of descending LOCAL_PREF value. It also gives an example community value for each class, which will be used later in this documentation.¶
+-----------------------------------+-------------------------+ | Preference Class | Example Community Value | +-----------------------------------+-------------------------+ | Above customer route | ASX:7:0 | | Normal customer route | ASX:8:0 | | Backup customer route | ASX:9:0 | | Peering route | ASX:10:0 | | Upstream transit route | ASX:11:0 | | Fallback route, to be installed | ASX:12:0 | | if no other path is available | | +-------------------------------------------------------------+
As LOCAL_PREF attribute strongly affects the best route selection process, TLP community values must be negotiated between the TLP service provider and the community value tagger. But if the AS who offers the TLP service does not inspect whether the community value tagger is allowed to tag this value, it might be used to launch TLP-based attacks.¶
An attackers on the backup path may use TLP community values that set the local preference to the class "normal customer route" or "backup customer route" to launch TLP-based attacks. An example is shown in Figure 4. AS1 is the origin AS of prefix p and AS3 offers the TLP service. AS3 receives two paths to AS1 for p. The first path is via path "AS2, AS1" and the second is via path "AS4, AS5, AS1". The business relationship between any two neighboring ASes is annotated in the figure. In general, AS3 prefers the path "AS2, AS1" since it is received from its peer AS2. In this case, if AS4, the provider of AS3, adds community value AS3:9:0 to the announcement to AS3 for p, AS3 will assign local preference of the route learned from AS4 to the class "backup customer route" and thus prefer path "AS4, AS5, AS1" rather than path "AS2, AS1". It is contrary to the economic considerations of AS3 which prefer routes learned from providers to routes learned from peers, and AS3 will suffer financial loss since it needs to pay AS4 for the traffic transmission.¶
Only prefixes whose best path are learned from peers or providers can be attacked by using the TLP community values that set local preference to class "normal customer route" or "backup customer route". But these two kinds of TLP community values are supported by many networks that provides TLP service and all ASes on backup paths for these prefixes are capable to launch TLP-based attacks using them. It means that such attacks can be launched from a wide range of ASes on the backup path.¶
+-------+ provider
| AS4 |----------+
+-------+ |
AS3:9:0 | provider |
| |
| customer | customer
+-------+ +-------+ +------+
| AS2 |-------| AS3 | | AS5 |
+-------+ peer +-------+ +------+
| provider | provider
| |
| customer |
+-------+ |
| AS1 |--------------------------+
+-------+ customer
Similarly, if an Internet service provider allows other ASes to tune local preference of announcements learned from them to class "above customer route", an attacker on a backup path can launch TLP-based attacks as shown in Figure 5. Here, AS1 is the origin AS of prefix p and AS2 offers TLP service. AS2 receives two paths to AS1 for p. The first path is via the direct connection to AS1, and the second is via path "AS4, AS3, AS1". The business relationship between any two neighboring ASes is annotated in the figure. In general, AS2 prefers the path directly received from its customer AS1. In this example, if AS3 or AS4, the attacker, adds community value AS2:7:0 to the announcement to AS2 for p, AS2 might select the path "AS4, AS3, AS1" instead of the path directly received from AS1, making a financial loss for AS2. Compared with the attacks in Figure 4, although few Internet service providers support the TLP community values of "above customer route", this kind of attacks can cause a bigger financial loss and have a wider range of victims. Even prefixes whose best path are learned from customers can be attacked rather than only prefixes whose best path are learned from peers or providers. All ASes on backup paths for these prefixes are capable to launch this kind of TLP-based attacks.¶
AS2:7:0 +-------+
+-----------| AS4 |
| provider +-------+
| | provider
| |
| customer | customer
+-------+ +-------+
| AS2 | | AS3 |
+-------+ +-------+
| provider | provider
| |
| customer |
+-------+ |
| AS1 |-----------+
+-------+ customer
In theory, the attacks discussed above can be easily prevented by inspecting the identity of the community value tagger. However, BGP does not have any specific mechanism to achieve it [RFC7999]. In general, the intended audience of many action community values are transit providers taking action on behalf of a customer or the community definer itself [RFC8195]. Yet, any AS that take part in the propagation of an announcement could add an action community value on it. The recipient cannot know who is the tagger of a community value, let alone judging whether the AS that added the community value is allowed to use the service it provided.¶
As BGP community-based attacks do not modify AS_PATH attribute, it is difficult to detect community-based attacks by existing hijack detection methods. As a result, community-based attacks have been rarely reported so far.¶
One reported community-based attack in the Internet is as follows. Oracle reported a BGP hijack towards authoritative DNS servers of US payment processing companies in July 2018 that misdirected users to malicious websites through directing the DNS requests of the users to a forged DNS server [oracle]. At the beginning of this BGP hijack, the hijack prefixes were only propagated to three peers. But later, the attacker changed a community value of the hijack announcements, then the hijack announcements were propagated to 48 peers. It can be seen that community values have been used in attacks to increase the scope of route propagation. [SF18] conducted an experiment to explore the potential of the 307 verified RTBH community values identified in [GV17] to be used to launch attacks. The researchers advertised prefix p twice, the first time without community values and the second time with one of the 307 RTBH community values. They issued probes from 200 vantage points to p to detect whether the traffic to p was blackholed. The result showed that 25 distinct community values among the 307 RTBH community values sucessfully blackholed the traffic from at least one vantage point to p, i.e., at least one vantage point is responsive after the first advertisement and then becomes unresponsive after the second advertisement.¶
It is reasonable to conjecture that there are unnoticed community-based attacks due to the difficulty to detect community-based attacks.¶
Community-based attacks may cause serious consequences for the networks that define community values. However, BGP contains no specific mechanism to prevent community-based attacks. As a result, there is a strong need for a mechanism to solve the problem. BGP community values are essentially a convention between two ASes. Therefore, community-based attacks can be mitigated by the signature of the community value tagger and the validation of the community recipient.¶
This document describes SecCommunity, an extension to BGP that provides the ability to authenticate the AS who adds a community value on an announcement. As informational community values are only used to label the routes that have particular attributes, they cannot be used to change the routing behaviors of other ASes directly, so there is little use for the community value recipient to verify the identity of the informational community value tagger. Therefore, SecCommunity is only used for action community values that may be leveraged to launch attacks through notifying other ASes to conduct specific actions. Before adopting SecCommunity, the community value definer needs to define an access control list that specifies which ASes are granted or denied access to a particular action community value it defines. We name the list as community access control list (referred to hereafter as CACL). Upon using SecCommunity, the router who adds an action community value needs to make sure its identity is authentic and knowable to the recipient by generating a digital signature. The recipient of the action community value (i.e., the AS who needs to take actions according to this community value) should verify the digital signature to know the identity of the community tagger and then check whether the community tagger is allowed to add this community value by consulting its pre-configured CACL. The recipient will conduct the specific actions only if the community tagger is allowed to add this community value in the CACL.¶
SecCommunity extension is implemented through an optional transitive BGP path attribute SecCommunity. This document specifies the format of SecCommunity attribute. It also describes how a SecCommunity-compliant BGP speaker (referred to hereafter as a SecCommunity speaker) generates, propagates, and validates BGP UPDATE messages containing this attribute (referred to hereafter as SecCommunity UPDATE message) to achieve BGP community origin authentication.¶
SecCommunity relies on the BGPsec router certificates [RFC8209] to generate and validate the digital signatures. Each BGPsec router certificate is issued to routers under a Resource Public Key Infrastructure (RPKI) certificate. A BGPsec route certificate contains a private key, a public key, AS Resources field and Subject Key Identifier (SKI) field. The AS Resources field includes at least one AS number that the router belongs to. The SKI field is used to identify the certificates that contain a particular pair of public key and private key [RFC6487]. Any SecCommunity speaker who wishes to send SecCommunity UPDATE messages to eBGP peers needs to possess a private key associated with an BGPsec router certificate. Note, however, that a SecCommunity speaker does not need such a certificate in order to validate received SecCommunity UPDATE messages.¶
SecCommunity attribute is an optional transitive BGP path attribute. SecCommunity attribute carries the digital signatures used to authenticate the ASes that added action community values to the BGP announcement.¶
SecCommunity attribute is made up of several Secure_Community segments. Figure 6 provides the specification of the format for SecCommunity attribute.¶
+----------------------------------------------------+
| Secure_Community Length (2 octets) |
+----------------------------------------------------+
| One or more Secure_Community Segments (variable) |
+----------------------------------------------------+
The Secure_Community Length field in Figure 6 is the number of Secure_Community segments contained in a SecCommunity attribute.¶
SecCommunity attribute contains one Secure_Community segment (see Figure 7) for each action community value added to the SecCommunity UPDATE message. A detailed description of the Secure_Community segment in a SecCommunity attribute is provided here in Figure 7.¶
+----------------------------------------------------+
| AS Number (4 octets) |
+----------------------------------------------------+
| Action Community Value (12 octets) |
+----------------------------------------------------+
| Algorithm Suite Identifier (1 octet) |
+----------------------------------------------------+
| Subject Key Identifier (SKI) (20 octets) |
+----------------------------------------------------+
| Signature Length (2 octets) |
+----------------------------------------------------+
| Signature (variable) |
+----------------------------------------------------+
The AS Number field in Figure 7 is the AS number of the BGP speaker that added the action community value in the Action Community Value field. The AS Number field MUST be encoded as a 4-octet quantity to support 4-octet AS numbers defined in [RFC6793].¶
The Action Community Value field in Figure 7 is the action community value that needs origin authentication. It should support the community values in Communities attribute [RFC1997] and BGP Large Communities attribute [RFC8092]. The community attribute values are 4 octets and the large community values are 12 octets. The Action Community Value field in Figure 7 SHOULD be encoded as a 12-octet quantity to support large community values. The considerations for 4-octet community values are detailed in Section 6.4. The Action Community Value field, like BGP large community, is made up of two parts. The first 4 octets contain the AS number who defines the community value. The last 8 octets contain the community value defined by this AS.¶
The Algorithm Suite Identifier in Figure 7 is a 1-octet identifier specifying the digest algorithm and digital signature algorithm used to produce the digital signature in the Signature field. The algorithm suite identifier used in SecCommunity can leverage the definations that IANA registry specified in the BGPsec algorithms document [RFC8608].¶
The Subject Key Identifier (SKI) field in Figure 7 contains the value in the SKI field of the BGPsec router certificate [RFC8209] that is used to verify the signature. The size of the SKI in an BGPsec router certificate is variable because of different methods to generate key identifiers [RFC7093] . Taking a page from the SKI field defined in BGPsec [RFC8205], the SKI field in SecCommunity attribute is set to a fixed size of 20 octets. If the SKI is longer than 20 octets, the SecCommunity speaker SHOULD use the leftmost 20 octets of the SKI in the BGPsec router certificate (excluding the tag and length) [RFC7093]. If the SKI value is shorter than 20 octets, the SecCommunity speaker SHOULD pad the SKI (excluding the tag and length) to the right (least significant octets) with octets having "0" values [RFC8205].¶
The Signature Length field in Figure 7 contains the size (in octets) of the value in the Signature field of the Secure_Community segment.¶
The Signature field in Figure 7 contains a digital signature that authenticates the AS that added the action community value.¶
In order to add a new action community value to a SecCommunity UPDATE message with a given algorithm suite, the SecCommunity speaker MUST possess a private key suitable for generating signatures to this algorithm suite. This private key must correspond to the public key in a valid BGPsec router certificate whose AS Resources field [RFC8209] includes the SecCommunity speaker's AS number.¶
When a SecCommunity speaker wants to add a new action community value, it needs to create a Secure_Community segment for this action community value. The following steps are used to create a new Secure_Community segment and update the SecCommunity attribute.¶
Upon receiving a SecCommunity UPDATE message from an external peer, a SecCommunity speaker SHOULD determine whether the action community values need origin authentication validation. If the first 4 octets of the Action Community Value field in all Secure_Community segments do not match the AS number of the SecCommunity speaker, there is no need to validate. Otherwise, a validation procedure is necessary before conducting the actions associated with the action community values.¶
Validation of a SecCommunity UPDATE message makes use of data from BGPsec router certificates [RFC8209]. Therefore, it is necessary that the recipient has access to the following fields that are obtained from all valid BGPsec router certificates: AS Number, Public Key, and SKI from each valid BGPsec router certificate.¶
The validation procedure is described as follows.¶
First, check to ensure that the SecCommunity attribute is syntactically correct (conforms to the specification in this document).¶
Second, check to ensure the Secure_Community Length is equal to the number of Secure_Community segments.¶
Third, locate the Secure_Community segments that need validation (referred to hereafter as NV segments). NV segments are the Secure_Community segments whose first 4 octets of the Action Community Value field match the AS number of this SecCommunity validator.¶
Fourth, verify the Signature field of each NV segments. A NV segment is validated as follows.¶
If a Secure_Community segment passes the above four-step validation, it is marked as 'Valid'. Then the SecCommunity speaker SHOULD check whether the AS in the AS Number field of this Secure_Community segment is permitted to add this community value by consulting its pre-configured CACL. If permitted, the SecCommunity speaker will conduct the action associated with this community value. For each action community value defined, the action community value definer SHOULD record the ASes who have the access to add a specific action community value in CACL and configure CACL at all eBGP routers before adopting SecCommunity.¶
If a Secure_Community segment is marked as 'Invalid', it SHOULD be removed from the SecCommunity attribute. The validation needs only be performed at the eBGP routers.¶
After conducting the specific actions associated with an action community value, the SecCommunity speaker SHOULD remove the Secure_Community segment containing this community value. In addition, the SecCommunity speaker SHOULD update the Secure_Community Length field to the original value minus one. If the Secure_Community Length field is zero, the SecCommunity speaker SHOULD remove SecCommunity attribute from the announcement.¶
Some operational issues that are closely relevant to the SecCommunity specification and deployment are highlighted here.¶
The generation of a Secure_Community segment requires a private key corresponding to the public key in a valid BGPsec router certificate to generate the digest signature. However, SecCommunity speakers in private ASes cannot be issued router certificates in the Global RPKI [RFC8205]. It is a common problem in RPKI system. This document recommends to solve this problem through the method proposed in [RFC8416].¶
SecCommunity attribute can coexist with Communities attribute in a SecCommunity UPDATE message. SecCommunity attribute only offers origin authentication for action community values. Informational community values SHOULD still be added to Communities attribute.¶
If a BGP speaker does not support SecCommunity, it can still add action community values to Communities attribute. Yet, the recipient of these action community values has no way to know the identity of the community tagger. The safety of these action community values cannot be protected. It is the recipient's own choice of how to deal with these action community values.¶
If a SecCommunity speaker does not know whether the AS who defines the action community values supports SecCommunity, it SHOULD add these action community values to both SecCommunity attribute and Communities attribute. Upon receiving a SecCommunity UPDATE message, a SecCommunity speaker SHOULD inspect SecCommunity attribute first and then Communities attribute.¶
If a BGP speaker who does not support SecCommunity receives a SecCommunity UPDATE message, it SHOULD ignore SecCommunity attribute and forward it normally to other eBGP peers.¶
Unlike BGPsec, SecCommunity does not need all ASes on the path to do signatures or validations to achieve action community origin authentication. It only needs to be signed by the AS who uses action community service and verified by the AS who provides this service to get the benefits of cryptographic action community protection. Other ASes on the path do not need to do anything except ignoring SecCommunity attribute and forwarding the announcement to other eBGP peers. The expense of deploying SecCommunity is quite small, but the risk of being attacked by community-based attacks can be avoided once the AS deploy this mechanism.¶
As defined in [RFC1997], community attribute values are four octets. The first two octets SHALL be an AS number and the semantics of the last two octets may be defined by this AS [RFC1997]. When adding a new four-octet community value to SecCommunity attribute, the third and fourth octets of Action Community Value field SHOULD be populated with the first two octets of this four-octet community value and the last two octets of Action Community Value field SHOULD be populated with the last two octets of this four-octet community value. The other octets of Action Community Value field SHOULD be populated with value "0".¶
If the four-octet community value that a SecCommunity speaker wants to add is not encoded as [RFC1997] defines, it is not supported by SecCommunity.¶
SecCommunity allow the recipient to know the identities of the ASes who added action community values through cryptographical verification.¶
SecCommunity update message validation procedure is a potential target for denial-of-service attacks against a SecCommunity speaker.¶
To mitigate the effectiveness of such denial-of-service attacks, SecCommunity speakers should implement a validation algorithm that performs expensive checks (e.g., signature verification) after performing checks that are less expensive (e.g., syntax checks).¶
IANA needs to register a new path attribute described in Section 5 in the "BGP Path Attribute" registry in the "Border Gateway Protocol (BGP) Parameters" registry group. The code for this new attribute is "SecCommunity". This document is the reference for the new attribute.¶