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¶
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.
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
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
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.