Chapter 4 · Network Security·Advanced·~16 min

Networking Refresher

QUIC's encrypted transport, IPv6's quietly different security model, and the slow walk toward authenticated BGP.

You will learn

  • QUIC's 0-RTT handshake and the connection migration trick
  • IPv6 security: SLAAC, RA Guard, neighbor discovery attacks
  • BGPsec path validation vs ASPA's lighter approach
  • RPKI ROV deployment status and what is realistic

QUIC at the transport

QUIC (RFC 9000, 2021) runs on UDP with built-in TLS 1.3. Key properties:

  • 1-RTT handshake: TLS 1.3 cryptographic state ships in the first flight; no separate TCP handshake.
  • 0-RTT resumption: with a previous session ticket, the client sends application data in the first packet. Same anti-replay caveats as TLS 1.3 0-RTT.
  • Connection ID: connections are identified by a server-issued ID, not the 4-tuple. The client can change networks (WiFi to LTE) and the connection survives.
  • Encrypted transport headers: even packet numbers and ACK info are encrypted, hiding metadata from on-path observers.
  • Stream multiplexing without TCP's head-of-line blocking.

HTTP/3 is HTTP over QUIC. Major CDNs and browsers ship it; adoption is the most significant TLS-era network change.

IPv6 security quirks

IPv6's address space is so large that scanning becomes infeasible. That changes attacker strategies:

  • SLAAC (Stateless Address Autoconfiguration): clients form addresses from Router Advertisements. A rogue RA on the LAN can configure clients with attacker-chosen prefixes and gateways. RA Guard at the switch filters RAs from unauthorized ports.
  • Neighbor Discovery is IPv6's ARP replacement and is similarly unauthenticated. SEND (Secure Neighbor Discovery) exists but is essentially unused.
  • Multiple addresses per interface: link-local + SLAAC + DHCPv6 + privacy extensions. Logs and firewall rules need to account for all of them.
  • IPv6 first by default on most modern OSes. An IPv4-only firewall rule with no IPv6 equivalent silently permits the IPv6 path.

BGPsec vs ASPA

RPKI Origin Validation (ROV) checks "the originating AS is authorized to announce this prefix." It does not validate the path. Two extensions try:

  • BGPsec (RFC 8205): every AS on the path signs the next-hop announcement. Heavyweight; requires per-update signing, breaks route aggregation, and adoption is essentially zero outside academic networks.
  • ASPA (Autonomous System Provider Authorization, RFC 9774): each AS publishes signed "my providers are X, Y, Z" records. Routers check whether observed paths are consistent with the published provider relationships. Lighter than BGPsec, less complete, gaining traction in 2025.

Realistic posture: publish ROAs, deploy ROV at your edge, monitor for hijacks with external services (BGPmon, RIPEstat), participate in ASPA when your upstreams support it.

Deployment status (2026 snapshot)

  • RPKI ROA coverage: ~50% of routed IPv4 prefixes, ~60% of IPv6.
  • RPKI ROV at large transits: most Tier 1s drop invalid routes.
  • BGPsec: essentially zero production deployment.
  • ASPA: pilot in some regional providers, early standardization.
  • QUIC: ~30% of measured web traffic at major CDNs.

The slow walk toward an authenticated default route continues. The pragmatic individual contribution: publish ROAs, deploy ROV, monitor.

Take the quizBack to intermediate