NLnetLabs-krill/defaults/krill.conf

######################################################################################
#                                                                                    #
#                                      DATA                                          #
#                                                                                    #
######################################################################################

# Specify the directory where the publication server will store its data.
# Note that clustering through a shared data directory is not supported.
# But, we plan to look into a proper clustering solution later.
#
### data_dir = "./data"

# Specify the path to the PID file for Krill.
#
# Defaults to "krill.pid" under the 'data_dir' specified above.
#
### pid_file = "./data/krill.pid"


######################################################################################
#                                                                                    #
#                                     LOGGING                                        #
#                                                                                    #
######################################################################################

# Log level
#
# The maximum log level ("off", "error", "warn", "info", or "debug") for
# which to log messages.
#
# Defaults to "warn"
#
### log_level = "warn"

# Log type
#
# Where to log to. One of "stderr" for stderr, "syslog" for syslog, or "file"
# for a file. If "file" is given, the "log_file" field needs to be given, too.
#
### log_type = "file"

# Syslog facility
#
# The syslog facility to log to if syslog logging is used. Defaults to "daemon".
#
### syslog_facility = "daemon"

# Log file
#
# The path to the file to log to if file logging is used. If the path is
# relative, it is relative to the current working directory from which
# the binary is executed.
#
### log_file = "./krill.log"


######################################################################################
#                                                                                    #
#                                     ACCESS                                         #
#                                                                                    #
######################################################################################

# Admin Token
#
# Define an admin token that can be used to interact with the API. Token use
# is modelled after OAuth 2.0 Bearer Tokens (RFC 6750), which are expected be
# included as an HTTP header in requests by clients.
#
# If you do not specify a value here, the server will insist that you provide
# a token as an environment variable with the key "KRILL_ADMIN_TOKEN".
#
### admin_token =

# Specify the ip address and port number that the server will use.
#
# Note: we recommend that you do NOT change the IP address to anything other
# than 127.0.0.1. Please use a proxy server such as NGINX or Apache if you
# must make your Krill instance accessible remotely.
#
# If you do change the IP address, then the service uri will use it as a hostname.
# If you want to use a proper public hostname, please set 'service_uri' below.
#
### ip             = "127.0.0.1"
### port           = 3000

# Specify the base public service URI hostname and port.
#
# The default service URI is set to https://localhost:3000/. This is fine for
# setups where you use Krill to run your own CA only. You do not need to set this
# to enable remote access to the UI or API (e.g. for using the CLI remotely).
# Simply setting up a proxy suffices for this.
#
# However, if you are serving as a parent CA or Publication Server that needs
# to be accessible by remote CAs, then you will need to tell your Krill instance
# what its public (base) URI will be, so that it can include the proper URIs
# in responses to those CAs.
#
# At present this MUST be an https URI with a hostname and optional port number only.
# It is not allowed to use a Krill specific path prefix. If you have a strong
# motivation for this, then please comment on the following github issue:
# https://github.com/NLnetLabs/krill/issues/263
#
# Krill UI, API and service URIs will be derived as follows:
#  <service_uri>api/v1/...                (api)
#  <service_uri>rfc6492                   (for remote children)
#  <service_uri>...                       (various UI resources)
### service_uri = "https://localhost:3000/"

######################################################################################
#                                                                                    #
#                                OTHER SEVER SETTINGS                                #
#                                                                                    #
######################################################################################


# CA certificate refresh rate
#
# This defines the rate, in seconds, for Krill CAs to to contact their parent CA
# via the RFC 6492 up-down protocol and query for updates in resource entitlements.
#
# Defaults to 10 minutes
#
### ca_refresh = 600

# Enable loading BGP Dumps from RIS for ROA vs BGP analysis.
#
# bgp_risdumps_enabled = true
# bgp_risdump_v4_uri = http://www.ris.ripe.net/dumps/riswhoisdump.IPv4.gz
# bgp_risdump_v6_uri = http://www.ris.ripe.net/dumps/riswhoisdump.IPv6.gz

# Restrict size of messages sent to the API.
#
# Default 256 kB
#
### post_limit_api = 262144

# Restrict size of messages sent to the RFC 6492 up-down protocol. Only relevant
# if you operate Krill as a parent to other CAs.
#
# Default 1MB (enough for a keyroll with certs of ~400kb, the biggest known cert is 220kB)
#
### post_limit_rfc6492 = 1048576


######################################################################################
#                                                                                    #
#                --------======== DANGER ZONE ========--------                       #
#                                                                                    #
#  Do not change the options below, unless you are really certain that you need to   #
#  override Krill's default behaviour.                                               #
#                                                                                    #
######################################################################################


# Set the following to true to force Krill to always perform full rechecks
# of its data directories at startup. This is disabled by default because
# if can slow down startup significantly.
#
# By default Krill will do some basic checks at startup already, and if any
# errors are encountered force a full recovery automatically: Krill will try
# to load all its state in its internal memory cache at startup. If there are
# no errors in reloading the latest 'info' about the state, any surplus data
# will be assumed to be the result from an incompletely finished transaction - or -
# a data directory backup which was taken during a transaction. In either case
# additional data is discarded and the last (committed) state is recreated.
#
# Note that this 'recovery' will make Krill fall back to the last possible
# consistent state that it can. But, there may be important changes missing.
# For example any changes in ROAs made after the last recoverable state will
# be missing. You will have to verify the state yourself.
#
# In short: use this option only if you suspect that there is an issue with
# your backed up data. And if you do, you may want to set the ENV variable
# "KRILL_UPGRADE_ONLY" as well, in order to force that Krill exits after doing
# all its data checks and clean ups, and you have a chance to check the logs
# before proceeding.
#
### always_recover_data = false


#
#                               ROA Aggregation
#
# It is recommended that separate ROAs are used for each authorized prefix, even
# though the RFC allows for multiple prefixes for the same ASN to be combined on
# a single ROA object. The reason for this is that the ROA will become invalid
# if any of the listed prefixes no longer appears on your CA's certificate. Note
# that Krill will automatically clean up over-claiming ROAs when it finds that its
# resources have been shrunk, but there is a possible time window where ROAs can
# be invalid before Krill discovers the shrinkage.
#
# That said, if there would be too many ROAs then this will impact all RPKI
# validators, therefore Krill will by default start aggregating ROAs per ASN
# when more than 100 ROAs would be issued. Conversely, Krill will start de-
# aggregating again when the number of authorizations drops below 90.
#
# This behaviour can be overridden with the following directives:
# roa_aggregate_threshold = 100
# roa_deaggregate_threshold = 90


#
#                               Republication Intervals
#
# The RPKI uses Manifests (RFC 6486) to communicate the list of current RPKI
# objects (such as ROAs) to RPKI Validators. Manifests are used to protect against
# attacks, or incidents, where Validators only see a partial view of the RPKI
# repository. For this to work properly Validators will need to know how 'fresh'
# the Manifests are - otherwise they would be vulnerable to replay attacks where
# they are presented old versions of Manifests thus withholding them from discovering
# new RPKI objects.
#
#
# Krill issues manifests with a default next update and validity period of 24 hours.
# This means that the maximum replay window is 24 hours. Krill checks every 10 minutes
# whether the next update time is less then 8 hours (by default) in the future, and in
# that case it will re-issue them to avoid that Validators would end up with expired
# manifests. This means that an operator has a minimum of just under 8 hours to deal
# with issues with their CA or Publication Server before RPKI Validators would notice.
#
# The default values can be overridden, but with care.. make the next update interval
# too short and this causes too much work for all RPKI validators, puts load on your
# publication server and shortens your window to deal with issues. Make it too long
# and you could be vulnerable to replay attacks. Re-issue to quickly and again you
# cause extra load to RPKI validators and publication server.
#
# All that said.. if you are willing to accept the, in practice, small risk of a replay
# attack then you could for example opt for 48 hours next update and re-issue every
# 24 hours. That way you would have a full day to fix issues.
#
# timing_publish_next_hours = 24           # (must be 2 or higher)
# timing_publish_hours_before_next = 8     # (must be 1 or higher)


#
#                 ROA and Delegate Certificate Times
#
# Krill will issue ROAs, and child CA certificates if you have delegated resources
# to child CAs, with a "not after" time of 52 weeks from issuance, and it will
# re-issue those ROAs and certificates 4 weeks before they would expire.
#
# Because of the automatic renewal there should be no real need to use longer
# validity times. In fact using longer times could have a negative impact on
# Validator performance because the Certificate Revocation Lists would become
# bigger.
#
# So, we do NOT recommend overriding the following values, except perhaps for
# testing purposes:
# timing_child_certificate_valid_weeks = 52
# timing_child_certificate_reissue_weeks_before = 4
# timing_roa_valid_weeks = 52
# timing_roa_reissue_weeks_before = 4

#
#                 Suspend inactive child CAs
#
# NOTE: YOU DO NOT NEED THIS UNLESS YOU DELEGATE RESOURCES TO CHILD CAS
#
# If you delegate resources to child CAs, it may happen that those (remote)
# child CAs become inactive, most likely because the operator turned off
# their RPKI CA software.
#
# When this happens the manifest and CRL published by the child CA in
# question are no longer refreshed and expire fairly quickly. The exact
# timing depends on the RPKI CA software implementation and configuration.
# For Krill CAs using default configuration settings expiration will happen
# within 8 to 24 hours after shutdown because, by default, Krill CAs will
# use a 'next update' time of 24 hours after refresh, and pre-emptively
# refresh the CRL and manifest 8 hours before they would expire.
#
# Expired manifests and CRLs will lead to rejection of all of the child CA's
# RPKI objects. Note that this does not affect the validity of objects published
# by any other child CAs.  Even though it is to be expected that this can happen in
# the RPKI, this rejection leads to logging by validation software, which in
# turn leads to concerns raised by network operators. 
#
# The first responsibility for remediating this is with the operator of the
# child CA in question. They should fix their setup, or if they no longer wish
# to operate an RPKI CA then they should request that you remove them as a
# child and withdraw all their published objects.
#
# However, the operator may be unwilling or unreachable. In such cases the
# parent CA (you) may want to take it upon themselves to remove the child
# and thus quell this source of errors being reported to network operators
# around the globe. The trouble with this is, that if the child CA is then
# re-activated later they will no longer be listed as your child, but they
# do not know this. Their CA will simply get errors when trying to sync with
# you (their parent). Meaning, in order to fix this they would most likely
# need to remove you as a parent first and then re-do the initial XML exchange
# to get themselves set up as a child under you again.
#
# This is rather cumbersome. Therefore, we have added support for another
# approach. Rather than removing inactive child CAs, Krill can 'suspend' them
# instead. When a child CA is suspended all of its delegated certificates are
# removed from your CA's publication point. This means that RPKI validation
# software will no longer see these certificates, or any of the objects published
# under the child CA. The effect on validated objects is the same as when the
# the child CA's publication point would be rejected due to an expired manifest
# or CRL, except that errors are no longer being reported.
#
# If the child CA then becomes active again, it can simply be 'unsuspended'.
# Meaning, its certificates will be published again - as long as they are not
# expired and do not contain resources no longer held by the child. And then
# the child can resume its normal certificate request cycle with you as their
# parent without the need to re-do the parent-child exchanges.
#
# Trouble is that there is no clear cut way for a parent to know that
# a child CA had been deactivated. The best indication we have is by looking
# at the last attempt by the child to send an RFC 6492 request to a parent. By
# default Krill CAs will send an RFC 6492 list query every 10 minutes. So, if 
# you did not receive any such query for more than this time, then it is likely
# the CA in question is no longer active.
#
# You can now configure Krill to automatically suspend child CAs for which
# no list query was received for longer than 'X' hours. The child is then
# automatically 'unsuspended' as soon as its sends another query.
#
# NOTE: By default Krill will NOT suspend children. This behaviour is only
# activated if the configuration directive below is set.
#
# Some outages are to be expected, and people may also change their configuration
# to send these queries less frequently. As mentioned earlier for Krill CAs
# an outage up to 8 hours will not result in any expired manifest or CRL issues.
# Therefore we recommend that you do not use any value lower than 8 for this
# directive:
# 
# suspend_child_after_inactive_hours = 8