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.
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.
[edit system internet-options] tcp-drop-synfin-set;
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:
[edit system internet-options] no-tcp-rfc1323;
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:
[edit system internet-options] no-tcp-rfc1323-paws;
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
- Configuring TCP MSS Inline on MX Series Routers Using MPC Line Cards
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:
[edit services service-set service-set-name] tcp-mss mss-value;
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:
[edit interfaces interface-name unit 0 family family service] input service-set service-set-name; output service-set service-set-name;
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:
[edit interfaces interface-name unit logical-unit-number family family] tcp-mss mss-value;
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.
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:
[edit system] default-address-selection;
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:
|
Outgoing Interface |
When |
When |
|---|---|---|
|
Unnumbered |
Use |
Use |
|
Numbered |
Use |
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.
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).
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:
[edit protocols]
bgp {
group one {
authentication-key "$ABC123";
allow 10.0.3.0/24;
dynamic-neighbor dyn_one {
allow 10.0.3.0/24;
authentication-key "$ABC123";
}
}
}
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:
[edit protocols ldp]
session-group 10.0.0.0/24 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
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:
user@device# set authentication-algorithm ao user@device# set authentication-key-chain keychain
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:
[edit routing-instances vrf-instance protocols bgp group group-name dynamic-neighbor dyn-name] user@device# set allow (all | prefix-list) user@device# set authentication-algorithm ao user@device# set authentication-key-chain keychain
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.
[edit routing-instances]
vrf-one {
protocols {
bgp {
group one {
peer-as 22;
neighbor 10.0.1.1 {
authentication-key "$ABC123"; ## SECRET-DATA
}
neighbor 10.0.1.2 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
}
group two {
peer-as 22;
dynamic-neighbor dyn_two {
allow 10.0.0.0/24;
authentication-algorithm ao;
authentication-key-chain tcpao;
}
}
}
}
}
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.
[edit routing-instances]
vrf-two {
protocols {
ldp {
session 10.0.1.1 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
session-group 10.0.0.0/24 {
authentication-algorithm ao;
authentication-key-chain tcpao;
}
}
}
}
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.