Skip to content

Commit

Permalink
Minor edits
Browse files Browse the repository at this point in the history
  • Loading branch information
pulsejet committed Feb 9, 2024
1 parent 0b7af52 commit 0d39d1c
Show file tree
Hide file tree
Showing 4 changed files with 68 additions and 18 deletions.
12 changes: 7 additions & 5 deletions docs/security.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,15 +2,16 @@

!!! warning "This page is under construction."

Security is baked into the core of NDN, and is a fundamental part of the architecture. NDN utilizes a data-centric name-based security model, where every piece of data is signed by its producer. This allows NDN to provide data-centric security, privacy, and trustworthiness. The following sections provide an overview of the security features of NDN.

## Signature

In NDN, every data packet is digitally signed by its producer.
The signature guarantees the _integrity_ of the packet,
because the signature can only be generated by the original producer, and becomes invalid if the encoded packet is modified.
In NDN, every Data packet is digitally signed by its producer.
The signature guarantees the _integrity_ of the packet, because the signature can only be generated by the original producer, and becomes invalid if the encoded packet is modified.

Digital signing is done by a pair of asymmetric keys, which consists of a private key and a public key.
The _private key_ is known only by the producer, used to generate signatures.
Then, anyone who knows the _public key_ can verify the signature.
Anyone who knows the _public key_ can verify the signature.

(Code snippet to be added)

Expand Down Expand Up @@ -61,7 +62,8 @@ An application may involve multiple trust domains. _Inter-domain trust relations
In the case where pure peer-to-peer trust relation is established, every member is its own controller.

!!! info "Trust Zone"
A trust domain isalso called a _trust zone_ in some papers, not to be confused with the hardware trust zone.

A trust domain has also been called a _trust zone_ in some papers, not to be confused with the hardware trust zone.

## Trust Schema

Expand Down
48 changes: 37 additions & 11 deletions docs/storage.md
Original file line number Diff line number Diff line change
@@ -1,20 +1,30 @@
# Storage

!!! warning "This page is under construction."
Persistent storage is a key component of application functionality. In the NDN philosophy, highly available storage is provided as part of the network infrastructure. This allows applications to store data in the network, and to retrieve it from the network, without needing to rely on a separate storage service.

In NDN, there are several kinds of storages, including
- _Content store_: a passive cache configured in all NDN forwarders.
Deployed by NDN network providers.
- _Repo_: a persistent general-purpose storage deployed in the network.
They are deployed and maintained by third party indepenend of the application users or developers.
- _Application storage_: storages used by specific applications.
They are maintained by the software developers and operated by users or service providers.
Generally speaking, there are three kinds of storage services in NDN. We describe each of these in further detail below.

## Content Store (passive cache)
- **Application Storage**: storage used by a particular application instance.
- **Data Repository**: a persistent general-purpose storage deployed in the network.
- **Content Store**: a passive cache configured in all NDN forwarders.

Content store is part of an NDN forwarder. Please see [Forwarding Plane](forwarding.md#content-store).
!!! info "General purpose storage"

## Repo (general persistent storage)
By design, NDN data stores are typically not application-specific, being provided as a service by the network infrastructure. This is in contrast to traditional cloud storage services, which are provided by third-party vendors and require applications to adapt to their specific APIs. Since data is secured independently of the transport and storage, the stored data is always secured at rest and in transit.

## Application Storage

Individual NDN applications typically require local storage for the data at a particular instance. This may include data that has been produced by the application, or data that has been fetched from the network. The application storage is typically managed by the application itself, and is not shared with other applications.

NDN libraries provide APIs for applications to store and retrieve data from local storage using the name. The storage itself may be implemented using memory or disk, and may store either the raw Data packets or the application-specific data structures.

=== "ndn-cxx"

``` c++
--8<-- "snippets/storage/ims.cpp"
```

## Data Repository

Imagine the following scenario: an application uses some public _online storage_ to store its data.
To make sure the online storage stores the data faithfully, every uploaded file is signed.
Expand All @@ -38,3 +48,19 @@ In this scenario, the role of the online storage plays a role similar to a Repo
- Different cloud providers typically cannot collaborate with each other,
and the application developers have to pick some providers and adapt for them.
NDN applications do not have to adapt for specific Repo providers.

## Content Store

The content store is an ephemeral cache in each NDN forwarder in the network, which stores the most recently or frequently requested data. Unlike the other storage types described above, the application does not exercise any control over the data stored in the content store. Further the content store does not provide any guarantess on cache eviction or availability, and thus should not be relied upon for long-term storage.

!!! warning "Data Immutability"

Since any forwarder in the network may cache data for any duration of time, applications must not rely on a given Data packet eventually being unavailable. Each Data packet must be treated as immutable and potentially available forever, and thus names must not be reused.

!!! tip "Clearing the content store"

During application development, the content store may lead to unexpected behavior, e.g. data that has not been produced yet may be available from a previous test run. In such situations, you may want to clear the cache using the `nfdc` command-line tool.

```bash
nfdc cs erase /<prefix> # erase all cached data under a prefix
```
4 changes: 2 additions & 2 deletions mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -25,13 +25,13 @@ nav:
- 'getting-started.md'
- 'packets.md'
- 'communication.md'
- 'forwarding.md'
- 'security.md'
- 'sync.md'
- 'storage.md'
- 'forwarding.md'
- 'routing.md'
- 'testbed.md'
- 'debugging.md'
- 'storage.md'

markdown_extensions:
- admonition
Expand Down
22 changes: 22 additions & 0 deletions snippets/storage/ims.cpp
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
#include <cassert>
#include <ndn-cxx/ims/in-memory-storage-persistent.hpp>
#include <ndn-cxx/security/key-chain.hpp>

int main(int argc, char** argv)
{
// Create an in-memory application-specific storage
ndn::InMemoryStoragePersistent ims;

// Create and sign a data packet
auto data = std::make_shared<ndn::Data>("/test/data");
data->setContent("Hello, World!");
ndn::KeyChain keyChain;
keyChain.sign(*data);

// Insert a data packet into the store
ims.insert(*data);

// Find a data packet in the store
ndn::Interest interest("/test/data");
assert(ims.find(interest)->getName() == data->getName());
}

0 comments on commit 0d39d1c

Please sign in to comment.