From a3b71bff7c8c32629637d2d28a9b19699f9024b8 Mon Sep 17 00:00:00 2001 From: mDuo13 Date: Fri, 8 Mar 2019 16:48:57 -0800 Subject: [PATCH] Peer protocol/crawler: updates per @jwbusch review --- content/concepts/the-rippled-server/peer-protocol.md | 5 +++-- .../key-generation-methods/validation_create.md | 4 ++-- content/references/rippled-api/peer-crawler.md | 2 +- .../configuration/configure-the-peer-crawler.md | 2 +- 4 files changed, 7 insertions(+), 6 deletions(-) diff --git a/content/concepts/the-rippled-server/peer-protocol.md b/content/concepts/the-rippled-server/peer-protocol.md index 68210c661a..8f151444de 100644 --- a/content/concepts/the-rippled-server/peer-protocol.md +++ b/content/concepts/the-rippled-server/peer-protocol.md @@ -30,12 +30,13 @@ The peer protocol port also serves the [special Peer Crawler API method](peer-cr ### Node Key Pair -When a server first starts up, it generates a _node key pair_ to use to identify itself in peer protocol communications. The server uses its key to sign all its peer protocol communications. This makes it possible to reliably identify and verify the integrity of messages from another server in the peer-to-peer network even if that server's messages are being relayed by untrusted peers. A node key pair is similar to a validator's ephemeral key pair, but validation key pairs are treated separately from node key pairs. +When a server first starts up, it generates a _node key pair_ to use to identify itself in peer protocol communications. The server uses its key to sign all its peer protocol communications. This makes it possible to reliably identify and verify the integrity of messages from another server in the peer-to-peer network even if that server's messages are being relayed by untrusted peers. The node key pair is saved in the database and reused when the server restarts. If you delete the server's databases, it creates a new node key pair, effectively coming online with a different identity. To reuse the same key pair even if the databases are deleted, you can configure the server with a `[node_seed]` stanza. To generate a value suitable for use in the `[node_seed]` stanza, use the [validation_create method][]. The node key pair also identifies other servers [clustered](clustering.html) with this one. If you have a cluster of servers, you should configure each server in the cluster with a unique `[node_seed]` setting. For more information on setting up a cluster, see [Cluster `rippled` Servers](cluster-rippled-servers.html). + ## Private Peers You can configure a `rippled` server to act as a "private" server to keep its IP address hidden from the general public. This can be a useful precaution against denial of service attacks and intrusion attempts on important `rippled` servers such as trusted validators. To participate in the peer-to-peer network, a private server must be configured to connect to at least one non-private server, which relays its messages to the rest of the network. @@ -46,7 +47,7 @@ Configuring a server as a private server has several effects: - The server does not accept incoming connections from other servers unless it has been explicitly configured to accept connections from those servers. - The server asks its direct peers not to reveal its IP address in untrusted communications, including the [peer crawler API response](peer-crawler.html). This does not affect trusted communications such as the [peers admin method][peers method]. - Servers configured as validators do this even if they aren't configured as private peers. This helps protect validators from being overloaded by denial of service attacks. [New in: rippled 1.2.1][] + Validators always ask their peers to hide the validators' IP addresses, regardless of the private server settings. This helps protect validators from being overloaded by denial of service attacks. [New in: rippled 1.2.1][] **Caution:** It is possible to modify a server's source code so that it ignores this request and shares its immediate peers' IP addresses anyway. You should configure your private server to connect only to servers that you know are not modified in this way. diff --git a/content/references/rippled-api/admin-rippled-methods/key-generation-methods/validation_create.md b/content/references/rippled-api/admin-rippled-methods/key-generation-methods/validation_create.md index d575fb7f8f..ba3ebe0f79 100644 --- a/content/references/rippled-api/admin-rippled-methods/key-generation-methods/validation_create.md +++ b/content/references/rippled-api/admin-rippled-methods/key-generation-methods/validation_create.md @@ -1,11 +1,11 @@ # validation_create [[Source]
](https://github.com/ripple/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/ValidationCreate.cpp "Source") -Use the `validation_create` command to generate cryptographic keys a `rippled` server can use to identify itself to the network. Similar to the [wallet_propose method][], this command makes no real changes, but only generates a set of keys in the proper format. +Use the `validation_create` command to generate [cryptographic keys a `rippled` server can use to identify itself to the network](peer-protocol.html#node-key-pair). Similar to the [wallet_propose method][], this method only generates a set of keys in the proper format. It does not any makes changes to the XRP Ledger data or server configuration. _The `validation_create` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._ -You can configure your server to use the generated key pair to sign validations (validation key pair) or regular peer-to-peer communications (node key pair). +You can configure your server to use the generated key pair to sign validations (validation key pair) or regular peer-to-peer communications ([node key pair](peer-protocol.html#node-key-pair)). **Tip:** For configuring a robust validator, you should use the `validator-keys` tool (included in the `rippled` RPM) to generate validator tokens (which can be rotated) with an offline master key. For more information, see [Validator Setup](run-rippled-as-a-validator.html#enable-validation-on-your-rippled-server). diff --git a/content/references/rippled-api/peer-crawler.md b/content/references/rippled-api/peer-crawler.md index bf2351f5d5..e7e8459522 100644 --- a/content/references/rippled-api/peer-crawler.md +++ b/content/references/rippled-api/peer-crawler.md @@ -26,7 +26,7 @@ The JSON object has the following fields: | `Field` | Value | Description | |:-----------------|:-------|:-------------------------------------------------| | `counts` | Object | _(May be omitted)_ Stats about this server's health, similar to the response from the [get_counts method][]. The default configuration does not report this field. Information reported includes: how large the ledger and transaction databases are, the cache hit rate for the in-application caches, and how many objects of various types are cached in memory. Types of objects that may be stored in memory include ledgers (`Ledger`), transactions (`STTx`), validation messages (`STValidation`), and more. | -| `overlay` | Object | Information about the peer servers currently connected to this one, similar to the response from the [peers method][]. Contains one field, `active`, which is an array of objects (see below). | +| `overlay` | Object | _(May be omitted)_ Information about the peer servers currently connected to this one, similar to the response from the [peers method][]. Contains one field, `active`, which is an array of objects (see below). | | `server` | Object | _(May be omitted)_ Information about this server. Contains public fields from the [server_state method][], including what `rippled` version you are running (`build_version`), which [ledger versions](ledger-history.html) your server has available (`complete_ledgers`), and the amount of load your server is experiencing. [Updated in: rippled 1.2.1][New in: rippled 1.2.1] | | `unl` | Object | _(May be omitted)_ Information about the validators and validator list sites this server is configured to trust, similar to the response from the [validators method][] and [validator_list_sites method][]. [Updated in: rippled 1.2.1][New in: rippled 1.2.1] | | `version` | Number | Indicates the version of this peer crawler response format. The current peer crawler version number is `2`. [Updated in: rippled 1.2.1][New in: rippled 1.2.1] | diff --git a/content/tutorials/manage-the-rippled-server/configuration/configure-the-peer-crawler.md b/content/tutorials/manage-the-rippled-server/configuration/configure-the-peer-crawler.md index 4c2c8a4591..14774486c6 100644 --- a/content/tutorials/manage-the-rippled-server/configuration/configure-the-peer-crawler.md +++ b/content/tutorials/manage-the-rippled-server/configuration/configure-the-peer-crawler.md @@ -25,7 +25,7 @@ To configure how much information your server provides in response to peer crawl counts = 0 unl = 1 - The settings in this example represent the default values. A setting with a value of `1` means to share that type of information. A value of `0` means not to share that information. The names of the config fields match the names of the fields they control in the [peer crawler response](peer-crawler.html#response-format). + The fields in this stanza control which fields the server returns in the [peer crawler response](peer-crawler.html#response-format). The names of the config fields match the fields of the API response. A setting with a value of `1` means to include the field in the response. A value of `0` means to omit that field from the response. This example shows the default values for each setting. 3. After saving the changes to the config file, restart your `rippled` server to apply the updated configuration: