9 minute read

Network protocol model - why it is important?

I heard a story that during a cybersecurity training developers were asked to do “ping to a host”…. “Do what???” - they replied. “We are just programmers!”. Apparently, the trainer involuntarily provoked some confusion…

IMHO it seems strange that most of the developers or even testers simply do not have any idea about security basics. And vice versa, as plenty of beginners thinking of a career in cybersecurity often ask: “Do I really need to learn any programming language to start studying cybersecurity?”

My answer for both groups would be: maybe not at the very beginning, but ideally you should know both security and programming to some extent, after some time, no matter what is your exact specialisation or field in the IT industry.

Let’s start by digging into basic networking. Abstraction layers of network protocols often seem to be a little… abstract, but they are important nevertheless. The problem is that IT theoretical knowledge is often served in messy, complex manner, and by the guys for who it is an obvious thing to understand. So for someone who is coming from the other side of tech world (from outside the zone), it sometimes does not make any sense.

Let’s be like a stalker, the protagonist in Strugatsky brothers’ novel Roadside Picnic (and Tarkovsky’s movie the Stalker), learning new things by immersion in the unknown and guiding others through the zone.

OSI (Open Systems Interconnection) model

What we know is that the OSI model has been based on OSI Basic Reference Model (1984). Created by ISO (International Organisation for Standarisation), it consists on seven layers:

Application layer #7

What we know is that these are real data coming into some application (software, web browser). The app passes the data to the presentation layer.

Presentation layer #6

Its definition is more ambiguous:

  • it contains “library-like” functions: data compression and decompression
  • but it can belong to 7th layer (application).

The application sends the data in some format, used by the application itself (meaning: sender), but it is not required for the data to be in any standarised format recognised by the application that receives the data. That might be a problem. This is why the presentation layer transforms / formats the data into a standardised format understood by the recipient. This layer is also responsible for handling any encryption, compression, decompression or any other transformations of the data.

Session layer #5

So it is even more ambiguous:

  • ensures reliability of the connection
  • but it can be also implemented in the 4th or 7th layer
  • it can remain unimplemented if the reliability is not really needed.

At this step, the layer receives already formatted data from the presentation layer. It checks if a connection with remote host across the network is possible. If not, it sends back the error to the data sender. If connection is possible, it communicates with the session layer of the other side. Important: the session would be unique and separate from other sessions established between these two actors at the same time. Hence, we can make multiple requests to one or many application REST endpoints, resend the requests and keep them as separate processes with different results (like various HTTP statuses: 200, 201, 400, 404 and so on) and different data, like sending different request body to Java / Spring REST controller every time.

Transport layer #4

It consists on sending packages of TCP / UDP protocol (context identifier, checksum). The layer is to be removed before transferring to the client app. Once the session has been established, the data are passed from the session layer to the transport layer. Its main task is to choose the protocol over which data is to be transferred: the most popular are:

TCP (Transmission Control Protocol)

  • connection-based protocol
  • a connection maintained for the duration of request
  • a reliable transmission
  • checks if all packages are delivered, lost data is sent again
  • accuracy is more important than speed
  • data divided into segments
  • e.g. e-mail, web browsing, file transfer

The connection is established through three-way handshake:

  • client is sending request to sever in order to initialise a connection
  • client’s request contains SYN bit (synchronise bit)
  • server responds by SYN bit and ACK bit (acknowledgement)
  • client is sending ACK bit to the server = connection has been established

UDP (User Datagram Protocol)

  • speed is more important than accuracy
  • packages are delivered at higher speed without verification
  • data divided into datagrams
  • e.g. chat, video streaming, VoIP

Network layer #3

  • responsible for locating the destination of a request
  • Internet Protocol (IP protocol) - logical addressing
  • IP protocol package (local sender, local recipient, checksum, size)
  • information about general direction of data transfer
  • universal identification of packet sender and recipient
  • network addressing
  • cannot be rejected / modified en route (contrary to #2 Data Link Layer)
  • may be rejected after the data has reached target system
  • physical addressing
  • presents data in proper format
  • checks if received data had not been corrupted during transmission
  • ethernet frame (headers, local sender, local recipient, checksum, size)
  • local devices communication protocols
  • MAC addressing (Media Access Control)
  • MAC address cannot be changed, but can be spoofed
  • the layer can be rejected / modified while en route, e.g. rejected while going through intermediary network device

Physical layer #1

  • real infrastructure: LAN - Local Area Network, WAN - Wide Area Network, BAN - Building Area Network, MAN - Metropolitan Area Network…
  • converts binary data into physical signal

Media used:

  • twisted pair cabling (two twisted wires), improves signal transmission, reduces electromagnetic radiations and crosstalk between neighbouring pairs, improves rejection of external electromagnetic interference, invented by Alexander Graham Bell, may be shielded (STP) or unshielded (UTP)
  • coaxial cable (stronger and heavier but more expensive, patented by Oliver Heaviside), used for antennas
  • optic fiber - allegedly resistant to external, physical eavesdropping
  • wireless - 802.11 a…. and so on

Physical infrastucture is vulnerabe to various attacks, like electromagnetic eavesdropping which was documented as early as in the 1980’s by Wim van Eck (see Eck’s phreaking, TEMPEST).

The next thing to learn: what is TCP / IP model. It is similar to OSI, what may be confusing :-)

TCP_IP model scheme
TCP / IP model vs OSI model: comparison of layers. Source: Ardika6879 / Wikipedia.
Licensed under the Creative Commons Attribution-Share Alike 4.0 International license.

Networking models - flyer by securityzines.com

TCP / IP model

Long story short: TCP / IP model a.k.a. Internet protocol suite is even older than the OSI model. It was created by DARPA / US Department of Defense in 1982, during legendary Cold War and ARPANET era. The model is similar to the OSI model, but it contains fewer layers (4). Some researchers also split Network Interface layer into Data Link and Physical Layer, as in the case of the OSI model, which - for the sake of clarity - is not good. So it seems the OSI model is considered to be better for learning purposes.

Encapsulation

In both models, encapsulation and de-encapsulation works in the same way: during encapsulation a header is added by each layer, and during de-encapsulation the header is removed. Headers contain information relevant from a point of view of a layer: Network Layer puts source and destination IP addresses into the header, Transport Layer includes i.a. information on protocol and so on. Data Link adds both header and a trailer at the end to prevents data corruption. Encapsulated data has different names at different layers: data, segments or datagrams, packets, frames, bits.

OSI model scheme
OSI model: during encapsulation data are referred to by different names at each layer.
Source: Dino.korah / Wikipedia. GNU Free Documentation License.

After reception by the recipient, de-encapsulation starts from the layer # 1, headers are removed, until the application layer # 7 is reached.

Networking OSIT - basic Linux tools

Ping

The ping command serves to test a connection, e.g. to a website on the internet or to a computer on a network, from the command line. Ping is using the ICMP protocol that belongs to the TCP/IP protocol family. The ICMP protocol works on the Network layer (OSI Model) and on the Internet layer (TCP/IP model).

Ping syntax:

ping <target>

Manual for Ping available after:

man ping

Request example:

ping quora.com

Response example:

$ ping google.com
PING google.com (142.250.203.206) 56(84) bytes of data.
64 bytes from waw02s22-in-f14.1e100.net (142.250.203.206): icmp_seq=1 ttl=120 time=9.14 ms
64 bytes from waw02s22-in-f14.1e100.net (142.250.203.206): icmp_seq=2 ttl=120 time=15.8 ms
64 bytes from waw02s22-in-f14.1e100.net (142.250.203.206): icmp_seq=3 ttl=120 time=9.71 ms

Traceroute

Traceroute shows intermediate points (servers, endpoints) en route to the target. It is possible to select which protocol shoud be use to execute the request. Basic Traceroute command syntax:

traceroute <target>

Manual available after:

man traceroute

Request example:

traceroute quora.com

Response sample:

traceroute to quora.com (54.236.132.27), 30 hops max, 60 byte packets
 1  _gateway (192.168.254.254)  6.746 ms  6.763 ms  6.784 ms
 2  little-green-men.com (109.103.55.79)  12.376 ms  12.308 ms  12.249 ms
 3  10.21.0.2 (10.211.999.0.2)  9.251 ms  9.443 ms  9.728 ms
 4  some.ip.ip4.ufo.com (192.126.27.130)  9.859 ms  11.412 ms  11.549 ms
 5  some.ip.ip4.ufo.com (192.126.24.153)  17.910 ms  18.344 ms  18.140 ms
 6  far-far-space.net (80.165.172.120)  34.856 ms  28.424 ms *

Whois

Command line equivalent of web version, simple syntax: whois

Example of use:

~$ whois bbc.com
   Domain Name: BBC.COM
   Registry Domain ID: 4794897_DOMAIN_COM-VRSN
   Registrar WHOIS Server: whois.tucows.com
   Registrar URL: http://www.tucows.com
   Updated Date: 2021-07-06T15:03:44Z
   Creation Date: 1989-07-15T04:00:00Z
   Registry Expiry Date: 2030-07-14T04:00:00Z
   Registrar: Tucows Domains Inc.

Dig and DNS resolving

How it works step by step?

Let’s execute a sample request from local computer to a website:

  • at the very beginning, computer does not really know that given website domain like something.com equals some real IP address
  • domain name cannot be resolved, hence the computer would not be able to connect to the target, because it does not know how to do that
  • the computer checks its local cache to find if the IP address for given domain has been recently stored
  • if not, the computer sends a request to arecursive DNS server
  • recursive DNS servers are owned by ISP companies and some IT companies (e.g. Google, OpenDNS)
  • coordinates of recursive DNS servers are stored in the router, hence the computer know how to locate the recursive DNS server to send the request
  • the server keeps its cache including details for some domains, let’s say - for the most popular
  • but if requested domain had not been found there, the local computer sends another request to root name server
  • it connects to the closest possible root name server; there are plenty of them, but they are accessible through 13 IP addresses
  • some time ago there were only 13 root name servers, later they expanded
  • the traffic to the final destination root name DNS server is balanced
  • lower layer of these servers is called Top-Level Domain servers (TLD)
  • TLD servers are split accordingly to domain extentions, creating another layer of TLD servers: servers for .com, servers for .net and so on
  • they are called authoritative name servers, and they store DNS records for given domain
  • to sum up, every domain has its DNS records stored by some authoritative name server

All these process can be monitored by dig tool. It’s a robust tool that requires further research to find out what it offers in greater detail.

Example of use:

~$ dig google.com @1.1.1.1

; <<>> DiG 9.16.1-Ubuntu <<>> google.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36949
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		58	IN	A	216.58.215.110

;; Query time: 8 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: wto sty 10 13:44:59 CET 2023
;; MSG SIZE  rcvd: 55

Reference books:

Michał Zalewski, Silence on the Wire, 2005

Deborah Russel, Nick Lehtinen, Computer Security Basics, 2006

Charlie Kaufman, Network Security: Private Communication in a Public World, 2002