Skip to main content

Examining RFC 791

 This will be the start of several posts that will examine the RFC 791 documentation. RFC 791 covers the Internet Protocol and provides an introduction, overview, and specifications of the protocol. For this post, we'll be reviewing the introduction, as well as outlining some key terminology needed to understand the protocol. This review will be somewhat limited, and may not be overly technical, but it should provide a decent overview of the Internet Protocol. 

To start, we'll cover the "who", the "why", and the "how's" of IP and give a small background on the history of the protocol.  We will also cover the basics of packet switching networks, the OSI and TCP/IP, and the structure of Internet datagrams. Hopefully, by the end of this post, you will be able to understand what these concepts are and how they fit into the Internet Protocol, as well as other protocols and standards. 

The document we will be examining is RFC 791, this is not the first IP document to be written & submitted to RFC, nor is it the most recent document, but it does provide a decent overview of the protocol and the basics of its operation. RFC 791 was originally prepared for the Defense Advanced Research Projects Agency (DARPA). The document was written by the Information Sciences Institute of the University of Southern California and was submitted in September of 1981. At the time, the internet did not exist in its current form. Networks were mostly limited to communication within themselves, and it was necessary to come up with a method of sharing information from one network to another. This is where IP comes in. 

IP was designed for interconnected systems of packet-switched networks. Packet-switching being a method of grouping data that is to be transmitted over a network. In a packet-switched network, "packets" are datagrams that consist of a header and a payload. The header stores data related to the delivery and assembly, and the payload contains the information that is being sent. Packet-switched networks also work asynchronously. This means that the packets are not necessarily received in order of assembly. As an example, look at the following media item. 


By Oddbodz - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=29033823

The specific path that the packets take is determined by the address stored in the header of the datagram. You might think of a datagram as an envelope. The envelope has an address on it that the post office uses to deliver. This is the header. The content of the envelope is the payload. As for how this information is addressed and packaged into a datagram, that will be covered in later posts.

To rehash, a datagram is a transfer unit that typically contains a header and a payload, and a packet-switched network is a network that uses packets or datagrams to transfer information. 

Delving further into the transfer of information from a local network to an external network, it is important to understand the TCP/IP stack and the OSI model. The images below show the OSI model and the TCP/IP stack.


These models both show how information travels across multiple "layers" to reach its destination. It is important to understand how these layers are connected to each other, and how data is processed and repackaged across them. 

For a brief overview, the green portion of the image covers information that is being transferred across the local network. The blue section covers internetworking, or internet transmission. The red section contains protocols such as TCP and UDP, that are used to provide reliable delivery of information. Finally, the yellow section covers application protocols such as pop3, HTTP, or ssh. Information travels across all of these layers in order to get from point to point, and understanding the interconnectivity of the layers is very important in regards to safeguarding secure information. 


A small end of post warning. I am learning about these topics as I post about them, and therefore cannot guarantee that the information present is 100% correct.


RFC 791 can be found here, https://www.rfc-editor.org/rfc/rfc791.html

Comments

Popular posts from this blog

Frag Attacks - A critical Wifi vulnerability

Wifi fragmentation and aggregation attacks (FragAttacks) are a new collection of vulnerabilities in which a threat actor can exfiltrate data or attack victims within radio range. Mathy Vanhoef, a postdoctoral researcher at New York University Abu Dhabi, recently published his paper, Fragment and Forge: Breaking Wi-Fi through Frame Aggregation and Fragmentation , detailing several attack vectors and examining the intricacies of the aggregation vulnerabilities that have been part of the 802.11 standards since the inception in 1997.  Quite interestingly, every device tested was susceptible to one or more of the FragAttacks. While several 802.11 standards make these attacks harder to perform, they can be executed on all devices across all standards. It's a good thing then, that there was a nine-month embargo on information related to these attacks, allowing manufacturers to provide security updates to affected devices. Mathy Vanhoef has also created a website documenting the FragAttack

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

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 th