gvpe/doc/vpe.protocol.7.pod

=head1 The VPE Protocol

=head2 Anatomy of a VPN packet

The exact layout and field lengths of a VPN packet is determined at
compiletime and doesn't change. The same structure is used for all
protocols, be it rawip or tcp.

 +------+------+--------+------+
 | HMAC | TYPE | SRCDST | DATA |
 +------+------+--------+------+

The HMAC field is present in all packets, even if not used (e.g. in auth
request packets), in which case it is set to all zeroes. The checksum
itself is over the TYPE, SRCDST and DATA fields in all cases.

The TYPE field is a single byte and determines the purpose of the packet
(e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE,
CONNECT REQUEST/INFO etc.).

SRCDST is a three byte field which contains the source and destination
node ids (12 bits each). The protocol does not yet scale well beyond 30+
hosts, since all hosts connect to each other on startup. But if restarts
are rare or tolerable and most connections are on demand, larger networks
are possible.

The DATA portion differs between each packet type, naturally, and is the
only part that can be encrypted. Data packets contain more fields, as
shown:

 +------+------+--------+------+-------+------+
 | HMAC | TYPE | SRCDST | RAND | SEQNO | DATA |
 +------+------+--------+------+-------+------+

RAND is a sequence of fully random bytes, used to increase the entropy of
the data for encryption purposes.

SEQNO is a 32-bit sequence number. It is negotiated at every connection
initialization and starts at some random 31 bit value. VPE currently uses
a sliding window of 512 packets to detect reordering, duplication and
reply attacks.

=head2 The authentification protocol

Before hosts can exchange packets, they need to establish authenticity of
the other side and a key. Every host has a private RSA key and the public
RSA keys of all other hosts.

A host establishes a simplex connection by sending the other host a
RSA encrypted challenge containing a random challenge (consisting of
the encryption key to use when sending packets, more random data and
PKCS1_OAEP padding) and a random 16 byte "challenge-id" (used to detect
duplicate auth packets). The destination host will respond by replying
with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which
will authentify that host. The destination host will also set the outgoing
encryption parameters as given in the packet.

When the source host receives a correct auth reply (by verifying the
hash and the id, which will expire after 120 seconds), it will start to
accept data packets from the destination host.

This means that a host can only initate a simplex connection, telling the
other side the key it has to use when it sends packets. The challenge
reply is only used to set the current IP address and protocol parameters.

The protocol here is completely symmetric, so to be able to send packets
the destination host must send a challenge in the exact same way as
already described (so, in essence, two simplex connections are created per
host pair).

=head2 Retrying

When there is no response to an auth request, the host will send auth
requests in bursts with an exponential backoff. After some time it will
resort to PING packets, which are very small (8 byte) and lightweight (no
RSA operations). A host that receives ping requests from an unconnected
peer will respond by trying to create a connection.

In addition to the exponential backoff, there is a global rate-limit on
a per-ip base. It allows long bursts but will limit total packet rate to
something like one control packet every ten seconds, to avoid accidental
floods due to protocol problems (like a rsa key file mismatch between two
hosts).

=head2 Routing and Protocol translation

The vpe routing algorithm is easy: there isn't any routing. Vped always
tries to establish direct connections, if the protocol abilities of the
two hosts allow it.

If the two hosts should be able to reach each other (common protocol, ip
and port all known), but cannot (network down), then there will be no
connection, point.

A host can usually declare itself unreachable directly by setting it's
port number(s) to zero. It can declare other hosts as unreachable by using
a config-file that disables all protocols for these other hosts.

If two hosts cannot connect to each other because their IP address(es)
are not known (such as dialup hosts), one side will send a connection
request to a router (routers must be configured to act as routers!), which
will send both the originating and the destination host a connection info
request with protocol information and IP address of the other host (if
known). Both hosts will then try to establish a connection to the other
peer, which is usually possible even when both hosts are behind a NAT
gateway.

If the hosts cannot reach each other because they have no common protocol,
the originator instead use the router with highest priority and matching
protocol as peer. Since the SRCDST field is not encrypted, the router host
can just forward the packet to the destination host. Since each host uses
it's own private key, the router will not be able to decrypt or encrypt
packets, it will just act as a simple router and protocol translator.

When no router is connected, the host will aggressively try to connect to
all routers, and if a router is asked for an unconnected host it will try
to ask another router to establish the connection.

... more not yet written about the details of the routing, please bug me
...

Revision:	1.3
Committed:	Mon Oct 6 12:47:58 2003 UTC (21 years, 3 months ago) by pcg
Branch:	MAIN
CVS Tags:	poll-based-iom, VPE-1_6_1, VPE_1_4, VPE_1_6, VPE_1_2
Changes since 1.2:	+27 -17 lines
Log Message:	* empty log message *
#	Content
1	=head1 The VPE Protocol
2
3	=head2 Anatomy of a VPN packet
4
5	The exact layout and field lengths of a VPN packet is determined at
6	compiletime and doesn't change. The same structure is used for all
7	protocols, be it rawip or tcp.
8
9	+------+------+--------+------+
10	\| HMAC \| TYPE \| SRCDST \| DATA \|
11	+------+------+--------+------+
12
13	The HMAC field is present in all packets, even if not used (e.g. in auth
14	request packets), in which case it is set to all zeroes. The checksum
15	itself is over the TYPE, SRCDST and DATA fields in all cases.
16
17	The TYPE field is a single byte and determines the purpose of the packet
18	(e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE,
19	CONNECT REQUEST/INFO etc.).
20
21	SRCDST is a three byte field which contains the source and destination
22	node ids (12 bits each). The protocol does not yet scale well beyond 30+
23	hosts, since all hosts connect to each other on startup. But if restarts
24	are rare or tolerable and most connections are on demand, larger networks
25	are possible.
26
27	The DATA portion differs between each packet type, naturally, and is the
28	only part that can be encrypted. Data packets contain more fields, as
29	shown:
30
31	+------+------+--------+------+-------+------+
32	\| HMAC \| TYPE \| SRCDST \| RAND \| SEQNO \| DATA \|
33	+------+------+--------+------+-------+------+
34
35	RAND is a sequence of fully random bytes, used to increase the entropy of
36	the data for encryption purposes.
37
38	SEQNO is a 32-bit sequence number. It is negotiated at every connection
39	initialization and starts at some random 31 bit value. VPE currently uses
40	a sliding window of 512 packets to detect reordering, duplication and
41	reply attacks.
42
43	=head2 The authentification protocol
44
45	Before hosts can exchange packets, they need to establish authenticity of
46	the other side and a key. Every host has a private RSA key and the public
47	RSA keys of all other hosts.
48
49	A host establishes a simplex connection by sending the other host a
50	RSA encrypted challenge containing a random challenge (consisting of
51	the encryption key to use when sending packets, more random data and
52	PKCS1_OAEP padding) and a random 16 byte "challenge-id" (used to detect
53	duplicate auth packets). The destination host will respond by replying
54	with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which
55	will authentify that host. The destination host will also set the outgoing
56	encryption parameters as given in the packet.
57
58	When the source host receives a correct auth reply (by verifying the
59	hash and the id, which will expire after 120 seconds), it will start to
60	accept data packets from the destination host.
61
62	This means that a host can only initate a simplex connection, telling the
63	other side the key it has to use when it sends packets. The challenge
64	reply is only used to set the current IP address and protocol parameters.
65
66	The protocol here is completely symmetric, so to be able to send packets
67	the destination host must send a challenge in the exact same way as
68	already described (so, in essence, two simplex connections are created per
69	host pair).
70
71	=head2 Retrying
72
73	When there is no response to an auth request, the host will send auth
74	requests in bursts with an exponential backoff. After some time it will
75	resort to PING packets, which are very small (8 byte) and lightweight (no
76	RSA operations). A host that receives ping requests from an unconnected
77	peer will respond by trying to create a connection.
78
79	In addition to the exponential backoff, there is a global rate-limit on
80	a per-ip base. It allows long bursts but will limit total packet rate to
81	something like one control packet every ten seconds, to avoid accidental
82	floods due to protocol problems (like a rsa key file mismatch between two
83	hosts).
84
85	=head2 Routing and Protocol translation
86
87	The vpe routing algorithm is easy: there isn't any routing. Vped always
88	tries to establish direct connections, if the protocol abilities of the
89	two hosts allow it.
90
91	If the two hosts should be able to reach each other (common protocol, ip
92	and port all known), but cannot (network down), then there will be no
93	connection, point.
94
95	A host can usually declare itself unreachable directly by setting it's
96	port number(s) to zero. It can declare other hosts as unreachable by using
97	a config-file that disables all protocols for these other hosts.
98
99	If two hosts cannot connect to each other because their IP address(es)
100	are not known (such as dialup hosts), one side will send a connection
101	request to a router (routers must be configured to act as routers!), which
102	will send both the originating and the destination host a connection info
103	request with protocol information and IP address of the other host (if
104	known). Both hosts will then try to establish a connection to the other
105	peer, which is usually possible even when both hosts are behind a NAT
106	gateway.
107
108	If the hosts cannot reach each other because they have no common protocol,
109	the originator instead use the router with highest priority and matching
110	protocol as peer. Since the SRCDST field is not encrypted, the router host
111	can just forward the packet to the destination host. Since each host uses
112	it's own private key, the router will not be able to decrypt or encrypt
113	packets, it will just act as a simple router and protocol translator.
114
115	When no router is connected, the host will aggressively try to connect to
116	all routers, and if a router is asked for an unconnected host it will try
117	to ask another router to establish the connection.
118
119	... more not yet written about the details of the routing, please bug me
120	...
121