rfcs/draft-ip-and-dns-on-interconnected-vpn.md at master - rfcs

27 KiB

Raw Permalink Blame History

title	author	status
IP and DNS standards for interconnected VPNs	Keith Irwin <ki9@gf4.pw>	Proposed

Abstract

This standard specifies a convention for host addressing and domain namespacing on interconnected virtual private networks (VPNs). The standard covers the assignment of internet protocol (IP) addresses using sane subnetworks for efficient routing within and between meshed VPNs. Best practices are provided for centralized (hub-and-spoke) routing, as well as direct client host connections. Later, the document describes proper allocation of domain and subdomain names on a private top-level zone, providing fully-qualified domain names for the private IPs on the VPNs. Finally, suggestions are provided for using these domains for SSL certificates, mailservers, web proxies, and other existing web protocols.

1. Introduction
1.1. Notational conventions
1.1.1. Requirements notation
1.1.2. Definitions 1.2. Structure of this document
2. Virtual Private Network
2.1. Software
2.2. Address allocation
2.2.1. IPv4
2.2.2. IPv6
2.3. Topology
2.3.1. Hub-and-spoke routing
2.3.2. Peer-to-peer routing
3. Domain name service
3.1. User domain names
3.2. Server domain names
3.3. Wildcard CNAMEs
4. Certificate authority
5. Proposal for a names and numbers authority
6. Procedural Information
6.1. Security considerations
6.2. Configuration considerations
Appendix A. Example configurations
A.1. Bind9 nameserver
A.2. UFW firewall
A.3. Nginx proxy to dev server
A.4. Nginx proxy from the internet to a client host
A.5. Postfix relay from the internet to a client host

1. Introduction

1.1. Notational conventions

1.1.1. Requirements notation

This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC2119].

1.1.2. Definitions

This document uses the following terms in respect to their subsequently provided definitions.

Classless Inter-Domain Routing or CIDR A notation for describing subnetwork address space, as per [RFC4632]

VPN or virtual private network A virtual IP network operating in accordance with [RFC1918] that lets devices connect to each other as if on a "virtual LAN".

hub-and-spoke or HAS A type of network topology where a single host acts as a central server (hub) for other client hosts (spokes).

intervpn Anything related to network connections and communication among VPNs

intravpn Anything related to network connections and communication within a VPN

client or device A user's wireguard-connected network host which acts as a "spoke" in its local HAS network.

server A community's device which acts as a hub in the local HAS network and, possibly, as a gateway to the wider intervpn network.

user A member of an internet community, who may control multiple client hosts (computers, phones, etc).

community or tilde Any private internet community that manages a virtual private network for multiple users.

NS or nameservers DNS nameservers run by communities in accordance with [RFC1035].

Top-level domain or TLD The highest level of the domain name system. Well-known TLDs include ".com" and ".org", but this document mainly refers to "private" TLDs that are not recognized by the Internet Assigned Numbers Authority (IANA)'s root nameservers.

CA or certificate authority A community acts as a CA by signing SSL/TLS certificates for their private TLD per [RFC5280].

Store now, decrypt later or SNDL A type of encryption attack that involves storing encrypted transmissions in data centers so that they can be decrypted in the future with better technology, namely, quantum computers.

1.2. Structure of this document

This document is divided into several sections.

This section, section 1, is a short introduction to the document.

Section 2 describes IP standards for communities to manage interconnected VPNs.

Section 3 specifies a convention for allocating private domain names pointing to private IP addresses.

Section 4 describes how a tilde can sign SSL/TLS certificates for users, and how they could be used.

Section 5 proposes the formation of an authority to manage intervpn assigned names and numbers.

Section 6 mentions security implications of the standard and warns of potentially breaking configuration changes.

Appendix A has some example configurations showing various best practices and use-cases for the network described in this document.

2. Virtual Private Network

2.1. Software

Communities MUST use the latest stable version of wireguard VPN software. VPN connections MUST implement quantum-resistant symmetric-key encryption to protect users from SNDL attacks. This can be done in wireguard by setting PSKs in every [Peer] section (see the examples in Section 2.3).

When generating user configs for wireguard, the server MUST NOT keep the client's private key anywhere on the server, including logfiles. It is to be sent to the user and forgotten.

Clients' new configurations MUST be sent to the user through a strongly-encrypted channel such as an existing wireguard connection, PGP-encrypted email, signal messenger, matrix/telegram encrypted room, etc. (A non-vpn https connection SHOULD NOT be used).

2.2. Address allocation

Communities MUST allocate either an IPv4 address, an IPv6 address, or both, to every host on their VPN. The IPs SHOULD be created in accordance with the standards outlined in this section. Ideally, a community MAY provide both addresses until IPv4-space is exhausted, and only IPv6 addresses after that.

2.2.1. IPv4

Section 3 of [RFC1918]] describes 3 IP spaces The Internet Assigned Numbers Authority (IANA) has reserved three IPv4 address spaces for private use:

10/8
172.16/12
192.168/16

Of these, only 10/8 is big enough to contain an organized network of multiple internet communities. Communities that want to interconnect MUST use this subnet to allocate IP addresses to both servers and clients. Communities SHOULD allocate IPv4 addresses of the form 10.x.y.z to user hosts, where x, y, and z are integers of the form 1 ≤ I ≤ 254 and:

x determines a community's entire 10.x/16 network
y determines a user's 10.x.y/24 network or
z determines a single host, 10.x.y.z/32.

The special case of y=0 and the respective network 10.x.0/24 SHOULD be reserved servers. Thus, a community's first server is typically addressed 10.x.0.1.

For example: Your home pc could be 10.11.1.1 and your phone 10.11.1.2. After configuring wireguard, you can use either device to ping your friend, whose pc is at 10.11.2.1.

2.2.2. IPv6

IPv6 MAY be implemented, where IP addresses SHOULD take the form fd69:1337:0:420:f4:x:y:z. This /80 network SHOULD be organized as above, except x, y, and z are now hexadecimal numbers of the form, 0 ≤ H ≤ ffff. Thus,

Several communities can use the fd69:1337:0:420:f4::/80 network
Each community gets a network of the form fd69:1337:0:420:f4:x::/96
Each community can host their servers on fd69:1337:0:420:f4:x::/112
Each user gets a fd69:1337:0:420:f4:x:y::/112 network for their devices

2.3. Topology

The proposed topology of the network is a mesh internetwork where each mesh node is a community's server, and each of these servers acts as a hub for the community's users' devices. Thus, servers act as a gateway between the local vpn and the greater intervpn network. This default topology allows users to permissionlessly create their own p2p connections between their clients, reducing latency and improving decentralization.

2.3.1. Hub-and-spoke routing

Wireguard configurations provided to users SHOULD be configured by default to route traffic from one client to another through the central hub server. This allows newly-connected devices to ping each other without further configuration.

Figure 2.3.1.a. Intervpn HAS routing

        +===========+        +=============+
        | myserver  +--------+ otherserver |
        | 10.11.0.1 |        |  10.13.0.1  |
        +=+=======+=+        +======+======+
          |       |                 |
+=========+=+   +=+=========+  +====+======+
|   mypc    |   |  myphone  |  | friendpc  |
| 10.11.1.1 |   | 10.11.1.2 |  | 10.13.1.1 |
+====+======+   +===========+  +====+======+

For example In Figure 2.3.1.a, myserver and otherserver represent two communities' servers and the three other blocks represent users' clients. It is clear from the diagram that a connection from myphone to friendpc will be routed through both servers. The routing may seem complicated, but the organized subnetting makes the configuration simple. Each of the two servers will have wireguard configs like this:

myserver:/etc/wireguard/mynet.conf

[Interface] # myserver
PrivateKey = XXXXXXXX
Address = 10.11.0.1/8 # Use /16 to close intervpn gateway
ListenPort = 42069 # Needs to be open

[Peer] # otherserver
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.13.0.0/16 # Route 10.13/16 traffic to this peer

[Peer] # mypc
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.11.1.1/32 # Internal host: talk to it directly

[Peer] # myphone
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.11.1.2/32 # Internal host: talk to it directly

And each client is given a default config like this: mypc:/etc/wireguard/mynet.conf

[Interface] # mypc
PrivateKey = XXXXXXXX
Address = 10.11.1.1/8

[Peer] # myserver
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.0.0.0/8 # Send all intervpn traffic to myserver
Endpoint = 9.8.7.6:42069 # Change to the server's public IP
PersistentKeepAlive = 25 # If mypc is behind NAT

2.3.2. Peer-to-peer routing

The setup in section 2.3.1 is not ideal due to the number of hops involved. Wireguard decrypts the data on each server hop so it's not end-to-end encrypted either.

Users may choose to improve their default configurations by setting up direct connections to other clients.

Figure 2.3.2.a. Intervpn routing with p2p connections

        +===========+        +=============+
        | myserver  +--------+ otherserver |
        | 10.11.0.1 |        |  10.13.0.1  |
        +=+=======+=+        +======+======+
          |       |                 |
+=========+=+   +=+=========+  +====+======+
|   mypc    |   |  myphone  |  | friendpc  |
| 10.11.1.1 +---+ 10.11.1.2 |  | 10.13.1.1 |
+====+======+   +===========+  +====+======+
     |                              |
     +------------------------------+

In figure 2.3.2.a, two p2p connections have been created, mypc<->myphone and mypc<->friendpc. A peer connection can be created between any two clients on any network, without requiring mediation from admins or server-side processes. The two users simply share their VPN IP addresses, external (internet) IP addresses, and a newly-generated PSK.

The configuration changes required by the clients depends on whether the clients have their external UDP wireguard listen port exposed to the internet or not. If the device is behind a home router, as most are, this can be done with port forwarding or direct IPv6 routing. It's typically not possible at all on mobile-network-connected devices.

If both clients have an open endpoint, no keep-alive packets are required.
If only one client has an open endpoint, the other client will need to maintain the connection by sending periodic keep-alive packets.
If neither client has an open endpoint, direct connections are not possible and the HAS method must be used.

The first scenario (1.) is ideal because no data are transmitted if the two clients are "at rest". Wireguard is an inherently "quiet" protocol that does not send any healthchecks or keepalives by default.

For example, assuming case (2.) where myphone is a mobile device with roaming IP addresses that never permits port forwarding and mypc does have port forwarding to wireguard port 51820 from its global IP, 1.2.3.4. A direct connection with keep-alive packets would look something like this:

mypc:/etc/wireguard/mynet.conf

[Interface] # mypc
PrivateKey = XXXXXXXX
Address = 10.11.1.1/8

[Peer] # myserver
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.0.0.0/8
Endpoint = 9.8.7.6:42069

[Peer] # myphone
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.11.1.2/32

myphone config imported to wireguard app

[Interface] # myphone
PrivateKey = XXXXXXXX
Address = 10.11.1.2/8

[Peer] # myserver
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.0.0.0/8
Endpoint = 9.8.7.6:42069
PersistentKeepAlive = 25

[Peer] # mypc
PublicKey = XXXXXXXX
PresharedKey = XXXXXXXX
AllowedIPs = 10.11.1.1/32
Endpoint = 1.2.3.4:51820
PersistentKeepAlive = 25

Connections from one client to another will default to the direct connection because the /32 address in the p2p peer's AllowedIPs is more specific than the /8 address in the server's section. Notably, the configurations don't need to change much from the default presented in section 2.3.1; each client just needs a new [Peer] section for the new connection.

3. Domain name service

A community MUST provide a domain name service for the IP addresses assigned in Section 2.2. The nameserver MUST serve names on a single predetermined TLD. The TLD could be anything that isn't already a global TLD like .com or a TLD already taken by another community. (see proposal x for a proposal to maintain a central directory of communities).

The community's nameserver MUST accept fDNS queries on subdomains for these private TLDs and provide VPN IP addresses as answers. The nameserver MUST also provide reverse DNS or "rDNS", so VPN IP addresses can be queried to determine the hostname/username/community associated with a given address.

The nameserver MUST NOT accept queries from the global internet. The nameserver MUST only accept fDNS and rDNS queries from their VPN or other tildes' VPNs. (Recommended nameserver configurations can be found in appendix A.1).

Users MAY set a search domain in their network configurations to associate a TLD with the correct VPN network interface.

3.1. User domain names

User device domain names MUST follow a hierarchical subdomain structure, A.B.C, where:

C is the community's TLD
B is the username
A is hostname of the device

For example: Your home pc could be pc.myuser.mynet and your phone phone.myuser.mynet. Either can ping up pc.myfriend.mynet. These domains would simply point to the corresponding IP addresses from the example in Section 2.2.1.

3.2. Server domain names

Designated server domain names MAY follow this convention, using a predetermined value for B such as srv. Alternatively, servers may take the form A.C as above. If this latter method is used, administrators MUST ensure that no server is assigned a hostname that matches a preexisting user name, and likewise, that users MUST NOT be created with usernames that match preexisting server hostnames.

3.3. Wildcard CNAMEs

When assigning host domain names, all first-level subdomains SHOULD be automatically linked to the domain name by a wildcard subdomain CNAME.

For example: *.mypc.myuser.mynet CNAMEs to mypc.myuser.mynet and *.myserver.mynet CNAMEs to myserver.mynet.

This can be done at the same time that the A and AAAA records are created for the domain. The wildcard subdomain CNAME assignment makes virtual hosting multiple services on a single host much easier.

4. Certificate authority

A community SHOULD provide a certificate authority service. The community SHOULD serve private services over encrypted SSL connections such as HTTPS whenever possible, even though the wireguard tunnel is already encrypted. This is because the SSL layer adds additional validation in addition to encryption.

Users SHOULD be provided with an SSL certificate and key for each of their connected devices. The certificate SHOULD include all IPs, domains, and subdomains associated with the host in the Subject Alternative Names section per Section 4.2.1.6 of [RFC1035].

For example: The certificate for mypc should have a [SAN] section like this:

X509v3 extensions:
	X509v3 Subject Alternative Name:
		DNS:mypc.myuser.mynet, DNS:*.mypc.myuser.mynet, IP Address:FD69:1337:0:420:f4:11:1:2, IP Address:10.11.1.2

That way, the same certificate can be used for https on any of these addresses:

https://10.11.1.2/
https://[fd69:1337:0:420:f4:11:1:2]/
https://mypc.myuser.mynet/
https://myservice.mypc.myuser.mynet/
https://myotherservice.mypc.myuser.mynet/
https://anyotherservice.mypc.myuser.mynet/

5. Proposal for a root authority

To prevent conflicting community IP networks and domains names, a central, democratically-goverened assigned names and numbers authority should be created. In addition, it could serve as root authorities for SSL and DNS. This guide so far has described the community's server as being both the certificate authority and root nameserver on the zone. The problem with this is that users of the intervpn will need to add a nameserver for every TLD they want to make lookups on, and they will need to import a different ca certificate for each one too.

This is at least a decentralized, working, upgradable system. A good upgrade would be for a central authority to sign each community's CA, which in turn signs the device certificates. The X.509 spec [RFC5280] is designed for this sort of hierarchical CA structure. Likewise, the DNS system could have another hierarchical layer of one or more intervpn root name servers.

To recap, needed central functions of this authority are:

Allocation of TLDs to communities
Allocation of IP subnets to communities
Root certificate authority
Root domain nameserver
Democratic self-governance with checks and balances

This is all out-of-scope of this document so a future RFC will have to provide all these details. Until then, communities can manage their own CAs and nameservers and make a best-effort to collaborate to avoid number- and namespace collisions.

5. Procedural Information

6.1. Security considerations

While home NAT gateways can be an impediment to mobile access to self-hosted services, they also provide a firewall layer between private devices and the wild wild internet. Connecting a device to a large vpn with many unknown users is a security risk that mandates mitigation with proper firewalling and routing. System operators need to take care that their system is configured correctly and should educate their users on proper packet management practices. The firewall rules and configurations in Appendix A show good examples of packet filtering rules in various programs.

6.2. Configuration considerations

This RFC does not improve a previous RFC so no revisions to previously conformant configurations are required. However, existing VPN and nameserver configs may require breaking changes to become compliant. See Appendix A for recommended configuration samples.

Appendix A. Example configurations

A.1. Bind9 nameserver

The allow-query line tells bind9 to only answer queries on the intervpn at 10/8. This setting is zone-specific and will not affect other zones, including public zones.

myserver:/etc/bind/named.conf.local

// Set acl
acl "intervpn" { 10.0.0.0/8; };
acl "ourvpn" { 10.11.0.0/16; };

// Forward DNS
zone "mynet" {
	type master;
	file "path/to/mynet.db";
	allow-query { localhost; localnets; intervpn; }; // Who can query .mynet domains
	allow-transfer { 10.11.0.2; }; // Slave servers AND dashboards that read axfr answers
	also-notify { 10.11.0.2; }; // Explicitly notify those slaves of changes
	update-policy { // Keys that can nsupdate .mynet domains
		grant myadmin zonesub ANY;
		grant mydashboard zonesub ANY;
	};
};

// IPv4 reverse DNS
zone "11.10.in-addr.arpa" {
	type master;
	file "path/to/10.11.db";
	allow-query { localhost; localnets; intervpn; };
	allow-transfer { 10.11.0.2; };
	also-notify { 10.11.0.2; };
	update-policy { // Keys that can do rDNS nsupdates
		grant myadmin zonesub ANY;
		grant mydashboard zonesub ANY;
	};
};

A.2. UFW firewall

Some examples of ufw ("uncomplicated firewall") commands to filter network packets. These examples assume a local VPN IP address of 10.11.1.1. A default deny rule is presupposed.

mypc root shell

# ufw allow from 10.11.1.0/24 to 10.11.1.1 \
	port 22 proto tcp comment "ssh from my devices"
# ufw allow from 10.11.2.0/24 to 10.11.1.1 \
	port 22 proto tcp comment "ssh from my friend's devices"
# ufw allow from 10.11.0.0/16 to 10.11.1.1 \
	port 443 proto tcp comment "share dev server with local tilde"
# ufw allow from 10.0.0.0/8 to 10.11.1.1 \
	port 25 proto tcp comment "let anyone in the intervpn send mail"

A.3. Nginx proxy to dev server

This nginx configuration allows a user and that user's friend to access the user's dev server over the VPN. This development website is made available on any of the two users' devices at https://dev.mypc.myuser.mynet and points to a web server running on port 8080 of the user's pc.

mypc:/etc/nginx/sites-enabled/dev-server.conf

server {
	server_name dev.mypc.myuser.mynet;
	listen 10.11.1.1:443 ssl http2;

	ssl_certificate     /path/to/downloaded/mypc.myuser.mynet/server.crt;
	ssl_certificate_key /path/to/downloaded/mypc.myuser.mynet/server.key;
	ssl_stapling        off;

	allow 10.11.1.0/24;  # My devices
	allow 10.11.2.0/24;  # My friend's devices
	deny  all;           # Nobody else

	# Proxy to local dev server
	location / {
		proxy_pass http://localhost:8080;
	}
}

Using this method is a handy way to test designs on a mobile device, so long as the device is on wireguard and listed in one of nginx's allow line. Note that this configuration is installed on a client PC and requires no permission from a server.

A.4. Nginx proxy from the internet to a client host

A server can act as a web gateway from the greater intervpn as well as the greater internet. In this example, myuser is hosting a website on the global internet at https://myuser.example.org/ but wants to self-host their public_html directory on their home pc. Maybe their ISP doesn't allow port-forwarding or static IPs. The web service can be proxied by having a webserver running on both the server and the pc.

myserver:/etc/nginx/sites-enabled/myuser.conf

server {
	server_name myuser.example.org;
	listen 443 ssl http2;
	ssl_certificate     /etc/letsencrypt/live/myuser.example.org/server.crt;
	ssl_certificate_key /etc/letsencrypt/live/myuser.example.org/server.key;
	location / {
		proxy_pass http://10.11.1.1;
	}
}

mypc:/etc/nginx/sites-enabled/www.conf

server {
	listen 10.11.1.1:80 http2 default_server;
	location / {
		root /var/www/public_html;
	}
}

The client has to have port 443/tcp open to 10.11.0.1 of course. And make sure mypc has a decent uptime!

A.5. Postfix relay from the internet to a client host

The typical method of delivering mail to users over a VPN is by closing all ports except 25 to the internet, so that mail retrieval through imaps/pop and sending over 587/smtp can only be done over the vpn. However, users may prefer to keep emails on their own pc where they are safe. Thus, it might be better to simply relay mail from the internet to a user's pc over the vpn.

Postfix has good documentation (Standard configuration: Email firewall/gateway) on how to configure a gateway "firewall" host that forwards traffic between the internet and a local network. This example is similar but uses our VPN as the "local network".

myserver:/etc/postfix/main.cf

mydomain = example.org
myhostname = myserver.$mydomain
myorigin = $mydomain

# Whose mail we relay to outside networks
# Don't run an "open relay"!
mynetworks = 127.0.0.0/8, 10.11.0.0/16
smtpd_relay_restrictions =
	permit_mynetworks reject_unauth_destination

# No local delivery
mydestination = 
local_recipient_maps = 
local_transport = error:No local delivery

# Receive mail to these domains and subdomains thereoff
relay_domains = mynet $mydomain
# Receive mail to these addresses (see below)
relay_recipient_maps = hash:/etc/postfix/relay_recipients
# Where to forward emails (see below)
transport_maps = hash:/etc/postfix/transport
# Mail aliases (i.e. postmaster)
virtual_alias_maps = hash:/etc/postfix/virtual

The list of mail addresses address to relay (drop the rest)

myserver:/etc/postfix/relay_recipients

@example.org         x
@myuser.example.org  x
@mynet               x
@myuser.mynet        x

Where to send myuser's mail

myserver:/etc/postfix/transport

myuser@example.org  relay:[mypc.myuser.mynet]
myuser.example.org  relay:[mypc.myuser.mynet]
myuser@mynet        relay:[mypc.myuser.mynet]
myuser.mynet        relay:[mypc.myuser.mynet]

And on the client designated to receive the mail:

mypc:/etc/postfix/main.cf

mydomain = myuser.mynet
myhostname = mypc.$mydomain
myorigin = $myhostname
inet_interfaces = $myhostname, localhost
mydestination = mypc, localhost, mypc.myuser.mynet,
	myuser.mynet, example.org, myuser.example.org
mynetworks = 127.0.0.0/8, 10.0.0.0/8
relayhost = [myserver.mynet] # Where to send outgoing mail
alias_maps = hash:/etc/aliases # Probably alias everything to myuser
alias_database = $alias_maps
home_mailbox = mail # Where in your homedir to put mail
luser_relay = myuser # Mail with unknown destination is sent here

27 KiB Raw Permalink Blame History