3 .\" Manual for the malicious proxy
5 .\" (c) 2008 Straylight/Edgeware
8 .\"----- Licensing notice ---------------------------------------------------
10 .\" This file is part of Trivial IP Encryption (TrIPE).
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.
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
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/>.
25 .\"--------------------------------------------------------------------------
26 .so ../common/defs.man \" @@@PRE@@@
28 .\"--------------------------------------------------------------------------
29 .TH tripe-mitm 8tripe "14 October 2003" "Straylight/Edgeware" "TrIPE: Trivial IP Encryption"
31 .\"--------------------------------------------------------------------------
34 tripe-mitm \- malicious proxy for TrIPE
36 .\"--------------------------------------------------------------------------
44 .\"--------------------------------------------------------------------------
53 Its purpose is to test the robustness of the TrIPE implementation, by
54 deliberately introducing communication problems such as dropped,
55 repeated or corrupted packets.
57 The command line contains a sequence of directives, each of which has
61 (The delimiter character can be changed using the
64 A list of directives can be stored in a file, one per line, and included
68 .SS "Command line options"
69 The following options are recognized.
72 Write a very brief help message to standard output, and exit
76 Write the program's version number to standard output, and exit
80 Write a usage message to standard output, and exit successfully.
82 .BI "\-d, \-\-delimiter=" char
85 as the delimiter to separate argument names in directives, rather than
88 .BI "\-k, \-\-keyring=" file
91 The default keyring file is
93 in the current directory.
95 A directive is ignored if it is empty, or if its first character is a
97 Directives consist of a name followed by zero or more arguments,
98 separated by a delimiter character. The default delimiter is
100 but this can be overridden using the
102 option (see above); this manual uses
104 consistently as the delimiter character.
105 The following directives are recognized.
107 .BI peer: name : local-port : remote-addr : remote-port
108 Register a peer. We listen for packets on
116 identifies the public key which that peer uses to authenticate itself.
117 (Currently this is checked, but not used for anything.)
122 may be numbers or UDP service names;
124 may be a hostname, an IPv4 address in dotted-quad format, or an IPv6
125 address in hex-and-colons format (this last obviously requires selecting
126 a different delimeter character). Exactly two
128 directives must be present. The one first registered is the
130 peer; the second is the
132 peer. The two peers must use
136 .BI peer4: name : local-port : remote-addr : remote-port
139 (see above), but force the use of IPv4.
141 .BI peer6: name : local-port : remote-addr : remote-port
144 (see above), but force the use of IPv6.
147 Read more directives from
149 Directives should appear one per line. Empty lines and comments are
150 permitted. An included file may include other files. It may even
151 include itself, though this is just a good way to tie the program in
152 knots until it runs out of file handles.
154 .BI filt: filter : args : \fR...
155 Apply a given filter to packets received from either peer. See the
156 description of filters below for more details.
158 .BI lfilt: filter : args : \fR...
159 Apply a given filter to packets received from the left peer.
161 .BI rfilt: filter : args :\fR...
162 Apply a given filter to packets received from the right peer.
164 .BI next: tag :\fR...
165 Begin the next branch of the first fork filter node named
167 in each filter chain. See below for more about filter chains.
169 .BI flood\fR[\fP: type : millis : size\fR]
170 Flood both peers with random packets. If
172 is given, it is interpreted as a TrIPE message type code in hexadecimal,
173 and the messages sent will have this type; otherwise the messages have
174 random type. Messages are sent approximately once every
176 milliseconds; the default interval is 10 milliseconds. The messages
179 bytes long each; the default size is 128 bytes.
181 .BI lflood\fR[\fP: type : millis : size\fR]
184 above, but only flood the left peer.
186 .BI rflood\fR[\fP: type : millis : size\fR]
189 above, but only flood the right peer.
191 Each peer has a filter chain associated with it. Messages received from
192 that peer get processed by the filter chain. Only if the filter chain
193 decides to send the message is it actually sent. (See the
195 filter, described below.)
196 Messages generated by a
198 directive (above) are also processed by a filter chain, just like normal
199 messages. The filters in a chain are processed in the order they were
202 The filters currently supported are as follows.
205 Send the message to the destination peer. This is the
207 way messages are sent. If your filter chains don't end in a
209 filter then nothing will get through!
212 Introduce a fork in a filter chain. A fork may have multiple branches
213 leading off it. The end of a branch is indicated by a
215 directive which names the fork
217 further filters added to the chain form a new parallel branch of that
218 fork. (If there are two forks with the same tag on a peer's chain, then
219 only the earliest is matched. This isn't helpful behaviour.)
221 .BI delay: qlen \fR[\fP: millis : p-replay\fR]
222 Delay, replay and reorder messages. A queue of
224 messages is maintained. If the queue fills up, or every
226 milliseconds (default 100), a message from the queue is chosen at random
227 and transmitted (i.e., processed by the rest of the filter chain). If
228 the message was transmitted due to a timer (rather than lack of space in
229 the queue) then it has a 1 in
231 probability (default 1 in 20) of being left in the queue.
233 .BI drop\fR[\fP: p-drop\fR]
234 Randomly drop messages. Each message has a 1 in
236 probability (default 1 in 5) of being discarded.
238 .BI corrupt\fR[\fP: p-corrupt\fR]
239 Randomly corrupt messages. Each message has a 1 in
241 probability (default 1 in 5) of being corrupted by having a
242 randomly chosen byte mangled. The message might be further corrupted,
247 .\"--------------------------------------------------------------------------
250 The parser is currently very primitive, and error handling is rather
251 poor. There are lots of pointless restrictions which wouldn't take very
252 long to fix. The program generally lacks polish. The program doesn't
253 understand the TrIPE protocol to a sufficient extent to really attack it
256 .\"--------------------------------------------------------------------------
261 .\"--------------------------------------------------------------------------
264 Mark Wooding, <mdw@distorted.org.uk>
266 .\"----- That's all, folks --------------------------------------------------