Follow stream · CASE 03 · Network Security · Protocol Analysis · Smart India Hackathon 2026 · Problem statement 160 · Team Highlanders

IPsec Sentinel

AI-Powered IPsec VPN Protocol Analyzer

Facts are parsed. Estimates are inferred.

Advanced build

Milestones M0–M10 (foundation through interfaces) are recorded as passed in the repository's progress log.

Passive IPsec protocol analysis and security assessment. Give it a packet capture and it returns a graded, cited assessment of every VPN tunnel in it, plus a ready-to-review configuration change for the weak ones.

Source code ↗

01 Lab: grade a proposal

Pick what a tunnel negotiated. The findings cite the clause they come from.

Key exchange
Authentication
Encryption
Integrity
Diffie-Hellman group

A toy grader for one proposal, based on RFC 8247 requirement levels, RFC 9395 and two well-known attacks. IPsec Sentinel itself parses real captures, separates parsed facts from inferred estimates, and applies 26 cited rules under six baselines. Its bundled worst-case capture grades F, as this preset does.

02 Brief

The problem

Wireshark shows you an IKE exchange. It does not tell you that the exchange agreed 3DES with a 1024-bit Diffie-Hellman group, that NIST disallowed that, that it is exposed to Logjam, or what to replace it with on your gateway. The product is the gap between visible and judged.

Why it matters

VPNs are trusted by default because they are encrypted, but encryption only proves that something was negotiated. It says nothing about whether the result is any good. Auditors and network engineers need different answers from the same capture, and most tools serve neither.

03 Architecture

Two lanes that never mix. Deterministic facts parsed from cleartext IKE go to Section A. Model estimates inferred from encrypted ESP, each with a calibrated confidence, go to Section B. A Pydantic validator refuses to build a report that mixes them.

IPsec Sentinel architecture: a packet capture is parsed (IKEv1/IKEv2, NAT-T, ESP correlation) into tunnels. Lane A, verified facts, applies 26 deterministic rules under six baselines, cross-checked with operator-supplied device state. Lane B, estimates, infers traffic type from encrypted flow shape with calibrated confidence. A validator keeps the lanes apart. Both feed the graded report and remediation for six platforms.SECTION A · VERIFIED FACTSSECTION B · INFERRED ESTIMATESVALIDATOR · LANES NEVER MIXcapture.pcapdevicexfrm / swanctlParserIKEv1/2 · NAT-T · ESP26 rules × 6 baselineseach finding cites its clausePQ readinessRFC 9370 · RFC 8784Flow-shape classifiercalibrated confidence · SHAPAbstainwhen signal is thinGraded reportHTML/PDF/JSON/CEFRemediation6 platforms
FIG. 03Facts are parsed · estimates are inferred
  1. 01

    Parser

    pcap → IKEv1 / IKEv2 (including NAT-T on UDP 4500) → correlated with the ESP flows each negotiation protects.

  2. 02

    Assessment engine

    26 deterministic rules, each citing its standard, under six baselines: NIST SP 800-77r1, CNSA 1.0, BSI TR-02102-3, RFC 8221/8247, ITSAR, CERT-In.

  3. 03

    Device-state cross-check

    Reads operator-supplied `ip xfrm state` / `swanctl --list-sas` output to close the rekey blind spot, without ever connecting to the gateway.

  4. 04

    Traffic inference

    Classifies what a tunnel carries from encrypted flow shape alone, with calibrated confidence, SHAP explanations and abstention when the signal is thin.

  5. 05

    Remediation

    Both-ends configuration for six platforms, sequenced for zero packet loss, with blast radius and a suggested maintenance window.

  6. 06

    Reporting & export

    HTML, PDF, versioned JSON and CEF / LEEF / syslog for SIEMs. Post-quantum readiness is graded against RFC 9370 and RFC 8784.

04 Implementation

Stack

Python · Pydantic · scikit-learn · SHAP · strongSwan · Docker · pcap / IKE / ESP · FastAPI dashboard

My contribution

Built and maintains the public repository (sole committer on GitHub). Submitted with team Highlanders at SIH 2026.

  • A containerised strongSwan two-peer testbed with dual-tap capture records ground-truth negotiated parameters next to each pcap.
  • A traffic-generation sweep (VoIP, video, web, email, messaging, ICMP) builds a labelled dataset documented with a datacard.
  • The deterministic IKE parser is cross-checked against tshark output.
  • Remediation is verified from a follow-up capture: a finding closes only when the fix is actually on the wire.
  • An interface watcher alerts on drift, measured against each tunnel's own history.

05 Engineering decisions

  1. A validator, not an assert

    Python's -O flag strips assertions, which would silently remove the product's central guarantee in optimised deployments. The fact/estimate separation is a Pydantic model validator, and a test runs it under -O.

  2. Name the blind spot

    CREATE_CHILD_SA is encrypted, so every rekey after the first is invisible on the wire. Instead of pretending otherwise, the tool reads operator-supplied device state. In the bundled demo this drops a tunnel's score from 33 to 12: the strongest-looking tunnel has 3DES and MD5 installed in the kernel.

  3. Passive by construction

    It never writes to a network device and never takes a credential. A test walks every module's AST to keep it that way. Active scanning exists, but it refuses to run without --i-have-authorisation.

06 Evidence

Sourced from: github.com/Prathamesh0-0/IPsec_Sentinel — README, docs/ARCHITECTURE.md, PROGRESS.md