-
Notifications
You must be signed in to change notification settings - Fork 13
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Ref: #60
- Loading branch information
Showing
5 changed files
with
114 additions
and
47 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
Overall | ||
======= | ||
|
||
The repo is considered as part of the NDN network infrastructure. | ||
Therefore, when deployed for production, | ||
the security requirements are supposed to be specified by the authority, | ||
such as the network operator or the project manager. | ||
|
||
For development deployment or internal use, the settings described in this section are recommended. | ||
|
||
Required Settings | ||
----------------- | ||
|
||
- All Interests with application parameters are required to be signed. Otherwise the Repo must drop the Interest. | ||
Currently including the check Interest ``/<repo_name>/<command> check`` and the publication notification Interest | ||
``"/<topic>/notify"``. | ||
- Check Interests are required to have at least one of ``SignatureTime``, ``SignatureNonce``, or ``SignatureSeqNum``. | ||
Otherwise, Check Interests' result is undefined behavior. | ||
This is to make sure these check Interests are different to avoid cache invalidation. | ||
|
||
.. warning:: | ||
Unfortunately current implementation does not follow these requirements by default. | ||
This may cause some potential vulnerbilities. Will be fixed in future versions. | ||
|
||
|
||
Recommended Settings | ||
-------------------- | ||
|
||
- Packet signatures should be signed by asymmetric algorithms. Use ECDSA or Ed25519 when in doubt. | ||
- Signed Interests should use ``SignatureNonce``. | ||
|
||
- Since there is no replay attack, the Repo does not have to remember the list of ``SignatureNonce``. | ||
|
||
- If the Repo is provided as a network service, the certifcate obtained from the network provider should be used. | ||
In this case, the prefix registration command and repo's publication data are signed using the same key. | ||
|
||
- For example, if one employs a Repo as a public service of NDN testbed, | ||
then both the client and the Repo server should use their testbed certificates. | ||
- The Repo should use the same verification method as its local NFD node to verify the register. | ||
- The client should use the same verification method as how it verifies the prefix registration command. | ||
|
||
- If the Repo is provided as an application service, it should either obtain an identity from the application namespace, | ||
or runs on its own trust domain and holds the trust anchor. | ||
In this case, the prefix registration command and repo's publication data are signed using different keys. | ||
|
||
- In this case, the Repo is supposed obtain the trust schema when it is bootstrapped into the application's namespace. | ||
If it is unable to obtain the trust schema, it should maintain a user list to verify the clients. | ||
The client should do similar things. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
Joining SVS Sync (Draft) | ||
======================== | ||
|
||
- Joining SVS Sync group is an optional feature. It should only be enabled when it is deployed as a network service. | ||
|
||
- If the Repo is deployed as an application service, | ||
the application deployer should run another process on the same node as an SVS peer and use the Repo only for Data. | ||
|
||
- The Repo should not join an application's SVS sync group as a producer. | ||
(unless the sync group is specifically designed for Repos to backup data) | ||
|
||
- The Repo should learn how to verify the target SVS group's Sync Interest. | ||
|
||
- The Repo should store its received latest SVS notification Interest as is, | ||
and responds with this Interest when it hears some out-of-dated SVS vector. | ||
|
||
- If there are multiple latest SVS state vectors, e.g. ``[A:1, B:2]`` and ``[A:2, B:1]``, | ||
the Repo will not be able to merge them into ``[A:2, B:2]``. | ||
Instead, it should respond with both stored Interests eventually. | ||
Maybe all at once, maybe one at one time. Not decided yet. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters