chiark / gitweb /
Version bump; new email address.
[tripe] / doc / tripe-mitm.8
6b3d271a 1.\" -*-nroff-*-
2.\". hP
5\h'-\w'\fB\\$1\ \fP'u'\fB\\$1\ \fP\c
6.. VS
8.sp 1
11.ft B
12.. VE
14.ft R
17.sp 1
18.. t \{\
20. ds o \(bu
21. ds ss \s8\u
22. ds se \d\s0
23. if \n(.g \{\
24. fam P
25. \}
27.el \{\
28. ds o o
29. ds ss ^
30. ds se
32.TH tripe-mitm 8 "14 October 2003" "Straylight/Edgeware" "TrIPE: Trivial IP Encryption"
33.SH "NAME"
34tripe-mitm \- malicious proxy for TrIPE
36.B tripe-mitm
37.RB [ \-k
38.IR keyring ]
39.IR directive ...
42.B tripe-mitm
43program is a
44.I malicious
45proxy for
46.BR tripe (8).
47Its purpose is to test the robustness of the TrIPE implementation, by
48deliberately introducing communication problems such as dropped,
49repeated or corrupted packets.
51The command line contains a sequence of directives, each of which has
52the form
53.IB command : arg \c
54.BR : ...
55A list of directives can be stored in a file, one per line, and included
56using the
57.B include
59.SS "Command line options"
60The following options are recognized.
62.B "\-h, \-\-help"
63Write a very brief help message to standard output, and exit
66.B "\-v, \-\-version"
67Write the program's version number to standard output, and exit
70.B "\-u, \-\-usage"
71Write a usage message to standard output, and exit successfully.
73.BI "\-k, \-\-keyring=" file
74Read keys from
75.IR file .
76The default keyring file is
78in the current directory.
79.SS "Directives"
80A directive is ignored if it is empty, or if its first character is a
81.RB ` # '.
82The following directives are recognized.
84.BI peer: name : local-port : remote-addr : remote-port
85Register a peer. We listen for packets on
86.I local-port
87and send them on to
88.I remote-port
90.IR remote-addr .
92.I name
93identifies the public key which that peer uses to authenticate itself.
95.I local-port
97.I remote-port
98must be numbers;
99.I remote-addr
100may be a hostname or an IP address in dotted-quad format. Exactly two
101.B peer
102directives must be present. The one first registered is the
103.I left
104peer; the second is the
105.I right
106peer. The two peers must use
107.I different
108local ports.
110.BI include: file
111Read more directives from
112.IR file .
113Directives should appear one per line. Empty lines and comments are
114permitted. An included file may include other files. It may even
115include itself, though this is just a good way to tie the program in
116knots until it runs out of file handles.
118.BI filt: filter : args : \fR...
119Apply a given filter to packets received from either peer. See the
120description of filters below for more details.
122.BI lfilt: filter : args : \fR...
123Apply a given filter to packets received from the left peer.
125.BI lfilt: filter : args :\fR...
126Apply a given filter to packets received from the right peer.
2d752320 128.BI next: tag :\fR...
6b3d271a 129Begin the next branch of the first fork filter node named
130.I tag
131in each filter chain. See below for more about filter chains.
133.BI flood\fR[\fP: type : millis : size\fR]
134Flood both peers with random packets. If
135.I type
136is given, it is interpreted as a TrIPE message type code in hexadecimal,
137and the messages sent will have this type; otherwise the messages have
138random type. Messages are sent approximately once every
139.I millis
140milliseconds; the default interval is 10 milliseconds. The messages
141will be
142.I size
143bytes long each; the default size is 128 bytes.
145.BI lflood\fR[\fP: type : millis : size\fR]
146As for
147.B flood
148above, but only flood the left peer.
150.BI rflood\fR[\fP: type : millis : size\fR]
151As for
152.B flood
153above, but only flood the right peer.
154.SS "Filters"
155Each peer has a filter chain associated with it. Messages received from
156that peer get processed by the filter chain. Only if the filter chain
157decides to send the message is it actually sent. (See the
158.B send
159filter, described below.)
160Messages generated by a
161.B flood
162directive (above) are also processed by a filter chain, just like normal
163messages. The filters in a chain are processed in the order they were
166The filters currently supported are as follows.
168.B send
169Send the message to the destination peer. This is the
170.I only
171way messages are sent. If your filter chains don't end in a
172.B send
173filter then nothing will get through!
175.BI fork: tag
176Introduce a fork in a filter chain. A fork may have multiple branches
177leading off it. The end of a branch is indicated by a
178.B next
179directive which names the fork
180.IR tag :
181further filters added to the chain form a new parallel branch of that
182fork. (If there are two forks with the same tag on a peer's chain, then
183only the earliest is matched. This isn't helpful behaviour.)
185.BI delay: qlen \fR[\fP: millis : p-replay\fR]
186Delay, replay and reorder messages. A queue of
187.I qlen
188messages is maintained. If the queue fills up, or every
189.I millis
190milliseconds (default 100), a message from the queue is chosen at random
191and transmitted (i.e., processed by the rest of the filter chain). If
192the message was transmitted due to a timer (rather than lack of space in
193the queue) then it has a 1 in
194.I p-replay
195probability (default 1 in 20) of being left in the queue.
197.BI corrupt\fR[\fP: p-corrupt\fR]
198Randomly corrupt messages. Each message has a 1 in
199.I p-corrupt
200probability (default 1 in 5) of being corrupted by having a
201randomly chosen byte mangled. The message might be further corrupted,
202again with a 1 in
203.I p-corrupt
205.SH "BUGS"
206The parser is currently very primitive, and error handling is rather
808702d2 207poor. There are lots of pointless restrictions which wouldn't take very
208long to fix. The program generally lacks polish. The program doesn't
209understand the TrIPE protocol to a sufficient extent to really attack it
6b3d271a 211.SH "SEE ALSO"
212.BR tripe (8).
d36eda2a 214Mark Wooding, <>