Architecture and detection

Architecture and detection

TFPS sits outside the SIP transaction path. It captures IPv4 packets with AF_PACKET, classifies SIP in userspace, and writes condemned addresses to an XDP map.

NIC → driver → XDP ← condemned sources are dropped here
                 ↓
              skb → packet capture → netfilter → softswitch

A packet dropped at XDP does not reach the later libpcap tap used by sngrep, tcpdump, and tshark. TFPS does not bind UDP 5060 and does not require softswitch logs.

Prevention pipeline

The inexpensive gates run first: IPv4/UDP decoding, configured SIP port, and SIP shape. Perimeter detectors then evaluate scanner user-agents, suspicious identities and URIs, registration enumeration, and authentication outcomes.

A normal digest challenge is not a failure. TFPS counts a rejected credential only when a request carrying Authorization or Proxy-Authorization receives another 401 or 407. Requests and responses are correlated by Via branch, with Call-ID and CSeq as fallback, and retransmissions count once.

The detailed, code-ordered account is in DETECTION.md.

Behavioural layer

When explicitly enabled, TFPS classifies international attempts using the source peer's dial plan. A sequential detector combines evidence from new destination prefixes, failed call completion, and source-relative volume. Benign rates are learned from the deployment rather than configured as traffic thresholds.

This layer is highly experimental. Learning and verdict reporting exist; applying the behavioural verdict to the kernel or returning a forged SIP 603 does not.

Read the rationale and references in docs/anomaly-detection.md.

Design sources

• SPEC.md — architecture decisions;
• CONTEXT.md — normative project vocabulary; and
• DETECTION.md — packet path, tests, counters, and worked examples.