CurveCP: Usable security for the Internet

An ISP or site administrator can easily run a huge number of CurveCP servers on a single global IPv4 address, even if the servers are independently operated with separate long-term public keys. This feature is provided by a simple extension mechanism in CurveCP addresses.
CurveCP servers are inherently anti-aliased, providing automatic virtual hosting and fixing some of the deficiencies in the "same-origin" policy in web browsers. This feature is provided by a simple domain-name mechanism in CurveCP addresses.
If a site has two server addresses, and one server is down, a CurveCP client will quickly connect to the other address.
A CurveCP connection remains fully functional even if the client changes IP address.

CurveCP is fully compatible with existing NAT (network address translation) mechanisms; none of the above features require clients or servers to know the global addresses of their gateways.

Server addresses

Before a client can create a CurveCP connection, it needs to know (1) the server's long-term public key and (2) the server's address. The server's address has four components:

4 bytes: a global IPv4 address identifying the server gateway. The client sends CurveCP packets through the Internet to this IPv4 address. Typically this address is statically configured into the gateway computer by the gateway administrator, and broadcast through DNS. (In principle, CurveCP can also be used within global address spaces other than IPv4, but this page focuses on IPv4 for concreteness.)
2 bytes: a UDP port. The client sends CurveCP packets to this UDP port. Typically this port is specified by a higher-level protocol using CurveCP, the same way that a TCP port is specified by a higher-level protocol using TCP (e.g., TCP port 25 for mail transfer through SMTP).
16 bytes: an extension understood by the server gateway. The semantics of this extension are decided by the server gateway administrator; the client simply copies the extension without trying to understand it.
Variable length, at most 255 bytes: the server's domain name.

These components are typically used as follows. Packets from the client are forwarded by Internet routers until they reach the gateway computer at this IPv4 address. Normally these routers ignore the UDP port (and extension), except that some firewalls limit the clients that can reach various UDP ports. Within the gateway computer, the operating-system kernel uses the UDP port to route the packet to a CurveCP-aware program. There are two common possibilities at this point:

Two-level gateway-server structure: The program extracts a local IPv4 or IPv6 or MAC or ... address from the CurveCP extension and forwards the packet accordingly to a local server. That local server is the CurveCP server; it has the corresponding secret key and decrypts the CurveCP packet. This last step of forwarding typically means rewriting the packet header (NAT) to contain the server's local address instead of the gateway's IPv4 address; the opposite translation happens for packets sent out to the Internet.
Single-level structure: This program is already the CurveCP server. The server is the gateway. The server has its own IPv4 address. No extra forwarding is necessary.

The server's domain name is sent by the client (encrypted) inside the client's second packet, the Initiate packet. The server drops the Initiate packet if the domain name is wrong (i.e., does not match the server's locally configured domain name). If third parties set up unauthorized domain names that are aliased to the same server then CurveCP connections to those domain names will fail. "Virtual" servers allow several configured domain names and take different actions for different domain names.

Client addresses

The client's packets include (1) the client's short-term public key and (2) the client's address. The client's address has three components:

4 bytes: a global IPv4 address identifying the client gateway. The server sends CurveCP packets through the Internet to this IPv4 address. Typically this address is dynamically configured into the client, for example through a DHCP server set up by the client gateway administrator.
2 bytes: a UDP port. The server sends CurveCP packets to this UDP port.
16 bytes: an extension understood by the client gateway. The semantics of this extension are decided by the client gateway administrator; the server simply copies the extension without trying to understand it. Typically this extension is dynamically configured into the client.

Current operating-system kernels already contain facilities to automatically copy a dynamically configured IPv4 address into each outgoing UDP packet, simplifying CurveCP client software. Current kernels also assign UDP ports. Some UDP applications assign their own random UDP ports as a security feature (for kernels that don't randomize UDP ports), but this feature would be redundant for CurveCP.

Current kernels do not contain analogous facilities for extensions. UNIX/Linux clients are encouraged to read 16 bytes (binary) from the file /etc/curvecpextension, and to re-read this file frequently to catch any updates; or to use 16 all-zero bytes if that file doesn't exist.

Backup servers

An Internet server can advertise multiple IP addresses, typically the addresses of two or three servers. If one server crashes then clients can connect to another server.

Unfortunately, a typical client will start by asking TCP to connect only to the first address. If that server is unresponsive, TCP will spend a long time trying many SYN packets to that address before aborting: typically 5 packets over 180 seconds. The client will then ask TCP to connect to the second address, but the user has already given up at this point; the connection is a failure from the user's perspective. Typical TCP implementations don't support a "connect to several addresses" feature.

A CurveCP client tries a Hello packet to the first address, then a Hello packet to the second address, etc. If one of the servers is up then the connection will succeed promptly. This drastically reduces the impact of a single-server outage: the outage typically wastes only 1 packet and only about 1 second with CurveCP, rather than 5 packets and 180 seconds with TCP.

Load-balancing DNS servers reduce the impact of outages in a different way, by quickly removing the advertisements for servers that are down. However, load-balancing DNS does not prevent failures for users who received an advertisement of a server just before that server crashed, while CurveCP does prevent these failures. Note that neither approach prevents failures when a server crashes in the middle of a connection.

Mobile clients

Bob has an open SSH connection from his laptop in his hotel room. He closes the laptop, checks out of the hotel, walks down the street to an Internet cafe, opens the laptop, and acquires a new IP address. All his open SSH connections are now unresponsive, because the server is sending responses to the laptop's old IP address. Bob has to close the SSH connections and make new connections.

CurveCP supports mobile clients. If the server sees a new address attached to a verified packet from the client, the server tries sending its response to that address. If the client acknowledges that response from the same new address, the server switches to that address for subsequent packets, smoothly migrating the connection to that address.

The client does not cryptographically authenticate (and in general does not have any secure way to know) its own address. If an eavesdropping attacker takes a packet from the client, forges a new packet with the same contents but the attacker's address, and prevents the original packet from reaching the server (for example, by flooding the network), then the server will try sending its response to the attacker's address. If the attacker then forwards that response to the client and similarly modifies the address on the client's acknowledgment, then the server will send subsequent packets to the attacker's address. However, the client will continue sending packets from its original address, and the only way for the attacker to continue misdirecting the server's packets is to continue blocking the client's packets. An attacker with this much power can successfully deny service, but could also have denied service without any mobility features. Note that the attacker still cannot compromise the confidentiality and integrity of the connection.

Version

This is version 2011.02.09 of the addressing.html web page.