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
BGP Authentication

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 ¶

Define the prefix-list rule as per Prefix List.
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.

The syntax of community list is:

routing bgp
  community-list NAME
    policy PRIORITY permit|deny attr1[ attr2[ ...]]

NAME: The community’s name.
PRIORITY: The policy priority. Lesser is the value, greater is the priority.
attr1[ attr2[ …]]: Community attribute(s): can take either value under format AA:BB, where AA and BB are (0-65535), or can take one of the following keywords: local-AS, no-advertise, no-export, internet.

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

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.

An extended community list is used in a match clause of a route map. An 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.

The syntax of extended community list is:

routing bgp
  extcommunity-list NAME
    policy PRIORITY permit|deny soo|rt attr1[ soo|rt attr2[ ...]]

NAME: The community’s name.
PRIORITY: The policy priority. Lesser is the value, greater is the priority.
soo|rt attr1[ soo|rt attr2[ …]]: Extended community attribute(s) in the format: soo|rt AS2B:BBBB|AS4B:BB|AS2B:IP, where AS2B and `AS4B respectively stand for the AS 2 byte and AS 4 byte value. BBBB and BB stand for a 4 and 2 byte value, while IP stands for an IPv4 address. rt stands for the Route Target extended community.

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

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 show-traffic, it is possible to verify that the option is taken into account.

BGP security¶

BGP filtering¶

Configuring a BGP-4 distribute list¶

Configuring a BGP-4 prefix list¶

Communities Filters¶