Skip to main content

RFC 791 pt2

 This week's post will cover the operation of the Internet Protocol. Specifically, Time to Live (TOL), Type of Service(TOS), the Header Checksum, and the other remaining options available when transmitting data across IP. While this post will cover the basic operations and provide descriptions of their functions and use, a more technical dive will be saved for next week's post, which will cover the specification section of RFC 791. The final post in this series will cover the security implications of the Internet Protocol, and briefly cover the updates made to the original document and protocol. 

Continuing from the last post, there are two main functions of the Internet Protocol. Addressing and Fragmentation. To begin,  the device you use to connect to the internet, or the internet module, uses the addressing function of IP to send and receive data. The internet module reads the address of the datagram and uses it to route to the desired endpoint. This address is carried in the header of the internet datagram. 

Information pertaining to the fragmentation of datagrams is also contained within the header. Much like the addressing information helps the internet modules route the datagrams, there is information inside the header that helps the modules assemble fragmented data. The fragments are transmitted asynchronously and are not necessarily received in assembly order. Thus, the internet datagram header contains both addressing information and assembly information. The addressing information ensures that the fragmented data is sent to the same destination and the assembly information gives instructions on the reconstruction of the fragmented data. 

Internet modules also share common rules for reading and formatting header information. This ensures that a datagram passed from one module to another can use the same addressing information. This applies to assembly as well. 

Aside from addressing and fragmentation, there are several other fields within the header. Starting off, Type of Service is the second byte contained in an IPv4 header. The TOS determines the datagrams' priority and routing. It can signify a request for low-latency, high-throughput, or high-reliability routing. It is a fairly obsolete system, having been redefined several times over the years. In modern applications, it sees little use. Even back in its more relevant days, the TOS field went relatively unused. 

Time to Live prevents datagrams from traveling endlessly. It provides a set value that decreases every time the datagram is processed while routing to its destination. When the value is set to 0, the datagram is destroyed. This helps to prevent undeliverable data from continuing to circulate on a network, causing congestion. Originally, TTL was measured in units of time, such as seconds. However, every host that processes the datagram must reduce the TTL limit, and thus in IPv6 the TTL field was renamed to hop limit. 

One of the more important fields in the header is the header checksum. The header checksum provides a method of verification for the datagram. Every host must validate the header checksum before sending the datagram to the next destination. The header checksum must also be changed every time the header is changed as well. As each host must decrease the TTL, they must also change the header checksum. The checksum first must be calculated and then verified. The calculation process works by adding the hex values of the 16-bit fields in the header, minus the checksum field. The first digit of the result is called the carry digit and is added to the sum. Next, you must take the ones' complement(flip every bit) of the sum and the result should be the value of the checksum field. The same process is used to verify the checksum. However, the checksum filed is now included in the calculation. The end result of the verification should equal 0. 

There are other minor optional fields in the internet datagram header. Control functions that may be necessary in certain specific situations for example. However, these options are not needed for more common applications and thus will not be expanded upon too much in this post. Some of the options, for example, include timestamping, increased security options, and special routing instructions. It is also possible to change the method of fragmentation of the data or to disallow fragmentation all together. 

Comments

Popular posts from this blog

Using PGPy to encrypt and decrypt files and messages

 PGPy is a library for python that enables the creation, storage, and encryption/decryption of PGP keys and files in python. Recently, in a small project to reacquaint myself with python, I used PGPy for key generation and encryption and decryption. That project can be found in my github at  https://github.com/lpowell . The goal of the project was to use command-line switches to control the program, and to provide basic encryption and decryption capabilities, along with rot13 and base64 encoding.  First, to load in a key use key, _ = pgpy.PGPKey.from_file(keyfilename) . This loads the key from either a binary or ASCII armored file. You can swap out .from_file for .from_blob , if you plan on using a key stored in a string or bytes object rather than a file. In my example code, I pull the key from a file, as I found it to be the simpler method.  Next, you'll need to open a file or create a string or bytes object that contains the message you wish to encrypt. We'll call this file

Using the Ubertooth One to sniff and intercept Bluetooth packets

While researching for my individual video project I came across this tool which allows for the sniffing and interception of bluetooth packets. This article covers some of the basic functionality of an Ubertooth One.  It's really quite interesting to see all the possibilities with devices like these. The tech behind them is very interesting as well. Hopefully, I'll be able to integrate some of this technology into my project video and include a demo of some of the interesting things it can do.

Installing the Ubertooth on the Mac mini M1

 For my video project, one of the demonstrations included using an Ubertooth One to scan for Bluetooth and BLE packets. This blog post will cover the installation of the Ubertooth One on the Mac mini M1. The official install guide for Mac devices didn't work very well for me, and I had to install some extra tools in order to get it to work. The examples assume you are using Python 3, and have homebrew installed.  To begin, follow the instructions found here:  https://github.com/greatscottgadgets/ubertooth/wiki/Build-Guide . Additionally, you may find that you need to install pytq5, numpy, and qtpy. To do this, simply run Python3 pip install pyqt5, numpy, qtpy. This will install the required libraries needed to run the Ubertooth tools. There are multiple ways to install pip on an OS X device, but I suggest using homebrew to install python3, which should install pip as well. Next, you will need to update the firmware of the device. When downloading the tools, a firmware directory sh