Maximum Transmit Unit (MTU) and Maximum Segment Size (MSS) are two important terms you should be familiar with when venturing into the world of networking, especially if you are working with GRE and IPSEC tunnels.
And if you are looking to use DDoS Protection as a service, you will need to know how MTU and TCP-MSS work.
What is ‘Maximum Transmit Unit’ (MTU)?
MTU is the largest packet or frame size, specified in octets (eight-bit bytes), that can be sent in a packet- or frame-based network on a particular data communications link.
The internet’s transmission control protocol (TCP) uses MTU to determine the maximum size of each packet in any transmission. MTU is usually associated with Ethernet where the typical largest frame allowed is 1500 bytes.
Fragmentation
One of the most common problems with MTU is that sometimes higher-level protocols may create packets larger than a particular link can support. There are two methods to deal with this problem: try to break the packet into smaller chunks or discard it entirely.
If the Do not Fragment (DF) bit is unchanged from its default setting (0), the router will fragment the packet that is too large to fit in the outgoing interface and send it on to its destination. If the DF bit is set (1) then the router will not have a choice but to discard the packet.
Some applications do not support reassembly of fragmented packets and some firewalls treat it as a security vulnerability. Therefore we should avoid this situation, if possible. The best way to avoid fragmentation is to adjust the maximum segment size, or TCP MSS, so the payload will be adjusted before reaching the data link layer.
Next let’s review a few examples that will illustrate the problem and discuss the solution. The diagram below explains the packet structure
As mentioned, the maximum legal packet size is 1500 bytes
In the figure above you can see the MTU is built from payload (also referred to as data) plus IP and TCP headers , 20 bytes each.This leaves us 1460 bytes for our payload.
Now, let’s imagine that we are using the GRE protocol in our network, encapsulating the original packet and adding 24 bytes (Outer IP Header + GRE Header) for the GRE header.
This means that GRE will increase our packet size by an additional 24 bytes making the total packet size 1524 bytes, which exceeds the 1500 bytes MTU value.
Another way of handling the increase in MTU size due to encapsulation and the resulting fragmentation is to utilize the TCP Maximum Segment Size (MSS) parameter. See below:
MTU – (TCP Header + IP Header + GRE Header) = MSS
1500 – (20 + 20 + 24 ) = 1436
What is Maximum Segment Size (MSS)?
MSS is the largest amount of data that a single communication can receive in a single TCP segment. It doesn’t include the TCP header and IP header.
The value will dictate the maximum size of the “data” part of the packet.
MTU – (TCP Header + IP Header) = MSS
1500 – (20 + 20 ) = 1460
1460 is the default size of the MSS
What differentiates MTU and MSS is that if a packet exceeds the MTU (for example 1500) it will be fragmented into small pieces to enable it to be sent on to the destination. However If a packet exceeds the MSS, the packet will be dropped and will not be fragmented
Configuring TCP MSS for DDoS for Networks Protection
For DDoS for Networks protection, we usually use GRE tunnels and therefore we need to address the possibility of fragmentation if we are not adjusting the TCP MSS.
Our solution, which is asymmetric by definition (meaning in-bound traffic via Imperva , outbound traffic via the original ISP) requires us to rewrite the TCP MSS value of SYN packets that are being sent by our protected customer to their end clients.
As you can see in the diagram above, the customer server sends the packet with an MSS value of 1460, but in the router’s interface we will adjust it to 1436 for GRE.
It’s important to understand that this value will affect the size of the traffic coming from the end client toward the customer’s server.
This is the traffic that will go via the tunnel and therefore be encapsulated with 24 bytes of GRE.
The outbound traffic, from the customer’s server toward the end client, goes directly via the original ISP, therefore there is no need to adjust the SYN packets the end user sends.
The diagram above shows how SYN packets in the three-way handshake travel. After the three-way handshake is completed and the connection established, the end user will send packets where the “data” won’t exceed the 1436 bytes size.
In addition the customer’s server will send packets whose “data” won’t exceed the default 1460 bytes.
Do take note that the GRE configuration of the MSS is done on the WAN interface not the tunnel interface because the SYN packets that are sent from the server toward the end user are not going via the GRE tunnel interface, but via the original ISP’s interface.
Recommendation for GRE customers:
TCP-MSS 1436
For the IPsec configuration, the additional header is dependent on the encapsulating security payload (ESP) protocol that has been used. It can be using the Data Encryption Standard (DES) or Triple-DES algorithm with additional Authentication (MD5 or SHA-1) or DMVPN with additional 73 bytes ESP-AES-256 and ESP-SHA-HMAC overhead and there will be variation in header sizes that must be accommodated within the IP packet.
Recommendation for GRE customer with IPSec/VPN traffic:
TCP-MSS 1360:
MTU – (TCP Header + IP Header + GRE Header + ESP Header) = MSS
1500 – (20 + 20+24+73 ) = 1363 = ~1360
Try Imperva for Free
Protect your business for 30 days on Imperva.
