IETF Internet-Drafts: Pilot Protocol Revision 01
IETF Internet-Drafts: Pilot Protocol Revision 01
TL;DR:
- Both IETF Internet-Drafts (Problem Statement and Protocol Specification) have been updated to revision 01, reflecting 80+ commits of new functionality since the initial March 2026 submission.
- The Protocol Specification now covers HKDF key derivation, PILP NAT punch frames, enterprise RBAC and audit trails, registry high availability, 18 new IPC commands, and a gateway bridge.
- The Problem Statement adds multi-tenant isolation requirements and positions Pilot against 30+ new IETF drafts filed since the CATALIST BoF at IETF 125.
When we submitted the initial Pilot Protocol Internet-Drafts to the IETF in March 2026, the protocol had a solid core: 48-bit virtual addressing, UDP tunnel encapsulation, X25519 key exchange, and a registry-mediated trust model. Three weeks and 80+ commits later, the implementation has grown substantially. Revision 01 brings the formal specification in line with what the code already does.
This post walks through what changed in each draft and why it matters for the broader IETF conversation around AI agent networking.
Table of Contents
- The IETF landscape has changed
- Problem Statement: what's new
- Protocol Specification: what's new
- Reading the drafts
- Frequently asked questions
The IETF landscape has changed
Since the original submission, the IETF agent protocol space has exploded. Over 30 individual drafts have been filed, and the CATALIST Birds of a Feather session at IETF 125 (Shenzhen, March 2026) marked the first formal coordination effort. Proposals now span agent identity (AIP), agent transfer protocols (AGTP, ATP), agent discovery (AID), audit trails, and routing considerations.
Despite this activity, a pattern holds: every new draft operates at the application layer over HTTP. None addresses the network or transport layer. None provides virtual addressing, overlay tunneling, or built-in NAT traversal. This validates the original problem statement's thesis and gives Pilot Protocol a distinct position in the conversation.
The revised Problem Statement adds a structured comparison of these new proposals, documenting where they overlap with Pilot and where they leave gaps.
Problem Statement: what's new
The Problem Statement draft (draft-teodor-pilot-problem-statement-01) receives four categories of updates:
CATALIST context
The introduction now cites the CATALIST BoF and the 30+ draft landscape. This frames the document within the current IETF coordination effort rather than as a standalone proposal.
Multi-tenant isolation
A new problem section (3.6) addresses the absence of network-level multi-tenancy in existing agent protocols. Organizations running multiple agent teams need isolated network segments with independent membership control, role-based access, and per-network policy enforcement. No existing draft covers this.
New requirements
Two new requirements formalize what the implementation already provides:
| Requirement | Description |
|---|---|
| REQ-12 | Multi-tenant isolation with independent membership control, RBAC (owner, admin, member), and per-network policy enforcement |
| REQ-13 | Audit trail recording security-relevant operations for compliance and forensic analysis |
Gap analysis updates
The existing approaches section now includes AGTP (intent-based methods over QUIC, but no overlay addressing), ATP (two-tier architecture with DNS discovery, but requires server infrastructure), AIP (verifiable identity with delegation tokens, but no transport), and a summary of CATALIST coordination status. Ten new informative references are added.
Protocol Specification: what's new
The Protocol Specification draft (draft-teodor-pilot-protocol-01) sees the largest changes. Here's what was added.
PILP NAT punch frame
A new tunnel frame type joins PILT, PILS, PILK, and PILA:
+------+------+------+------+----------+
| 0x50 | 0x49 | 0x4C | 0x50 | SenderID |
+------+------+------+------+----------+
P I L P 4 bytes
PILP frames carry no overlay payload. Their sole purpose is to create NAT bindings during hole-punch coordination. Receivers silently discard them after recording the sender's source address.
HKDF key derivation
The original draft said X25519 ECDH produces a shared secret and derives an AES-256-GCM key, but didn't specify how. Revision 01 adds the full HKDF specification (RFC 5869):
Extract: PRK = HMAC-SHA256(salt=empty, IKM=shared_secret)
Expand: key = HMAC-SHA256(PRK, info || 0x01)
Two distinct info strings separate tunnel encryption (pilot-tunnel-v1) from application-layer encryption on port 443 (pilot-secure-v1). GCM Additional Authenticated Data (AAD) is also specified: the sender's Node ID for tunnel encryption, and the nonce prefix for port 443.
Role-prefix nonce scheme
Port 443 encryption now uses a role-prefix nonce scheme that prevents nonce collision between the two sides of a connection:
| Role | Prefix | Counter |
|---|---|---|
| Server | 0x00000001 |
8-byte counter starting at 0 |
| Client | 0x00000002 |
8-byte counter starting at 0 |
Replay detection
The security section now specifies a sliding-window replay bitmap (recommended window: 256 nonces). Nonces older than the window or already seen within it are rejected, providing replay protection while tolerating out-of-order packet delivery.
Expanded IPC command set
Eighteen new IPC commands (0x11 through 0x22) are added, covering hostname resolution, visibility control, deregistration, tags, webhooks, task execution, network management, and health checks. A new Network sub-command table documents the seven operations for multi-tenant network management (list, join, leave, members, invite, poll invites, respond to invite).
Registry high availability
A new section documents the hot-standby replication architecture: one primary, one or more standbys, push-based state snapshots on mutations, 15-second heartbeat for liveness detection, and manual failover promotion.
Enterprise extensions
A full new top-level section covers the enterprise control plane:
- RBAC with three roles: Owner (full control), Admin (manage members and policies), Member (participate)
- Network policies including per-network
max_membersenforcement - Audit trail as a ring-buffer log recording registration, trust changes, network membership, RBAC modifications, policy changes, and key rotation
- Identity integration with optional OIDC/JWT validation, RS256 signature verification, JWKS endpoint caching, and directory synchronization webhooks
Gateway bridge
A new section specifies the gateway that bridges the overlay and standard IP networks. It maps virtual addresses to local IP addresses via loopback aliases, enabling unmodified TCP programs (curl, browsers, databases) to communicate with overlay agents without any code changes.
Security additions
Three new security subsections document P2P handshake signing (Ed25519 signatures over relay messages to prevent forgery by a compromised registry), registry authentication (Ed25519 signatures or admin tokens for write operations), and TLS certificate pinning (SHA-256 fingerprint verification).
Updated implementation status
The implementation status section now reports 983 tests validated across 5 GCP regions. The Python SDK is upgraded from beta to production-ready. A new Node.js SDK entry documents the TypeScript FFI bindings published on npm.
Reading the drafts
Both drafts are available in multiple formats:
| Draft | HTML | Plain Text |
|---|---|---|
| Problem Statement | HTML | TXT |
| Protocol Specification | HTML | TXT |
The source Markdown and build tooling live in docs/ietf/ in the repository. Run make build to regenerate from source (requires kramdown-rfc and xml2rfc).
Frequently asked questions
What is an IETF Internet-Draft?
An Internet-Draft (I-D) is a working document submitted to the Internet Engineering Task Force for review and discussion. It is the standard mechanism for proposing new internet protocols and is a prerequisite for eventual publication as an RFC (Request for Comments).
What is the CATALIST BoF?
CATALIST (Coordinating AI Agent Layer Interoperability and Standardization) was a Birds of a Feather session at IETF 125 in Shenzhen (March 2026). It was the first formal IETF coordination effort specifically focused on AI agent networking protocols.
How does Pilot differ from other IETF agent drafts?
All other IETF agent drafts (AGTP, ATP, AIP, AID, and others) operate at the application layer over HTTP. Pilot Protocol is the only proposal that operates at the network and transport layer, providing virtual addressing, overlay tunneling, built-in NAT traversal, and encrypted encapsulation.
Will there be a revision 02?
Yes. The drafts will continue to track the implementation as new features are added and as the CATALIST working group conversation develops. Feedback from the IETF community will be incorporated into subsequent revisions.
