1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
$Id$
Sample implementation of draft-ymbk-rpki-rtr-protocol.
This depends on rcynic (../rcynic/) to collect and validate the RPKI
data. This program's job is to serve up that data in a lightweight
format suitable for routers that want to do prefix origin
authentication.
To use this, you need to do two things beyond setting up rcynic:
1) Add an invocation of this program in --cronjob mode to the cron job
you're already running to run rcynic. In cronjob mode this program
needs write access to a directory where it can store pre-digested
versions of the data it pulls from rcynic.
The program will create a collection of data files, as well as a
subdirectory in which each instance of the program running in
--server mode can write a PF_UNIX socket file. At present, it
creates these files under the directory in which the program was
run.
So if this script lives in $srcdir, rcynic writes its data files
under $rcynicdir, and you want this program to write its datafiles
to $rtrorigindir, you would add something like the following to
your cronjob:
cd $rtrorigindir
/usr/local/bin/python $srcdir/rtr-origin.py --cronjob $rcynicdir
You should make sure this program runs at least once before
attempting to configure --server mode. Nothing terrible will
happen if you don't, but --server invocations started before the
first --cronjob run may behave oddly.
2) You need to to set up a server listener that invokes this program
in --server mode. What kind of server listener you set up depends
on which network protocol you're using to transport this protocol.
The specification says that the rpki-rtr protocol will run under
ssh, but not all clients support that yet. rtr-origin.py doesn't
really care, it just reads from stdin and writes to stdout.
--server mode should be run as a non-privileged user (it is
read-only for a reason). You may want to set up a separate UNIX
userid for this purpose so that you can give that user its own home
directory and ssh configuration files.
As with --cronjob mode, --server mode currently uses the directory
in which it was started as its data directory (this may change in
the future), so you need to arrange for whatever program invokes it
to cd to whatever you used as your $rtrorigindir, above. Eg:
cd $rtrorigindir
/usr/local/bin/python $srcdir/rtr-origin.py --server
There's a sample sshd.conf in the source directory. You will have
to modify it to suit your environment. The most important part is
the Subsystem line, which runs the server.sh script as the
"rpki-rtr" service, as required by the protocol specification.
If you are using sshd you will presumably also want to configure an
authorized_keys file. You may want to consider using a command=""
parameter in the key line (see the sshd(8) man page) to lock down
this ssh key so that it can only be used to run the "rpki-rtr"
service.
You can also run this code under inetd (or the netpipes "faucet"
program), with the understanding that this is totally insecure and
only suitable for early testing.
In theory one could also run this under TLS, eg, via the stunnel
program, which would provide security roughly equivalent to (albeit
different from) ssh. Other than a few lines that might need
hacking to log the connection peer properly, the program really
doesn't care.
The program has two other modes, which might be useful for debugging:
a) --client mode implements a dumb client program for this protocol,
over ssh, raw tcp, or by invoking --server mode directly in a
subprocess. The output is not expected to be useful except for
debugging.
b) --show mode will display a text dump of pre-digested data files in
the current directory.
|
