/* First-match semantics (most NGFW products, iptables, Snort) */
/* Rules evaluated in order; FIRST matching rule wins */
/* Implication: rule ordering MATTERS CRITICALLY */
/* More specific rules must come BEFORE less specific rules */

/* Example — correct ordering (first-match) */
Rule 1: src=10.1.0.5/32   dst=8.8.8.8/32  proto=UDP port=53  → PERMIT
Rule 2: src=10.1.0.5/32   dst=any         proto=any           → DENY (block this host)
Rule 3: src=10.1.0.0/24   dst=any         proto=any           → PERMIT
Rule 99: src=any           dst=any                            → DENY (implicit)

/* Packet from 10.1.0.5 → 8.8.8.8:53 → matches Rule 1 → PERMIT */
/* Packet from 10.1.0.5 → 1.2.3.4    → matches Rule 2 → DENY */
/* Packet from 10.1.0.10 → anywhere   → matches Rule 3 → PERMIT */

/* If Rule 3 were placed before Rule 2: Rule 2 would never fire! */

/* Best-match semantics (BGP routing, some firewall vendors) */
/* Most specific matching rule wins (longest prefix) */
/* Rule ordering does NOT matter */
/* More complex to implement but harder to get wrong */
/* Used by: Juniper SRX (route-based mode), some SDN firewalls */

/* Shadow rule detection — compiler-time check */
/* Rule A is "shadowed" by Rule B if: */
/*   Rule B appears before Rule A AND Rule B matches all packets Rule A would match */
/* Shadow = Rule A can never fire (dead code) */

int detect_shadow(compiled_rule_t *rules, int n) {
    for (int i = 1; i < n; i++) {
        for (int j = 0; j < i; j++) {
            if (rule_covers(rules[j], rules[i])) {
                fprintf(stderr, "Rule %d shadowed by Rule %d\n",
                        rules[i].rule_id, rules[j].rule_id);
                /* In production: warn admin and optionally remove shadow rule */
            }
        }
    }
}

/* Rule conflict detection */
/* Rule A and Rule B conflict if: same traffic can match both */
/* but they have different actions */
/* Resolution: first-match resolves automatically, but warn admin */

/* Policy diff — show changes between two policy versions */
void policy_diff(policy_table_t *old_pt, policy_table_t *new_pt) {
    /* For each rule in new: present in old? Same action? */
    /* For each rule in old: removed from new? */
    /* Output: added, removed, changed, reordered rules */
    /* Critical for audit trail: every policy change must be logged */
}

/* Complete NGFW packet processing pipeline */
/* Built on VPP (from M18) with all modules integrated */

INGRESS PACKET (from NIC via DPDK)
  │
  ▼
[dpdk-input]          DPDK PMD, burst receive, mbuf allocation
  │
  ▼
[ethernet-input]      L2 demux, MAC learning, VLAN stripping
  │
  ▼
[ip4-input]           IP header validation, TTL check, checksum verify
                      IP defragmentation (reassemble before conntrack)
  │
  ▼
[ip4-unicast feature arc] ← VPP feature arc — ordered insertion points
  │
  ├── [ngfw-zone-lookup]          Classify src_zone and dst_zone
  │                               Set vnet_buffer meta: src/dst zone IDs
  │
  ├── [acl-plugin-in-ip4-fa]     Conntrack (M23): session lookup or create
  │                               TCP state machine
  │                               First-packet: evaluate policy (M26)
  │                               Cache: action in session entry
  │
  ├── [ngfw-nat-in2out]           NAT44-ED (M23): DNAT inbound
  │                               Rewrite dst_ip, dst_port, update checksums
  │
  ├── [ngfw-dpi-node]             DPI (M24): protocol dissection
  │                               App identification (app_id → session)
  │                               Hyperscan stream scan
  │
  ├── [ngfw-ips-node]             IPS (M25): Suricata rules inline
  │                               Threat intel IoC check
  │                               Beacon / anomaly scores
  │
  └── [ngfw-ssl-bump-node]        SSL inspection (M22): TLS MITM if required
                                  Generate forged cert, maintain two TLS legs
  │
  ▼
[ip4-lookup]          FIB lookup (M18 VPP FIB): find output interface
  │
  ▼
[ip4-rewrite]         Next-hop MAC rewrite (adjacency)
  │
  ▼
[ip4-output feature arc]
  │
  ├── [ngfw-nat-out2in]           NAT44-ED: SNAT outbound
  │                               Rewrite src_ip, src_port, checksums
  │
  └── [ngfw-log-node]             Session log (background ring buffer)
  │
  ▼
[interface-output]    TX queue, DPDK PMD transmit, batch to NIC

/* Control plane (separate from data plane) */
Control Plane Components:
  Policy Manager:      compile and install policy tables
  Threat Intel:        ingest feeds, maintain IoC databases
  Certificate Manager: generate inspection certs, manage CA
  Session Manager:     monitor session table, enforce limits
  Stats Collector:     per-rule hit counts, per-app bytes, per-zone traffic
  SIEM Exporter:       consume log ring, format, forward to Kafka/syslog
  REST API:            policy CRUD, stats queries, operational commands
  CLI:                 vppctl + custom NGFW CLI commands

/* Performance targets for production NGFW on 10G dual-port Mellanox */
/* (Based on your team's ConnectX infrastructure) */

Throughput:         10 Gbps bidirectional (line rate)
Sessions:           1M concurrent
New sessions/sec:   100K/s (TCP with 3-way handshake)
DPI throughput:     5–8 Gbps (with Hyperscan, 1000 sigs)
SSL inspect:        2–4 Gbps (crypto is the bottleneck)
Latency (add):      <100µs for established flows (DPDK)
Latency (add):      <500µs for new flows (session creation + policy eval)
CPU cores needed:   6–10 worker cores + 2 management cores
Memory:             16GB (1M sessions + DPI state + threat intel)

/* VPP worker affinity */
/* Workers 0-3: packet processing (pinned to NUMA 0, same as NIC) */
/* Workers 4-5: SSL inspection offload (CPU-intensive) */
/* Worker 6:   management plane (policy updates, CLI) */
/* Worker 7:   logging + SIEM export */

/* Capstone: suggested technology stack for Jio NGFW */
/*
  Data Plane:        FD.io VPP 23.x on DPDK 23.x
  NIC:               Mellanox ConnectX-6 Dx (100G, IPsec offload)
  OS:                Ubuntu 22.04 LTS with RT kernel patch
  Session Table:     clib_bihash_48_8 (VPP native)
  DPI Engine:        Intel Hyperscan / Vectorscan (open-source)
  IPS Rules:         Emerging Threats + custom Jio-specific rules
  Pattern Matching:  Hyperscan streaming mode (per-flow hs_stream)
  SSL Inspect:       OpenSSL 3.x for cert generation; BoringSSL option
  Threat Intel:      Feodo Tracker + AbuseCH + commercial feed TBD
  Policy:            Custom compiled rule engine in C
  Logging:           Ring buffer → Kafka → Elasticsearch
  API:               REST (gRPC protobuf for performance-sensitive ops)
  CLI:               vppctl + custom NGFW CLI (using vppctl framework)
  Testing:           TRex for traffic generation; Suricata for IDS validation
*/

/* Decision: why VPP over custom DPDK */
/* Custom DPDK requires reimplementing: IPv4/IPv6 forwarding, ARP/ND,   */
/* routing, fragmentation, GRE, VxLAN, MPLS, etc. — years of work       */
/* VPP provides all of these plus a plugin framework and graph engine     */
/* Estimated 12–18 months saved vs building raw DPDK pipeline from scratch */
/* VPP performance is within 5% of hand-optimised DPDK for most workloads */