Bonus Protocols — File Transfer, Email Access and Real-Time Communication

Category: Bonus Protocols — Additional important protocols covering email access, file transfer, real-time communication, tunneling, and resource discovery.

Table of Contents

1. IMAP
2. FTP
3. SIP
4. RTP
5. PPTP
6. TFTP
7. RLP

1. IMAP (Internet Message Access Protocol)

What is IMAP?

IMAP is an email retrieval protocol that allows users to access and manage emails directly on the mail server — without downloading them permanently to a local device. Unlike POP3 which takes emails off the server, IMAP keeps everything on the server and synchronizes state across devices.

Key Insight: IMAP makes email work like a cloud-based service — mark a message as read on your phone, and it shows as read on your laptop. This seamless multi-device experience is why IMAP replaced POP3 for most users.

IMAP vs POP3 — Detailed Comparison

IMAP Session Flow — Detailed

CLIENT (Thunderbird/Outlook) IMAP SERVER (Dovecot/Exchange)
| |
|=== Connection & Auth ===================|
|--- TCP SYN (port 143) ---------------->|
|<-- TCP SYN-ACK -------------------------|
|--- TCP ACK ---------------------------->|
|<-- * OK IMAP server ready --------------|
| |
|--- a001 LOGIN "user" "password" ------->| (or a001 AUTHENTICATE)
|<-- a001 OK LOGIN completed -------------|
| |
|=== Folder Selection ====================|
|--- a002 LIST "" "*" ------------------->| List all folders
|<-- * LIST (\HasNoChildren) "/" INBOX ----|
|<-- * LIST (\HasNoChildren) "/" Sent ----|
|<-- * LIST (\HasNoChildren) "/" Drafts --|
|<-- a002 OK LIST completed --------------|
| |
|--- a003 SELECT INBOX ------------------>| Open Inbox
|<-- * 42 EXISTS -------------------------| 42 messages
|<-- * 1 RECENT --------------------------| 1 new message
|<-- * FLAGS (\Seen \Answered \Flagged ...)|
|<-- a003 OK [READ-WRITE] SELECT completed|
| |
|=== Message Retrieval ===================|
|--- a004 FETCH 1:42 (FLAGS) ------------>| Get flags for all messages
|<-- * 1 FETCH (FLAGS (\Seen)) ----------|
|<-- ... |
|<-- a004 OK FETCH completed -------------|
| |
|--- a005 FETCH 42 (BODY[HEADER]) ------->| Get header of newest
|<-- * 42 FETCH (BODY[HEADER] {342} |
| Date: Wed, 17 Jul 2024 14:30:00 |
| From: Alice <alice@example.com> |
| To: Bob <bob@example.com> |
| Subject: Meeting reminder |
| Message-ID: <abc123@example.com> |
| ) |
|<-- a005 OK FETCH completed -------------|
| |
|--- a006 FETCH 42 (BODY[TEXT]) --------->| Fetch just the body
|<-- * 42 FETCH (BODY[TEXT] {1200} |
| Hi Bob, Don't forget our meeting... |
| ) |
|<-- a006 OK FETCH completed -------------|
| |
|=== Message Manipulation ================|
|--- a007 STORE 42 +FLAGS (\Seen) ------->| Mark as read
|<-- a007 OK STORE completed -------------|
|--- a008 COPY 42 "Archive" ------------->| Move to Archive
|<-- a008 OK COPY completed -------------|
|--- a009 STORE 42 +FLAGS (\Deleted) ---->| Mark for deletion
|<-- a009 OK STORE completed -------------|
| |
|=== Search Folder =======================|
|--- a010 SEARCH FROM "Alice" ----------->| Search on server
|<-- * SEARCH 3 15 22 40 42 ------------|
|<-- a010 OK SEARCH completed ------------|
| |
|=== IDLE (Push Notification) ============|
|--- a011 IDLE -------------------------->| Enter idle mode
|<-- + idling ---------------------------| Server: I'll wait
| |
| ... New mail arrives! |
| |
|<-- * 43 EXISTS ------------------------| Server pushes notification
|<-- * 44 EXISTS ------------------------| Another arrives
|<-- * 2 RECENT -------------------------|
| |
|--- DONE ------------------------------->| Leave idle mode
|<-- a011 OK IDLE terminated ------------|
| |
|=== Logout ==============================|
|--- a012 LOGOUT ------------------------>|
|<-- * BYE IMAP server closing -----------|
|<-- a012 OK LOGOUT completed ------------|

Complete IMAP Commands Reference

IMAP FETCH Items — What You Can Retrieve

IMAP Server Configuration

Dovecot IMAP Server (Linux):

# /etc/dovecot/dovecot.conf
protocols = imap pop3
listen = *, ::

ssl = required
ssl_cert = </etc/letsencrypt/live/mail.example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.example.com/privkey.pem

# Authentication
auth_mechanisms = plain login
!include auth-passwdfile.conf.ext

# Mail location
mail_location = maildir:~/Maildir

# IMAP specific settings
protocol imap {
mail_max_userip_connections = 10
imap_client_workarounds = tb-extra-mailbox-sep
}

# Limits
mail_max_userip_connections = 10
mail_attachment_dir = /var/mail/attachments

# Services
service imap-login {
inet_listener imap {
port = 143
}
inet_listener imaps {
port = 993
ssl = yes
}
}

IMAP Testing

# Manual IMAP test with openssl
openssl s_client -connect mail.example.com:993 -crlf

# After connecting:
? LOGIN username password
? LIST "" "*"
? SELECT INBOX
? FETCH 1:* (FLAGS)
? FETCH 1 BODY[HEADER]
? LOGOUT

# Test with netcat (plain IMAP)
nc -C mail.example.com 143

# Common IMAP errors:
# a001 NO [AUTHENTICATIONFAILED] — Wrong password
# a001 BAD [Server doesn't support command]
# * BYE [Server timeout/closing connection]

IMAP Security

2. FTP (File Transfer Protocol)

What is FTP?

FTP is a standard network protocol for transferring files between a client and a server. It is one of the oldest protocols still in use (1985), designed for reliable file transfers with directory navigation, authentication, and various transfer modes.

Key Insight: FTP uses TWO separate connections — a control connection (port 21) for commands and a data connection (port 20 or ephemeral) for actual file data. This separation is both its strength and its complexity.

FTP Connection Modes — Detailed

Active Mode (PORT)

CLIENT SERVER
| |
|==== Control Connection =====|
|--- TCP SYN (port 21) ---> |
|<-- TCP SYN-ACK ----------- |
|--- TCP ACK -------------- ->|
| |
|--- PORT 192,168,1,10,6,200 -| "I'm listening on 192.168.1.10:1736"
|<-- 200 PORT command successful |
| |
|--- LIST ------------------>| "List directory"
| |
|==== Data Connection ========| (from SERVER to CLIENT)
|<-- TCP SYN (from port 20 | Server connects TO client
| to client port 1736) |
|--- TCP SYN-ACK ----------- | PROBLEM: Client firewall may block!
|--- TCP ACK -------------- ->| (Unsolicited incoming SYN)
| |
|<-- 150 Opening data connection |
|<-- (directory listing) ----|
|<-- 226 Transfer complete --|

Passive Mode (PASV) — Preferred

CLIENT SERVER
| |
|==== Control Connection =====|
|--- TCP SYN (port 21) ---> |
|<-- TCP SYN-ACK ----------- |
|--- TCP ACK -------------- ->|
| |
|--- PASV ------------------>| "Tell me which port to connect to"
|<-- 227 Entering Passive Mode |
| (192,168,1,1,34,210) | "Connect to 192.168.1.1:8914"
| |
|==== Data Connection ========| (from CLIENT to SERVER)
|--- TCP SYN (client port X ->| Client initiates connection
| to server port 8914) | Firewall-friendly!
|<-- TCP SYN-ACK ----------- |
|--- TCP ACK -------------- ->|
| |
|--- LIST ------------------>| (over control channel)
|<-- 150 Opening data connection |
|<-- (directory listing ---- | (over data channel)
|<-- 226 Transfer complete --|

FTP Session — Complete Example

Connected to ftp.example.com.
220 FTP server ready.

# Authentication
USER alice
331 Password required for alice.
PASS *******
230 User alice logged in.

# System info
SYST
215 UNIX Type: L8

# Directory navigation
PWD
257 "/home/alice" is current directory.
CWD documents
250 CWD command successful.
PWD
257 "/home/alice/documents" is current directory.

# List files
PASV
227 Entering Passive Mode (192,168,1,1,112,203)
LIST
150 Here comes the listing.
-rw-r--r-- 1 alice alice 1234 Jul 17 10:00 report.pdf
-rw-r--r-- 1 alice alice 56789 Jul 16 15:30 data.tar.gz
drwxr-xr-x 2 alice alice 4096 Jul 15 09:00 photos
226 Directory send OK.

# Download file
PASV
227 Entering Passive Mode (192,168,1,1,112,204)
RETR report.pdf
150 Opening BINARY mode data connection for report.pdf (1234 bytes).
226 Transfer complete.
Downloaded: 1234 bytes in 0.02 seconds (61.7 KB/s)

# Upload file
PASV
227 Entering Passive Mode (192,168,1,1,112,205)
STOR notes.txt
150 Opening BINARY mode data connection for notes.txt.
226 Transfer complete.

# Transfer mode
TYPE A
200 Type set to A (ASCII).

TYPE I
200 Type set to I (Binary/Image).

# Delete
DELE old_file.txt
250 DELE command successful.

# Make/remove directory
MKD new_folder
257 "new_folder" created.
RMD old_folder
250 RMD command successful.

# Quit
QUIT
221 Goodbye.

FTP Commands — Complete Reference

FTP Transfer Modes

Important: Transferring a binary file in ASCII mode WILL corrupt it! FTP automatically converts CR/LF in ASCII mode, which changes binary file content.

FTP Client Commands

# Command-line FTP client
ftp ftp.example.com
ftp -p ftp.example.com # Passive mode (firewall-friendly)

# Download all .pdf files
ftp> mget *.pdf

# Upload all .html files
ftp> mput *.html

# Interactive prompting
ftp> prompt # Toggle confirmation per file

# Recursive (use with caution)
ftp> mget -R directory/ # Linux/BSD

# Scripted FTP
ftp -n < ftp_commands.txt # Non-interactive

FTP vs SFTP vs FTPS — Detailed Comparison

FTP Security — Plaintext Demonstration

Without encryption (standard FTP):

tcpdump -X -i eth0 port 21

Captured (all visible!):
────────────────────────────────
USER alice ← Visible!
PASS SuperSecret123 ← Visible! STOLEN!
RETR confidential_report.pdf ← Visible!
STOR payroll_data.xlsx ← Visible!

Data connection:
[encrypted_nothing.jpg] ← Visible file content!

MODERN FIX: Use SFTP or FTPS

Secure FTP Options

# SFTP (part of OpenSSH) — RECOMMENDED
sftp alice@example.com
sftp> get confidential.pdf # Encrypted over SSH

# FTPS (vsftpd with TLS)
# /etc/vsftpd.conf
ssl_enable=YES
ssl_tlsv1_2=YES
ssl_ciphers=HIGH
rsa_cert_file=/etc/pki/tls/certs/vsftpd.pem
require_ssl_reuse=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES

3. SIP (Session Initiation Protocol)

What is SIP?

SIP is a signaling protocol used for initiating, maintaining, modifying, and terminating real-time communication sessions — voice calls (VoIP), video calls, instant messaging, and other multimedia sessions.

Key Insight: SIP is to voice/video calls what HTTP is to web pages. It's a text-based request/response protocol that sets up and tears down multimedia sessions. The actual media (audio/video) flows through a separate protocol — RTP.

SIP Architecture

┌─────────────────────┐
│ DNS Server │
│ (SRV records for │
│ sip.example.com) │
└──────────┬──────────┘
│
▼
┌──────────┐ SIP ┌─────────────────────┐ SIP ┌──────────┐
│ SIP Phone │ ───────→│ SIP Proxy/Registrar │ ←───────│ SIP Phone │
│ (Alice) │ ←───────│ (Call Control) │ ───────→│ (Bob) │
└─────┬─────┘ └─────────────────────┘ └─────┬─────┘
│ │ │
│ RTP │ RTP │
│ (Audio Stream) │ (Audio Stream) │
└──────────────────────┼──────────────────────────────┘
│
┌──────────▼──────────┐
│ Media can flow │
│ direct (peer-to- │
│ peer) or through │
│ a Media Gateway │
└─────────────────────┘

SIP Message Format (Text-based — Like HTTP)

───────────────────────────────────────────────────────────────
INVITE sip:bob@example.com SIP/2.0 ← Request Line
Via: SIP/2.0/UDP 192.168.1.10:5060 ← Transport path
Max-Forwards: 70
From: Alice <sip:alice@example.com> ← Sender
To: Bob <sip:bob@example.com> ← Recipient
Call-ID: abc123def456@192.168.1.10 ← Unique session ID
CSeq: 1 INVITE ← Sequence number
Contact: <sip:alice@192.168.1.10:5060> ← Direct contact
Content-Type: application/sdp ← Session description
Content-Length: 152 ← Body length

[Blank line — separates headers from body]

v=0 ← SDP body starts
o=alice 2890844526 2890844526 IN IP4 192.168.1.10
s=-
c=IN IP4 192.168.1.10
t=0 0
m=audio 49170 RTP/AVP 0 8 101 ← Media description
a=rtpmap:0 PCMU/8000 ← Codec: G.711 μ-law
a=rtpmap:8 PCMA/8000 ← Codec: G.711 A-law
a=rtpmap:101 telephone-event/8000 ← DTMF tones
───────────────────────────────────────────────────────────────

SIP Methods (Request Types)

SIP Response Codes (Status Codes)

Important SIP Response Codes

100 Trying ── "Working on it..."
180 Ringing ── "Phone is ringing!"
183 Session Progress ── "Early media (ringback tone)"
200 OK ── "Call answered!"
302 Moved Temporarily── "User is at another address"
401 Unauthorized ── "Need authentication"
404 Not Found ── "User doesn't exist"
486 Busy Here ── "On another call"
487 Request Canceled ── "Caller hung up before answer"
603 Decline ── "User rejected the call"

SIP Call Flow — Complete Example

Alice's SIP Phone SIP Proxy Bob's SIP Phone
(sip:alice@example.com) (sip.example.com) (sip:bob@example.com)
│ │ │
│ │ │
│ REGISTER │ │
│ (Tells proxy: "Alice │ │
│ is at 192.168.1.10") │ │
│─────────────────────────>│ REGISTER │
│ 200 OK │ "Bob is at │
│<─────────────────────────│ 203.0.113.50" │
│ │<────────────────────────│
│ │ 200 OK │
│ │────────────────────────>│
│ │ │
│=== Alice calls Bob ======│ │
│ │ │
│ INVITE bob@example.com │ │
│─────────────────────────>│ INVITE (looks up Bob) │
│ 100 Trying │────────────────────────>│
│<─────────────────────────│ 180 Ringing │
│ │<────────────────────────│
│ 180 Ringing │ │
│<─────────────────────────│ │
│ │ Bob answers! │
│ │ 200 OK │
│ │<────────────────────────│
│ 200 OK │ │
│<─────────────────────────│ │
│ │ │
│ ACK │ │
│───────────────────────────────────────────────────>│ (Direct ACK to Bob)
│ │ │
│ │ │
│<========= RTP Media (Audio) ======================>│ Media flows direct!
│<========= Bidirectional voice =====================>│ (Peer-to-peer)
│ │ │
│ │ │
│=== Bob hangs up ========│ │
│ │ │
│ BYE (from Bob) │ │
│<───────────────────────────────────────────────────│
│ 200 OK │ │
│───────────────────────────────────────────────────>│
│ │ │

SDP (Session Description Protocol)

SDP describes the media part of a SIP session — what codecs, ports, and formats to use.

v=0 ← SDP version
o=alice 2890844526 2890844526 ← Owner (username, session ID, version)
IN IP4 192.168.1.10 ← Owner's address
s=- ← Session name
c=IN IP4 192.168.1.10 ← Connection info
t=0 0 ← Time (0 = permanent)
m=audio 49170 RTP/AVP 0 8 97 ← Media: audio on port 49170, codecs 0,8,97
a=rtpmap:0 PCMU/8000 ← Codec 0 = G.711 μ-law
a=rtpmap:8 PCMA/8000 ← Codec 8 = G.711 A-law
a=rtpmap:97 telephone-event/8000 ← Codec 97 = DTMF
a=sendrecv ← Both directions
m=video 51372 RTP/AVP 99 ← Media: video on port 51372
a=rtpmap:99 H264/90000 ← Codec 99 = H.264 video
a=fmtp:99 packetization-mode=1 ← H.264 parameters

SIP Configuration Example

FreeSwitch PBX Configuration:

<!-- SIP Profile -->
<gateway name="provider1">
<param name="realm" value="sip.provider1.com"/>
<param name="username" value="user123"/>
<param name="password" value="secret"/>
<param name="register" value="true"/>
<param name="register-transport" value="udp"/>
<param name="expire-seconds" value="300"/>
</gateway>

<!-- User Extension -->
<user id="1001">
<params>
<param name="password" value="user1001pass"/>
<param name="vm-password" value="1001"/>
</params>
</user>

Asterisk SIP Configuration:

; /etc/asterisk/sip.conf
[general]
context=public
port=5060
bindaddr=0.0.0.0
srvlookup=yes

[1001] ; Extension 1001
type=friend
host=dynamic
secret=pass1001
context=internal
qualify=yes
nat=force_rport,comedia

[trunk-sip-provider]
type=peer
host=sip.provider.com
username=user123
secret=myproviderpass
fromuser=123456

SIP Commands & Testing

# Manual SIP test with netcat
cat > sip_invite.txt << EOF
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=1928301774
To: Bob <sip:bob@example.com>
Call-ID: a84b4c76e66710
CSeq: 1 INVITE
Contact: <sip:alice@192.168.1.10>
Content-Type: application/sdp
Content-Length: 0

EOF

nc -u 192.168.1.20 5060 < sip_invite.txt

# SIPp testing tool
sipp -sf uac.xml -i 192.168.1.10 sip.proxy.com:5060

# Wireshark SIP filter
sip || sdp

SIP Security Issues

4. RTP (Real-time Transport Protocol)

What is RTP?

RTP is designed for delivering audio and video over IP networks in real-time. It is the standard protocol for streaming media in VoIP, video conferencing, IPTV, and online gaming. RTP works together with RTCP (RTP Control Protocol) which provides feedback on transmission quality.

Key Insight: RTP doesn't guarantee timely delivery — it provides the tools (timestamps, sequence numbers, payload identification) that applications need to reconstruct and play real-time media. QoS is handled by the underlying network.

RTP Packet Header — Detailed Structure

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Synchronization Source (SSRC) Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contributing Source (CSRC) Identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Payload |
| (Audio/Video Data) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTP Header Fields

RTP Payload Types (PT Values)

Jitter Buffer — How RTP Handles Network Variation

Network Packets (irregular arrival):
───────────────────────────────────────
Time → 1 2 3 4 5 6 ...
↑
Jitter!

Jitter Buffer (smoothing):
───────────────────────────────────────
┌─────────────────────────┐
│ Jitter Buffer │
│ [1][2][3][4][5][6]... │
└─────────────────────────┘
│
▼
Playout (regular intervals):
───────────────────────────────────────
Time → 1 2 3 4 5 6 7 8 ...

How it works:
1. Packet 4 arrives late (after packet 5)
2. Jitter buffer holds packets temporarily
3. Sequence numbers reorder: 3 → 4 → 5 → 6
4. Timestamps tell the codec when to play each sample
5. Smooth audio output (at cost of some delay)

RTP vs RTCP vs SRTP

RTCP Packet Types

RTCP Reports Include:

• Packet loss rate
• Cumulative packets lost
• Interarrival jitter
• Round-trip time (delay)
• Last SR timestamp
• Delay since last SR

RTP Tools & Commands

# RTP analysis with Wireshark/TShark
tshark -r capture.pcap -Y rtp

# RTP stream analysis
tshark -r capture.pcap -Y "rtp" -T fields -e rtp.ssrc -e rtp.seq -e rtp.timestamp

# Detect RTP packet loss
tshark -r capture.pcap -Y "rtp" -T fields -e rtp.ssrc -e rtp.seq | sort

# Play raw RTP stream
ffplay -f mulaw -ar 8000 -ac 1 rtp://@:5004

# RTP dump
rtpdump -F payload -f capture.rtp

# Estimate jitter
tshark -r capture.pcap -Y rtp -T fields -e frame.time_relative -e rtp.seq

# Common RTP issues:
# - High jitter (>20ms) → poor audio quality
# - Packet loss (>5%) → choppy audio/video
# - Out-of-order packets → check sequence numbers

RTP Issues & Solutions

5. PPTP (Point-to-Point Tunneling Protocol)

What is PPTP?

PPTP is a VPN tunneling protocol developed by Microsoft (1999) that encapsulates PPP (Point-to-Point Protocol) packets into IP datagrams for transmission over IP networks. It was widely used in the late 1990s and early 2000s for remote access VPNs.

Key Insight: PPTP was revolutionary for its time (the first widely-available Microsoft VPN protocol), but it is now completely broken from a security perspective. Every major security researcher recommends against its use.

How PPTP Works — Technical Details

PPTP Packet Structure:
┌──────────────────────────────────────────────────────────────┐
│ IP Header (Protocol 47 = GRE) │
├──────────────────────────────────────────────────────────────┤
│ GRE Header │
│ ┌─────┬──────┬──────────────────────────────────────────┐ │
│ │ C/R │ Key │ Protocol Type (0x880B = PPP) │ │
│ └─────┴──────┴──────────────────────────────────────────┘ │
├──────────────────────────────────────────────────────────────┤
│ PPP Frame (Encapsulated) │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ PPP Header │ Encrypted Data │ Padding │ CRC │ │
│ └──────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘

PPTP Connection Process

PPTP Client PPTP Server (RAS/VPN)
| |
|=== TCP Control (Port 1723) ===========|
|--- TCP SYN + ACK + ESTABLISHED ------>|
| |
|--- Start-Control-Connection-Request ->|
|<-- Start-Control-Connection-Reply ----|
| |
|--- Outgoing-Call-Request ------------>|
|<-- Outgoing-Call-Reply ---------------|
| |
|=== GRE Tunnel Established ============|
| |
|=== PPP Negotiation (over GRE) ========|
|--- LCP Configure-Request ------------>| (Link Control)
|<-- LCP Configure-Ack -----------------|
| |
|--- PAP or CHAP/MS-CHAPv2 =============>
| (Authentication — PLAINTEXT or weak)|
|<-- Auth Success ---------------------|
| |
|--- MPPE Encryption Keys Established ->| (RC4 — WEAK!)
| |
|=== IPCP (IP Address) =================|
|--- IPCP Configure-Request ----------->| (Get IP address)
|<-- IPCP Configure-Ack + IP Address ---|
| |
|=== Data Transfer (Encrypted PPP over GRE) ==========|
| |
|=== Tear Down =========================|
|--- Clear-Call-Request --------------->|
|<-- Clear-Call-Reply ------------------|

PPTP Encryption — Why It's Broken

PPTP Configuration (Legacy — for reference only)

Windows Server PPTP (historical):

# Enable VPN server
Install-RemoteAccess -VpnType Vpn

# Allow PPTP connections
Set-VpnAuthProtocol -UserAuthenticationProtocol EAP

Linux PPTP Client (historical):

# /etc/ppp/peers/vpn-provider
pty "pptp vpn.example.com --nolaunchpppd"
name username
password password
remotename PPTP
require-mppe-128
noauth
persist
maxfail 0
defaultroute
replacedefaultroute

PPTP vs Modern VPN Protocols

6. TFTP (Trivial File Transfer Protocol)

What is TFTP?

TFTP is a simplified, connectionless file transfer protocol built on UDP. It is much simpler than FTP — no authentication, no directory listing, no fancy features — just read and write files. This simplicity makes it ideal for booting diskless workstations (PXE), loading firmware onto network devices (routers, switches), and network appliance configuration.

Key Insight: TFTP's lack of security is by design. It's meant for use in controlled, local environments where simplicity and small code footprint matter more than security.

TFTP Protocol — 5 Operations Only

TFTP Transfer Flow — "Stop and Wait"

TFTP CLIENT TFTP SERVER
| |
|====== Read Request (RRQ) ============|
|--- RRQ (Op=1) file="config.txt" --->|
| mode="octet" |
| |
|====== Data Transfer =================|
|<-- DATA (Op=3) Block=1, 512 bytes ---|
|--- ACK (Op=4) Block=1 ------------->|
| |
|<-- DATA (Op=3) Block=2, 512 bytes ---|
|--- ACK (Op=4) Block=2 ------------->|
| |
| ... (repeats for each 512-byte block)|
| |
|<-- DATA (Op=3) Block=N, 400 bytes ---| (Last block < 512 bytes
|--- ACK (Op=4) Block=N ------------->| signals end of transfer)
| |
|====== Transfer Complete =============|
| |

NOTE: Each block MUST be ACKed before next block is sent.
If ACK is lost, sender retransmits after timeout.
This is called "stop-and-wait" — simple but slow.

512-Byte Block Rule

If transfer size is exactly a multiple of 512:
A final DATA packet with 0 bytes is sent
(The payload < 512 bytes is the "end" signal)

Example: 1024-byte file:
Block 1: 512 bytes → ACK 1
Block 2: 512 bytes → ACK 2
Block 3: 0 bytes → ACK 3 (DONE!)

TFTP Configuration

Linux TFTP Server (tftpd-hpa):

# Install
sudo apt install tftpd-hpa

# /etc/default/tftpd-hpa
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot" # Root directory for TFTP
TFTP_ADDRESS="0.0.0.0:69" # Listen on all interfaces
TFTP_OPTIONS="--secure --create" # --secure = chroot, --create = allow upload

# Set permissions
sudo mkdir -p /var/lib/tftpboot
sudo chmod 777 /var/lib/tftpboot
sudo chown tftp:tftp /var/lib/tftpboot

# Restart
sudo systemctl restart tftpd-hpa

Cisco TFTP Configuration (for firmware/backup):

! Backup running config to TFTP server
copy running-config tftp://192.168.1.100/config-backup.txt

! Restore config from TFTP
copy tftp://192.168.1.100/config-backup.txt running-config

! Upgrade IOS
copy tftp://192.168.1.100/c2960-lanbasek9-mz.150-2.SE.bin flash:
reload

! Backup IOS image
copy flash:c2960-lanbasek9-mz.150-2.SE.bin tftp://192.168.1.100/

TFTP Commands

# Linux TFTP client
tftp 192.168.1.100
tftp> get firmware.bin # Download file
tftp> put log.txt # Upload file
tftp> verbose # Show transfer details
tftp> binary # Set binary mode (octet)
tftp> ascii # Set ASCII mode
tftp> status # Show connection status
tftp> timeout 30 # Set retransmission timeout
tftp> trace # Enable packet tracing
tftp> quit

# One-liner
tftp 192.168.1.100 -c get firmware.bin
tftp 192.168.1.100 -c put output.txt

# Windows TFTP (enable in Features first)
tftp -i 192.168.1.100 GET firmware.bin
tftp -i 192.168.1.100 PUT log.txt

TFTP vs FTP vs SFTP

TFTP Limitations

7. RLP (Resource Location Protocol)

What is RLP?

RLP is one of the earliest resource discovery protocols, designed to help clients find network services and resources by name or description. It was developed in the early days of the internet to allow hosts to discover services like printers, file servers, and other network resources on a local network.

Key Insight: RLP was an early attempt at service discovery — a concept that later evolved into protocols like SLP (Service Location Protocol, RFC 2608), DNS-SD (DNS Service Discovery, RFC 6763), and mDNS (Multicast DNS, RFC 6762). RLP itself is largely obsolete.

How RLP Works

RLP CLIENT RLP SERVER/AGENT
| |
|=== Query ============================|
|--- RLP Request (UDP port 39) ------->|
| (Ask for resources matching |
| specific attributes or type) |
| |
|=== Response =========================|
|<-- RLP Response ---------------------|
| (List of matching resources |
| with location information) |
| |
|=== Client uses resource =============|
|--- (e.g., connects to found service)|

RLP Resource Types

RLP defines various resource types that can be located:

RLP vs Modern Service Discovery Protocols

RLP Limitations

Bonus: Complete Protocol Port & Layer Reference