Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Examples: Configuring TCP and BGP Security

 

Understanding Security Options for BGP with TCP

Among routing protocols, BGP is unique in using TCP as its transport protocol. BGP peers are established by manual configuration between routing devices to create a TCP session on port 179. A BGP-enabled device periodically sends keepalive messages to maintain the connection.

Over time, BGP has become the dominant interdomain routing protocol on the Internet. However, it has limited guarantees of stability and security. Configuring security options for BGP must balance suitable security measures with acceptable costs. No one method has emerged as superior to other methods. Each network administrator must configure security measures that meet the needs of the network being used.

For detailed information about the security issues associated with BGP’s use of TCP as a transport protocol, see RFC 4272, BGP Security Vulnerabilities Analysis.

Example: Configuring a Filter to Block TCP Access to a Port Except from Specified BGP Peers

This example shows how to configure a standard stateless firewall filter that blocks all TCP connection attempts to port 179 from all requesters except from specified BGP peers.

Requirements

No special configuration beyond device initialization is required before you configure this example.

Overview

In this example, you create a stateless firewall filter that blocks all TCP connection attempts to port 179 from all requesters except the specified BGP peers.

The stateless firewall filter filter_bgp179 matches all packets from the directly connected interfaces on Device A and Device B to the destination port number 179.

Figure 1 shows the topology used in this example. Device C attempts to make a TCP connection to Device E. Device E blocks the connection attempt. This example shows the configuration on Device E.

Figure 1: Typical Network with BGP Peer Sessions
Typical Network with BGP Peer
Sessions

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device C

Device E

Configuring Device E

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device E with a stateless firewall filter that blocks all TCP connection attempts to port 179 from all requestors except specified BGP peers:

  1. Configure the interfaces.
  2. Configure BGP.
  3. Configure the autonomous system number.
  4. Define the filter term that accepts TCP connection attempts to port 179 from the specified BGP peers.

  5. Define the other filter term to reject packets from other sources.

  6. Apply the firewall filter to the loopback interface.

Results

From configuration mode, confirm your configuration by entering the show firewall, show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying That the Filter Is Configured

Purpose

Make sure that the filter is listed in output of the show firewall filter command.

Action

user@E> show firewall filter filter_bgp179

Verifying the TCP Connections

Purpose

Verify the TCP connections.

Action

From operational mode, run the show system connections extensive command on Device C and Device E.

The output on Device C shows the attempt to establish a TCP connection. The output on Device E shows that connections are established with Device A and Device B only.

user@C> show system connections extensive | match 10.10.10
user@E> show system connections extensive | match 10.10.10

Monitoring Traffic on the Interfaces

Purpose

Use the monitor traffic command to compare the traffic on an interface that establishes a TCP connection with the traffic on an interface that does not establish a TCP connection.

Action

From operational mode, run the monitor traffic command on the Device E interface to Device B and on the Device E interface to Device C. The following sample output verifies that in the first example, acknowledgment (ack) messages are received. In the second example, ack messages are not received.

user@E> monitor traffic size 1500 interface ge-1/2/1.5
user@E> monitor traffic size 1500 interface ge-1/0/0.9

Example: Configuring a Filter to Limit TCP Access to a Port Based On a Prefix List

This example shows how to configure a standard stateless firewall filter that limits certain TCP and Internet Control Message Protocol (ICMP) traffic destined for the Routing Engine by specifying a list of prefix sources that contain allowed BGP peers.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

In this example, you create a stateless firewall filter that blocks all TCP connection attempts to port 179 from all requesters except BGP peers that have a specified prefix.

A source prefix list, plist_bgp179, is created that specifies the list of source prefixes that contain allowed BGP peers.

The stateless firewall filter filter_bgp179 matches all packets from the source prefix list plist_bgp179 to the destination port number 179.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Configure the Filter

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure the filter:

  1. Expand the prefix list bgp179 to include all prefixes pointed to by the BGP peer group defined by protocols bgp group <*> neighbor <*>.

  2. Define the filter term that rejects TCP connection attempts to port 179 from all requesters except the specified BGP peers.

  3. Define the other filter term to accept all packets.

  4. Apply the firewall filter to the loopback interface.

Results

From configuration mode, confirm your configuration by entering the show firewall, show interfaces, and show policy-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Displaying the Firewall Filter Applied to the Loopback Interface

Purpose

Verify that the firewall filter filter_bgp179 is applied to the IPv4 input traffic at logical interface lo0.0.

Action

Use the show interfaces statistics operational mode command for logical interface lo0.0, and include the detail option. Under the Protocol inet section of the command output section, the Input Filters field displays the name of the stateless firewall filter applied to the logical interface in the input direction.

[edit]
user@host> show interfaces statistics lo0.0 detail

Example: Limiting TCP Segment Size for BGP

This example shows how to avoid Internet Control Message Protocol (ICMP) vulnerability issues by limiting TCP segment size when you are using maximum transmission unit (MTU) discovery. Using MTU discovery on TCP paths is one method of avoiding BGP packet fragmentation.

Requirements

No special configuration beyond device initialization is required before you configure this example.

Overview

TCP negotiates a maximum segment size (MSS) value during session connection establishment between two peers. The MSS value negotiated is primarily based on the maximum transmission unit (MTU) of the interfaces to which the communicating peers are directly connected. However, due to variations in link MTU on the path taken by the TCP packets, some packets in the network that are well within the MSS value might be fragmented when the packet size exceeds the link's MTU.

To configure the TCP MSS value, include the tcp-mss statement with a segment size from 1 through 4096.

If the router receives a TCP packet with the SYN bit and the MSS option set, and the MSS option specified in the packet is larger than the MSS value specified by the tcp-mss statement, the router replaces the MSS value in the packet with the lower value specified by the tcp-mss statement.

The configured MSS value is used as the maximum segment size for the sender. The assumption is that the TCP MSS value used by the sender to communicate with the BGP neighbor is the same as the TCP MSS value that the sender can accept from the BGP neighbor. If the MSS value from the BGP neighbor is less than the MSS value configured, the MSS value from the BGP neighbor is used as the maximum segment size for the sender.

This feature is supported with TCP over IPv4 and TCP over IPv6.

Topology Diagram

Figure 2 shows the topology used in this example.

Figure 2: TCP Maximum Segment Size for BGP
TCP Maximum Segment Size for BGP

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

R0

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router R0:

  1. Configure the interfaces.
  2. Configure an interior gateway protocol (IGP), OSPF in this example.
  3. Configure one or more BGP groups.
  4. Configure MTU discovery to prevent packet fragmentation.
  5. Configure the BGP neighbors, with the TCP MSS set globally for the group or specifically for the various neighbors.
    Note

    The TCP MSS neighbor setting overrides the group setting.

  6. Configure the local autonomous system.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, run the following commands:

  • show system connections extensive | find <neighbor-address>, to check the negotiated TCP MSS value.

  • monitor traffic interface, to monitor BGP traffic and to make sure that the configured TCP MSS value is used as the MSS option in the TCP SYN packet.

Troubleshooting

MSS Calculation with MTU Discovery

Problem

Consider an example in which two routing devices (R1 and R2) have an internal BGP (IBGP) connection. On both of the routers, the connected interfaces have 4034 as the IPv4 MTU.

user@R1# show protocols bgp | display set
user@R1# run show interfaces xe-0/0/3 extensive | match mtu

In the following packet capture on Device R1, the negotiated MSS is 3994. In the show system connections extensive information for MSS, it is set to 2048.

user@R1# run show system connections extensive | find 45.45

Solution

This is expected behavior with Junos OS. The MSS value is equal to the MTU value minus the IP or IPv6 and TCP headers. This means that the MSS value is generally 40 bytes less than the MTU (for IPv4) and 60 bytes less than the MTU (for IPv6). This value is negotiated between the peers. In this example, it is 4034 - 40 = 3994. Junos OS then rounds this value to a multiple of 2 KB. The value is 3994 / 2048 * 2048=2048. So it is not necessary to see same MSS value with in the show system connections output.

3994 / 2048 = 1.95

1.95 is rounded to 1.

1 * 2048 = 2048