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]