knowledge-base/NETWORKING.en.md

🌐 Network Architecture

Reference Model (TCP/IP)

Layer	Protocols	Devices
Application	HTTP/HTTPS, DNS, SMTP, SSH	—
Transport	TCP, UDP	—
Network	IP, ICMP, BGP	Routers
Link	Ethernet, ARP, VLAN	Switches

TCP Detail

3-way Handshake

Client                          Server
  |                               |
  |  SYN (seq=x)                  |
  |──────────────────────────────>|
  |                               |
  |  SYN+ACK (seq=y, ack=x+1)    |
  |<──────────────────────────────|
  |                               |
  |  ACK (seq=x+1, ack=y+1)      |
  |──────────────────────────────>|
  |                               |
  |  << established >>            |

• SYN — client sends segment with SYN flag (Synchronize Sequence Number)
• SYN-ACK — server responds with its own SYN + acknowledgment of client's seq number
• ACK — client acknowledges, connection is established
• TCP Fast Open (TFO) — data in SYN packet for 0-RTT on repeated connections

Flow Control (Sliding Window)

• Receiver Window (rwnd) — how much data the receiver is willing to accept
• Sliding Window — sender maintains a window of unacknowledged packets
• Window scaling (RFC 1323) — allows window up to 1 GB (instead of 64 KB)
• Zero Window — receiver advertises 0, sender stops, persist timer periodically tests

Congestion Control

Algorithm	Description	Use Case
Cubic	Default in Linux (since kernel 2.6.19), cubic growth function	General networks, default for the Internet
BBR (Bottleneck Bandwidth and RTT)	Model-based, measures bandwidth and RTT, not packet loss	High-speed networks, YouTube, Google
Reno	Classic AIMD (Additive Increase Multiplicative Decrease)	Legacy, reference
CDG (CAIA Delay Gradient)	Delay-based, congestion detection by RTT gradient	Video streaming, real-time

BBRv2 (2024+) — includes ECN signaling, coexistence with Cubic, better loss handling.

DNS (Domain Name System)

• Record types: A, AAAA, CNAME, MX, TXT, NS, SRV, PTR, CAA, DS, DNSKEY, RRSIG, NSEC
• DNS resolver: recursive query through hierarchy (root → TLD → authoritative)
• Anycast DNS — same IP from multiple locations, routing to the nearest
• DNS caching — TTL control, cache poisoning protection (DNSSEC)
• Cloud DNS — Route53, Azure DNS, Cloud DNS

DNS Lookup Flow (Step by Step)

1. User enters "api.example.com" in the browser
2. OS stub resolver checks local cache (/etc/hosts, systemd-resolved)
3. If not in cache → query to recursive resolver (ISP / 8.8.8.8 / 1.1.1.1)
4. Resolver checks its cache
5. Not found → resolver starts recursive lookup:
   a. Query to root nameserver (.) → returns NS for .com
   b. Query to .com TLD nameserver → returns NS for example.com
   c. Query to authoritative NS for example.com → returns A record (IP)
6. Resolver stores in cache (TTL), returns IP to client
7. Client establishes TCP connection to the obtained IP

The whole process typically takes 10–200 ms (with cache < 1 ms).

DNSSEC Detail

• RRSIG — digital signature for each RRset (Resource Record Set)
• DNSKEY — zone public key (ZSK = Zone Signing Key, KSK = Key Signing Key)
• DS (Delegation Signer) — DNSKEY hash passed to the parent zone (chain of trust)
• NSEC / NSEC3 — authenticated denial of existence (proof that a record does not exist)
• Chain of trust: root → .com → example.com (path from trust anchor through DS records)

Root DS → .com DNSKEY → .com DS → example.com DNSKEY → example.com RRSIG(A)

• Validation: resolver checks signatures across the entire chain up to the trust anchor

DNS-based Service Discovery

Mechanism	Description	Example
SRV record	Service location (priority, weight, port, target)	_http._tcp.example.com
Consul DNS	Service discovery via DNS interface	web.service.consul
CoreDNS	Kubernetes DNS, plugin-based	my-svc.my-namespace.svc.cluster.local
Kubernetes DNS	Service discovery inside the cluster (kube-dns / CoreDNS)	svc.cluster.local
mDNS (Multicast DNS)	Zero-config, local network (Bonjour/Avahi)	myprinter.local

Load Balancing

Type	OSI Layer	Description
L4 (NLB)	4	TCP/UDP, fast, lower latency
L7 (ALB)	7	HTTP/HTTPS, path-based routing, sticky sessions
Global	DNS	Geo-routing, latency-based, weighted

Algorithms

• Round Robin / Weighted RR
• Least Connections
• IP Hash (session persistence)
• Random

Health Check Types

Type	Description	Suitable For
TCP health check	TCP handshake to target port	L4 NLB, basic check
HTTP health check	HTTP GET to URL, expects 200 OK	L7 ALB, web services
HTTPS health check	HTTP + TLS handshake	Services with TLS termination
gRPC health check	gRPC Health/Check RPC (gRPC specific)	Microservices, gRPC services
ICMP ping	Ping to target IP	Basic connectivity

Connection Draining

• Connection draining (AWS) / Deregistration delay — when a target is removed from ASG/LB, it waits for existing connections to finish (configurable: 1-3600 s)
• Slow start — new target gradually receives more requests (prevents cold cache overload)

Cross-zone Load Balancing

• Enabled: LB evenly distributes traffic across all AZs (even with uneven instance count)
• Disabled: traffic split evenly between AZs, then within AZ among instances
• AWS ALB/NLB: enabled by default (2022+), no additional charges

Firewalls and Security

• Stateful firewall — tracks connection state (AWS Security Groups, Azure NSG)
• Stateless firewall — ACL (Network ACLs)
• NGFW — application layer, IPS/IDS (Palo Alto, Fortinet)
• WAF — web application protection (Cloudflare, AWS WAF, Azure WAF)

Network Segmentation — Security Groups vs Network ACLs

Property	Security Group (SG)	Network ACL (NACL)
State	Stateful (automatically allows return traffic)	Stateless (explicit rule required for both directions)
Level	Instance / ENI	Subnet
Rules	Allow only	Allow and deny
Evaluation	All rules evaluated (OR)	Rules from lowest number (first match)
Default	All traffic denied (inbound), all traffic allowed (outbound)	All traffic denied (inbound and outbound)
Support	AWS, GCP (firewall rules), Azure (NSG)	AWS (NACL), GCP (firewall rules on subnet), Azure (NSG)

Micro-segmentation

• Zero Trust networking — each workload has its own security group / NGFW policy
• Service mesh — Istio, Linkerd, Consul Connect for L7 micro-segmentation (mTLS, authorization policies)
• Network policies — Kubernetes NetworkPolicy for pod-to-pod traffic segmentation
• Tanzu / NSX — micro-segmentation at hypervisor level

VPN

• Site-to-Site — IPSec, permanent connection between sites
• Client-to-Site — OpenVPN, WireGuard, AnyConnect
• Cloud VPN — AWS VPN, Azure VPN Gateway, GCP Cloud VPN

CDN (Content Delivery Network)

• Edge locations for caching static content
• DDoS protection
• SSL/TLS termination at edge
• Providers: CloudFront, Cloudflare, Akamai, Fastly

BGP and Routing

• BGP — protocol for exchanging routes between AS (Autonomous Systems)
• ASN — unique network identifier
• iBGP — internal BGP (within AS)
• eBGP — external BGP (between AS)

BGP Path Selection Algorithm

BGP router selects a single best path according to the following criteria (in priority order):

1. WEIGHT (Cisco-specific) — highest weight (local to router)
2. LOCAL_PREF — highest local preference (within AS)
3. Originate — prefers route originated by local router
4. AS_PATH — shortest AS_PATH length
5. ORIGIN — IGP < EGP < INCOMPLETE
6. MED (Multi-Exit Discriminator) — lowest MED (with same AS neighbor)
7. eBGP > iBGP — prefers external BGP over internal
8. Next-hop reachable — path to next-hop must be reachable
9. Neighbor IP — prefers path from router with lowest IP
10. Router ID — prefers path with lowest Router ID

iBGP Full Mesh vs Route Reflectors

Aspect	Full Mesh	Route Reflectors
Number of sessions	n(n-1)/2	n (each peer to RR)
With 100 routers	4,950 sessions	100 (with 1 RR)
Scaling	Poor (quadratic)	Linear
Redundancy	Natural	Requires multi-RR + cluster
Configuration	Simple logic	RR rules (non-transitive)

BGP must be known for: Cloud interconnects, MPLS L3VPN, SD-WAN, Data center fabrics (VXLAN + BGP EVPN)

VPC / Virtual Network Architecture

Internet ──┬── Internet Gateway (IGW)
           │
    ┌──────▼──────┐
    │  Public Subnet │
    │  ┌──────────┐  │
    │  │  ALB/NAT │  │
    │  └────┬─────┘  │
    └───────┼────────┘
            │
    ┌───────▼────────┐
    │  Private Subnet │
    │  ┌──────────┐   │
    │  │  App      │   │
    │  └────┬─────┘   │
    └───────┼─────────┘
            │
    ┌───────▼─────────┐
    │  Data Subnet     │
    │  ┌────────────┐  │
    │  │  Database   │  │
    │  └────────────┘  │
    └──────────────────┘

VPC Design Patterns

Three-tier architecture

• Web tier (public subnets) → ALB
• App tier (private subnets) → auto-scaling
• Data tier (private subnets) → RDS / self-managed DB
• NAT Gateway / Instance in public subnet for outbound traffic from app/data tier

VPC Peering

• Direct connection between two VPCs (same or cross-account)
• Transitive peering is not supported (A→B, B→C does not imply A→C)
• Use cases: sharing resources (LDAP, monitoring), service endpoints

Transit Gateway

• Hub-and-spoke topology, transitive routing
• Supports: VPC, VPN, Direct Connect, peering between TGWs
• Route tables per attachment — environment isolation
• AWS TGW: 50 Gbps per attachment, up to 5000 attachments

PrivateLink / VPC Endpoint

• Private access to services without IGW, NAT, VPC peering
• Interface Endpoint (ENI in subnet) — for AWS services, SaaS
• Gateway Endpoint (S3, DynamoDB) — route table entry, free
• AWS PrivateLink — Service Consumer ↔ NLB/ENI ↔ Service Provider

MTU, Jumbo Frames, PMTUD

Network	Standard MTU	Jumbo Frames
Ethernet	1500 B	9001 B (AWS: 9001, Azure: 1400→9000)
GRE tunnel	1476 B	—
PPPoE	1492 B	—
VLAN (802.1Q)	1496 B	—
VXLAN	N/A (inner 1500 + 50)	8950 B

PMTUD (Path MTU Discovery)

• Sets DF (Don't Fragment) bit in IP header
• If path requires fragmentation → ICMP "Fragmentation Needed" (Type 3, Code 4)
• Decreases MTU until packet passes
• Common problem: ICMP blocked by firewall → black hole (TCP connection hangs)
• Workaround: MSS clamping (TCP MSS = MTU - 40)

Jumbo Frames Use Cases

• NFS / SMB (NAS)
• iSCSI / NVMe-oF (SAN)
• HPC / MPI workloads
• Data replication (DB, DRBD)
• Amazon EFS, AWS Managed Streaming for Kafka

Anycast vs Unicast vs Multicast

Type	Description	Example
Unicast	1:1 — one source, one destination	Regular TCP/IP traffic
Multicast	1:N — one source, group of receivers	IPTV, mDNS, VXLAN BUM traffic
Anycast	1:1 from nearest — same IP from multiple locations	DNS (8.8.8.8, 1.1.1.1), Cloudflare
Broadcast	1:ALL — all devices on the network	ARP, DHCP (limited to L2 broadcast domain)

Anycast detail:

• Same IP prefix is announced from multiple locations (BGP)
• Traffic goes to the topologically nearest node (BGP path selection)
• Advantages: simple redundancy, DDoS absorption, lower latency
• Challenges: connection persistence (TCP), stateful anycast, routing convergence
• Cloud: Route53, CloudFront, Cloudflare, Google DNS

Cloud Networking Resilience (2026)

See also: CLOUD.en.md — cloud architecture, multi-AZ, hybrid cloud connectivity.

Cell-based Architectures

• Isolate fault domain into "cells" (group of AZ + services)
• Each cell independently deployable, own DB, own LB
• Limit blast radius: failure of one cell does not affect others
• Implementation: AWS Cell-based architecture, Azure STAG (Scale Tier Availability Group)

DNS Resilience

• Anycast DNS — same IP from multiple regions, routing to the nearest
• DNS failover — health checks automatically remove unavailable endpoints
• Multi-DNS provider — Route53 + Cloudflare + UltraDNS to eliminate SPOF

Traffic Engineering

• BGP optimization — AS path prepend, MED, local pref for controlling inbound/outbound traffic
• Global Load Balancing — GSLB at DNS level (latency-based, geo-proximity, weighted)
• AIOps — ML-based traffic pattern prediction and automatic scaling

New Trends

• Path Aware Networking — applications choose the network path based on current conditions
• Segment Routing (SR-MPLS / SRv6) — MPLS simplification, programmable paths
• Zero Trust Networking — micro-segmentation, identity-based access, never trust / always verify

Advanced Topics from Books

TCP/IP Illustrated (Stevens, ISBN 978-0321336316)

Key architectural principles according to the book:

• End-to-End Argument — correctness and completeness of communication can only be ensured at the application level, not at lower layers. The network should be "dumb", end stations "smart".
• Fate Sharing — all state necessary to maintain active communication must be stored at the endpoints, not in the network.
• Layering — hierarchical layering of protocols per the OSI model; each layer encapsulates the PDU from the higher layer and adds its own header.
• Multiplexing/Demultiplexing — protocols at the same layer coexist thanks to identifiers (IP proto, TCP/UDP port).
• Sliding Window — efficient link utilization under high latency (window size = bandwidth × RTT).

The book covers the entire TCP/IP stack from the link layer (Ethernet, ARP, PPP) through IP, ICMP, DHCP, NAT, DNS, UDP, TCP (connection management, timeout, retransmission, congestion control, keepalive) to applications (SNMP, Telnet, FTP, SMTP, NFS, HTTP).

AI Data Center Network Design (Subramaniam, ISBN 978-0-13-543628-8)

Comprehensive, vendor-agnostic guide to designing network infrastructure for AI clusters.

Key Concepts:

• Rail-Optimized Design (ROD) — connecting GPUs across racks along "rails", each rail forms an independent network for all-reduce communication. Minimizes latency for synchronous training.
• Rail-Unified Design (RUD) — shared network fabric for all GPUs, more flexible but higher demands on load balancing.
• RoCEv2 (RDMA over Converged Ethernet) — primary transport for AI clusters: requires lossless fabric (ECN, PFC, DCQCN, SFC, CSIG).
• Load Balancing for AI — ECMP is insufficient, requires dynamic/global load balancing (DLB/GLB), flowlet-based rebalancing, per-packet spraying.
• Topologies — Clos (3-stage/5-stage), Dragonfly, Torus for scaling to tens of thousands of GPUs.
• Ultra Ethernet Consortium (UEC) — new standard for Ethernet in AI clusters (2025+), addresses RoCEv2 limitations.
• Storage for AI — NVMe-oF, GPUDirect Storage, parallel file systems for checkpointing and dataset loading.
• KPIs — Job Completion Time (JCT), tail latency, fabric utilization, PFC storm detection.

Cloud Networking and Resilience (Critelli, ISBN 979-8868824357)

Practical guide to building resilient cloud networks (Apress, 2026). The author is EMEA Lead for Networking & Resilience at AWS.

Layered Approach to Resilience (per OSI model):

Layer	Measures
L1 (Physical)	Redundant connections, diverse fibre paths, DWDM
L2 (Link)	MLAG, LACP, spanning-tree fast convergence
L3 (Network)	BGP multi-homing, AS path prepend, Anycast
L4 (Transport)	Connection draining, slow start, health checks
L7 (Application)	DNS failover, global load balancing, cell-based architectures

Regulatory Frameworks: DORA (Digital Operational Resilience Act), NIS2 — require regular resilience testing, chaos engineering, business continuity plans.

AIOps in Resilience: ML-based traffic pattern prediction, automatic scaling, proactive fault detection (transition from reactive monitoring to predictive prevention).

Zero Trust in Resilient Cloud and Network Architectures (Halley et al., ISBN 978-0-13-820460-0)

Cisco Press — practical guide for deploying Zero Trust architectures in hybrid and cloud environments.

Implementation Framework:

• User and Device Trust — verification of both user and device identity before granting access (SSE — Security Service Edge).
• Application Access Policies — granular rules at the application level, not IP addresses.
• Greenfield vs Brownfield — new networks built as Zero Trust from the ground up vs. migration of existing infrastructure.
• Automation — Terraform, Ansible for provisioning; Meraki, EVPN, Pub/Sub telemetry.
• Industrial Zero Trust — extending the concept to OT/ICS environments.
• Quantum Security — preparation for post-quantum cryptography in network architectures.

The Segmentation Blueprint (Kulkarni, ISBN 978-0-13-546236-2)

Cisco Press (2026) — pragmatic guide to network segmentation from VLAN to nanosegmentation.

Evolution of Segmentation:

Generation	Technology	Scope
Traditional	VLAN, ACL, firewall	Subnet
Micro-segmentation	Security Groups, Network Policies	Workload / instance
Nanosegmentation	Service mesh (Istio, Linkerd), mTLS	Application / API / process

Segmentation Maturity Model:

1. Initial — flat network, no segmentation
2. Basic — VLANs, firewall between environments
3. Defined — Security Groups, service access policies
4. Managed — Micro-segmentation, Network Policies, EVPN
5. Optimized — Nanosegmentation, service mesh, Zero Trust, AI-driven policy management

Key Metric: Blast radius — how many workloads are compromised when one node is breached. Goal is reduction to a minimum.

Segment Routing for SP and Enterprise Networks (Deragisch, ISBN 978-0-13-823101-9)

Cisco Press (2024) — comprehensive guide to Segment Routing for both MPLS and IPv6 data plane.

SR-MPLS vs SRv6:

Property	SR-MPLS	SRv6
SID length	20 bit (MPLS label)	128 bit (IPv6 address)
Data plane	MPLS	IPv6 + SRH (Segment Routing Header)
Signaling	IGP (IS-IS/OSPF) extensions	IGP + BGP extensions
Maturity	Mature, widely deployed	Emerging, standardization complete
Use case	SP networks, MPLS migration	Cloud, DC, 5G, end-to-end programmability

Advantages of SR over classic MPLS:

• Elimination of LDP/RSVP-TE (signaling is part of IGP)
• Traffic engineering state moved from nodes to packet headers (source routing)
• Fast reroute (FRR) without additional protocols
• Egress Peer Engineering (EPE) — selection of AS exit point
• Micro-loop avoidance during convergence

Migration Strategies: Greenfield (new network), Brownfield (gradual migration from MPLS), "SR in a box" — combination of SR and LDP.

Understanding and Designing Azure Networking (Stuart, Moreno, 2025)

Practical guide to designing Azure networks by two Microsoft Solution Engineers (former CCIEs).

Key Topics:

Area	Key Services and Concepts
Topologies	Hub-and-spoke, Virtual WAN, multi-hub designs, Azure Route Server
Hybrid Connectivity	ExpressRoute, VPN Gateway, SD-WAN integration
Multi-cloud	Azure ↔ AWS/GCP, cross-cloud fabrics
Security	NSG, Azure Firewall, DDoS Protection, WAF, AVNM, ZTNA
DNS & PaaS	Private Link, Private DNS Zones, Private Resolver, hybrid DNS forwarding
Application Delivery	Azure Load Balancer, App Gateway, Front Door, Traffic Manager
Monitoring	Network Watcher, Traffic Analytics, Azure Monitor, Policy-as-code

Design Decision Framework: Gather requirements → analyze constraints → select topology → implement → monitor.

Mastering Next-Gen Juniper Data Centers (Chatterjee, ISBN 978-0-13-533636-6)

Addison-Wesley (2026) — hands-on guide to EVPN VXLAN fabrics on Juniper devices.

Key Architectures:

• EVPN VXLAN fabric — multi-tenant overlay networks with BGP EVPN control plane and VXLAN data plane.
• Multivendor interoperability — detailed procedures for EVPN across Juniper, Cisco NX-OS, Arista EOS.
• Multicast in EVPN VXLAN — intra-subnet and inter-subnet multicast design (IGMP/MLD proxying, PIM, EVPN Type-6/7 routes).
• Day-2 operations — Juniper Apstra for automation (Terraform provider), telemetry (gNMI, OpenConfig).
• Service chaining — connecting NGFW, load balancers within the fabric.
• DCI with EVPN — Over-the-Top (OTT) and Integrated Interconnect (VXLAN stitching, MPLS transit).

Evolution from previous book (Deploying Juniper Data Centers with EVPN VXLAN, 2024): Expansion with advanced topics — multicast, interoperability, Apstra Day-2, observability stack.

Intelligent Cloud Networking: AI-Driven Resource Management (Yadav, ISBN 9364220110)

Intersection of AI/ML and cloud network management (Addition Publishing, 2026).

AI Applications in Network Management:

Area	Technique	Benefit
Flow prediction	LSTM, Transformer	Traffic pattern prediction, proactive scaling
Flow classification	CNN, RL	Traffic type identification for QoS
Load balancing	DRL (Deep RL)	Dynamic load distribution, congestion reduction
Resource management	Q-learning, DQN	Optimization of CPU/memory/network allocation
Routing optimization	DRL, GNN	Adaptive routing based on current conditions
Congestion control	ML-based CC	Predictive congestion control (instead of reacting to loss)
Anomaly detection	Autoencoders, Isolation Forest	Real-time attack and anomaly detection
Blockchain security	Smart contracts	Decentralized access control, audit trail

Technology Trends:

• Ultra Ethernet Consortium (UEC) — next-generation Ethernet for AI, lossless fabric, telemetry, adaptive routing.
• Path Aware Networking — applications choose path based on current conditions (latency, loss, cost).
• Self-optimizing networks — closed loop: telemetry → AI analysis → automatic action → feedback.

OpenStack Networking (Neutron)

OpenStack Neutron is an SDN framework for managing virtual networks in a multi-tenant environment. Supports VLAN, VXLAN, GRE tunnels, security groups, QoS, and LBaaS (Octavia).

Backends

Backend	Description	Suitable For
OVN (Open Virtual Network)	Native OpenFlow/OVSDB backend; replaces OVS+agent architecture	Production, scalable deployments
OVS (Open vSwitch)	Classic agent-based backend (neutron-openvswitch-agent)	Small deployments, legacy
Linux Bridge	Simple backend without OVS	Development, testing, embedded
Hyper-V	Windows Server backend	Hybrid environments

Important Concepts

• Networks, Subnets, Ports — basic network objects
• Routers — L3 forwarding between tenant networks (DVR for distributed routing)
• Security Groups — stateful firewall rules at the port level
• Floating IPs — public IPs mapped to instances (1:1 NAT)
• LBaaS / Octavia — load balancing as a service (HAProxy, amphora)
• Trunk ports — VLAN tagging for instances (parent + subports)

Performance Tuning

• DPDK — userspace packet processing, bypass kernel, lower latency
• SR-IOV — passthrough VF to instance, minimal hypervisor overhead
• NUMA pinning — vCPU/memory/NIC affinity for compute instances
• Hardware offload — OVS TC Flower, ASAP²

Use Cases

• Multi-tenant cloud (public and private)
• Telco/NFVI (DPDK, SR-IOV, low-latency)
• SDN lab / network function virtualization

Zero Trust Networking

Zero Trust is a "never trust, always verify" security model — no entity is implicitly trusted, regardless of its location in the network.

Principles (NIST SP 800-207)

1. All resources are external — there is no trusted internal network
2. Least privilege — access only to necessary resources
3. Micro-segmentation — workload isolation at the individual process/container level
4. Encrypt everything — TLS/mTLS for all communication
5. Continuous verification — every request is authenticated and authorized
6. Dynamic policies — rules change based on context (user, device, location, time)

Implementation Layers

Layer	Technology	Description
Identity	OIDC, SAML, LDAP	User and device authentication
Device	MDM, UEM, device certificates	Device state verification (compliant, patch level)
Network	Micro-segmentation, firewall, SDN	Traffic isolation between workloads
Application	mTLS, service mesh, API gateway	Applications enforce mutual authentication
Data	Encryption at rest + in transit, DLP	Data protection regardless of location
Analytics	SIEM, UEBA, AI/ML	Real-time anomaly and threat detection

Tools and Platforms

Category	Tools
ZTNA (Zero Trust Network Access)	Cloudflare Access, Zscaler, Netskope, Palo Alto Prisma
Service Mesh	Istio, Linkerd, Consul Connect, Cilium
Micro-segmentation	VMware NSX, Illumio, Guardicore, Akamai
BeyondCorp	Google BeyondCorp (open-source: BeyondCorp Alliance)
Security Service Edge (SSE)	SWG, CASB, ZTNA in one (Zscaler, Netskope, Cloudflare)

Zero Trust in the Data Center

In a private DC, Zero Trust is deployed via:

• EVPN VXLAN — overlay network with tenant isolation
• Network Policies (Kubernetes) — per-pod firewall rules
• Cilium — eBPF-based L3/L7 policy enforcement
• WireGuard / IPsec — encryption between nodes
• HashiCorp Boundary — identity-based access to servers without bastion host

Best Practices

• Network segmentation — separate environments (dev/staging/prod), tiers (web/app/db)
• Least privilege access — security groups allow only necessary traffic
• Monitoring — VPC Flow Logs, netflow, sFlow
• Redundancy — multi-AZ, multi-region for critical services
• Encryption in transit — TLS everywhere, mTLS for service-to-service
• DDoS protection — AWS Shield, Azure DDoS Protection, Cloudflare

Resources

Links, books and standards: sources/networking/sources.en.md

• MTU alignment — consistent MTU across the entire path, check ICMP blocking for PMTUD
• IP planning — RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), avoid overlaps for peering

TLS Detail

TLS 1.3 Handshake (1-RTT)

Client                                     Server
  |                                          |
  |  ClientHello (key_share, sig_algs)      |
  |─────────────────────────────────────────>|
  |                                          |
  |  ServerHello + EncryptedExtensions       |
  |  + Certificate + CertificateVerify      |
  |  + Finished                              |
  |<─────────────────────────────────────────|
  |                                          |
  |  Finished                                |
  |─────────────────────────────────────────>|
  |                                          |
  |  << Application Data >>                  |

• 0-RTT (early data) — client sends data immediately with the first message (on repeated connection with PSK)
• 0-RTT risk: replay attacks (HTTP GET is safe, POST requires protection)
• Compared to TLS 1.2: removed obsolete ciphers, AEAD required, faster handshake (2 RTT → 1 RTT)

Cipher Suites

Suite	Key exchange	Auth	Encryption	MAC	Status
TLS_AES_128_GCM_SHA256	(EC)DHE	(EC)DHE	AES-128-GCM	AEAD	TLS 1.3 default
TLS_AES_256_GCM_SHA384	(EC)DHE	(EC)DHE	AES-256-GCM	AEAD	Higher security
TLS_CHACHA20_POLY1305_SHA256	(EC)DHE	(EC)DHE	ChaCha20-Poly1305	AEAD	Mobile / no AES-NI
ECDHE-ECDSA-AES128-GCM-SHA256	ECDHE	ECDSA	AES-128-GCM	AEAD	TLS 1.2 (PFS)
ECDHE-RSA-AES128-GCM-SHA256	ECDHE	RSA	AES-128-GCM	AEAD	TLS 1.2 (PFS)

PFS (Perfect Forward Secrecy) — compromising the private key cannot decrypt previously captured traffic (ECDHE + ephemeral keys).

Certificate Chain Validation

1. Client receives certificate chain from server
2. Validation:
   a. Date: certificate is not expired and is valid (notBefore, notAfter)
   b. CRL / OCSP: certificate is not revoked (OCSP stapling to reduce latency)
   c. Signature chain: each cert's signature in the chain is verified with the issuer's public key
   d. Root CA: the last cert in the chain is trusted (in client's trust store)
3. CN / SAN: domain name in the certificate must match the target domain

Typical chain: Leaf Cert → Intermediate CA → Root CA (self-signed, in trust store).

Last revised: 2026-06-03