Internet Protocol Authenticated Encryption

Introduction

IPAE (Internet Protocol Authenticated Encryption) is a proposal for a replacement for IPSEC that is faster with the goal encrypting everything on the Internet (not just a few VPNs) including domain name lookups, datagrams, and connections. It grew out of my thinking about combining the TLS and SCTP handshakes into a more efficient protocol, Encrypted Stream Transmission Protocol (ESTP). In that document, in explaining why IPSEC is inadequate, I speculated than a new protocol, there named IPSECv2, based on the same ideas might be more comprehensive and just as efficient as ESTP. Here I explore this idea further, while changing the name to IPAE.

The goals of IPAE are:

• Encrypt/authenticate as much as possible to minimize metadata collection.
• Use strong cryptography (e.g. 256-bit encryption) as the starting point, but allow new cryptography.
• Minimize key size (i.e. don’t use 15360-bit RSA!)
• Eliminate MITM attacks using public keys, providing server identity check and optional client identity check.
• Replace Certificate Authorities with DNS public keys (the commercial CA model is broken), allowing frequent key changes, by adding keys to SRV records.
• Allowing multiple virtual hosts per physical host in a better fashion than HTTPS.
• Efficiency: fewer round-trip times than TLS/SCTP (4 RTT) or IPSEC (6 RTT for Phase1+Phase2) or DTLS (3 RTT).
• Solving the Reflection Denial of Service problem (should be solved once and for all, not in every individual protocol like DNS, SCTP, etc.) using a general Host-to-Host cookie mechanism (stateless on servers), with TTL values in hours to minimize RTT most of the time.

Initially IPAE will be built on top of UDP using port 1138. Eventually it may be promoted to a status similar to IPSEC (e.g. using a protocol number in a IPv4 header Protocol field or IPv6 header Next Header field.

Overview

The Cookie Defense to Denial of Service Attacks

SCTP addresses Denial of Service (DoS) attacks and Reflected Denial of Service attacks in two ways. First, it is designed so that the server need not allocate any resources in response to the first packet from a client, and it provides the client a cookie to echo back that proves that the client can receive packets at the source address in the IPv4/IPv6 header. We need to implement this same feature in a datagram protocol. In IPAE a client that wants to initiate a connection to a server (either datagram, TCP SCTP, etc.), first checks its cache for a server cookie. If the cookie is found, and its Time-To-Live (TTL) value is less than the current time, then the connection is initiated and the cookie is provided. Otherwise it first sends a cookie request to the server. The server simply ignores any packet received for a new connection unless it contains a valid cookie that the server issued for the IP source address of this connection attempt (i.e. it validates the cryptographic MAC embedded in the cookie and checks the TTL value against the current time). This mechanism allows clients to reuse cookies for multiple connections over a period of minutes or hours (depending on the TTL given out by the server), and so this extra round-trip time amortized over possibly many connections. Servers do not need to store information about the cookies they hand out, making these cookie requests a poor DoS attack vector. Cookie requests are also padded to be longer than cookie responses, so that Reflected DoS attacks are diminished, rather than amplified. This mechanism also allows servers to better handle DoS attacks employing cookie requests, as legitimate clients only send cookie requests a small number of times (once in most cases, two or three times if retransmission is required) during the TTL period, so receiving frequent cookie requests from a given IP address is a sign of an attack and reason to drop all packets from the source address for some time. Such defense requires some resources to be allocated after sending a cookie response, but this state can be temporary and reclaimed as necessary.

Cookies simplify the protocols that follow, since they know the client is not forging its source IP address.

The COOKIE_REQUEST IPAE packet type is used by a client requesting a cookie from a server. It includes a client cookie (which the server is free to ignore).

Host to Host Protocols

Cookies are an instance of a Host-to-Host Protocol substrate on which other protocols may be built. The ARPAnet, prior to the introduction of IP, had explicit host-to-host protocols (as well as IMP-to-IMP and host-to-IMP protocols) for congestion control. Since packet buffers are often allocated on in a host operating system kernel, doing per-connection congestion control between rather than per-host congestion control might be seen as a step backward. IPSEC and IPAE are examples of protocols that restore a host-to-host aspect to IP, and it may be worth exploring what other features, such as congestion control, might exploit this host-to-host channel. However, this is beyond the scope of this particular document.

To be continued...

Blah blah blah.

Glossary