AI-Powered IPsec VPN Protocol Analyzer and Security Assessment Framework
National Technical Research Organisation (NTRO)
Reasonable choice. The scoreboard liked it. The scoreboard is not the one asking questions on the day.
Worth considering. 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. Roughly 70–160 teams are expected to go here.
The receipts
Every red flag on this statement, in full. These are the four places it bites.
Exhibit A
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
It gets worse
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
Still reading?
The testbed automation across many configurations is more work than teams expect and can consume the time meant for the analyser
And the finisher
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
The damage report
Every score this statement earned, and what each one actually costs you.
Feasibility
3/5Buildable. Not comfortably. There is a week in here you have not planned for yet.
Building 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/5Mildly interesting. The novelty will not carry the room; the build has to.
The 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 ask is unambiguous, which quietly removes your favourite excuse.
The 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.
Acceptance potential
3/5Middle of the pack. This statement will not win the room for you — you will have to.
The 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.
Effort
MassiveA semester of work wearing a hackathon costume. Something is getting cut; decide what now, not in week five.
Standing 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
MediumDemoable, if you rehearse it. Nobody rehearses it.
Inferring 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.
Data
None suppliedNo dataset comes with this one, so every accuracy figure you quote is a number about labels you invented.
Nothing is provided with the statement. You are sourcing, cleaning and labelling it yourself, and that work is invisible in the demo but very visible in the questions.
The demo they will have already seen
Somewhere around 70–160 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly — you have built predictably, which costs exactly the same and hurts more.
What survives
The ground worth standing on when the questions start.
- The testbed requirement means you generate your own labelled traffic across configurations, removing data-sourcing risk
- strongSwan makes standing up varied IPsec configurations genuinely automatable, so the testbed half is tractable
- IKE negotiation exposes cipher and key-exchange proposals, giving you a real observable basis for configuration inference
Nothing here is fatal. It is just the list of places this statement pushes back, and you now get to push there first.
The framing is a joke. The findings are not — they are the same analysis on the statement page, and every line above is attached to a score or a fact in the record. It is one opinion with its reasoning attached, so argue with it before you trust it.