Skip to Content

FNC_Day_02_Morning_Lecture

═══════════════════════════════════════════════════════════════════ RESTRICTED DISTRIBUTION — DICDP PROGRAM PARTICIPANTS ONLY ═══════════════════════════════════════════════════════════════════

═══════════════════════════════════════════════════════════════════
RED IRISH GLOBAL SERVICES
Defense Information Capacity Development Program (DICDP)
Communications and Information Systems (CIS) Track — Foundation Level
Foundation Networking Course | Day 02 Morning Lecture Notes
Document ID: DICDP-CIS-FNC-D02-LN-AM-v2
Issued: [date of determination]
Controlled by: Program Director, DICDP, Red Irish Global Services
Redirect requests: ops@redirish.global
Distribution: RESTRICTED — Program participants only
═══════════════════════════════════════════════════════════════════

Restricted Distribution Statement

This material is the intellectual property of Red Irish Global Services. Distribution is authorized only to participants enrolled in the Defense Information Capacity Development Program (DICDP). Reproduction, transmission, posting to public networks or social media, sharing with non-participants, or use as the basis for derivative training materials, in whole or in part, requires prior written authorization from Red Irish Global Services. Other requests shall be referred to: ops@redirish.global

Day 2 — The OSI Model and TCP/IP Suite

MORNING SESSION — The Models and the Layers

Document ID: DICDP-CIS-FNC-D02-LN-AM-v2 Version: v2.0

Opening — From Yesterday's Frame to Today's Inside View

Yesterday you built the frame.

You learned what a DoD network is, what makes a host a DoD host, what NIPRNet / SIPRNet / JWICS are, what the DoDIN / DISN / DISA structure looks like from above, what the Four Rules are, and how the RMF turns a piece of equipment into an authorized system. You walked away with a clear picture of the outside — what the DoD network environment looks like at the enterprise level.

Today you go inside.

The morning session covers two universal networking models — the OSI Model and the TCP/IP Model — and then walks through what each OSI layer actually looks like inside a DoD network. By lunch you will be able to point at any device, any cable, any session, and say which OSI layer it operates at and which DoD-specific controls apply to it.

The afternoon session takes the most operationally important layer — Layer 4 (Transport) — and goes deep on PPSM (Ports, Protocols, and Services Management), the DoD program that controls which ports and protocols are allowed to cross DoDIN boundaries. It also covers the analytical methodology — "trust nothing, verify everything" — that you will apply in the lab.

But you should know one thing before any of that.

The TCP/IP model — the model the entire Internet runs on — is a Department of Defense invention.

You are not just learning networking models. You are learning something your organization created. Every web page that loads, every email that sends, every video call that connects, anywhere in the world — uses a protocol stack that came out of a DoD research project in the 1960s.

This is your heritage. Pay attention.

Part 1 — Your Heritage: TCP/IP Is a DoD Invention

The Short History

Year

Event

1969

DARPA (Defense Advanced Research Projects Agency) funds ARPANET — the first packet-switched network, connecting four US universities. This is the ancestor of the Internet.

1973–1974

Vint Cerf (Stanford) and Bob Kahn (DARPA), working under DARPA contract, collaborate on the design of a new internetworking protocol. Their paper "A Protocol for Packet Network Intercommunication" is submitted in November 1973 and published in IEEE Transactions on Communications in May 1974. The 1974 paper described a single protocol called TCP — at this stage it combined what we now call both the transport and network functions.

1978

Cerf and Jon Postel propose splitting it into two separate protocols: IP (network layer) and TCP (transport layer).

1981

IP (Internet Protocol) specification published as RFC 791 (September 1981). TCP specification published as RFC 793 (September 1981). Both resulted from the TCP/IP split.

January 1, 1983

"Flag Day" — ARPANET officially switches from the older NCP protocol to TCP/IP. This is the birth date of the modern Internet.

Later 1980s

DoD adopts TCP/IP as the standard for all military networking.

1990s onward

TCP/IP spreads globally as the basis of the commercial Internet.



Why This Matters for You

The civilian lecture notes call the four-layer model the "TCP/IP model" or the "DoD model." Both names are correct. They refer to the same thing.

  • DoD invented it.

  • DoD funded the research.

  • DoD published the first standards.

  • DoD adopted it before the world did.

When you operate on the DoDIN, you are using the same fundamental protocol stack that DoD has used for over forty years.

Reference: Joint Publication 6-0 — Joint Communications System — provides joint doctrine on military communications, including the origins of DoD networking.

Part 2 — The Universal OSI Model

The OSI model itself is not a DoD product. It was developed by the ISO (International Organization for Standardization) in 1984 as an international standard.

The seven OSI layers are the same in DoD as everywhere else:

Layer

Name

7

Application

6

Presentation

5

Session

4

Transport

3

Network

2

Data Link

1

Physical



The civilian lecture covered each layer in detail. This document does not repeat that.

What changes in the DoD world is not the model — it is the discipline applied at every layer. Every layer of OSI has DoD-specific rules, protections, and policies layered on top of the universal standard. That is the focus of the rest of this morning's lecture: same model, different reality.

Part 3 — Encapsulation, PDUs, and the TCP/IP Mapping

Before walking the seven layers through the DoD lens, three foundational concepts need to be solid. These are the vocabulary the rest of the course uses constantly — every lab exercise, every PPSM declaration, every troubleshooting decision relies on them.

Why Network Models Exist

A network model is not a piece of equipment you can buy. It is a shared blueprint that every vendor's products follow so devices from different manufacturers can talk to each other.

In the early days of networking — the 1970s and 1980s — equipment was proprietary. A router from one vendor could not exchange packets with a switch from another. A global network like the Internet, where billions of devices from thousands of manufacturers communicate seamlessly, would have been impossible.

Reference models — OSI and TCP/IP — solved this by defining the rules that every manufacturer follows. The result: a Cisco router talks to a Juniper firewall talks to a Microsoft server talks to a Linux workstation — because all of them implement the same protocol stack at each layer.

For DoD this is doubly important. The DoDIN connects equipment from dozens of vendors across thousands of installations across decades of procurement. Without a shared model, none of it would interoperate. The models are what makes the DoDIN possible as a single network instead of an archipelago of incompatible systems.

Memory Aids — The Two Mnemonics

Students remember mnemonics. These are the standard ones used worldwide for the OSI layer order.

Direction

Mnemonic

What it spells

Layer 1 → 7 (bottom up)

"Please Do Not Throw Sausage Pizza Away"

Physical · Data Link · Network · Transport · Session · Presentation · Application

Layer 7 → 1 (top down)

"All People Seem To Need Data Processing"

Application · Presentation · Session · Transport · Network · Data Link · Physical



You will use both directions. Sending data flows top-down (7 → 1). Receiving data flows bottom-up (1 → 7). Knowing the order forward and backward is foundational.

The Two Models — OSI and TCP/IP — and How They Map

OSI has seven layers. TCP/IP has four. They model the same network behavior at different levels of granularity. Every networking professional needs to be able to flip between them.

TCP/IP Layer (4-layer model)

OSI Layers it covers

Protocols at this layer

Application

OSI 7, 6, 5 (Application, Presentation, Session)

HTTP, HTTPS, FTP, SFTP, SMTP, DNS, SSH, SNMP

Host-to-Host (also called Transport)

OSI 4 (Transport)

TCP, UDP

Internet

OSI 3 (Network)

IP, ICMP, routing protocols

Network Access (also called Link)

OSI 2 and 1 (Data Link, Physical)

Ethernet, Wi-Fi, fiber, copper



OSI's upper three layers (Session, Presentation, Application) collapse into TCP/IP's single Application layer. OSI's lower two (Data Link, Physical) collapse into TCP/IP's Network Access. The middle two — Transport at OSI 4 = TCP/IP Host-to-Host, and Network at OSI 3 = TCP/IP Internet — map one-to-one.

Why both models matter: OSI is the thinking and teaching framework. TCP/IP is what the actual Internet and the DoDIN run on. Engineers troubleshoot with OSI ("the problem is at Layer 3") but configure equipment for TCP/IP. You need both.

PDUs — The Vocabulary at Each Layer

Every layer of the OSI model has a specific name for the unit of data it handles. These names are called Protocol Data Units (PDUs).

OSI Layer

PDU Name

What is added at this layer

7 — Application

Data

User data (e.g., the contents of an HTTP request)

6 — Presentation

Data

Formatting, encryption, compression

5 — Session

Data

Session control information

4 — Transport

Segment (TCP) / Datagram (UDP)

L4 header — source port, destination port, sequencing, flags

3 — Network

Packet

L3 header — source IP, destination IP, TTL, protocol field

2 — Data Link

Frame

L2 header (source MAC, destination MAC, EtherType) + trailer (Frame Check Sequence)

1 — Physical

Bit

Raw electrical signals, light pulses, or radio waves — no header is added at L1



A critical detail: Layer 2 is the only layer that adds both a header and a trailer. The trailer is the Frame Check Sequence (FCS) — a checksum that lets the receiving device verify the frame was not corrupted in transit. If the FCS does not match, the frame is dropped.

You will hear these PDU names every day for the rest of the course. Segment, packet, frame, bit is the standard shorthand. When someone says "a packet arrived at the router," they mean a Layer 3 PDU. When someone says "the switch dropped the frame," they mean a Layer 2 PDU with a failed FCS. Speak the language correctly.

Encapsulation — How Data Travels Down

When a workstation sends data, that data starts at Layer 7 (Application) and travels down the stack. At each layer, a header (and at Layer 2, a trailer) is added, wrapping the data from the layer above. This wrapping process is called encapsulation.

SENDING SIDE — Encapsulation (top to bottom)

L7 Application Browser invokes HTTPS → produces "Data"
|

L6 Presentation Data may be formatted/encrypted → still "Data"
|

L5 Session Session info added → still "Data"
|

L4 Transport TCP header added (source port, dest port,
| sequence number, flags) → result is a SEGMENT

L3 Network IP header added (source IP, dest IP, TTL,
| protocol) → result is a PACKET

L2 Data Link Ethernet header added (source MAC, dest MAC,
| EtherType) + FCS trailer → result is a FRAME

L1 Physical Frame converted to electrical signals,
light pulses, or radio waves → BITS on the wire

Each layer treats the entire output of the layer above as opaque payload — it does not look inside. It just wraps it with its own header and passes it down. This is why the model works: each layer is independent and substitutable. You can swap copper for fiber at Layer 1 without affecting any other layer. You can swap TCP for QUIC at Layer 4 without affecting routing at Layer 3.

De-encapsulation — How Data Travels Up

When the destination workstation receives the bits, the reverse happens. Bits are assembled into a frame, the frame's headers are validated and stripped to reveal a packet, the packet's headers are validated and stripped to reveal a segment, and so on — all the way up to Data at Layer 7.

RECEIVING SIDE — De-encapsulation (bottom to top)

L1 Physical Receives bits from the wire → assembles a FRAME
|

L2 Data Link Validates FCS, checks destination MAC,
| strips L2 header + trailer → PACKET

L3 Network Checks destination IP, validates TTL,
| strips L3 header → SEGMENT

L4 Transport Validates checksum, reassembles segments
| in order, strips L4 header → Data

L5 Session Routes Data to the correct session
|

L6 Presentation Decrypts, decompresses, formats → Data
|

L7 Application Delivered to the receiving application
(e.g., the web server software)

Same-layer communication. Layer N on the sending device talks logically to Layer N on the receiving device. The Layer 4 headers a sending workstation writes are read by the Layer 4 of the receiving workstation. The Layer 3 headers a sending router writes are read by the Layer 3 of the next router. This is same-layer communication — peers at the same layer on different devices.

Adjacent-layer communication. Within one device, Layer N talks to Layer N-1 (down) or Layer N+1 (up) by handing the PDU between them. This is adjacent-layer communication — neighbors on the same device.

Both happen simultaneously. Adjacent-layer communication is how data moves within a device; same-layer communication is how protocols interoperate across devices.

TCP vs UDP — The Layer 4 Decision

At Layer 4 there are two transport protocols, and the choice between them affects everything that runs on top.

Property

TCP

UDP

Connection model

Connection-oriented — three-way handshake establishes the session first, like a phone call

Connectionless — packets sent immediately with no setup, like posting a letter

Reliability

Reliable — acknowledgments, sequencing, retransmission of lost segments

Unreliable — no acknowledgments, no retransmissions, no guarantees

Flow control

Yes — windowing negotiates the rate so a fast sender does not overwhelm a slow receiver

No

Ordering

Segments reassembled in order at the receiver

No ordering — packets may arrive out of order

Overhead

Higher — additional bytes for sequence numbers, acks, flags

Lower — minimal header

Speed

Slower (because of the handshake and confirmation traffic)

Faster (no setup, no confirmation)

Best for

Web traffic (HTTP/HTTPS), file transfer (SFTP, FTP), email (SMTP, IMAP) — anywhere data integrity matters

Voice and video (RTP), online gaming, DNS, NTP, SNMP — anywhere speed matters more than perfect delivery



A useful way to think about the trade-off: TCP is what you use when missing a single byte means the application breaks (a corrupted file is useless). UDP is what you use when missing a single packet is less bad than waiting for retransmission (a missed video frame is invisible to the human eye if it arrives 200 ms late, but the delay of retransmission would freeze the video).

For DoD: the protocol matters for PPSM. Every PPSM declaration specifies both the port number AND the protocol — TCP/443 is HTTPS web traffic; UDP/443 is QUIC or VPN. They cross the same boundary differently and get evaluated differently. When the Afternoon session covers PPSM in depth, "TCP vs UDP" is not academic — it is part of the declaration.

Which Rule applies (to all of Part 3): Rule 3 (Documentation) — PDU names and TCP/UDP distinction are the shared vocabulary that PPSM declarations and STIG documentation use. Without it, you cannot write a clean PPSM entry or read a STIG check result.

Part 4 — OSI Layers Through a DoD Lens

Same seven layers. Different operational rigor. For each layer below, you will see what is universal, then what DoD adds — and which of yesterday's Four Rules the additions enforce.

Layer 1 — Physical (DoD Lens)

Universal: Cables, connectors, voltages, light pulses, radio waves — the physical signal layer.

DoD adds:

  • TEMPEST controls — electromagnetic emissions from cables and equipment can leak classified information. Equipment in classified spaces may be TEMPEST-certified to limit emanations. (Covered in detail in Day 3.)

  • Protected Distribution System (PDS) — classified cables outside protected areas must run inside armored conduit, either continuously inspected or alarmed. (Covered in detail in Day 3.)

  • RED/BLACK separation — unencrypted classified (RED) cables physically separated from unclassified or encrypted (BLACK) cables by a minimum distance. (Covered in detail in Day 3.)

  • Fiber preferred for classified — fiber emits no electromagnetic signal that can be intercepted at a distance, and is harder to tap without detection. Many SIPRNet installations are all-fiber by design.

  • Cable color coding — typically red sheathing for SIPRNet, sometimes blue or black for NIPRNet, orange or yellow for other classification levels. Visual identification matters.

Which Rule applies: Rule 4 (Classification Boundary) — physical separation by classification is enforced even at the cable level. Rule 2 (Compliance) — TEMPEST and PDS requirements are STIG-equivalent configuration mandates.
Reference: DoDI 8500.01 — Cybersecurity; CNSSAM TEMPEST/1-13.

Layer 2 — Data Link (DoD Lens)

Universal: MAC addresses, switches, frames, VLANs.

DoD adds:

  • VLAN segmentation by sensitivity — even within a single classification level, sub-enclaves are often separated by VLAN (e.g., user network vs. management network vs. printer network).

  • 802.1X port authentication mandatory — STIGs require that every switch port authenticates the connected device before allowing traffic. No authenticated identity = no network access.

  • Port security — switches are configured to allow only known MAC addresses on each port. An unknown device plugged in = port shutdown automatically.

  • BPDU Guard, Root Guard, DHCP Snooping, Dynamic ARP Inspection — Layer 2 attack mitigations, required by switch STIGs.

  • No DTP, no auto-trunking — every port is explicitly configured as either access or trunk. No dynamic negotiation.

Which Rule applies: Rule 2 (Compliance) — every Layer 2 protection above is a STIG check item. Rule 3 (Documentation) — every VLAN, every port assignment, every MAC address allowed on a port is recorded.
Reference: DISA Cisco IOS XE Switch L2S STIG; DoDI 8500.01.

Layer 3 — Network (DoD Lens)

Universal: IP addresses, routing, packets, routers.

DoD adds:

  • DoD IP address space — DoD operates its own large blocks of IP address space (NIPRNet, SIPRNet). Routing within DoD is internal; classified networks have no public Internet routing at all.

  • Strict routing policy — every route is documented. Routing protocols (OSPF, BGP) are configured with authentication mandatory per STIG.

  • No direct Internet routing on classified networks — SIPRNet has no path to the public Internet, ever.

  • Type 1 encryption at Layer 3 — when classified data must cross untrusted infrastructure, HAIPE (High Assurance Internet Protocol Encryptor) operates at Layer 3, wrapping IP packets in NSA-certified encryption. Devices like TACLANE are inline Layer 3 encryptors. (Covered in detail in Day 8.)

  • DoD-managed DNS — DoDIN networks use DoD-operated DNS servers, not public DNS like 8.8.8.8 or 1.1.1.1. DNSSEC validation is required per OMB M-08-23.

Which Rule applies: Rule 4 (Classification Boundary) — SIPRNet's complete isolation from public Internet routing is the Absolute Rule enforced at Layer 3. Rule 2 (Compliance) — OSPF/BGP authentication is a STIG requirement. Rule 3 (Documentation) — every IP allocation and every route is documented.
Reference: DoDI 8523.01 — Communications Security (COMSEC); NSA HAIPE specifications.

Layer 4 — Transport (DoD Lens) — Pointer to PPSM

Universal: TCP and UDP, ports, segments.

DoD adds: PPSM (Ports, Protocols, and Services Management).

This is the most important Layer 4 concept in DoD networking, and it gets the entire afternoon session. PPSM is the formal program that controls every port and protocol allowed to cross DoDIN boundaries — and it is the operational expression of Rule 3 (Documentation) at the port/protocol layer.

For now, hold onto this: in DoD, you do not just open a port. You register it.

The full mechanics — the 16-boundary model, the Categorized Approved List (CAL), the Vulnerability Assessment (VA) process, the Component Local Services Assessment (CLSA), and how PPSM declarations integrate with the RMF package — are all covered this afternoon.

Layer 5 — Session (DoD Lens)

Universal: Establishes, manages, terminates sessions.

DoD adds:

  • All sessions logged — session start, session end, source and destination logged centrally per STIG requirements.

  • Idle session timeouts mandatory — STIGs require sessions to terminate after a defined idle period (typically 15 minutes for management sessions, longer for user sessions).

  • Session security policies — re-authentication may be required for sensitive operations even within an active session.

Which Rule applies: Rule 2 (Compliance) — session timeouts and logging are STIG-mandated. Rule 3 (Documentation) — the session logs themselves are the documentation of who accessed what, when.

Layer 6 — Presentation (DoD Lens)

Universal: Data formats, encryption, compression.

DoD adds:

  • FIPS 140-2 / 140-3 validated cryptographic modules — DoD requires FIPS-validated cryptography. FIPS 140-3 became effective September 22, 2019 and is the current standard. FIPS 140-2 certificates remain valid until September 21, 2026; new procurements must use FIPS 140-3. NSA-approved algorithms are required for classified systems (above FIPS scope).

  • TLS 1.2 minimum, TLS 1.3 required since January 1, 2024 per NIST SP 800-52r2. Older versions (SSL, TLS 1.0, TLS 1.1) explicitly disabled by STIG.

  • Approved cipher suites only — the STIG specifies which cipher suites are allowed; everything else is disabled.

  • Certificate authority controls — DoD operates its own PKI (Public Key Infrastructure). Devices and users hold DoD-issued certificates, not commercial certificates. (See Day 1 for the CAC and DoD PKI.)

Which Rule applies: Rule 2 (Compliance) — FIPS validation, TLS version, and cipher suite restrictions are all STIG requirements.
Reference: DoDI 8520.02 — Public Key Infrastructure (PKI) and Public Key (PK) Enabling; FIPS 140-3; NIST SP 800-52r2.

Layer 7 — Application (DoD Lens)

Universal: HTTP, FTP, SMTP, DNS, SSH, and so on.

DoD adds:

  • Insecure protocols banned — Telnet, FTP (plaintext), HTTP for sensitive content, SNMPv1/v2c, rlogin — all banned by STIG.

  • Secure equivalents required — SSH instead of Telnet, SFTP or SCP instead of FTP, HTTPS instead of HTTP, SNMPv3 instead of SNMPv1/v2c.

  • Every application requires an ATO — yesterday's Rule 1 still applies at Layer 7.

  • Application STIGs — there is a STIG for almost every common application (Apache, IIS, MySQL, Microsoft Office, Adobe Acrobat, web browsers, and many more).

  • Cross-Domain Solutions (CDS) — when an application must move data between classification levels, a CDS is required. (Covered in Day 1 Afternoon; CDS doctrine is DoDI 8540.01.)

Which Rule applies: Rule 1 (Authorization) — every application has an ATO. Rule 2 (Compliance) — every application has a STIG. Rule 4 (Classification Boundary) — cross-classification application data requires CDS.
Reference: DISA STIG Library — public.cyber.mil/stigs/

Part 5 — Encryption Across the Layers in DoD

You learned at Layer 6 (Presentation) that encryption happens at the Presentation layer in the OSI model. That is true — but in DoD, encryption can happen at multiple layers, depending on the requirement.

Where encryption happens

What is encrypted

Example

Layer 6 (Presentation) — TLS / HTTPS

Application-layer data inside the packet

A web browser session over HTTPS

Layer 3 (Network) — IPsec

The entire IP packet payload

Site-to-site VPN between two installations

Layer 3 (Network) — HAIPE / Type 1

The entire classified IP packet

SECRET traffic crossing untrusted infrastructure via TACLANE

Layer 2 (Data Link) — MACsec

The entire frame between two switches

High-security data center fabric links

Layer 1 (Physical) — bulk link encryption

All bits on the link, regardless of content

Older classified WAN links, some satellite



Key concept: The data still has all the OSI layers. Encryption does not remove a layer — it wraps it. A SECRET packet riding through a TACLANE still has all seven OSI layers inside; they are just inside a Type 1 encrypted envelope.

This matters because students often assume "the network is encrypted" is one thing. In DoD it is not. Where the encryption happens determines what is protected and from whom. A TLS session protects the data inside the packet from someone watching the packet. A HAIPE tunnel protects the entire packet (including its real source and destination) from someone watching the network. Different protections, different layers.

Reference: DoDI 8523.01 — COMSEC; CNSSI 4009 — National Information Assurance Glossary.

Part 6 — Real-World DoD Example: Tracing a SIPRNet Session

A user in a SIPRNet-authorized facility opens a browser and navigates to an internal SIPRNet web application. Here is what happens at each OSI layer:

Layer

What Happens (DoD Context)

7 — Application

Browser invokes HTTPS (not HTTP — HTTP is banned by STIG). The internal SIPR DNS resolves the application's hostname.

6 — Presentation

TLS 1.3 session established using DoD PKI certificates. Cipher suite restricted to STIG-approved set.

5 — Session

Session established. Session start logged centrally. Idle timeout configured per STIG.

4 — Transport

TCP session on port 443 — port 443 is on the PPSM Categorized Approved List for HTTPS web traffic (you will see how this works this afternoon). Source and destination ports recorded in flow logs.

3 — Network

IP packets routed within SIPRNet IP space — no public Internet involvement, ever. If the session crosses an installation boundary, traffic may pass through JRSS or its successor.

2 — Data Link

At each hop, frames carry the packet across switches. Switches enforce 802.1X authentication and port security per STIG.

1 — Physical

Signals travel over fiber (preferred for classified). Cables run in PDS conduit where outside controlled space. Equipment is in a TEMPEST-controlled environment.



Same OSI model. Same web request. The DoD discipline is on every layer.

This single example is worth holding onto. Every concept this course teaches in Days 3 through 10 will reinforce one or more of these layers. When you see TEMPEST in Day 3, you are deepening Layer 1. When you see VLANs and 802.1X in Day 4, you are deepening Layer 2. When you see routing and OSPF authentication in Days 5 and 6, you are deepening Layer 3. When you see PPSM in detail this afternoon, you are deepening Layer 4. When you see TLS and PKI in Day 7 and 8, you are deepening Layer 6. The OSI model is the spine; every day adds muscle to a specific layer.

End of Morning Session

By lunch you should be comfortable with:

✓ The TCP/IP / DoD model as a DoD invention — DARPA, 1973-1983
✓ Why network models exist — vendor interoperability across the DoDIN
✓ The mapping between the OSI 7-layer model and the TCP/IP 4-layer model
✓ The PDU at each layer — Data, Segment, Packet, Frame, Bit — and the
L2 trailer (Frame Check Sequence)
✓ Encapsulation (top-down at the sender) and de-encapsulation
(bottom-up at the receiver)
✓ Same-layer communication (peers on different devices) vs adjacent-layer
communication (neighbors within one device)
✓ TCP vs UDP — connection-oriented vs connectionless, reliable vs fast,
when each is the right choice
✓ The seven OSI layers and what is universal vs what DoD adds at each
✓ Which of the Four Rules from Day 1 applies at each layer
✓ Why encryption happens at multiple layers in DoD, and what each
layer's encryption actually protects
✓ How a single SIPRNet HTTPS session uses every OSI layer with full
DoD discipline applied at each
✓ A clear hand-off to the afternoon: PPSM at Layer 4, plus the
"trust nothing, verify everything" methodology you will apply
in the lab

The afternoon session takes Layer 4 — Transport — and goes deep on PPSM. PPSM is the operational program that controls every port and protocol crossing DoDIN boundaries. The afternoon also introduces the analytical methodology you will use in the lab to verify whether a protocol on the wire actually matches what the vendor claims it is.

Get a coffee. Come back ready to think.

Morning Glossary

Term

Meaning

OSI Model

Open Systems Interconnection model — 7-layer reference model from ISO (1984). Universal.

TCP/IP Model

4-layer model. Same as the DoD Model. Originated at DARPA in the 1970s; finalized 1981; ARPANET adopted it January 1, 1983. The four layers are Application, Host-to-Host (Transport), Internet, and Network Access.

PDU

Protocol Data Unit. The unit of data at a specific OSI layer. Each layer has a distinct PDU name.

Data

The PDU at OSI Layers 5, 6, and 7.

Segment

The PDU at OSI Layer 4 when using TCP. (A UDP PDU is sometimes called a Datagram.)

Packet

The PDU at OSI Layer 3 — an IP-layer unit with source and destination IP addresses.

Frame

The PDU at OSI Layer 2 — includes Ethernet header (source MAC, destination MAC) and trailer (FCS).

Bit

The PDU at OSI Layer 1 — raw electrical signals, light pulses, or radio waves on the medium.

FCS

Frame Check Sequence. The checksum in the L2 trailer that lets the receiver verify the frame was not corrupted. Failed FCS = dropped frame.

Encapsulation

The process at the sending side of wrapping each layer's PDU with the header (and at L2, the trailer) of the layer below. Travels top-down (7 → 1).

De-encapsulation

The reverse process at the receiving side — stripping each layer's header to reveal the PDU above. Travels bottom-up (1 → 7).

Same-layer communication

Logical communication between Layer N on one device and Layer N on another device. The two peers read and write each other's L-N headers.

Adjacent-layer communication

Communication between Layer N and Layer N-1 (or N+1) within a single device — how the PDU is passed up or down the stack internally.

TCP

Transmission Control Protocol. Connection-oriented, reliable, with acknowledgments, sequencing, and flow control. Used where data integrity matters.

UDP

User Datagram Protocol. Connectionless, unreliable, fast. Used where speed matters more than perfect delivery (voice, video, DNS, NTP, SNMP).

DARPA

Defense Advanced Research Projects Agency — funded ARPANET, parent of the Internet.

ARPANET

The 1969 packet-switched network that became the Internet.

RFC 791 / RFC 793

IETF specifications for IP and TCP respectively, published September 1981.

HAIPE

High Assurance Internet Protocol Encryptor — NSA Type 1 IP-layer encryption protocol. Covered in detail in Day 8.

TACLANE

A family of Type 1 inline network encryptors implementing HAIPE. Covered in detail in Day 8.

TEMPEST

Standard for preventing electromagnetic emanations from leaking classified data. Covered in detail in Day 3.

PDS

Protected Distribution System — armored conduit for classified cabling. Covered in detail in Day 3.

RED/BLACK separation

Physical separation between unencrypted classified (RED) and unclassified or encrypted (BLACK) equipment and cables. Covered in detail in Day 3.

DoD PKI

DoD's Public Key Infrastructure — issues the certificates used for authentication across DoDIN systems. Covered in Day 1.

802.1X

Port-based authentication standard required by switch STIGs.

DNSSEC

DNS Security Extensions. Cryptographic signatures on DNS records. Required on DoD networks per OMB M-08-23. Covered in Day 1.

FIPS 140-3

Current standard for cryptographic module validation. Effective September 22, 2019.

MACsec

IEEE 802.1AE — Layer 2 encryption between switches.

PPSM

Ports, Protocols, and Services Management. The DoD program that controls port and protocol use at DoDIN boundaries. Covered in detail this afternoon.

STIG

Security Technical Implementation Guide. The DISA-published configuration baseline a device must match. Covered in Day 1.

JRSS

Joint Regional Security Stacks. DISA's regional NIPRNet boundary defense. Covered in detail in Day 8.

CDS

Cross-Domain Solution. NSA-accredited engineered device for moving information between classification networks. Governed by DoDI 8540.01. Covered in Day 1.



Further Reading and Doctrine References

  • DoDI 8500.01 — Cybersecurity

  • DoDI 8523.01 — Communications Security (COMSEC)

  • DoDI 8520.02 — Public Key Infrastructure (PKI) and Public Key (PK) Enabling

  • DoDI 8540.01 — Cross Domain (CD) Policy

  • DoDI 8530.01 — Cybersecurity Activities Support to DoD Information Network Operations

  • JP 6-0 — Joint Communications System — Chapter 1 covers DoD networking heritage

  • NIST SP 800-53 Rev 5 — Security and Privacy Controls (control families AC, SC, SI relate directly to OSI layer concerns)

  • NIST SP 800-52 Rev 2 — Guidelines for the Selection, Configuration, and Use of TLS Implementations (TLS 1.3 mandate)

  • FIPS 140-3 — Security Requirements for Cryptographic Modules

  • CNSSI 4009 — National Information Assurance Glossary

  • CNSSAM TEMPEST/1-13 — TEMPEST guidance

  • RFC 791 — Internet Protocol (1981)

  • RFC 793 — Transmission Control Protocol (1981)

  • DISA STIG Library — public.cyber.mil/stigs/

Document History

Version

Date

Changes

v1.0

Current

Initial creation of Day 2 Morning Lecture Notes. Split from the prior FNC_Day_02_Lecture_v4 single document into a morning/afternoon pair to bring Day 2 in line with the Day 1 structure and to give PPSM the space it needs in the afternoon. Morning contains: opening that bridges from Day 1's frame to today's inside-the-network view; Part 1 — TCP/IP as DoD heritage (DARPA history, 1973-1983 timeline); Part 2 — the universal OSI model (7 layers, brief acknowledgment that OSI itself is universal); Part 3 — OSI layers through a DoD lens (each of layers 1, 2, 3, 5, 6, 7 with universal vs DoD-adds pattern, plus a pointer at Layer 4 forward to the afternoon PPSM session); Part 4 — encryption across the layers (table showing where encryption happens at each layer); Part 5 — the SIPRNet HTTPS session walkthrough that ties everything together. Each layer's DoD additions are explicitly mapped to the Four Rules from Day 1 Afternoon, making the conceptual frame visible. Stale "Day 1 Appendix" references replaced — TEMPEST/PDS/RED/BLACK now point to Day 3; HAIPE/TACLANE point to Day 8; JRSS points to Day 8; CDS reference points to Day 1 Afternoon. PPSM moved entirely to the Afternoon session per program structure decision. Companion to FNC_Day_02_Afternoon_Lecture (in development). v4-style branding applied: top banner, full nine-line cover panel with Document ID DICDP-CIS-FNC-D02-LN-AM-v1, Restricted Distribution Statement, symmetric bottom footer plus closing banner. All technical claims confirmed against Day 1 validation work and against DISA / NIST sources cited.

v2.0

Current

Gap-fill update following review of the civilian Day 2 slide deck. The civilian deck spends significant time on encapsulation, PDUs, the OSI-to-TCP/IP mapping, and TCP vs UDP — foundational vocabulary that the rest of the course depends on. The original v1 assumed students had absorbed all of this from the civilian session, but the depth was insufficient to anchor the DoD content reliably. New Part 3 — Encapsulation, PDUs, and the TCP/IP Mapping inserted between the old Part 2 (Universal OSI Model) and the old Part 3 (now Part 4 — OSI Layers Through DoD Lens). The new Part 3 contains: (1) Why network models exist — vendor interoperability framed for the DoDIN; (2) the two standard mnemonics ("Please Do Not Throw Sausage Pizza Away" bottom-up and "All People Seem To Need Data Processing" top-down); (3) the OSI-to-TCP/IP layer mapping table — OSI 7+6+5 → Application, OSI 4 → Host-to-Host, OSI 3 → Internet, OSI 2+1 → Network Access; (4) the PDU table at each layer with the L2 Frame Check Sequence trailer explicitly called out; (5) the encapsulation flow diagram (top-down at sender) and de-encapsulation flow (bottom-up at receiver); (6) same-layer communication vs adjacent-layer communication explained; (7) the TCP vs UDP comparison table with concrete use cases (TCP for web/files/email, UDP for voice/video/DNS/gaming). Closes with a Rule 3 callout that PDU names and TCP/UDP distinction are the shared vocabulary PPSM declarations use. Old Parts 3, 4, 5 renumbered to Parts 4, 5, 6. End-of-Morning checklist expanded from 6 items to 12 items reflecting the new content. Glossary expanded with 14 new terms: PDU, Data, Segment, Packet, Frame, Bit, FCS, Encapsulation, De-encapsulation, Same-layer communication, Adjacent-layer communication, TCP, UDP, plus the expanded TCP/IP Model definition with all four layer names. Length grew from approximately 370 lines to approximately 490 lines. No changes to existing content — strictly additive.



═══════════════════════════════════════════════════════════════════ Red Irish Global Services | DICDP | CIS Track | FNC DICDP-CIS-FNC-D02-LN-AM-v2 | Issued: [date] ═══════════════════════════════════════════════════════════════════

═══════════════════════════════════════════════════════════════════ RESTRICTED DISTRIBUTION — DICDP PROGRAM PARTICIPANTS ONLY ═══════════════════════════════════════════════════════════════════


Rating
0 0

There are no comments for now.

to be the first to leave a comment.