Add notion of `ephemeral' associations and a goodbye protocol.
[tripe] / peerdb / peers.in.5.in
... / ...
CommitLineData
1.\" -*-nroff-*-
2.\".
3.\" Manual for the peer configuration file
4.\"
5.\" (c) 2008 Straylight/Edgeware
6.\"
7.
8.\"----- Licensing notice ---------------------------------------------------
9.\"
10.\" This file is part of Trivial IP Encryption (TrIPE).
11.\"
12.\" TrIPE is free software: you can redistribute it and/or modify it under
13.\" the terms of the GNU General Public License as published by the Free
14.\" Software Foundation; either version 3 of the License, or (at your
15.\" option) any later version.
16.\"
17.\" TrIPE is distributed in the hope that it will be useful, but WITHOUT
18.\" ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
19.\" FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
20.\" for more details.
21.\"
22.\" You should have received a copy of the GNU General Public License
23.\" along with TrIPE. If not, see <https://www.gnu.org/licenses/>.
24.
25.\"--------------------------------------------------------------------------
26.so ../common/defs.man \"@@@PRE@@@
27.
28.\"--------------------------------------------------------------------------
29.TH peers.in 5tripe "27 March 2008" "Straylight/Edgeware" "TrIPE: Trivial IP Encryption"
30.
31.\"--------------------------------------------------------------------------
32.SH "NAME"
33.
34peers.in \- source form for TrIPE peer database
35.
36.\"--------------------------------------------------------------------------
37.SH "DESCRIPTION"
38.
39The
40.B peers.in
41file is a plain text configuration file. It is read by
42.BR tripe-newpeers (8)
43in order to produce the
44.BR tripe.cdb (8)
45database used by services and other tools.
46.
47.SS "General structure"
48The configuration file is line-oriented. Blank lines are ignored; lines
49beginning with a hash
50.RB ` # '
51or semicolon
52.RB ` ; '
53are ignored. The file is divided into sections by section headers,
54which are lines of the form
55.IP
56.BI [ name ]
57.PP
58Within each section are a number of assignments, of the form
59.IP
60.IB key " = " value
61.PP
62or (entirely equivalent)
63.IP
64.IB key ": " value
65.PP
66The
67.I key
68must start in the left hand column. The
69.I value
70may span multiple lines if subsequent lines begin with whitespace, in
71the manner of RFC822 headers.
72.PP
73There is a special case to be aware of: if a section doesn't specify a
74value for the key
75.B name
76then the section's own name is used as a default.
77.PP
78The following substitutions are made in the body of a value.
79.hP \*o
80An occurrence of
81.BI $( key )
82is replaced by the value assigned to the given
83.IR key .
84.hP \*o
85An occurrence of
86.BI $[ host ]
87is replaced by the IP address of the named
88.IR host .
89Note that
90.I host
91may itself contain
92.BI $( key )
93substitutions.
94.PP
95There is a simple concept of
96.I inheritance
97for sections. If a section contains an assignment
98.IP
99.BI "@inherit = " parent
100.RB [[,]
101.I parent
102\&...]
103.PP
104then any lookups which can't be satisfied in that section will be
105satisfied instead from its
106.I parent
107sections (and, if necessary, their parents in turn, and so on).
108.PP
109.hP \*o
110If a value can be found for a key via multiple parents then all of them
111must report the
112.I same
113value. This restriction may be relaxed somewhat, if it turns out that a
114more flexible notion of multiple inheritance is useful.
115.hP \*o
116It's not allowed for a section to inherit, possibly indirectly, from
117itself. Currently errors of this kind are only diagnosed when a cycle
118is encountered while looking up a key and none of the sections on the
119path from the original section up to and round the cycle define a value
120for it. Future versions of this program might be more picky.
121.PP
122Note that
123.BI $( key )
124substitutions in the resulting value will be satisfied from the original
125section (though falling back to scanning parent sections). For
126example, given the sections
127.VS
128[parent]
129detail = in $(name)
130blurb = expand $(detail)
131
132[child]
133@inherit = parent
134.VE
135the key
136.B blurb
137takes the value
138.RB ` "expand in parent" '
139in section
140.BR parent ,
141and
142.RB ` "expand in child" '
143in section
144.BR child .
145.PP
146Apart from its effect on lookups, as just described, the
147.B @inherit
148key is entirely ignored. In particular, it is never written to the
149database.
150.
151.SS "Standard keys and their meanings"
152The following keys have meanings to programs in the TrIPE suite. Other
153keys may be used by separately distributed extensions or for local use.
154The descriptions given are summaries only; see the references for
155details.
156.TP
157.B auto
158If true, include the peer in the
159.B %AUTO
160record. Used by
161.BR connect (8)
162and
163.BR tripe-newpeers (8);
164described below.
165.TP
166.B connect
167Shell command for initiating connection to this peer. Used by
168.BR connect (8).
169.TP
170.B cork
171Don't initiate immediate key exchange. Used by
172.BR connect (8).
173.TP
174.B disconnect
175Shell command for closing down connection to this peer. Used by
176.BR connect (8).
177.TP
178.B ephemeral
179Mark the peer as ephemeral: see
180.BR tripe-admin (5)
181for what this means. Used by
182.BR connect (8).
183.TP
184.B every
185Interval for checking that the peer is still alive and well. Used by
186.BR connect (8).
187.TP
188.B ifdown
189Script to bring down tunnel interface connected to the peer. Used by
190.BR connect (8).
191.TP
192.B ifname
193Interface name to set for the tunnel interface to the peer. Used by
194.BR tripe-ifup (8).
195.TP
196.B ifup
197Script to bring up tunnel interface connected to the peer. Used by
198.BR connect (8).
199.TP
200.B ifupextra
201Script containing additional interface setup. Used by
202.BR tripe-ifup (8).
203.TP
204.B laddr
205Local address for the tunnel interface to the peer. Used by
206.BR tripe-ifup (8).
207.TP
208.B keepalive
209Interval for sending keepalive pings. Used by
210.BR connect (8).
211.TP
212.B key
213Key tag to use to authenticate the peer. Used by
214.BR connect (8).
215.TP
216.B knock
217Knock string to send when establishing a dynamic connection. Used by
218.BR connect (8).
219.TP
220.B mobile
221Peer's IP address is highly volatile. Used by
222.BR connect (8).
223.TP
224.B mtu
225Maximum transmission unit for the tunnel interface. Used by
226.BR tripe-ifup (8).
227.TP
228.B nets
229Networks to be routed over the tunnel interface. Used by
230.BR tripe-ifup (8).
231.TP
232.B peer
233Network address for this peer, or
234.BR PASSIVE .
235Used by
236.BR connect (8).
237.TP
238.B priv
239Tag of the private key to use when communicating with the peer.
240Used by
241.BR connect (8).
242.TP
243.B raddr
244Remote address for the tunnel interface to the peer. Used by
245.BR tripe-ifup (8).
246.TP
247.B retries
248Number of failed ping attempts before attempting reconnection. Used by
249.BR connect (8).
250.TP
251.B timeout
252Timeout for ping probes. Used by
253.BR connect (8).
254.TP
255.B tunnel
256Tunnel driver to use when adding the peer. Used by
257.BR connect (8)).
258.TP
259.B user
260Peer will make active connection as
261.IR user .
262Used by
263.BR connect (8)
264and
265.BR tripe-newpeers (8);
266described below.
267.
268.SS "Conversion"
269This section describes how the textual
270.B peers.in
271file is converted into the
272.BR peers.cdb (5)
273database.
274.PP
275The handling of each section depends on its name.
276.hP \*o
277Sections whose names have the form
278.BI @ whatever
279are ignored (though their contents may be relevant if the section is
280named in another section's
281.B @inherit
282key).
283.hP \*o
284Sections whose names have the form
285.BI $ whatever
286are written to local-type database records with the same name. The keys
287and values defined in the section (and its parent section, if it
288contains an
289.B @inherit
290key) are stored in the record using
291.B form-urlencoding
292as defined in RFC1822, except that the key-value pairs are separated by
293semicolons
294.RB ` ; '
295rather than ampersands
296.RB ` & '.
297Keys whose names begin with
298.RB ` @ '
299are not written to the database.
300.hP \*o
301Other sections are written to peer-type database records, named
302.BI P name \fR,
303in exactly the same way as for local-type records. However, two special
304actions are also taken.
305.IP
306Firstly, if there is a key
307.B auto
308in the section (or in its parent, etc.), and the value is
309.BR y ,
310.BR yes .
311.BR t ,
312.BR true ,
313.BR 1 ,
314or
315.BR on ,
316then the section's name is added in the special
317.B %AUTO
318record.
319.IP
320Secondly, if there is a key
321.B user
322in the section (or in its parent, etc.), then a user record
323.BI U user
324is created whose contents is the section name.
325.
326.\"--------------------------------------------------------------------------
327.SH "SEE ALSO"
328.
329.BR cdb (5),
330.BR tripe (8).
331.PP
332.BR tripe-newpeers (8),
333.BR peers.cdb (5),
334.BR connect (8),
335.BR tripe-ifup (8).
336.
337.\"--------------------------------------------------------------------------
338.SH "AUTHOR"
339.
340Mark Wooding, <mdw@distorted.org.uk>
341.
342.\"----- That's all, folks --------------------------------------------------