AI-Powered IPsec VPN Protocol Analyzer and Security Assessment Framework
National Technical Research Organisation (NTRO) · Blockchain & Cybersecurity · Software
Well-specified and you generate your own data, but IPsec's encrypted payload limits passive inference more than the email-TLS equivalent — be clear about what you infer versus observe, and consider that SIH26159 is the cleaner problem in the same family.
What it actually is
IPsec VPNs secure government and enterprise traffic, but their security depends on the crypto algorithms, key exchange and mode chosen, and misconfigurations silently weaken them. The ask is a tool that analyses IPsec traffic, infers the VPN's mode and cryptographic configuration, assesses the security posture and generates a recommendations report — including building a testbed to generate the varied configurations to analyse.
What to build
A protocol-analysis platform with two halves: a testbed that stands up IPsec VPNs across many configurations — tunnel and transport mode, AES-128, AES-256, AES-GCM, various key-exchange and authentication choices — to generate labelled traffic, and an analyser that inspects captured or live IPsec traffic, infers the operating mode and cryptographic parameters from the IKE negotiation and ESP characteristics, evaluates the configuration against security best practice, flags weak or outdated choices, and generates an automated assessment report with actionable recommendations.
Smallest thing that wins the room
Analyse captured traffic from two IPsec tunnels the testbed created — one using AES-GCM with strong key exchange and one using a weak legacy cipher — and show the analyser correctly inferring each tunnel's mode and crypto configuration and flagging the weak one with a concrete recommendation.
How crowded this one gets
A guess, projected from the 2025 statements — the last year where both the submission counts and the winners were published.
Quieter than 80% of the 226 · #45 of 226 by expected field
Few teams are likely to go here. The best odds on the board come from statements like this.
Why: defence, intelligence and space bodies drew small fields.
This is a guess, not a fact
Nobody has published 2026’s numbers yet. This is an analysed estimate from last year’s pattern, so please do not take it as the truth — check the live counter on the SIH portal before you decide anything. The range covers the middle half of likely outcomes, so one statement in two lands outside it. Entry closes at 500 ideas per statement, so no range goes past that — a statement that reaches the cap fills and shuts rather than drawing an unlimited crowd. The model reads only three things a team can see before choosing — software or hardware, the theme, and what kind of body posted it — and those explain about a quarter of the variation in last year’s field sizes (R² 0.25 on held-out statements). Trust the band more than the number, and the ordering more than either. It cannot see how good your idea is, which is the part that actually decides it.
The scores
The number is the shorthand. The line under it is the reason.
Acceptance potential
3/5The testbed requirement means you generate your own data and the problem is well-specified, but IPsec's encrypted ESP payload limits what can be passively inferred, so the analyser sees less than the email-TLS equivalent and a judge will ask how you assess crypto you cannot directly observe — SIH26159 is the cleaner sibling.
Feasibility
3/5Building the IPsec testbed with strongSwan and capturing traffic is achievable, and IKE negotiation is partly visible, but once IPsec is established the ESP payload is encrypted so much of the cryptographic configuration must be inferred from the IKE handshake and observable metadata rather than read directly, which is genuinely harder than the email-TLS case.
Innovation scope
3/5The analysis is largely dictated by the IPsec and IKE protocols, so your room is in the inference of configuration from limited observables and in the testbed automation, rather than in the assessment criteria which follow best practice.
Clarity
4/5The description specifies the testbed configurations to support, the analysis tasks and the report output, so the deliverable is well defined, and the testbed requirement usefully tells you how to generate your own data.
Effort
MassiveStanding up an automated multi-configuration IPsec testbed and building an analyser that infers mode and crypto parameters from partly-encrypted traffic plus a reporting layer is a large, multi-part effort.
Demo-ability
MediumInferring a tunnel's configuration and flagging a weak one is a clear result, but IPsec analysis is abstract and needs the protocol context explained before a judge appreciates what is being inferred.
In its favour
- Green flag: The testbed requirement means you generate your own labelled traffic across configurations, removing data-sourcing risk
- Green flag: strongSwan makes standing up varied IPsec configurations genuinely automatable, so the testbed half is tractable
- Green flag: IKE negotiation exposes cipher and key-exchange proposals, giving you a real observable basis for configuration inference
- Green flag: The assessment criteria come from published best practice, so your verdicts have an authoritative basis
Against it
- Red flag: Once IPsec is established the ESP payload is encrypted, so much of the crypto configuration must be inferred from the handshake and metadata rather than read, which bounds what the analyser can honestly assess
- Red flag: IKEv2 can hide more of the negotiation than IKEv1, so what you can observe depends on the version and a judge will probe that boundary
- Red flag: The testbed automation across many configurations is more work than teams expect and can consume the time meant for the analyser
- Red flag: Its sibling SIH26159 does the same class of assessment on email TLS where the handshake is more observable, so this is the harder of the two
What you will be writing
- strongSwan IPsec testbed automation
- IKEv1/IKEv2 negotiation analysis
- ESP traffic characteristic inference
- Scapy / tshark packet analysis
- Configuration best-practice rule evaluation
- Automated assessment report generation
- VPN security
- Protocol analysis
- Cryptographic assessment
Prior art to read before you start
IPsec configuration inference · VPN security posture assessment · IKE negotiation analysis
Analysed by Claude Opus. Every score above is a judgment call with its reasoning attached — kindly cross-check this against the official statement on the SIH portal before your team commits to it.