BGP security

BGP is used for inter-domain routing, so it is a critical service for the Internet infrastructure. Therefore security aspect of BGP, with valid routing advertisement, is a high issue and the current system is highly vulnerable to human errors, as well as a wide range of attacks.

Filtering is currently the most used mechanism. Nevertheless complementary security features may be used to add security with BGP. Thus, in some cases MD5 authentication may be used to control BGP routing information advertisement, as described for OSPF.

BGP filtering

Two types of BGP filtering method exist:

Distribute-list

Allows filtering on prefix basis,

AS-PATH access-list

Filters all networks in relation with a particular ASN.

Configuring a BGP-4 distribute list

Once an IPv4 Access List is created, it is possible to apply this access-list to a neighbor. The number of prefixes will be modified/filtered so that the neighbor will not see the exact entries that local device sees.

Following configuration illustrates 2 devices rt1 and rt2, where rt2 is configured to apply filtering by using distribute list.

rt1

routing bgp
  router-id 10.1.1.1
  as 65510
  neighbor 10.1.1.2 remote-as 65520

rt2

 routing
 ipv4-access-list acl_name
    remark description
    deny 192.168.1.0/24
    permit any
    ..
 ..
vrf main
routing bgp
  router-id 10.1.1.2
  address-family ipv4-unicast network 192.168.1.0/24
    .. .. ..
  address-family ipv4-unicast network 192.168.2.0/24
    .. .. ..
  as 65520
  neighbor 10.1.1.1 remote-as 65510
  neighbor 10.1.1.1 address-family ipv4-unicast distribute-list out access-list acl_name
  ..
  ..
..

Consequently, 192.168.1.0/24 prefix will not be exported to rt1

rt1> show bgp ipv4 unicast
 BGP table version is 40, local router ID is 10.1.1.1, vrf id 0
 Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
                i internal, r RIB-failure, S Stale, R Removed
 Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
 Origin codes:  i - IGP, e - EGP, ? - incomplete

 Network          Next Hop            Metric LocPrf Weight Path
 *> 192.168.2.0      10.1.1.2                 0             0 65520 i

Note

The below IPv4 prefix-list should be preferred to the IPv4 access-lists.

Configuring a BGP-4 prefix list

  1. Define the prefix-list rule as per Prefix List.

  2. Apply the prefix list rule to a neighbor:

neighbor 10.125.0.3 address-family ipv4-unicast prefix-list in prefix-list-name pname

Communities Filters

The attribute community permits to group destinations in a community and apply routing decisions. It is an optional, global transitive attribute in the numerical range of 1 to 4,294,967,200. Based on the community, you can control the routing information. In BGP there are some predefined well known communities which are:

no-export

The routes of this community must not be advertised to external peer. Value is 0xFFFFFF01.

no-advertise

The routes must not be advertised to any peer. Value is 0xFFFFFF02.

internet

The routes may be advertised to any peer. Value is 0x0.

local-as

Used in confederation to avoid sending packets outside the local AS. Value is 0xFFFFFF03.

In general, BGP community has the form of AS:NN where AS is the autonomous system number, and NN is a number.

In addition to communities, BGP introduced one new kind of communities : extended communities. It extends the range of values. For instance, extended community can be used to store 4 AS byte value, while community is generally used to encode only 2 AS value. The format changed compared with community, because the serviecs are different ( for instance, L3VPN services benefit from route target extended communities).

Both communities are used to apply filtering on incoming or outgoing BGP updates. This can be done by using route-maps.

Note

To match a community or an extended community attribute it is recommended to use route-maps. In general, BGP community has the form of AS:NN where AS is the autonomous system number, and NN is a number. Conversely, BGP extended community is 6 octet wide, and has three available forms : as2B:NNNN or as4B:NN or as2B:IPv4. Where as2B and as4B respectively stand for the autonomous system 2 byte and 4 byte AS value . NN and NNNN are arbitrary value encoded with 2 and 4 byte values.

The community and extended attribute is sent to neighbors by default with the option both (standard and extended commnunity):

neighbor 10.125.0.3 address-family ipv4-unicast send-community both
  • Delete the community parameters:

    neighbor A.B.C.D address-family ipv4-unicast
    del send-community
    

The community’s or extented community’s policies are examined in the priority order for each prefix. As soon as a policy matches a prefix, the desired behaviour (permit or deny) is applied (when used in a “match community id <community name>” clause of a route-map: it’s a match/it’s not a match) and the processing stops for this prefix. There is also an implicit final deny policy in each community list that rejects any prefix that did not match any previous defined policies. A policy applies to a prefix if and only if all of its communities are set on the prefix.

More information about how to configure BGP communities lists and BGP extended communities lists can be found below.

Community list

Community list is a group of rules which permit to filter or set attributes based on different lists of community numbers.

Community list has two types. It could be either a standard community list or an expanded community list.

Standard community list defines communities attributes. Thus, it will be directly compared to BGP communities attribute in BGP updates.

On the other hand, expanded community list defines its communities attribute in a string with regular expression.

A community list is used in a match clause of a route map. To illustrate a use case, prefixes learnt from various transit providers may bring such information per prefix. It may be desirable to append its own community tag based on the incoming community tags already present. The syntax of community list usage in route-map is the following one:

routing
route-map rmap_name
seq 11 policy permit|deny
seq 11 match community id com_name exact-match true

For example, the following configuration will redistribute any prefix having at least one of the communities 22850:65101 or 22850:65102:

routing
  route-map myrmap
    seq 1
        policy permit
        match
            community id MYCLIST
            ..
  bgp
    community-list MYCLIST
      policy 1 permit 22850:65101
      policy 2 permit 22850:65102

But, the following configuration will redistribute any prefix having both communities 22850:65101 and 22850:65102:

routing
  route-map myrmap
    seq 1
        policy permit
        match
            community id MYCLIST
            ..
  bgp
    community-list MYCLIST
      policy 1 permit 22850:65101 22850:65102

It is also possible to add a new community list in the BGP update. By default, previous community list is removed. Below example attaches two communities no-peer and internet to BGP prefix matching that route-map entry.

routing
  route-map myrmap
    seq 1
        policy permit
        set
            community
                replace-by
                    no-peer
                    internet
                    ..

It may be desirable to maintain the already available community list in the BGP prefix. In that case, use the add keyword to merge both community lists:

routing
  route-map myrmap
    seq 1
        policy permit
        set
            community
                add
                    no-peer
                    internet
                    ..

Reversely, if all communities of the BGP prefix should be removed, use the none keyword to suppress the original community-list:

routing
  route-map myrmap
    seq 1
        policy permit
        set
            community
                none
                ..

Extended Community list

An extended community list is a group of rules which permit to filter or set attributes based on different lists of extended community numbers.

Extended community list has two types: standard and expanded extcommunity lists.

A standard extended community list is based on BGP extended community attribute. Two kinds of communities can be created : route-target ( RT), and site-of-origin ( SOO). The former is used to define import and export policies across the vrfs, while the latter is used to prevent routing loops between sites.

An expanded extended community list uses regular expression to match extended communities attribute in BGP updates.

An extended community list is used in a match clause of a route map. Like for community lists, extended community lists can be used for receiving prefixes from transit provider, that need to be appended with some extended communities tags accordingly. The syntax of extended community list usage in route-map is the following one:

routing
route-map rmap_name
seq 11 policy permit|deny
seq 11 match extcommunity ecom_name_1

extcommunity-list ecom_name_1 policy permit soo 65501:43
extcommunity-list ecom_name_2 policy deny rt 10.125.0.1:54

For example, the following configuration will redistribute any prefix having at least one of the extended communities soo 65501:43 or rt 10.125.0.1:54:

routing
  route-map myrmap
    seq 1
        policy permit
        match
            extcommunity MYXCLIST
            ..
  bgp
    extcommunity-list MYXCLIST
      policy 1 permit soo 65501:43
      policy 2 permit rt 10.125.0.1:54

But, the following configuration will redistribute any prefix having both extended communities soo 65501:43 and rt 10.125.0.1:54:

routing
  route-map myrmap
    seq 1
        policy permit
        match
            extcommunity MYXCLIST
            ..
  bgp
    extcommunity-list MYXCLIST
      policy 1 permit soo 65501:43 rt 10.125.0.1:54

It is also possible to add one or more extended communities in the BGP update. Previous extended community list is maintained, and both communities are merged. Below example adds two extended communities to prefixes matching that route-map.

routing
  route-map myrmap
    seq 1
        policy permit
        set
            extcommunity
                rt 65500:100
                rt 65500:200
                ..

Large community list

A large community list is similar to a community list, except that it has one more component. Large community is a group of rules which permit to filter or set attributes based on different large community numbers. Large community numbers is based on BGP large community list, defined in RFC 8092.

Communities have been presented in RFC 1997 as a variable length attribute, encoding the AS number, along with other information self to the policy of each ISP. While community atttribute was limited to a single 32 bit value, extended community was limited to 6 bytes value length. As the usage of 4-byte ASNs has been generalized, in the best case, ISPs had only 2 bytes left to encode their policy. BGP large community helps in encoding more data. It is made up of a tuple of three four octet values. The first four octet value is used for global administrator value. The two other four octet values are used for local policy.

Large Community list has two types. It could be either a standard large community list or an expanded large community list. Standard community list defines large communities attributes. Thus, it will be directly compared to BGP large communities attribute in BGP updates. On the other hand, expanded community list defines its large communities attribute in a string with regular expression.

A large community list is used in a match clause of a route map. To illustrate a use case, prefixes learnt from various transit providers may bring such information per prefix. It may be desirable to append its own large community tag based on the incoming large community tags already present.

For example, the following configuration will redistribute any prefix having at least one of the communities 65500:44444:100 or 65500:55555:200:

routing
  route-map myrmap
    seq 1
        policy permit
        match
            large-community id MYCLIST
            ..
  bgp
    large-community-list MYCLIST
      policy 1 permit 65500:44444:100
      policy 2 permit 65500:55555:200

But, the following configuration will redistribute any prefix having both communities 65500:44444:100 and 65500:55555:200:

routing
  route-map myrmap
    seq 1
        policy permit
        match
            large-community id MYCLIST
            ..
  bgp
    large-community-list MYCLIST
      policy 1 permit 65500:44444:100 65500:55555:200

It is also possible to add a new large community list in the BGP update. By default, previous large community list is removed. Below example creates two new large communities in the matching BGP updates:

routing
  route-map myrmap
    seq 1
        policy permit
        set
            large-community
                replace-by
                    65500:66666:300
                    65500:77777:400
                    ..

It may be desirable to not replace the already available large community list. In that case, use the add keyword to merge both large community lists:

routing
  route-map myrmap
    seq 1
        policy permit
        set
            large-community
                add
                    65500:66666:300
                    65500:77777:400
                    ..

Reversely, if all large communities of the BGP prefix should be removed, use the none keyword to suppress the original large community-list:

routing
  route-map myrmap
    seq 1
        policy permit
        set
            large-community
                none
                ..

BGP Authentication

BGP authentication is using MD5. This feature relies on the Operating System support for the TCP MD5 signature option as proposed in the RFC 2385. This OS option is used with the BSD-like configuration API.

The command format for BGP MD5 is as follows:

vrf main
   routing bgp
      neighbor 10.125.0.1 password my-secret

For information, when analyzing the BGP packets with the sniffer traffic-capture, it is possible to verify that the option is taken into account.