Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

TCP

Many applications and services use TCP to communicate. Configure TCP options to improve link quality and security.

Security for TCP Headers with SYN and FIN Flags Set

By default, your device accepts packets that have both the SYN and FIN bits set in the TCP flag. Configure your device to drop packets with both the SYN and FIN bits set to reduce security vulnerabilities.

Both the SYN and FIN control flags are not normally set in the same TCP segment header. The SYN flag synchronizes sequence numbers to initiate a TCP connection. The FIN flag indicates the end of data transmission to finish a TCP connection. Their purposes are mutually exclusive. A TCP header with the SYN and FIN flags set is anomalous TCP behavior, causing various responses from the recipient, depending on the OS. See Figure 1.

Figure 1: TCP Header with SYN and FIN Flags SetTCP Header with SYN and FIN Flags Set

An attacker can send a segment with both flags set to see what kind of system reply is returned and thereby determine what kind of OS is on the receiving end. The attacker can then use any known system vulnerabilities for further attacks. When you enable the tcp-drop-synfin-set statement, Junos OS checks if the SYN and FIN flags are set in TCP headers. If it discovers such a header, it drops the packet.

Disable TCP RFC 1323 Extensions

To disable RFC 1323 TCP extensions, include the no-tcp-rfc1323 statement at the [edit system internet-options] hierarchy level:

To disable the Protection Against Wrapped Sequence (PAWS) number extension (described in RFC 1323, TCP Extensions for High Performance), include the no-tcp-rfc1323-paws statement at the [edit system internet-options] hierarchy level:

Configure TCP MSS for Session Negotiation

During session connection establishment, two peers agree in negotiations to determine the IP segment size of packets that they will exchange during their communication. The TCP MSS (maximum segment size) value in TCP SYN packets specifies the maximum number of bytes that a TCP packet’s data field, or segment, can contain. An MSS value that is set too high can result in an IP datagram that is too large to send and that must be fragmented. Fragmentation can incur additional overhead cost and packet loss.

To diminish the likelihood of fragmentation and to protect against packet loss, you can use the tcp-mss statement to specify a lower TCP MSS value. The tcp-mss statement applies to all IPv4 TCP SYN packets traversing all the router’s ingress interfaces whose MSS value is higher than the one you specify. You cannot exempt particular ports from its effects.

The following section describes how to configure TCP MSS on T Series, M Series, and MX Series routers.

Configuring TCP MSS on T Series and M Series Routers, and MX Series Routers Using a Service Card

To specify a TCP MSS value on T Series and M Series routers as well as MX Series routers using a service card, include the tcp-mss mss-value statement at the [edit services service-set service-set-name] hierarchy level:

The range of the tcp-mss mss-value parameter is from 536 through 65535 bytes.

Add the service set to any interface for which you want to adjust the TCP-MSS value:

To view statistics of SYN packets received and SYN packets whose MSS value is modified, issue the show services service-sets statistics tcp-mss operational mode command.

For further information about configuring TCP MSS on T Series and M Series routers, see the Junos OS Services Interfaces Library for Routing Devices.

Configuring TCP MSS Inline on MX Series Routers Using MPC Line Cards

To specify a TCP MSS value on MX Series routers that use MPC line cards, include the tcp-mss statement at the [edit interfaces interface-name unit logical-unit-number family family] hierarchy level:

The range of the mss-value parameter is from 64 through 65,535 bytes. The TCP MSS value must be lower than the MTU of the interface.

This statement is supported on the following interfaces: gr- (GRE), ge- (Gigabit Ethernet), xe- (10-Gigabit Ethernet), and et- (40-Gigabit and 100-Gigabit Ethernet). Families supported are inet and inet6.

Note:

Configuring TCP MSS inline on MX Series routers using MPC line cards works only for traffic exiting/egressing the interface, not traffic entering/ingressing the interface.

Select a Fixed Source Address for Locally Generated TCP/IP Packets

Locally generated IP packets are the packets that are produced by applications running on the Routing Engine. Junos OS chooses a source address for these packets so that the application peers can respond. It also enables you to specify the source address on a per application basis. To serve this purpose, the Telnet CLI command contains the source-address argument.

This section introduces the default-address-selection statement:

If you specifically choose the source address, as in the case of Telnet, default-address-selection does not influence the source address selection. The source address becomes the one that is specified with the source-address argument (provided the address is a valid address specified on the interface of a router). If the source address is not specified or if the specified address is invalid, default-address-selection influences the default source address selection.

If the source address is not explicitly specified as in the case of Telnet, then by default (when default-address-selection is not specified) the source address chosen for locally generated IP packets is the IP address of the outgoing interface. This indicates that depending on the chosen outgoing interface, the source address might be different for different invocations of a given application.

If the interface is unnumbered (no IP address is specified on an interface), Junos OS uses a predictable algorithm to determine the default source address. If default-address-selection is specified, Junos OS uses the algorithm to choose the source address irrespective of whether the outgoing interface is numbered. This indicates that with default-address-selection, you can influence Junos OS to provide the same source address in locally generated IP packets regardless of the outgoing interface.

The behavior of source address selection by Junos OS can be summed up as shown in the following table:

Table 1: Source Address Selection

Outgoing Interface

When default-address-selection Is Specified

When default-address-selection Is Not Specified

Unnumbered

Use default-address-selection

Use default-address-selection

Numbered

Use default-address-selection

Use IP address of outgoing interface

See Configuring Default, Primary, and Preferred Addresses and Interfaces for more information about the default address source selection algorithm.

Note:

For IP packets sent by IP routing protocols (including OSPF, RIP, RSVP, and the multicast protocols, but not including IS-IS), the local address selection is often constrained by the protocol specification so that the protocol operates correctly. When this constraint exists in the routing protocol, the packet's source address is unaffected by the presence of the default-address-selection statement in the configuration. For protocols in which the local address is unconstrained by the protocol specification like IBGP and multihop EBGP, if you do not configure a specific local address when configuring the protocol, the local address is chosen using the same method as other locally generated IP packets.

TCP Authentication

Enabling a TCP authentication method enhances the security and ensures the authenticity of TCP segments exchanged during BGP and LDP sessions. Junos devices support three main types of TCP authentication: TCP MD5, TCP Authentication Option (TCP-AO), and TCP keychain-based authentication. For more information about TCP-AO, see TCP Authentication Option (TCP-AO).

Note:

Although Junos devices support both the TCP-AO and TCP MD5 authentication methods, you cannot use both at the same time for a given connection.

IP Subnet Support

Prior to Junos OS Evolved Release 22.4R1, Junos devices only permit you to use TCP authentication with a specific address. This means you can only authenticate TCP connections to remote peers with known IP addresses.

Starting in Junos OS Evolved Release 22.4R1, TCP-AO and TCP MD5 authentication support IP subnets for LDP and BGP sessions. When you configure TCP authentication with a network address and a prefix length, your chosen TCP authentication method authenticates TCP connections to the entire range of addresses under that subnet. This means you can authenticate TCP connections without needing to know the exact IP addresses of the destination devices.

When IP subnets overlap, the authentication method uses the longest prefix match (LPM) to determine the exact authentication key for a specific TCP session.

BGP

To configure prefix-based authentication for BGP sessions, include the allow (all | prefix-list) statement at either of the following hierarchies:

  • [edit protocols bgp group group-name]

  • [edit protocols bgp group group-name dynamic-neighbor dyn-name]

You can use IPV4 or IPV6 addresses for the subnet.

In this example, TCP MD5 authenticates TCP connections to devices in the 10.0.3.0/24 subnet for all BGP sessions:

LDP

To configure prefix-based authentication for LDP, configure TCP authentication under the session-group ip-prefix hierarchy. You must use an IPv4 address.

In this example, LDP uses TCP-AO to authenticate any TCP connection with a device that has an address in the 10.0.0.0/24 subnet:

For how to configure your TCP-AO keychain, see TCP Authentication Option (TCP-AO).

VRF Support

In releases prior to Junos OS Evolved Release 22.4R1, TCP MD5 and TCP-AO ignore virtual routing and forwarding (VRF) instances. The device ignores TCP MD5 and TCP-AO configurations under non-default routing instances. When you configure TCP MD5 or TCP-AO under the default VRF instance, the device applies that authentication method to all TCP sessions that have destinations inside the IP address range for that VRF instance. If a TCP session belonged to non-default VRF instance but had the same destination IP address as the default VRF instance, TCP MD5 and TCP-AO would apply the same authentication key to two TCP connections with the same destination IP address.

Starting in Junos OS Evolved Release 22.4R1, TCP-AO and TCP MD5 authentication are VRF aware in BGP and LDP sessions. You can configure TCP-AO and TCP MD5 under non-default routing instances. The TCP authentication method you configure under a routing instance is only applied to the TCP sessions inside that VRF instance. If a TCP connection in a different VRF instance has the same destination IP address, the TCP authentication method does not get applied to that TCP connection if the VRF instance does not have TCP authentication configured for the peer.

Configure VRF-based TCP authentication as you normally would, but under a routing-instances hierarchy level. To use TCP MD5 authentication, include the authentication-key authentication-key statement. To use TCP-AO, include the following statements:

For how to configure your TCP-AO keychain, see TCP Authentication Option (TCP-AO).

You can combine VRF-aware configurations with IP subnets. This enables you to authenticate connections to a range of addresses inside the VRF instance.

BGP

Configure VRF-based TCP authentication for BGP sessions at any of the following hierarchy levels:

  • [edit routing-instances vrf-instance protocols bgp]

  • [edit routing-instances vrf-instance protocols bgp group group-name]

  • [edit routing-instances vrf-instance protocols bgp group group-name neighbor neighbor-ip]

  • [edit routing-instances vrf-instance protocols bgp group group-name dynamic-neighbor dyn-name]

If you configure VRF-based authentication at the dynamic-neighbor level, include the allow statement along with your chosen authentication method configuration. For example, to use TCP-AO with a dynamic neighbor:

In the following example, BGP uses TCP authentication to ensure the security of TCP connections in a VRF instance called vrf-one. In group one, BGP uses TCP MD5 to authenticate connections to the neighbor with the IP address 10.0.1.1. It uses TCP-AO to authenticate connections to the neighbor with the IP address 10.0.1.2.

In group two, BGP uses TCP-AO to authenticate connections to any device in the 10.0.0.0/24 subnet.

LDP

Configure VRF-based authentication for LDP sessions at any of the following hierarchy levels:

  • [edit routing-instances vrf-instance protocols ldp]

  • [edit routing-instances vrf-instance protocols ldp session session-ip]

  • [edit routing-instances vrf-instance protocols ldp session-group ip-prefix]

In this example, TCP-AO authenticates TCP connections in a VRF instance called vrf-two. It authenticates TCP connections to the address 10.0.1.1 as well as any address in the 10.0.0.0/24 subnet.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
22.4R1
Starting in Junos OS Evolved Release 22.4R1, you can configure TCP-AO or TCP MD5 authentication with an IP subnet to include the entire range of addresses under that subnet.
22.4R1
Starting in Junos OS Evolved Release 22.4R1, TCP authentication is VRF aware.