Learning and working with large frames on IP networks

Erick Rangel
Sinch Blog
Published in
7 min readJun 15, 2020

Introduction

An important feature of the IPv4 protocol is to allow communication between different physical media, such as wireless (802.11), optical (FDDI) or copper (802.3). Thus, a host can receive data from different media, where each has its own characteristics that change the datagram, where at this point we are interested in its maximum size.

Datagram size

Different physical architectures allow more or less data (header, data and trailers) to be transmitted at once. This limitation is called MTU (Maximum Transmission Unit) which was initially defined by RFC 1063. Below are the standard values ​​defined by RFC 1191 (November 1990), plus wireless technology:

The difference between the sizes of the different technologies is due to the capacity that each one has to send more or less data. High-speed networks, such as optics, send more data than lower-speed networks, such as ARCNET, because data transmission will occupy the physical medium, if the frame is very large and the technology slow, it will be occupied for a longer time, preventing data return.

Fragmentation

The main function of MTU is to allow data transmission over networks with different architectures. It can do this by splitting incoming datagrams into smaller pieces when they are larger than the MTU configured on the host it is receiving. The IPv4 protocol has fields that control the fragmentation and reassembly of the datagram, as shown below:

IPv4 header

Total Length: 16 bits field that indicates the total size of the datagram. In fragmented datagrams, this value will be equal to or less than the MTU and less than the value of the total size of the datagram;

Identification: 16 bit field containing the unique value that identifies the datagram and all fragments, if it has been fragmented, preventing a fragment from being delivered to another datagram;

Flags: a 3-bit value that will indicate whether the datagram can be fragmented, whether there are more fragments or whether it is the last fragment, as shown below:

Flags IPv4

Fragment Offset : 13 bits field that together with the length corner indicates the position of the fragment in relation to the original datagram. In non-fragmented datagrams, this field will be 0. This value will be defined with the aid of the Length field in the fragments except the first one that receives a value of 0. The value of the following fragments will be the value of this field in the datagram that is going over the NFB (Number of Fragment Blocks)³.

Illustration of fragmentation

There is an addition of 8 bytes to the lower layer trailers. Due to the transport of more headers, the sending of the total datagram is increased by approximately 20 bytes per new generated datagram.

Reassembly

RFC 815 defines a procedure for reassembling IPv4 datagrams, however each developer may use the form he deems appropriate, as it is in the document “This document describes an alternate approach …”.

First, the host that will reassemble the datagram will need to control all fragments of the entry. Second, new fragments need to be analyzed in order to determine whether it is duplicated, whether it is the last, whether spaces will be completed sequentially, etc.

As soon as a fragment arrives at the host (not necessarily this must be the first, with Offset equal to 0) it will create a buffer and define that this datagram is incomplete and then the host will start looking for the others. If no fragments are received within the defined time (usually 15 seconds as defined in RFC 791) this buffer will be discarded. Upon receiving a new fragment, the system will identify which portion it will complete and continue to analyze incoming traffic until the last datagram (Flags equal to 0x00) is received.

Problems

Fragmented datagrams are generally expected on a network, since some packet filters do not always know what to do with the fragments or their presence is an indication of attack, as very small fragments where they do not receive all the information from the transport protocol. Certain types of attacks consist of splitting tcp packets into fragments smaller than 20 bytes, causing the firewall or IDS / IPS to queue their remnants or have difficulty determining their actions.

Nowadays, fragmented datagrams are rare and mostly unwanted, so by default the default action for any datagram of this type is refusal. However, when we receive valid and true traffic (e.g. traffic under an already established IPSEC VPN), its acceptance can be painful. When we set up a stateful firewall for a connection that can receive fragmented datagrams, the dynamic rules will not allow it, so there is a lack of data to reassemble the datagram.

Therefore, we must create rules allowing this known traffic and also rules for accepting fragmented IP datagrams. Each packet filter will have its own parameters, but below are some examples of firewalls from the UNIX world:

iptables: there is the -f parameter that will make the rule apply to subsequent fragments, for iptables the first fragment is treated as if it were any datagram, the following fragments of this not. Example:

iptables -A INPUT -f -s <source> -d <destination> -j ACCEPT

ipf: has two parameters for handling fragments, with frag, which will make the rule apply to fragmented datagrams, and keep frags, which will make the rule apply to the following fragments, as it will keep the information from it. Example:

pass in quick from <source> to <destination> with frag keep frags

pf: advanced options for handling fragments such as timeout limit fragment receipt and memory entries for reconstruction of datagrams; as follows:

set limit frag <number> -maximum number of entries in memory for reconstructing datagrams;

set timeout frag <number> — seconds before a fragment expires.

Filtering can occur in two ways, by standardization and by individual rules. By rules, it works in the same way as common rules, however the protocol or port should not be specified, only network layer fields. Example:

pass in proto ip from <source> to <destination>

Another way is normalization or scrubs. With it, the pf had reassembled the datagram before performing its filtering, avoiding ambiguities. The simplest way to use it is:

scrub in all — causes all incoming datagrams to be reassembled;

However, there are more parameters that can be used, such as the following:

fragment reassemble buffer incoming packets and remount them before filtering;

fragment crop — similar to the fragment reassemble, however it rejects duplicate packages, however the filtering will be carried out before reassembly;

max-mss <number> — defines the Maximum Segment Size (MSS) in tcp packets.

Bibliography

POSTEL, Jon, INTERNET PROTOCOL. Available in : http://tools.ietf.org/html/rfc791. Accessed in : 11/21/2013.

CLARK, David D., IP DATAGRAM REASSEMBLY ALGORITHMS. Available in : http://tools.ietf.org/html/rfc815. Accessed in : 11/21/2013.

MOGUL, Jeffrey, DEERING, Steve, Path MTU Discovery. Available in : http://tools.ietf.org/html/rfc1191. Accessed in 11/19/2013.

KRAEMER, Bruce P. e grupo, IEEE Standard for Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 5 : Enhancements for Higher Throughput, IEEE, 2009.

KOZIERO, Charles M., IP Datagram Size, Maximum Transmission Unit (MTU), Fragmentation and Reassembly. Available in : http://www.tcpipguide.com/free/t_IPMessageReassemblyProcess.htm. Accessed in: 11/20/2013.

PEPELNJAK, Ivan, The never ending story of IP fragmentation. Available in : http://stack.nil.com/ipcorner/IP_Fragmentation/. Accessed in: 11/20/2013.

FAIRHURST, Gorry, IP Fragmentation. Available in : http://www.erg.abdn.ac.uk/~gorry/course/inet-pages/ip-fragmentatiion.html. Accessed in : 11/24/2013.

HARDWOOD, Mike, Cert Guide CompTIA Network+ N10–004, first edition, Pearson, 2010.

MAIA, Luiz Paulo, Arquitetura de redes de computadores, LTC, 2011.

FreeBSD, 29.5. The IPFILTER (IPF) Firewall. Available in : http://www.freebsd.org/doc/handbook/firewalls-ipf.html. Accessed in : 11/24/2013.

ROUSE, Margaret. Stateful Inspection. Available in : http://searchnetworking.techtarget.com/definition/stateful-inspection. Accessed in: 11/24/2013.

Nmap, Evitando e enganando o Firewall/IDS. Available in : http://nmap.org/man/pt_PT/man-bypass-firewalls-ids.html. Accessed in : 11/30/201.

ZIEMBA, Paul G., REED, Darren e TRAINA, Paul. Security Considerations for IP Fragment Filtering. Available in : http://www.ietf.org/rfc/rfc1858.txt. Accessed in: 11/30/2013.

FARRELL, John, PF and ALTQ. Available in : http://www.freebsd.org/doc/handbook/firewalls-pf.html. Accessed in: 12/08/2013

RUSSEL, Rusty, Linux 2.4 Packet Filtering HOW TO. Available in : http://www.netfilter.org/documentation/HOWTO/pt/packet-filtering-HOWTO-7.html. Accessed in: 12/08/2013

OpenBSD Team, Scrub (Packet Normalization). Available in : http://www.openbsd.gr/faq/pf/scrub.html. Accessed in: 12/08/2013

¹ The MTU of 802.11 standard is not mentioned in the RFC, as it is prior to the development of such;

² The maximum size of the MSDU (Mac Service Data Unit) before encryption is 2304 bytes, depending on the method, the size will vary:

WPA (TKIP) adds 20 bytes header;

WPA2 (AES) adds 16 bytes header.

³ NFB is the amount of data that travels in a fragmented IP datagram. This value is defined by (MTU-IHL * 4) / 8;

⁴ Stateless checks the packets in isolation, it does not consider the state of the connection or other packets that this connection will receive. Statefull monitors traffic and creates dynamic rules, allowing or blocking them.

--

--