Transcription

2 Contents Introduction Introduction... 2 Assumptions... 3 Topology... 4 Routing Options [edit routing-options]... 5 AS Number... 5 Static Routes... 5 Black Hole Routes... 6 Martians Prefixes... 8 Load Balancing BGP Options [edit protocols bgp] Tracing Logging Route Damping Private-AS Filtering Prefix Limiting Peer Authentication Policy Options [edit policy-options] Inbound Prefixes Outbound Prefixes Special Prefixes Firewall Filtering [edit firewall] BGP Connections Conclusion References BGP is the glue that holds the Internet together. It is a robust protocol whose primary purpose is to distribute routing information between peering points pertaining to every public internetwork in a seamless fashion. Indubitably, inherent in BGP is a great responsibility, but also a great potential for disaster. This misfortune can be caused by inadvertent misconfiguration or deliberate misuse. Consequently, it is crucial that BGP administrators take extra care in fully securing their peering routers. Not hardening BGP configurations could prove very detrimental to one's local network, or even worse, proving harmful to the rest of the Internet community. It is quite common to encounter the following BGP related problems on the Internet on a regular basis: - unaggregated prefixes - invalid prefixes qorbit Technologies 2

3 - excessive prefixes - duplicate prefixes - accidental prefixes - flapping prefixes - unnecessary prefixes This paper describes several preventative measures within Juniper routers that can be taken to decrease the problems mentioned above. No configuration is foolproof, but several suggestions are presented that can reduce the security exposure of Juniper peering routers. Two Juniper security templates have previously been published by the author designed to guide the administrator through the process of securing his or her Juniper router. This document further bridges the Juniper documentation gap and fleshes the JUNOS Secure BGP Template into more detailed verbiage. Both security templates are available for download here: JUNOS Secure Template [1] /documents/junos-template.pdf JUNOS Secure BGP Template [2] /documents/junos-bgp-template.pdf The Juniper router templates were originally based on two Cisco security templates written by Robert Thomas. Both of them can be downloaded from his website at the following URLs: Cisco Secure Template [4] Cisco Secure BGP Template [5] Assumptions A few assumptions worth noting are made by this document. Firstly, we assume the reader has a basic understanding of the BGP protocol and a working knowledge of Juniper Routers. The JUNOS documentation set can be found at Please consult the Juniper documentation for further information on configuring Juniper Routers and BGP. Secondly we assume that the configurations presented in this document are representative of the test topology below and that individual network qorbit Technologies 3

4 policies may warrant modifications to the recommendations described herein. Finally, we also assume that the routers in question are running JUNOS version 4.3 or above. Topology Before delving into the details of our recommended BGP security measures, we present a topology diagram on which the configuration details are based. Figure 1 - Juniper BGP Topology Figure 1 pictures three autonomous systems and four distinct Juniper routers. Two routers in AS 111 each contain one EBGP link to AS 222 and to AS 333 over which they announce the aggregate prefix, /29. Furthermore, they maintain an IBGP session between each other. Relevant IP addresses have been included in the diagram for clarity, and are described below: , AS 222 external IP , AS 333 external IP , AS 111 secure-router-01 loopback , AS 111 secure-router-02 loopback , AS 111 secure-router-02 internal IP , internal IP next-hop not shown in topology , same as the above , same as the above. qorbit Technologies 4

5 The configurations presented in this document were written from the perspective of secure-router-01. They are also listed in function style formatting rather than set style formatting for better readability. Issuing the commands on a router would require appending the word set to the beginning of each statement, or using the CLI command load merge term for the function style configurations. We leave porting these configurations from the included examples to the neighboring routers as an exercise for the reader. This document is divided into four major sections, including: - Routing Options - BGP Options - Policy Options - Firewall Filtering All sections represent a major level in the JUNOS configuration tree; each is interspersed with basic commands to assist in network verification and troubleshooting. Routing Options [edit routing-options] Basic routing settings such as static routes, aggregate routes, martian routes, load balancing options, and the local AS number are configured at the [edit routing-options] level. AS Number BGP needs a local AS number to advertise to its peers. The AS number of the local router is configured as follows: [edit routing-options] /* Our AS Number */ autonomous-system 111; Static Routes Next, static routes can be used to create aggregates and more specific routes. The aggregate protocol can achieve the same results as a static discard route, but here we chose to stick with a static to announce our prefix of /19. To override the discard route, more specific routes are needed in the local routing table. Loss of connectivity to any of these contributing routes will not carry into external advertisements. This has the added benefit of increasing stability of the global routing table by not changing reachability information to the aggregate prefix. JUNOS will always prefer more specific routes, therefore when packets arrive at the local router they will be forwarded to the appropriate location, assuming it is reachable, rather than being blackholed. qorbit Technologies 5

6 [edit routing-options] static { /* This is our aggregate static route */ route /19 discard; /* More specific routes used with discard route above. Remove if using an IGP to discover internal routes. */ route /24 next-hop ; route /24 next-hop ; route /25 next-hop ; /* Route to loopback of our ibgp peer */ route /32 next-hop ; Three static routes are used to direct the local traffic towards its final destination. Notice that packets that fall within the scope of the aggregate prefix (/19) but not within the specifics (/24, /24, /25) will be discarded until further specific routes are added to the local routing table. The last static route listed is used to point to the loopback address of our IBGP peer. This is necessary because we typically peer with loopback addresses for increased IBGP resilience. In our sample topology there is only one path to our IBGP peer, but in the real world there might be several paths to an internal peer. An IGP such as OSPF or IS-IS would usually be used to learn the best path to an internal peer. Peering with a loopback address allows the IGP path to change without affecting the BGP peering session assuming another route exists to the destination. DNS resolution is not usually necessary on a router. As such, it can be disabled thusly: [edit routing-options] options { /* Turn off DNS resolution */ no-resolve; Black Hole Routes Similar to our discard aggregate, below we list a series of routes that should never be seen on the Internet. Whether packets are traveling outbound or inbound, traffic destined to these networks will be dropped if they reach the local router. All of the routes are divided into /8 prefixes for administrative purposes since IANA allocations may change over time. For an aggregated list, please consult the bogon list at: If your network does not contain a 0/0 default route and contains the entire Internet routing table, the static discard routes below are not necessary. Instead, the martian addresses should be replaced with the orlonger keyword which will disallow these networks from entering the routing table. qorbit Technologies 6

11 The prefix /24 listed in Bill Manning s draft [7] used for RFC nameservers has not been included because they are used to reduce the load of the root nameservers for those who do not comply with RFC Once again, Multicast and RFC1918 address ranges have been include in the list above and may need to be removed if your network configuration requires these. Load Balancing When multiple equal cost paths exist to a destination, JUNOS has the capability of performing load balancing to split the load across multiple paths. Routers that have an IP2 ASIC can perform per flow load balancing on up to 16 equal cost paths. Routers that have an IP1 ASIC can perform per packet load balancing also on up to 8 equal cost paths. On older M40 routers that contain the IP1 ASIC load balancing is not generally recommended for interactive traffic. Per-packet load balancing is not enabled by default; however per-prefix load balancing is. For a given destination prefix, a random next-hop address will be selected and placed in the forwarding table. The greater the number of prefixes, the better the load distribution will be across different next-hops. To install multiple next-hops into the FIB you should enable flow-based per-packet load balancing. This is done by creating a simple load balancing policy and applying it to the forwarding table. The forwarding table should point to a policy that enables load balancing with an export statement like so: [edit routing-options] /* Export the policy to turn on flow based load balancing */ forwarding-table { export load-balancing; The load balancing policy is created under the [edit policy-options] hierarchy as follows: [edit policy-options] /* Policy to configure load balancing. */ policy-statement load-balancing { then { load-balance per-packet; The per-packet directive is somewhat of a misnomer because it actually performs flow based load balancing on the IP2 ASIC. qorbit Technologies 11

13 Route Damping Route damping is a mechanism for BGP enabled routers aimed at improving the overall stability of the Internet routing table and offloading routers' CPUs. Unstable routes may have a profound effect on the interdomain routing table; in many cases if the oscillation of a flapping route is small enough, it is considered good practice to withdraw the advertisement until it has stabilized. A well known publication by the RIPE organization known as RIPE-229 [6], provides excellent guidelines and watermarks on which to base these parameters. The premise of the parameters defined in the RIPE publication is simple: the degree of restrictions placed on prefixes should increase according to length. The only exceptions are the netblocks that pertain to the root name servers. Since DNS resolution is at the heart of how the Internet functions, and since humans are not in the regular practice of memorizing IP addresses, these netblocks should always be announced whether they oscillate or not. RIPE-229 supercedes RIPE-210, a previous publication that neglected to stay up-to-date with the changes in DNS netblock allocations. Before the golden networks in RIPE-229 were introduced, a publication entitled RIPE-210 Addendum [3] was released by the author aimed at educating the administrator on how to stay current with these special allocations. Still the golden networks website neglects to stay up-to-date with listed prefixes and doesn t include all of the top level domains. Rather, a more accurate and complete list can be found at qorbit.net [9]. BGP route damping can be enabled globally on a Juniper Router like so: [edit protocols bgp] damping; If the administrator were to leave BGP damping enabled with the default settings, he or she would be neglecting to perform two important functions, namely graded flap damping, and golden network exclusion. A more robust configuration would take the RIPE-229 publication seriously and would employ a policy to bypass key prefixes while performing measured damping based on prefix length. JUNOS penalizes on route withdrawal and on readvertisement. One route flap attracts a total penalty of 2000 ( ) while an attribute change attracts a penalty of 500. The penalty is known as the figure of merit. The damping policy below should be used whenever possible: [edit policy-options] policy-statement damping { qorbit Technologies 13

15 /* Min: 15 min, Max: 45 min, dampen at 3 flaps */ damping damp-medium { half-life 15; reuse 1500; suppress 6000; max-suppress 45; /* Min: 10 min, Max: 30 min, dampen at 3 flaps */ damping damp-short { half-life 10; reuse 3000; suppress 6000; max-suppress 30; /* Do not dampen. Referenced for DNS root-servers */ damping damp-none { disable; The half-life is an exponential decay algorithm that applies to the figure of merit value. The reuse threshold specifies at what value the route will be used again while the suppress value specifies at what point a route should start to be suppressed. Finally, the max-suppress statement delineates the maximum amount of time that a route can be suppressed. Once the policy is fully configured, it should be applied to external BGP peers as an import policy. The import policy chain to enable BGP damping for EBGP peers is listed in the [edit policy-options] section later in this paper. To view route damping statistics, one can use the show route damping [decayed suppressed history] command. A quick summary of the number of routes that are damped per peer can be seen in the show bgp summary command output. Private-AS Filtering JUNOS does not remove private AS numbers from AS Path advertisements by default. Private AS numbers subsist in the range and are reserved for local use only. Private AS numbers should not be seen on the public Internet. To keep private AS numbers from leaking out, use the following syntax: [edit protocols bgp] /* Keep private AS numbers from leaking out */ remove-private; Prefix Limiting The size of the Internet routing table varies daily and is constantly increasing. This rate of change and slow growth can be used to the administrator s advantage by hard coding the number of prefixes that are qorbit Technologies 15

16 expected from a BGP peer. If the number of routes received exceeds a known threshold, it is quite likely that there has been a misconfiguration on the other end allowing more than the standard prefixes to be advertised. Prefix limiting is the ability to place an upper bound on the number of prefixes received from a neighbor in order to guard against accidents caused by peers. Peers that exceed this threshold are logged and shut down. The two primary benefits of prefix limiting include memory conservation and protection from invalid route propagation. If this feature is to be used, the administrator must take into account the current size of the routing table and keep a close watch on these watermarks. One way of staying up-to-date is to receive the bgp-stats report by subscribing to with the statement subscribe bgp-stats" in the message body. Prefix limits can be applied at the neighbor level or group level. Here we configure them globally like so: [edit protocols bgp] family inet { any { prefix-limit { /* Tear down connection when routes reach maximum. */ maximum ; /* Issue warning messages at teardown percent */ teardown 90; Notice that we have asked the router to begin issuing warning messages when the number of prefixes received is at 90% of the threshold. When the number of prefixes reaches the connection will be torn down, and will stay down awaiting manual intervention. Peer Authentication BGP peer authentication adds an additional layer of protection against external forgery by requiring a deeper trust relationship among peers through the HMAC-MD5 algorithm. It is strongly recommended that routing protocols employ the use of authentication whenever possible. HMAC-MD5 computes a hash from a local secret key and the data being transmitted. The same hash is computed on both sides with the transmitted data and compared against what is received for message validation. Messages received that do not match the local hash are discarded. qorbit Technologies 16

17 The example below shows the configuration of a group-level authentication key for all peers in AS 111 in this case there is only one, BGP authentication can also be configured globally or at the individual neighbor levels. The relevant BGP configuration statement has been printed in bold below: [edit protocols bgp] /* ibgp peer-group with AS 111. Peer-groups save typing and CPU cycles when multiple neighbors exist with same policy */ group ibgp_111 { /* No longer needed in newer versions if JUNOS. */ type internal; description "ibgp with AS 111"; /* Set my address to that of lo0 */ local-address ; authentication-key bgpwith111; /* Set next-hop-self for ebgp routes sent to our ibgp peer */ export next-hop-self; /* The following is assumed if not entered */ peer-as 111; /* Loopback address of our internal peer */ neighbor ; Policy Options [edit policy-options] Policy statements are created within the [edit policy-options] hierarchy. They are used to control routing behavior such as filtering and setting specific attributes on routes. Inbound Prefixes To control what we will do with all routes received from our BGP peers we create several policies, each with their own specific purpose. First we need a policy that will reject all bogon routes. Since we have already created a list of martians, this list only consists of the multicast range 224/4. Notice that we did not include /24 in the martian list because some IGPs such as OSPF use multicast to communicate routing information. [edit policy-options] policy-statement nobogons { from route-filter /4 orlonger reject; We also create a filter to reject all advertisements that contain a private AS number anywhere in the AS Path. Do not use this filter for peering sessions that require the use of private AS numbers. [edit policy-options] policy-statement noprivateasns { from as-path private; then reject; qorbit Technologies 17

18 as-path private.* ( ).* ; Next, we create a policy that drops all prefixes larger than a /27. Individual BGP policies may vary on the size of prefixes accepted into BGP. Here we have chosen to be fairly lax: policy-statement nosmallprefixes { from route-filter /0 prefix-length-range /27-/32 reject; Finally, we create a policy used for our IBGP peers that sets the next-hop address in the BGP advertisement to the IP address of the local router instead of carrying the EBGP next-hop information into IBGP. Be very careful when using route-reflectors not to blindly apply this policy to IBGP route-reflector peer-groups. Otherwise, unintended routing loops may occur when client routes are reflected to others. /* Set next-hop to self. */ policy-statement next-hop-self { then { next-hop self; Each of the policies can in turn be applied consecutively to our BGP peers in a chain-like fashion. Our policies were designed with this thought in mind by not issuing a accept or reject statements for the catchall rules. For our EBGP peers we use a chain of four policy statements to filter out all bogons, to remove private ASN and all small prefix advertisements, and to dampen routes. The relevant BGP configuration statement has been highlighted below: [edit protocols bgp] /* ebgp peer-group with AS 222 */ group ebgp_222 { /* No longer needed in newer versions if JUNOS. */ type external; description "ebgp with AS 222"; authentication-key bgpwith222; /* Remove bogons, set damping, and remove small prefixes */ import [ nobogons nosmallprefixes noprivateasns damping ]; /* Only announce our netblock */ export announce; peer-as 222; multipath; neighbor ; To view the prefixes that have been received from a neighbor, or ADJ- RIB-IN, use the show route receive-protocol bgp <neighbor> command. qorbit Technologies 18

19 One configuration option which the reader might not yet be familiar with is the multipath statement used above. Multipath enables the selection of multiple non-multi-hop EBGP or IBGP paths as active paths. To view the BGP prefixes that have made it into the routing table, or LOC- RIB, use the show route protocol bgp command. Outbound Prefixes To control what we will do with all routes sent to our EBGP peers we create one policy that will only accept our aggregate prefix. Since the topology in this paper is not a transit AS, we do not want to announce reachability to other Internet destinations through our network. Announcing only our prefix to our EBGP peers allows us to be the sole users of our network pipes. [edit policy-options] /* Match what we configured as our static aggregate netblock */ policy-statement announce { term 1 { from { protocol static; route-filter /19 exact; then accept; then reject; The announce policy-statement must be applied to peers in AS 222 and AS 333. Since we have previously shown the configuration for peers in AS 222, we include the peer-group for AS 333 below with the export policy highlighted in bold: /* ebgp peer-group with AS 333 */ group ebgp_333 { type external; description "ebgp with AS 333"; authentication-key bgpwith333; import [ nobogons nosmallprefixes noprivateasns damping ]; export announce; peer-as 333; multipath; neighbor ; To view the prefixes that will be sent to a neighbor, or ADJ-RIB-OUT, issue the show route advertising-protocol bgp <neighbor> command. qorbit Technologies 19

Tutorial: Options for Blackhole and Discard Routing Joseph M. Soricelli Wayne Gustavus NANOG 32, Reston, Virginia Caveats and Assumptions The views presented here are those of the authors and they do not

Cisco To Juniper Thomas Mangin Exa Networks LINX 51 Scope This presentation is not about : Juniper vs Cisco A line per line conversion analysis It is about Giving you an overview how hard/easy integrating

Border Gateway Protocol Exterior routing protocols created to: control the expansion of routing tables provide a structured view of the Internet by segregating routing domains into separate administrations

Chapter 33 BGP Configuration Guidelines To configure the Border Gateway Protocol (BGP), you can include the following statements. Three portions of the bgp statement those in which you configure global

Module 12 Multihoming to the Same ISP Objective: To investigate various methods for multihoming onto the same upstream s backbone Prerequisites: Module 11 and Multihoming Presentation The following will

Worldwide Education Services 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408-745-2000 www.juniper.net This document is produced by Juniper Networks, Inc. This document or any part thereof may not

Configuring BGP This chapter describes how to configure Border Gateway Protocol (BGP). For a complete description of the BGP commands in this chapter, refer to the BGP s chapter of the Network Protocols

BGP conﬁguration best practices Document produced by ANSSI (French National Security Agency of Information Systems), in collaboration with the following operators: Association Kazar ; France-IX ; Jaguar

JNCIE Juniper Networks Certified Internet Expert Study Guide - Chapter 1 by Harry Reynolds This book was originally developed by Juniper Networks Inc. in conjunction with Sybex Inc. It is being offered

Transitioning to BGP ISP Workshops Last updated 24 April 2013 1 Scaling the network How to get out of carrying all prefixes in IGP 2 Why use BGP rather than IGP? p IGP has Limitations: n The more routing

Module 7 Routing and Congestion Control Lesson 4 Border Gateway Protocol (BGP) Specific Instructional Objectives On completion of this lesson, the students will be able to: Explain the operation of the

basic BGP in Huawei CLI BGP stands for Border Gateway Protocol. It is widely used among Internet Service Providers to make core routing decisions on the Internet. The current BGP version is BGP-4 defined

BGP Scaling Techniques Philip Smith E2 Workshop, AfNOG 2006 BGP Scaling Techniques How to scale ibgp mesh beyond a few peers? How to implement new policy without causing flaps and route churning? How to

BGP Support for IP Prefix Import from Global Table into a VRF Table The BGP Support for IP Prefix Import from Global Table into a VRF Table feature introduces the capability to import IPv4 unicast prefixes

BGP4 Case Studies/Tutorial Sam Halabi-cisco Systems The purpose of this paper is to introduce the reader to the latest in BGP4 terminology and design issues. It is targeted to the novice as well as the

Mikrotik Routing Static Dynamic Routing To Be Discussed RIP Quick Discussion OSPF BGP What is Routing Wikipedia has a very lengthy explanation http://en.wikipedia.org/wiki/routing In the context of this

Border Gateway Protocol Best Practices By Clifton Funakura The Internet has grown into a worldwide network supporting a wide range of business applications. Many companies depend on the Internet for day-to-day

Lab 3-1: JIR Lab Guide Load Balancing and Filter-Based Forwarding In this activity, you will complete the following objectives. Part 1: Configure load balancing. Part 2: Configure filter based forwarding.

The feature is enabled by default when a supporting Cisco software image is installed. BGP next-hop address tracking is event driven. BGP prefixes are automatically tracked as peering sessions are established.

This module contains information about Cisco Express Forwarding and describes the tasks for configuring a load-balancing scheme for Cisco Express Forwarding traffic. Load-balancing allows you to optimize

Worldwide Education Services 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA 408-745-2000 www.juniper.net This document is produced by Juniper Networks, Inc. This document or any part thereof may not