/* crypto/o_time.c -*- mode:C; c-file-style: "eay" -*- */ /* Written by Richard Levitte (richard@levitte.org) for the OpenSSL * project 2001. */ /* ==================================================================== * Copyright (c) 2001 The OpenSSL Project. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution. * * 3. All advertising materials mentioning features or use of this * software must display the following acknowledgment: * "This product includes software developed by the OpenSSL Project * for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/)" * * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to * endorse or promote products derived from this software without * prior written permission. For written permission, please contact * licensing@OpenSSL.org. * * 5. Products derived from this software may not be called "OpenSSL" * nor may "OpenSSL" appear in their names without prior written * permission of the OpenSSL Project. * * 6. Redistributions of any form whatsoever must retain the following * acknowledgment: * "This product includes software developed by the OpenSSL Project * for use in the OpenSSL Toolkit (http://www.OpenSSL.org/)" * * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. * ==================================================================== * * This product includes cryptographic software written by Eric Young * (eay@cryptsoft.com). This product includes software written by Tim * Hudson (tjh@cryptsoft.com). * */ #include #include #include "o_time.h" #ifdef OPENSSL_SYS_VMS # include # include # include # include # include # include #endif struct tm *OPENSSL_gmtime(const time_t *timer, struct tm *result) { struct tm *ts = NULL; #if defined(OPENSSL_THREADS) && !defined(OPENSSL_SYS_WIN32) && !defined(OPENSSL_SYS_OS2) && !defined(__CYGWIN32__) && (!defined(OPENSSL_SYS_VMS) || defined(gmtime_r)) && !defined(OPENSSL_SYS_MACOSX) && !defined(OPENSSL_SYS_SUNOS) /* should return &data, but doesn't on some systems, so we don't even look at the return value */ gmtime_r(timer,result); ts = result; #elif !defined(OPENSSL_SYS_VMS) ts = gmtime(timer); if (ts == NULL) return NULL; memcpy(result, ts, sizeof(struct tm)); ts = result; #endif #ifdef OPENSSL_SYS_VMS if (ts == NULL) { static $DESCRIPTOR(tabnam,"LNM$DCL_LOGICAL"); static $DESCRIPTOR(lognam,"SYS$TIMEZONE_DIFFERENTIAL"); char logvalue[256]; unsigned int reslen = 0; struct { short buflen; short code; void *bufaddr; unsigned int *reslen; } itemlist[] = { { 0, LNM$_STRING, 0, 0 }, { 0, 0, 0, 0 }, }; int status; time_t t; /* Get the value for SYS$TIMEZONE_DIFFERENTIAL */ itemlist[0].buflen = sizeof(logvalue); itemlist[0].bufaddr = logvalue; itemlist[0].reslen = &reslen; status = sys$trnlnm(0, &tabnam, &lognam, 0, itemlist); if (!(status & 1)) return NULL; logvalue[reslen] = '\0'; t = *timer; /* The following is extracted from the DEC C header time.h */ /* ** Beginning in OpenVMS Version 7.0 mktime, time, ctime, strftime ** have two implementations. One implementation is provided ** for compatibility and deals with time in terms of local time, ** the other __utc_* deals with time in terms of UTC. */ /* We use the same conditions as in said time.h to check if we should assume that t contains local time (and should therefore be adjusted) or UTC (and should therefore be left untouched). */ #if __CRTL_VER < 70000000 || defined _VMS_V6_SOURCE /* Get the numerical value of the equivalence string */ status = atoi(logvalue); /* and use it to move time to GMT */ t -= status; #endif /* then convert the result to the time structure */ /* Since there was no gmtime_r() to do this stuff for us, we have to do it the hard way. */ { /* The VMS epoch is the astronomical Smithsonian date, if I remember correctly, which is November 17, 1858. Furthermore, time is measure in thenths of microseconds and stored in quadwords (64 bit integers). unix_epoch below is January 1st 1970 expressed as a VMS time. The following code was used to get this number: #include #include #include #include main() { unsigned long systime[2]; unsigned short epoch_values[7] = { 1970, 1, 1, 0, 0, 0, 0 }; lib$cvt_vectim(epoch_values, systime); printf("%u %u", systime[0], systime[1]); } */ unsigned long unix_epoch[2] = { 1273708544, 8164711 }; unsigned long deltatime[2]; unsigned long systime[2]; struct vms_vectime { short year, month, day, hour, minute, second, centi_second; } time_values; long operation; /* Turn the number of seconds since January 1st 1970 to an internal delta time. Note that lib$cvt_to_internal_time() will assume that t is signed, and will therefore break on 32-bit systems some time in 2038. */ operation = LIB$K_DELTA_SECONDS; status = lib$cvt_to_internal_time(&operation, &t, deltatime); /* Add the delta time with the Unix epoch and we have the current UTC time in internal format */ status = lib$add_times(unix_epoch, deltatime, systime); /* Turn the internal time into a time vector */ status = sys$numtim(&time_values, systime); /* Fill in the struct tm with the result */ result->tm_sec = time_values.second; result->tm_min = time_values.minute; result->tm_hour = time_values.hour; result->tm_mday = time_values.day; result->tm_mon = time_values.month - 1; result->tm_year = time_values.year - 1900; operation = LIB$K_DAY_OF_WEEK; status = lib$cvt_from_internal_time(&operation, &result->tm_wday, systime); result->tm_wday %= 7; operation = LIB$K_DAY_OF_YEAR; status = lib$cvt_from_internal_time(&operation, &result->tm_yday, systime); result->tm_yday--; result->tm_isdst = 0; /* There's no way to know... */ ts = result; } } #endif return ts; } 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 


































































































































































                                                                               
****** rpki-rtr ******

rtr-origin is an implementation of the rpki-rtr protocol.

rtr-origin depends on rcynic to collect and validate the RPKI data. rtr-
origin's's job is to serve up that data in a lightweight format suitable for
routers that want to do prefix origin authentication.

To use rtr-origin, you need to do two things beyond setting up rcynic:

  1. You need to set up post-processing of rcynic's output into the data files
     used by rtr-origin, and
  2. You need to set up a listener for the rtr-origin server, using the
     generated data files.

***** Post-processing rcynic's output *****

rtr-origin is designed to do the translation from raw RPKI data into the rpki-
rtr protocol only once. It does this by pre-computing the answers to all the
queries it is willing to answer for a given data set, and storing them on disk.
rtr-origin's --cronjob mode handles this.

To set this up, add an invocation of rtr-origin --cronjob to the cron job
you're already running to run rcynic. In --cronjob rtr-origin, needs write
access to a directory where it can store pre-digested versions of the data it
pulls from rcynic.

rtr-origin creates 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, rtr-origin creates these files under the directory in
which you run it.

So, assuming that rtr-origin is installed in /usr/local/bin, that rcynic writes
its data files under /var/rcynic/data/authenticated, and you want rtr-origin to
write its datafiles to /var/rpki-rtr, you'd add something like the following to
your cronjob:

  cd /var/rpki-rtr
  /usr/local/bin/rtr-origin --cronjob /var/rcynic/data/authenticated

See the instructions for setting up a cron job for an example of how to run
rcynic and rtr-origin together in a single cron job.

You should make sure that rtr-origin runs at least once before attempting to
configure --server mode. Nothing terrible will happen if you don't do this, but
--server invocations started before the first --cronjob run may behave oddly.

***** Setting up the rpki-rtr server *****

You need to to set up a server listener that invokes rtr-origin in --server
mode. What kind of server listener you set up depends on which network protocol
you're using to transport this protocol. rtr-origin is happy to run under
inetd, xinetd, sshd, or pretty much anything -- rtr-origin 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.

--server mode takes an optional argument specifying the path to its data
directory; if you omit this argument, it uses the directory in in which you run
it.

The details of how you set up a listener for this vary depending on the network
protocol and the operating system on which you run it. Here are two examples,
one for running under inetd, the other for running under sshd.

**** Running rtr-origin --server under inetd ****

Running under inetd with plain TCP is insecure and should only be done for
testing, but you can also run it with TCP-MD5 or TCP-AO, or over IPsec. The
inetd configuration is generally the same, the details of how you set up TCP-
MD5, TCP-AO, or IPsec are platform specific.

To run under inetd, you need to:

  1. Add an entry to /etc/services defining a symbolic name for the port, if
     one doesn't exist already. At present there is no well-known port defined
     for this protocol, for this example we'll use port 42420 and the symbolic
     name rpki-rtr.

     Add to /etc/services:

  rpki-rtr          42420/tcp

  1. Add the service line to /etc/inetd.conf:

  rpki-rtr stream tcp nowait nobody /usr/local/bin/rtr-origin rtr-origin --
  server /var/rpki-rtr

     This assumes that you want the server to run as user "nobody", which
     is generally a safe choice, or you could create a new non-priviledged
     user for this purpose. DO NOT run the server as root; it shouldn't do
     anything bad, but it's a network server that doesn't need root
     access, therefore it shouldn't have root access.

**** Running rtr-origin --server under sshd ****

To run rtr-origin under sshd, you need to:

  1. Decide whether to run a new instance of sshd on a separate port or use the
     standard port. rtr-origin doesn't care, but some people seem to think that
     it's somehow more secure to run this service on a different port. Setting
     up sshd in general is beyond the scope of this documention, but most
     likely you can copy the bulk of your configuration from the standard
     config.
  2. Configure sshd to know about the rpki-rtr subsystem. Add something like
     this to your sshd.conf:

  Subsystem rpki-rtr /usr/local/bin/rtr-origin

  1. Configure the userid(s) you expect ssh clients to use to connect to the
     server. For operational use you almost certainly do NOT want this user to
     have a normal shell, instead you should configure its shell to be the
     server (/usr/local/bin/rtr-origin or wherever you've installed it on your
     system) and its home directory to be the rpki-rtr data directory (/var/
     rpki-rtr or whatever you're using). If you're using passwords to
     authenticate instead of ssh keys (not recommended) you will always need to
     set the password(s) here when configuring the userid(s).
  2. Configure the .ssh/authorized_keys file for your clients; if you're using
     the example values given above, this would be /var/rpki-rtr/.ssh/
     authorized_keys. You can have multiple ssh clients using different keys
     all logging in as the same ssh user, you just have to list all of the ssh
     keys here. You may want to consider using a command= parameter in the key
     line (see the sshd(8) man page) to lock down the ssh keys listed here so
     that they can only be used to run the rpki-rtr service.

     If you're running a separate sshd for this purpose, you might also
     want to add an AuthorizedKeysFile entry pointing at this
     authorized_keys file so that the server will only use this
     authorized_keys file regardless of what other user accounts might
     exist on the machine:

  AuthorizedKeysFile /var/rpki-rtr/.ssh/authorized_keys

     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.

**** Other transports ****

You can also run this code under xinetd, or the netpipes "faucet" program, or
stunnel...other than a few lines that might need hacking to log the connection
peer properly, the program really doesn't care.

You should, however, care whether the channel you have chosen is secure; it
doesn't make a lot of sense to go to all the trouble of checking RPKI data then
let the bad guys feed bad data into your routers anyway because you were
running the rpki-rtr link over an unsecured TCP connection.

***** Other modes *****

rtr-origin has two other modes which might be useful for debugging:

  1. --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.
  2. --show mode will display a text dump of pre-digested data files in the
     current directory.

rtr-origin has a few other modes intended to support specific research
projects, but they're not intended for general use.