| 1 |
.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14 |
| 2 |
.\" |
| 3 |
.\" Standard preamble: |
| 4 |
.\" ======================================================================== |
| 5 |
.de Sh \" Subsection heading |
| 6 |
.br |
| 7 |
.if t .Sp |
| 8 |
.ne 5 |
| 9 |
.PP |
| 10 |
\fB\\$1\fR |
| 11 |
.PP |
| 12 |
.. |
| 13 |
.de Sp \" Vertical space (when we can't use .PP) |
| 14 |
.if t .sp .5v |
| 15 |
.if n .sp |
| 16 |
.. |
| 17 |
.de Vb \" Begin verbatim text |
| 18 |
.ft CW |
| 19 |
.nf |
| 20 |
.ne \\$1 |
| 21 |
.. |
| 22 |
.de Ve \" End verbatim text |
| 23 |
.ft R |
| 24 |
.fi |
| 25 |
.. |
| 26 |
.\" Set up some character translations and predefined strings. \*(-- will |
| 27 |
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left |
| 28 |
.\" double quote, and \*(R" will give a right double quote. | will give a |
| 29 |
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to |
| 30 |
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' |
| 31 |
.\" expand to `' in nroff, nothing in troff, for use with C<>. |
| 32 |
.tr \(*W-|\(bv\*(Tr |
| 33 |
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' |
| 34 |
.ie n \{\ |
| 35 |
. ds -- \(*W- |
| 36 |
. ds PI pi |
| 37 |
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch |
| 38 |
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch |
| 39 |
. ds L" "" |
| 40 |
. ds R" "" |
| 41 |
. ds C` |
| 42 |
. ds C' |
| 43 |
'br\} |
| 44 |
.el\{\ |
| 45 |
. ds -- \|\(em\| |
| 46 |
. ds PI \(*p |
| 47 |
. ds L" `` |
| 48 |
. ds R" '' |
| 49 |
'br\} |
| 50 |
.\" |
| 51 |
.\" If the F register is turned on, we'll generate index entries on stderr for |
| 52 |
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index |
| 53 |
.\" entries marked with X<> in POD. Of course, you'll have to process the |
| 54 |
.\" output yourself in some meaningful fashion. |
| 55 |
.if \nF \{\ |
| 56 |
. de IX |
| 57 |
. tm Index:\\$1\t\\n%\t"\\$2" |
| 58 |
.. |
| 59 |
. nr % 0 |
| 60 |
. rr F |
| 61 |
.\} |
| 62 |
.\" |
| 63 |
.\" For nroff, turn off justification. Always turn off hyphenation; it makes |
| 64 |
.\" way too many mistakes in technical documents. |
| 65 |
.hy 0 |
| 66 |
.if n .na |
| 67 |
.\" |
| 68 |
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). |
| 69 |
.\" Fear. Run. Save yourself. No user-serviceable parts. |
| 70 |
. \" fudge factors for nroff and troff |
| 71 |
.if n \{\ |
| 72 |
. ds #H 0 |
| 73 |
. ds #V .8m |
| 74 |
. ds #F .3m |
| 75 |
. ds #[ \f1 |
| 76 |
. ds #] \fP |
| 77 |
.\} |
| 78 |
.if t \{\ |
| 79 |
. ds #H ((1u-(\\\\n(.fu%2u))*.13m) |
| 80 |
. ds #V .6m |
| 81 |
. ds #F 0 |
| 82 |
. ds #[ \& |
| 83 |
. ds #] \& |
| 84 |
.\} |
| 85 |
. \" simple accents for nroff and troff |
| 86 |
.if n \{\ |
| 87 |
. ds ' \& |
| 88 |
. ds ` \& |
| 89 |
. ds ^ \& |
| 90 |
. ds , \& |
| 91 |
. ds ~ ~ |
| 92 |
. ds / |
| 93 |
.\} |
| 94 |
.if t \{\ |
| 95 |
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" |
| 96 |
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' |
| 97 |
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' |
| 98 |
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' |
| 99 |
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' |
| 100 |
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' |
| 101 |
.\} |
| 102 |
. \" troff and (daisy-wheel) nroff accents |
| 103 |
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' |
| 104 |
.ds 8 \h'\*(#H'\(*b\h'-\*(#H' |
| 105 |
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] |
| 106 |
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' |
| 107 |
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' |
| 108 |
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] |
| 109 |
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] |
| 110 |
.ds ae a\h'-(\w'a'u*4/10)'e |
| 111 |
.ds Ae A\h'-(\w'A'u*4/10)'E |
| 112 |
. \" corrections for vroff |
| 113 |
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' |
| 114 |
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' |
| 115 |
. \" for low resolution devices (crt and lpr) |
| 116 |
.if \n(.H>23 .if \n(.V>19 \ |
| 117 |
\{\ |
| 118 |
. ds : e |
| 119 |
. ds 8 ss |
| 120 |
. ds o a |
| 121 |
. ds d- d\h'-1'\(ga |
| 122 |
. ds D- D\h'-1'\(hy |
| 123 |
. ds th \o'bp' |
| 124 |
. ds Th \o'LP' |
| 125 |
. ds ae ae |
| 126 |
. ds Ae AE |
| 127 |
.\} |
| 128 |
.rm #[ #] #H #V #F C |
| 129 |
.\" ======================================================================== |
| 130 |
.\" |
| 131 |
.IX Title "GVPE.PROTOCOL 7" |
| 132 |
.TH GVPE.PROTOCOL 7 "2005-03-15" "1.8" "GNU Virtual Private Ethernet" |
| 133 |
.SH "The GNU-VPE Protocols" |
| 134 |
.IX Header "The GNU-VPE Protocols" |
| 135 |
.SH "Overview" |
| 136 |
.IX Header "Overview" |
| 137 |
\&\s-1GVPE\s0 can make use of a number of protocols. One of them is the \s-1GNU\s0 \s-1VPE\s0 |
| 138 |
protocol which is used to authenticate tunnels and send encrypted data |
| 139 |
packets. This protocol is described in more detail the second part of this |
| 140 |
document. |
| 141 |
.PP |
| 142 |
The first part of this document describes the transport protocols which |
| 143 |
are used by \s-1GVPE\s0 to send it's data packets over the network. |
| 144 |
.SH "PART 1: Tansport protocols" |
| 145 |
.IX Header "PART 1: Tansport protocols" |
| 146 |
.Sh "\s-1RAW\s0 \s-1IP\s0" |
| 147 |
.IX Subsection "RAW IP" |
| 148 |
.Sh "\s-1ICMP\s0" |
| 149 |
.IX Subsection "ICMP" |
| 150 |
.Sh "\s-1UDP\s0" |
| 151 |
.IX Subsection "UDP" |
| 152 |
.Sh "\s-1TCP\s0" |
| 153 |
.IX Subsection "TCP" |
| 154 |
.Sh "\s-1DNS\s0" |
| 155 |
.IX Subsection "DNS" |
| 156 |
.SH "PART 2: The GNU VPE protocol" |
| 157 |
.IX Header "PART 2: The GNU VPE protocol" |
| 158 |
This section, unfortunately, is not yet finished, although the protocol |
| 159 |
is stable (until bugs in the cryptography are found, which will likely |
| 160 |
completely change the following description). Nevertheless, it should give |
| 161 |
you some overview over the protocol. |
| 162 |
.Sh "Anatomy of a \s-1VPN\s0 packet" |
| 163 |
.IX Subsection "Anatomy of a VPN packet" |
| 164 |
The exact layout and field lengths of a \s-1VPN\s0 packet is determined at |
| 165 |
compiletime and doesn't change. The same structure is used for all |
| 166 |
transort protocols, be it \s-1RAWIP\s0 or \s-1TCP\s0. |
| 167 |
.PP |
| 168 |
.Vb 3 |
| 169 |
\& +------+------+--------+------+ |
| 170 |
\& | HMAC | TYPE | SRCDST | DATA | |
| 171 |
\& +------+------+--------+------+ |
| 172 |
.Ve |
| 173 |
.PP |
| 174 |
The \s-1HMAC\s0 field is present in all packets, even if not used (e.g. in auth |
| 175 |
request packets), in which case it is set to all zeroes. The checksum |
| 176 |
itself is calculated over the \s-1TYPE\s0, \s-1SRCDST\s0 and \s-1DATA\s0 fields in all cases. |
| 177 |
.PP |
| 178 |
The \s-1TYPE\s0 field is a single byte and determines the purpose of the packet |
| 179 |
(e.g. \s-1RESET\s0, \s-1COMPRESSED/UNCOMPRESSED\s0 \s-1DATA\s0, \s-1PING\s0, \s-1AUTH\s0 \s-1REQUEST/RESPONSE\s0, |
| 180 |
\&\s-1CONNECT\s0 \s-1REQUEST/INFO\s0 etc.). |
| 181 |
.PP |
| 182 |
\&\s-1SRCDST\s0 is a three byte field which contains the source and destination |
| 183 |
node ids (12 bits each). The protocol does not yet scale well beyond 30+ |
| 184 |
hosts, since all hosts must connect to each other once on startup. But if |
| 185 |
restarts are rare or tolerable and most connections are on demand, much |
| 186 |
larger networks are feasible. |
| 187 |
.PP |
| 188 |
The \s-1DATA\s0 portion differs between each packet type, naturally, and is the |
| 189 |
only part that can be encrypted. Data packets contain more fields, as |
| 190 |
shown: |
| 191 |
.PP |
| 192 |
.Vb 3 |
| 193 |
\& +------+------+--------+------+-------+------+ |
| 194 |
\& | HMAC | TYPE | SRCDST | RAND | SEQNO | DATA | |
| 195 |
\& +------+------+--------+------+-------+------+ |
| 196 |
.Ve |
| 197 |
.PP |
| 198 |
\&\s-1RAND\s0 is a sequence of fully random bytes, used to increase the entropy of |
| 199 |
the data for encryption purposes. |
| 200 |
.PP |
| 201 |
\&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection |
| 202 |
initialization and starts at some random 31 bit value. \s-1VPE\s0 currently uses |
| 203 |
a sliding window of 512 packets/sequence numbers to detect reordering, |
| 204 |
duplication and reply attacks. |
| 205 |
.Sh "The authentification protocol" |
| 206 |
.IX Subsection "The authentification protocol" |
| 207 |
Before hosts can exchange packets, they need to establish authenticity of |
| 208 |
the other side and a key. Every host has a private \s-1RSA\s0 key and the public |
| 209 |
\&\s-1RSA\s0 keys of all other hosts. |
| 210 |
.PP |
| 211 |
A host establishes a simplex connection by sending the other host a |
| 212 |
\&\s-1RSA\s0 encrypted challenge containing a random challenge (consisting of |
| 213 |
the encryption key to use when sending packets, more random data and |
| 214 |
\&\s-1PKCS1_OAEP\s0 padding) and a random 16 byte \*(L"challenge\-id\*(R" (used to detect |
| 215 |
duplicate auth packets). The destination host will respond by replying |
| 216 |
with an (unencrypted) \s-1RIPEMD160\s0 hash of the decrypted challenge, which |
| 217 |
will authentify that host. The destination host will also set the outgoing |
| 218 |
encryption parameters as given in the packet. |
| 219 |
.PP |
| 220 |
When the source host receives a correct auth reply (by verifying the |
| 221 |
hash and the id, which will expire after 120 seconds), it will start to |
| 222 |
accept data packets from the destination host. |
| 223 |
.PP |
| 224 |
This means that a host can only initate a simplex connection, telling the |
| 225 |
other side the key it has to use when it sends packets. The challenge |
| 226 |
reply is only used to set the current \s-1IP\s0 address of the other side and |
| 227 |
protocol parameters. |
| 228 |
.PP |
| 229 |
This protocol is completely symmetric, so to be able to send packets the |
| 230 |
destination host must send a challenge in the exact same way as already |
| 231 |
described (so, in essence, two simplex connections are created per host |
| 232 |
pair). |
| 233 |
.Sh "Retrying" |
| 234 |
.IX Subsection "Retrying" |
| 235 |
When there is no response to an auth request, the host will send auth |
| 236 |
requests in bursts with an exponential backoff. After some time it will |
| 237 |
resort to \s-1PING\s0 packets, which are very small (8 bytes) and lightweight |
| 238 |
(no \s-1RSA\s0 operations required). A host that receives ping requests from an |
| 239 |
unconnected peer will respond by trying to create a connection. |
| 240 |
.PP |
| 241 |
In addition to the exponential backoff, there is a global rate-limit on |
| 242 |
a per-IP base. It allows long bursts but will limit total packet rate to |
| 243 |
something like one control packet every ten seconds, to avoid accidental |
| 244 |
floods due to protocol problems (like a \s-1RSA\s0 key file mismatch between two |
| 245 |
hosts). |
| 246 |
.Sh "Routing and Protocol translation" |
| 247 |
.IX Subsection "Routing and Protocol translation" |
| 248 |
The gvpe routing algorithm is easy: there isn't any routing. \s-1GVPE\s0 always |
| 249 |
tries to establish direct connections, if the protocol abilities of the |
| 250 |
two hosts allow it. |
| 251 |
.PP |
| 252 |
If the two hosts should be able to reach each other (common protocol, ip |
| 253 |
and port all known), but cannot (network down), then there will be no |
| 254 |
connection, point. |
| 255 |
.PP |
| 256 |
A host can usually declare itself unreachable directly by setting it's |
| 257 |
port number(s) to zero. It can declare other hosts as unreachable by using |
| 258 |
a config-file that disables all protocols for these other hosts. |
| 259 |
.PP |
| 260 |
If two hosts cannot connect to each other because their \s-1IP\s0 address(es) |
| 261 |
are not known (such as dialup hosts), one side will send a connection |
| 262 |
request to a router (routers must be configured to act as routers!), which |
| 263 |
will send both the originating and the destination host a connection info |
| 264 |
request with protocol information and \s-1IP\s0 address of the other host (if |
| 265 |
known). Both hosts will then try to establish a connection to the other |
| 266 |
peer, which is usually possible even when both hosts are behind a \s-1NAT\s0 |
| 267 |
gateway. |
| 268 |
.PP |
| 269 |
If the hosts cannot reach each other because they have no common protocol, |
| 270 |
the originator instead use the router with highest priority and matching |
| 271 |
protocol as peer. Since the \s-1SRCDST\s0 field is not encrypted, the router host |
| 272 |
can just forward the packet to the destination host. Since each host uses |
| 273 |
it's own private key, the router will not be able to decrypt or encrypt |
| 274 |
packets, it will just act as a simple router and protocol translator. |
| 275 |
.PP |
| 276 |
When no router is connected, the host will aggressively try to connect to |
| 277 |
all routers, and if a router is asked for an unconnected host it will try |
| 278 |
to ask another router to establish the connection. |
| 279 |
.PP |
| 280 |
\&... more not yet written about the details of the routing, please bug me |
| 281 |
\&... |
