netsec-ethz / rains Goto Github PK

Add infrastructure signature to all messages sent between servers

RAINS is designed to be address-family and architecture-independent, and initial work has focused on building out RAINS as an Internet naming service. The codebase and protocol need minor updates to be usable as a naming service for SCION:

Subtasks:

• Add support for a :scionip4: assertion object type, carrying a SCION address as an octet array
• Add support for a :scionip6: assertion object type, carrying a SCION address as an octet array
• Design and build tooling to add RAINS root keys to a SCION TRC
• Integrate verification of the RAINS root key against the SCION TRC into RAINS

The caches are currently not able to lookup an anyContext query.

Implement capabilities according to https://britram.github.io/rains-prototype/#rfc.section.5.15
The cache design must be taken into account, but might be changed.

When a contained assertion or shard is validated it gets dropped in the verify step because it does not yet inherit the signature(s) from its outer section.

When the server or a tool receives a notification section, it logs it but does not further processing.
Implement logic there if needed, especially the capability case.
Capabilities sent in response do not need a notification type, they can be attached to a bare message.

Use #45 instead of the current binary trie implementation and make the number of children per node dependent on a server configuration.

Make it configurable when consistency checks are stopped. Based on what stats is the load of the system/server evaluated.

Design and implement a policy by which the server can decide if it wants to cache the section for
Assertion, Shard, Zone, AddressAssertion, AddressZone.

Currently a random section answering the query is returned.
How to efficiently determine which has the smallest encoding size

Currently all non expired assertions are sent back

An external process must be able to dynamically update the blacklist. I.e. that the server has an up to date blacklist which could e.g. be used to defend against DOS attacks

Instead of loading a hard coded default config and then rewrite parts of it by parsing a json encoded config file, we should create a cmd line interface where these values are the flags' default value.

Add a clock synchronization protocol to the rains server.

We currently have a binary trie data structure. Make it generic and use a n-trie where n is configurable

Currently cap'n'proto is used.

We want to remove the dependency between wire and signing format.
We use capnproto to binary encode a rains message before we send it over the wire. The capnproto schema must be refined and a library (which uses capnproto's encode and decode) to encode and decode must be implemented.

First the caches for reverse lookup must be refactored. #45, #46, #47

Decide which consistency checks MUST be done at run time by the server and which SHOULD be analyzed by a separate service (which then must be able to take appropriate actions, e.g. remove elements from the server's cache, blacklist an entity, etc.)
Implement/refactor consistency checks
Shard's and Zone's content are sorted. We do not have to sort them for consistency checks but only check that they are really sorted (if not drop the section and send a msgInconsistent notification back).

Change the way how we read in the config file represented as json.
Do not directly read the input into the internal object.

1. Read in values
2. Copy/Cast them to the internal representation.

engine.containedAssertionQueryResponse()

Because we only accept sections from servers and rainspub we need to be able to distinguish them. How can we do that? (for rainspub we can configure it manually but how do we handle other servers?)

Move examples and test servers to a different folder or repo.
There should be an interface where one can specify which kind of servers are wanted and then they get automatically started.

Right now the system can only handle 1 (the first) object per assertion although one could add several. Make it work also for multiple objects per assertion. Be aware that the cache implementation must also be changed.

Design and Implement a high bandwidth airgapping mechanism to sign elements of a zone file.

This includes how Tokens are handled by the server (if they are stored in a cache or not), which determines prioritization of packets and dropping in case of congestion

Implement engine.handleAddressZoneQueryResponse()

"Reverse lookups are done using a completely separate tree, supporting delegations of any prefix length, in accordance with CIDR [RFC4632] and the IPv6 addressing architecture [RFC4291]" [1]
Also look at section 5.8-5.10
[1] https://britram.github.io/rains-prototype/#introduction

Use the zone file format to output received messages in the command line

Currently only a section from a message containing the same token as the query message triggers the pending query callback function. Extend the behavior such that an unrelated section also answering the query can be used to directly send the response back

Currently assertions are sorted and then split up in groups of a configurable size.
The size is currently per assertion instead of per assertion name. This must be changed. Otherwise if there are more assertions of a name than the configured size, they will always be rejected.

Write down which operations are necessary for which cache and how performance critical they are.
Which replacement strategy we choose for each.
Find data structures that fit our needs.

The server's ip blacklist should be updated in real time and only messages originating from different addresses are forwarded in the switchboard

implement using #45 and add it to the server

Document which ports we use and why

Right now we are only able to verify signatures from the global context. Implement methods to extract the authority from the context field and verify the signature(s) against it.

Currently a random connection information is chosen from the redirection cache

Description should be generated from internal constants.
We also want string mnemonics for query options on the command-line.