--- gvpe/doc/gvpe.protocol.7	2008/09/01 06:06:11	1.10
+++ gvpe/doc/gvpe.protocol.7	2013/07/13 04:10:29	1.12
@@ -1,15 +1,7 @@
-.\" Automatically generated by Pod::Man 2.16 (Pod::Simple 3.05)
+.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.20)
 .\"
 .\" Standard preamble:
 .\" ========================================================================
-.de Sh \" Subsection heading
-.br
-.if t .Sp
-.ne 5
-.PP
-\fB\\$1\fR
-.PP
-..
 .de Sp \" Vertical space (when we can't use .PP)
 .if t .sp .5v
 .if n .sp
@@ -53,7 +45,7 @@
 .el       .ds Aq '
 .\"
 .\" If the F register is turned on, we'll generate index entries on stderr for
-.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
 .\" entries marked with X<> in POD.  Of course, you'll have to process the
 .\" output yourself in some meaningful fashion.
 .ie \nF \{\
@@ -132,7 +124,7 @@
 .\" ========================================================================
 .\"
 .IX Title "GVPE.PROTOCOL 7"
-.TH GVPE.PROTOCOL 7 "2008-09-01" "2.2" "GNU Virtual Private Ethernet"
+.TH GVPE.PROTOCOL 7 "2013-07-12" "2.24" "GNU Virtual Private Ethernet"
 .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
 .\" way too many mistakes in technical documents.
 .if n .ad l
@@ -157,7 +149,7 @@
 The following sections describe each transport protocol in more
 detail. They are sorted by overhead/efficiency, the most efficient
 transport is listed first:
-.Sh "\s-1RAW\s0 \s-1IP\s0"
+.SS "\s-1RAW\s0 \s-1IP\s0"
 .IX Subsection "RAW IP"
 This protocol is the best choice, performance-wise, as the minimum
 overhead per packet is only 38 bytes.
@@ -168,7 +160,7 @@
 Using raw \s-1IP\s0 frames has the drawback that many firewalls block \*(L"unknown\*(R"
 protocols, so this transport only works if you have full \s-1IP\s0 connectivity
 between nodes.
-.Sh "\s-1ICMP\s0"
+.SS "\s-1ICMP\s0"
 .IX Subsection "ICMP"
 This protocol offers very low overhead (minimum 42 bytes), and can
 sometimes tunnel through firewalls when other protocols can not.
@@ -180,14 +172,14 @@
 .PP
 This transport should only be used if other transports (i.e. raw \s-1IP\s0) are
 not available or undesirable (due to their overhead).
-.Sh "\s-1UDP\s0"
+.SS "\s-1UDP\s0"
 .IX Subsection "UDP"
 This is a good general choice for the transport protocol as \s-1UDP\s0 packets
 tunnel well through most firewalls and routers, and the overhead per
 packet is moderate (minimum 58 bytes).
 .PP
 It should be used if \s-1RAW\s0 \s-1IP\s0 is not available.
-.Sh "\s-1TCP\s0"
+.SS "\s-1TCP\s0"
 .IX Subsection "TCP"
 This protocol is a very bad choice, as it not only has high overhead (more
 than 60 bytes), but the transport also retries on it's own, which leads
@@ -208,7 +200,7 @@
 set to zero, other nodes cannot connect to this node directly. If the
 \&\f(CW\*(C`tcp\-port\*(C'\fR is non-zero, the node can act both as a client as well as a
 server.
-.Sh "\s-1DNS\s0"
+.SS "\s-1DNS\s0"
 .IX Subsection "DNS"
 \&\fB\s-1WARNING:\s0\fR Parsing and generating \s-1DNS\s0 packets is rather tricky. The code
 almost certainly contains buffer overflows and other, likely exploitable,
@@ -224,7 +216,7 @@
 In addition, the same problems as the \s-1TCP\s0 transport also plague this
 protocol.
 .PP
-It's only use is to tunnel through firewalls that do not allow direct
+Its only use is to tunnel through firewalls that do not allow direct
 internet access. Similar to using a \s-1HTTP\s0 proxy (as the \s-1TCP\s0 transport
 does), it uses a local \s-1DNS\s0 server/forwarder (given by the \f(CW\*(C`dns\-forw\-host\*(C'\fR
 configuration value) as a proxy to send and receive data as a client,
@@ -242,7 +234,7 @@
 is stable (until bugs in the cryptography are found, which will likely
 completely change the following description). Nevertheless, it should give
 you some overview over the protocol.
-.Sh "Anatomy of a \s-1VPN\s0 packet"
+.SS "Anatomy of a \s-1VPN\s0 packet"
 .IX Subsection "Anatomy of a VPN packet"
 The exact layout and field lengths of a \s-1VPN\s0 packet is determined at
 compile time and doesn't change. The same structure is used for all
@@ -282,18 +274,22 @@
 initialization and starts at some random 31 bit value. \s-1VPE\s0 currently uses
 a sliding window of 512 packets/sequence numbers to detect reordering,
 duplication and replay attacks.
-.Sh "The authentication protocol"
+.PP
+The encryption is done on \s-1RAND+SEQNO+DATA\s0 in \s-1CBC\s0 mode with zero \s-1IV\s0 (or,
+equivalently, the \s-1IV\s0 is \s-1RAND+SEQNO\s0, encrypted with the block cipher,
+unless \s-1RAND\s0 size is decreased or increased over the default value).
+.SS "The authentication protocol"
 .IX Subsection "The authentication protocol"
 Before nodes can exchange packets, they need to establish authenticity of
 the other side and a key. Every node has a private \s-1RSA\s0 key and the public
 \&\s-1RSA\s0 keys of all other nodes.
 .PP
-A host establishes a simplex connection by sending the other node an
-\&\s-1RSA\s0 encrypted challenge containing a random challenge (consisting of
-the encryption key to use when sending packets, more random data and
-\&\s-1PKCS1_OAEP\s0 padding) and a random 16 byte \*(L"challenge-id\*(R" (used to detect
-duplicate auth packets). The destination node will respond by replying
-with an (unencrypted) \s-1RIPEMD160\s0 hash of the decrypted challenge, which
+A host establishes a simplex connection by sending the other node an \s-1RSA\s0
+encrypted challenge containing a random challenge (consisting of the
+encryption and authentication keys to use when sending packets, more
+random data and \s-1PKCS1_OAEP\s0 padding) and a random 16 byte \*(L"challenge-id\*(R"
+(used to detect duplicate auth packets). The destination node will respond
+by replying with an (unencrypted) hash of the decrypted challenge, which
 will authenticate that node. The destination node will also set the
 outgoing encryption parameters as given in the packet.
 .PP
@@ -310,7 +306,7 @@
 destination node must send a challenge in the exact same way as already
 described (so, in essence, two simplex connections are created per node
 pair).
-.Sh "Retrying"
+.SS "Retrying"
 .IX Subsection "Retrying"
 When there is no response to an auth request, the node will send auth
 requests in bursts with an exponential back-off. After some time it will
@@ -334,10 +330,10 @@
 Sending packets over the \s-1VPN\s0 will reset the retry intervals as well, which
 means as long as somebody is trying to send packets to a given node, \s-1GVPE\s0
 will try to connect every few seconds.
-.Sh "Routing and Protocol translation"
+.SS "Routing and Protocol translation"
 .IX Subsection "Routing and Protocol translation"
 The \s-1GVPE\s0 routing algorithm is easy: there isn't much routing to speak
-of: When routing packets to another node, \s-1GVPE\s0 trues the following
+of: When routing packets to another node, \s-1GVPE\s0 tries the following
 options, in order:
 .IP "If the two nodes should be able to reach each other directly (common protocol, port known), then \s-1GVPE\s0 will send the packet directly to the other node." 4
 .IX Item "If the two nodes should be able to reach each other directly (common protocol, port known), then GVPE will send the packet directly to the other node."
@@ -345,7 +341,7 @@
 .ie n .IP "If this isn't possible (e.g. because the node doesn't have a \*(C`hostname\*(C' or known port), but the nodes speak a common protocol and a router is available, then \s-1GVPE\s0 will ask a router to ""mediate"" between both nodes (see below)." 4
 .el .IP "If this isn't possible (e.g. because the node doesn't have a \f(CW\*(C`hostname\*(C'\fR or known port), but the nodes speak a common protocol and a router is available, then \s-1GVPE\s0 will ask a router to ``mediate'' between both nodes (see below)." 4
 .IX Item "If this isn't possible (e.g. because the node doesn't have a hostname or known port), but the nodes speak a common protocol and a router is available, then GVPE will ask a router to mediate between both nodes (see below)."
-.ie n .IP "If a direct connection isn't possible (no common protocols) or forbidden (\*(C`deny\-direct\*(C'\fR) and there are any routers, then \s-1GVPE\s0 will try to send packets to the router with the highest priority that is connected already \fIand is able (as specified by the config file) to connect directly to the target node." 4
+.ie n .IP "If a direct connection isn't possible (no common protocols) or forbidden (\*(C`deny\-direct\*(C') and there are any routers, then \s-1GVPE\s0 will try to send packets to the router with the highest priority that is connected already \fIand\fR is able (as specified by the config file) to connect directly to the target node." 4
 .el .IP "If a direct connection isn't possible (no common protocols) or forbidden (\f(CW\*(C`deny\-direct\*(C'\fR) and there are any routers, then \s-1GVPE\s0 will try to send packets to the router with the highest priority that is connected already \fIand\fR is able (as specified by the config file) to connect directly to the target node." 4
 .IX Item "If a direct connection isn't possible (no common protocols) or forbidden (deny-direct) and there are any routers, then GVPE will try to send packets to the router with the highest priority that is connected already and is able (as specified by the config file) to connect directly to the target node."
 .IP "If no such router exists, then \s-1GVPE\s0 will simply send the packet to the node with the highest priority available." 4