Internet DRAFT - draft-liu-sidrops-community-authentication
draft-liu-sidrops-community-authentication
sidrops Y. Liu
Internet-Draft J. Wang
Intended status: Standards Track Y. Wang
Expires: 30 March 2024 M. Xu
Tsinghua University
27 September 2023
BGP Community-based Attacks and Community Origin Authentication
draft-liu-sidrops-community-authentication-00
Abstract
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 defend 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.
Status of This Memo
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 30 March 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liu, et al. Expires 30 March 2024 [Page 1]
RFC Community Origin Authentication September 2023
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 4
3. Community-based Attack Cases . . . . . . . . . . . . . . . . 4
3.1. Remotely Triggered Blackholing . . . . . . . . . . . . . 5
3.2. Tuning Local Prference . . . . . . . . . . . . . . . . . 9
4. Community-based Attacks in the Wild . . . . . . . . . . . . . 12
5. BGP Community Origin Authentication . . . . . . . . . . . . . 13
5.1. SecCommunity Attribute . . . . . . . . . . . . . . . . . 15
5.2. Adding action community values to the SecCommunity
Attribute . . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Validating a Received SecCommunity UPDATE Message . . . . 17
5.4. Removing action community values from the SecCommunity
Attribute . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Operational Considerations . . . . . . . . . . . . . . . . . 19
6.1. Private AS Numbers . . . . . . . . . . . . . . . . . . . 19
6.2. Deployment Considerations . . . . . . . . . . . . . . . . 20
6.3. Incremental Deployment Considerations . . . . . . . . . . 20
6.4. Considerations for Four-octet Community Values . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7.1. Security Guarantees . . . . . . . . . . . . . . . . . . . 21
7.2. Mitigation of Denial-of-Service Attacks . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
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].
Liu, et al. Expires 30 March 2024 [Page 2]
RFC Community Origin Authentication September 2023
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 [RFC7999].
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
Liu, et al. Expires 30 March 2024 [Page 3]
RFC Community Origin Authentication September 2023
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 advertise
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.
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.
2. Suggested Reading
It is assumed that the reader understands BGP [RFC4271], BGP
communities [RFC1997], Remotely Triggered Blackholing [RFC5635]
[RFC7999], RPKI [RFC6480], and BGPsec [RFC8205].
3. Community-based Attack Cases
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.
Liu, et al. Expires 30 March 2024 [Page 4]
RFC Community Origin Authentication September 2023
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.
(1) Remotely Triggered Blackholing (RTBH) [RFC7999]. See
Section 3.1 for more details.
(2) Tuning local preference (TLP) [RFC8195]. See Section 3.2 for
more details.
(3) Selective NO_EXPORT [RFC8195]. As part of an agreement between
AS1 and AS2, AS1 might request AS2 to selectively filter routes
learned from AS1 to certain eBGP neighbors.
(4) Selective AS_PATH prepending [RFC8195]. As part of an agreement
between AS1 and AS2, AS1 might request AS2 to selectively
prepend the AS_PATH with AS2 on routes learned from AS1 to
certain eBGP neighbors.
Not all kinds of action communities can be used to attack routing
behaviors. If an action community value can change the priority of
the routes that it is tagged on, it can be used to launch community-
based attacks. In other words, it can influence best route selection
process and force the community value definer to choose a backup path
that is harmful to itself. Two kinds of action community values
satisfy this requirement, i.e., RTBH community values and TLP
community values.
3.1. Remotely Triggered Blackholing
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.
Liu, et al. Expires 30 March 2024 [Page 5]
RFC Community Origin Authentication September 2023
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.
Liu, et al. Expires 30 March 2024 [Page 6]
RFC Community Origin Authentication September 2023
+-------+
+---| AS3 |--+
| +-------+ |
AS3:666 | |
| |
+-------+ +-------+
+--| AS2 | | AS4 |
| +-------+ +-------+
| |
| |
| +-------+
| | AS5 |
| +-------+
+-------+ |
| AS1 |---------------+
+-------+
Figure 1: Attacker on the best path blackholes the traffic at
RTBH service provider through RTBH-based attacks
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.
(1) AS2 AS1
(2) AS3 AS2 AS1
(3) AS5 AS6 AS7 AS1
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
Liu, et al. Expires 30 March 2024 [Page 7]
RFC Community Origin Authentication September 2023
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
Figure 2: Attacker on the backup path blackholes the traffic at
RTBH service provider through RTBH-based attacks
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
Liu, et al. Expires 30 March 2024 [Page 8]
RFC Community Origin Authentication September 2023
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.
3.2. Tuning Local Prference
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 | |
+-------------------------------------------------------------+
Figure 3: Preference Classes and Example Community Values in TLP
Service
Liu, et al. Expires 30 March 2024 [Page 9]
RFC Community Origin Authentication September 2023
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.
Liu, et al. Expires 30 March 2024 [Page 10]
RFC Community Origin Authentication September 2023
+-------+ provider
| AS4 |----------+
+-------+ |
AS3:9:0 | provider |
| |
| customer | customer
+-------+ +-------+ +------+
| AS2 |-------| AS3 | | AS5 |
+-------+ peer +-------+ +------+
| provider | provider
| |
| customer |
+-------+ |
| AS1 |--------------------------+
+-------+ customer
Figure 4: Attacker on a backup path attracts the traffic of TLP
service provider by tuning local preference to class backup
customer route
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.
Liu, et al. Expires 30 March 2024 [Page 11]
RFC Community Origin Authentication September 2023
AS2:7:0 +-------+
+-----------| AS4 |
| provider +-------+
| | provider
| |
| customer | customer
+-------+ +-------+
| AS2 | | AS3 |
+-------+ +-------+
| provider | provider
| |
| customer |
+-------+ |
| AS1 |-----------+
+-------+ customer
Figure 5: Attacker on a backup path attracts the traffic of TLP
service provider by tuning local preference to class above
customer route
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.
4. Community-based Attacks in the Wild
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
Liu, et al. Expires 30 March 2024 [Page 12]
RFC Community Origin Authentication September 2023
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.
5. BGP Community Origin Authentication
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.
Liu, et al. Expires 30 March 2024 [Page 13]
RFC Community Origin Authentication September 2023
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 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.
Liu, et al. Expires 30 March 2024 [Page 14]
RFC Community Origin Authentication September 2023
5.1. SecCommunity Attribute
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) |
+----------------------------------------------------+
Figure 6: SecCommunity Attribute Format
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) |
+----------------------------------------------------+
Figure 7: Secure_Community Segment Format
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].
Liu, et al. Expires 30 March 2024 [Page 15]
RFC Community Origin Authentication September 2023
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.
5.2. Adding action community values to the SecCommunity Attribute
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.
Liu, et al. Expires 30 March 2024 [Page 16]
RFC Community Origin Authentication September 2023
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.
(1) Set the AS Number field. The AS Number field MUST match the AS
number of this SecCommunity speaker.
(2) Set the Action Community Value field. The Action Community
Value field SHOULD be the action community value that the
SecCommunity speaker wants to add.
(3) Set the Algorithm Suite Identifier field. The Algorithm Suite
Identifier field SHOULD be the algorithm used to produce the
digital signature in Signature field.
(4) Set the Subject Key Identifier field. The Subject Key
Identifier field is populated with the identifier contained in
the SKI field of BGPsec router certificate (see Section 4.8.2 of
[RFC6487]) for the SecCommunity speaker.
(5) Compute digital signature. The Signature field contains a
digital signature that binds the Action Community Value field to
the BGPsec router certificate of the SecCommunity speaker. The
digital signature is computed as follows. First, apply the
digest algorithm (for the algorithm suite of this
Secure_Community) to the Action Community Value field to obtain
a digest value. Next, apply the signature algorithm (for the
algorithm suite of this Secure_Community) to this digest value
to obtain the digital signature. Then populate the Signature
field in Figure 7 with this digital signature.
(6) Populate Signature Length field with the length (in octets) of
the value in the Signature field.
(7) Update the Secure_Community Length field to the original value
plus one.
5.3. Validating a Received SecCommunity UPDATE Message
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.
Liu, et al. Expires 30 March 2024 [Page 17]
RFC Community Origin Authentication September 2023
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.
(1) Examine the Algorithm Suite Identifier field. If the Algorithm
Suite Identifier field of the NV segment contains an algorithm
suite that the SecCommunity speaker does not support, this NV
segment is not considered in the validation process.
(2) Find the public key that is needed to verify this signature.
The SecCommunity speaker SHOULD consult all valid BGPsec router
certificate data and look up all valid (AS Number, Public Key,
SKI) triples. Of these triples that match the AS Number field
of the NV segment, the SecCommunity speaker SHOULD check whether
there is an SKI that matches the value in the SKI field of the
NV segment. If this check finds no such matching SKI value,
then the SecCommunity speaker SHOULD mark the Secure_Community
segment as 'Invalid' and proceed to the next NV segment.
(3) Compute the digest function for the Action Community Value field
of the NV segment.
(4) Use the signature validation algorithm to verify the Signature
field of the NV segment. That is, invoke the signature
validation algorithm on the following three inputs: the value of
the Signature field in the Secure_Community segment, the digest
value computed in (3) and public key obtained in (2). If the
signature validation algorithm determines that the signature is
Liu, et al. Expires 30 March 2024 [Page 18]
RFC Community Origin Authentication September 2023
invalid, then the SecCommunity speaker SHOULD mark the
Secure_Community as 'Invalid' and proceed to the next NV
segment.
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.
5.4. Removing action community values from the SecCommunity Attribute
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.
6. Operational Considerations
Some operational issues that are closely relevant to the SecCommunity
specification and deployment are highlighted here.
6.1. Private AS Numbers
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].
Liu, et al. Expires 30 March 2024 [Page 19]
RFC Community Origin Authentication September 2023
6.2. Deployment Considerations
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.
6.3. Incremental Deployment Considerations
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.
6.4. Considerations for Four-octet Community Values
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
Liu, et al. Expires 30 March 2024 [Page 20]
RFC Community Origin Authentication September 2023
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.
7. Security Considerations
7.1. Security Guarantees
SecCommunity allow the recipient to know the identities of the ASes
who added action community values through cryptographical
verification.
7.2. Mitigation of Denial-of-Service Attacks
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).
8. IANA Considerations
IANA needs to register a new path attribute described in Section 5 in
the "BGP Path Attribute" subregistry under the "Border Gateway
Protocol (BGP) Parameters" registry. The code for this new attribute
is "SecCommunity". This document is the reference for the new
attribute.
9. References
9.1. Normative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<https://www.rfc-editor.org/info/rfc1997>.
[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/info/rfc4271>.
Liu, et al. Expires 30 March 2024 [Page 21]
RFC Community Origin Authentication September 2023
[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/info/rfc6487>.
[RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas,
I., and N. Hilliard, "BGP Large Communities Attribute",
RFC 8092, DOI 10.17487/RFC8092, February 2017,
<https://www.rfc-editor.org/info/rfc8092>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
Specification", RFC 8205, DOI 10.17487/RFC8205, September
2017, <https://www.rfc-editor.org/info/rfc8205>.
[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/info/rfc8209>.
[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/info/rfc8416>.
[RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8608,
DOI 10.17487/RFC8608, June 2019,
<https://www.rfc-editor.org/info/rfc8608>.
9.2. Informative References
[AM17] Antonakakis, M., April, T., Bailey, M., Bernhard, M.,
Bursztein, E., Cochran, J., Durumeric, Z., Halderman, J.,
Invernizzi, L., Kallitsis, M., Kumar, D., Lever, C., Ma,
Z., Mason, J., Menscher, D., Seaman, C., Sullivan, N.,
Thomas, K., and Y. Zhou, "Understanding the mirai botnet",
USENIX'17, DOI 10.5555/3241189.3241275, August 2017,
<https://dl.acm.org/doi/10.5555/3241189.3241275>.
[DB08] Donnet, B. and O. Bonaventure, "On BGP Communities",
CCR'08, DOI 10.1145/1355734.1355743, March 2008,
<https://dl.acm.org/doi/pdf/10.1145/1355734.1355743>.
[gtt] GTT, "Semantics of community values defined by AS 3257",
2023, <https://www.gtt.net/us-en/services/managed-
networking/internet/ip-transit/bgp-communities/>.
Liu, et al. Expires 30 March 2024 [Page 22]
RFC Community Origin Authentication September 2023
[GV17] Giotsas, V., Smaragdakis, G., Dietzel, C., Richter, P.,
Feldmann, A., and A. Berger, "Inferring BGP blackholing
activity in the internet", IMC'17,
DOI 10.1145/3131365.3131379, November 2017,
<https://dl.acm.org/doi/10.1145/3131365.3131379>.
[irrdatabase]
Internet Routing Registry, "IRR database", 2023,
<https://www.irr.net/>.
[onestep] One Step, "Semantics of community values defined by AS
174", 2023, <https://onestep.net/communities/as174/>.
[oracle] Oracle, "A case community values are used in hijack
attacks", 2018, <https://indigodefense.com/2018/08/08/bgp-
dns-hijacks-target-payment-systems/>.
[RFC1998] Chen, E. and T. Bates, "An Application of the BGP
Community Attribute in Multi-home Routing", RFC 1998,
DOI 10.17487/RFC1998, August 1996,
<https://www.rfc-editor.org/info/rfc1998>.
[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/info/rfc2119>.
[RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole
Filtering with Unicast Reverse Path Forwarding (uRPF)",
RFC 5635, DOI 10.17487/RFC5635, August 2009,
<https://www.rfc-editor.org/info/rfc5635>.
[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/info/rfc6480>.
[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/info/rfc6793>.
[RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods
for Generating Key Identifiers Values", RFC 7093,
DOI 10.17487/RFC7093, December 2013,
<https://www.rfc-editor.org/info/rfc7093>.
Liu, et al. Expires 30 March 2024 [Page 23]
RFC Community Origin Authentication September 2023
[RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G.
Hankins, "BLACKHOLE Community", RFC 7999,
DOI 10.17487/RFC7999, October 2016,
<https://www.rfc-editor.org/info/rfc7999>.
[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/info/rfc8174>.
[RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP
Large Communities", RFC 8195, DOI 10.17487/RFC8195, June
2017, <https://www.rfc-editor.org/info/rfc8195>.
[SF18] Streibelt, F., Lichtblau, F., Beverly, R., Feldmann, A.,
Pelsser, C., Smaragdakis, G., and R. Bush, "BGP
Communities: Even more Worms in the Routing Can", IMC'18,
DOI 10.1145/3278532.3278557, October 2018,
<https://dl.acm.org/doi/pdf/10.1145/3278532.3278557>.
Authors' Addresses
Yunhao Liu
Tsinghua University
Beijing
100084
China
Email: lyh22@mails.tsinghua.edu.cn
Jessie Hui Wang
Tsinghua University
Beijing
100084
China
Email: jessiewang@tsinghua.edu.cn
Yangyang Wang
Tsinghua University
Beijing
100084
China
Email: wangyy@cernet.edu.cn
Liu, et al. Expires 30 March 2024 [Page 24]
RFC Community Origin Authentication September 2023
Mingwei Xu
Tsinghua University
Beijing
100084
China
Email: xumw@tsinghua.edu.cn
Liu, et al. Expires 30 March 2024 [Page 25]
