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
rt1 running config# / vrf main routing bgp as 65510
rt1 running config# / vrf main routing bgp router-id 10.1.1.1
rt1 running config# / vrf main routing bgp ebgp-requires-policy false
rt1 running config# / vrf main routing bgp neighbor 10.1.1.2 remote-as 65520
rt1 running config# / vrf main routing bgp address-family ipv4-unicast redistribute connected
rt1 running config# / vrf main interface physical eth1 port pci-b0s4
rt1 running config# / vrf main interface physical eth1 ipv4 address 10.1.1.1/24
rt2
rt2 running config# / routing ipv4-access-list ACCESS_LIST remark description
rt2 running config# / routing ipv4-access-list ACCESS_LIST seq 1 deny 192.168.1.0/24
rt2 running config# / routing ipv4-access-list ACCESS_LIST seq 2 permit any
rt2 running config# / vrf main routing bgp as 65520
rt2 running config# / vrf main routing bgp router-id 10.1.1.2
rt2 running config# / vrf main routing bgp ebgp-requires-policy false
rt2 running config# / vrf main routing bgp network-import-check false
rt2 running config# / vrf main routing bgp address-family ipv4-unicast network 192.168.1.0/24
rt2 running network 192.168.1.0/24# / vrf main routing bgp address-family ipv4-unicast network 192.168.2.0/24
rt2 running network 192.168.2.0/24# / vrf main routing bgp neighbor 10.1.1.1 remote-as 65510
rt2 running network 192.168.2.0/24# / vrf main routing bgp neighbor 10.1.1.1 address-family ipv4-unicast distribute-list out access-list ACCESS_LIST
rt2 running network 192.168.2.0/24# / vrf main interface physical eth1 port pci-b0s4
rt2 running network 192.168.2.0/24# / vrf main interface physical eth1 ipv4 address 10.1.1.2/24
Consequently, 192.168.1.0/24 prefix will not be exported to rt1
rt1> show bgp ipv4 unicast
BGP table version is 2, local router ID is 10.1.1.1, vrf id 0
Default local pref 100, local AS 65510
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
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 0.0.0.0 0 32768 ?
*> 192.168.2.0/24 10.1.1.2 0 0 65520 i
Displayed 2 routes and 2 total paths
Note
The below IPv4 prefix-list should be preferred to the IPv4 access-lists.
Configuring a BGP-4 prefix list¶
The following configuration illustrates 2 devices rt1 and rt2, where rt2 is configured to apply filtering by using a prefix list.
rt1
rt1 running config# / vrf main routing bgp as 65510
rt1 running config# / vrf main routing bgp router-id 10.1.1.1
rt1 running config# / vrf main routing bgp ebgp-requires-policy false
rt1 running config# / vrf main routing bgp neighbor 10.1.1.2 remote-as 65520
rt1 running config# / vrf main routing bgp address-family ipv4-unicast redistribute connected
rt1 running config# / vrf main interface physical eth1 port pci-b0s4
rt1 running config# / vrf main interface physical eth1 ipv4 address 10.1.1.1/24
rt2
rt2 running config# / routing ipv4-prefix-list PREFIX_LIST seq 1 policy permit address 192.168.1.0/24
rt2 running config# / vrf main routing bgp as 65520
rt2 running config# / vrf main routing bgp router-id 10.1.1.2
rt2 running config# / vrf main routing bgp ebgp-requires-policy false
rt2 running config# / vrf main routing bgp network-import-check false
rt2 running config# / vrf main routing bgp address-family ipv4-unicast network 192.168.1.0/24
rt2 running network 192.168.1.0/24# / vrf main routing bgp address-family ipv4-unicast network 192.168.2.0/24
rt2 running network 192.168.2.0/24# / vrf main routing bgp neighbor 10.1.1.1 remote-as 65510
rt2 running network 192.168.2.0/24# / vrf main routing bgp neighbor 10.1.1.1 address-family ipv4-unicast prefix-list out prefix-list-name PREFIX_LIST
rt2 running network 192.168.2.0/24# / vrf main interface physical eth1 port pci-b0s4
rt2 running network 192.168.2.0/24# / vrf main interface physical eth1 ipv4 address 10.1.1.2/24
As a result, the 192.168.2.0/24 prefix will not be exported to rt1.
rt1> show bgp ipv4 unicast
BGP table version is 2, local router ID is 10.1.1.1, vrf id 0
Default local pref 100, local AS 65510
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
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 0.0.0.0 0 32768 ?
*> 192.168.1.0/24 10.1.1.2 0 0 65520 i
Displayed 2 routes and 2 total paths
Note
More information can be found in the Prefix List chapter.
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:
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 match community id COMMUNITY
vsr running config# / routing bgp community-list COMMUNITY policy 1 permit 22850:65101
vsr running config# / routing bgp community-list COMMUNITY policy 2 permit 22850:65102
But, the following configuration will redistribute any prefix having both
communities 22850:65101 and 22850:65102:
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 match community id COMMUNITY
vsr running config# / routing bgp community-list COMMUNITY 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.
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 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:
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 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:
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 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:
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 match extcommunity EXTCOMMUNITY
vsr running config# / routing bgp extcommunity-list EXTCOMMUNITY policy 1 permit soo 65501:43
vsr running config# / routing bgp extcommunity-list EXTCOMMUNITY 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:
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 match extcommunity EXTCOMMUNITY
vsr running config# / routing bgp extcommunity-list EXTCOMMUNITY 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.
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 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:
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 match large-community id LARGECOMMUNITY
vsr running config# / routing bgp large-community-list LARGECOMMUNITY policy 1 permit 65500:44444:100
vsr running config# / routing bgp large-community-list LARGECOMMUNITY policy 2 permit 65500:55555:200
But, the following configuration will redistribute any prefix having both
communities 65500:44444:100 and 65500:55555:200:
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 match large-community id LARGECOMMUNITY
vsr running config# / routing bgp large-community-list LARGECOMMUNITY 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:
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 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:
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 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:
vsr running config# / routing route-map ROUTEMAP seq 1 policy permit
vsr running config# / routing route-map ROUTEMAP seq 1 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.