commit c7b0941a60bcc8fb30c00ac0212b70e80ba2cc34
parent 78a4ca8c314f0668d10c9d24a066b8980bc6e9c7
Author: Christian Grothoff <christian@grothoff.org>
Date: Thu, 11 Jul 2024 23:08:41 +0200
add system and security model
Diffstat:
1 file changed, 66 insertions(+), 0 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -1,13 +1,16 @@
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
+<!ENTITY RFC2663 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2663.xml">
<!ENTITY RFC2782 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
+<!ENTITY RFC3561 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3561.xml">
<!ENTITY RFC3629 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC3686 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml">
<!ENTITY RFC3826 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml">
<!ENTITY RFC3986 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4634 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4634.xml">
<!ENTITY RFC5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
+<!ENTITY RFC5245 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY RFC5869 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml">
<!ENTITY RFC5890 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY RFC5891 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml">
@@ -141,6 +144,69 @@
when, they appear in all capitals, as shown here.
</t>
</section>
+ <section numbered="true" toc="default">
+ <name>System Model</name>
+ <t>
+ DHTs usually operate as overlay networks consisting of peers
+ communicating over the existing Internet. Hence canonical
+ DHT designs often assume that the IP protocol provides the
+ peers of the overlay with unrestricted end-to-end pairwise
+ connectivity. However, in practice firewalls and network
+ address translation (<xref target="RFC2663"/>) make it
+ difficult for peers operating on consumer end-devices to
+ directly communicate, especially in the absence of core
+ network infrastructure enabling NAT traversal via protocols
+ such as ICE (<xref target="RFC5245"/>).
+ </t>
+ <t>
+ Furthermore, not all peer-to-peer networks consistently
+ operate over the Internet, such as mobile ad-hoc networks
+ (MANETs). While routing protocols have been designed for
+ such networks (<xref target="RFC3561"/>) these generally
+ have issues with security in the presence of malicious
+ participants, as they vulnerable to impersonation attacks.
+ The usual solution to these issues is to assert that the
+ entire MANET is a closed network and to require
+ authentication on all control messages. In contrast, the
+ system model for R<sup>5</sup>N is that of an open network
+ without any kind of authorities that could restrict access
+ only to trusted participants.
+ </t>
+ </section>
+ <section numbered="true" toc="default">
+ <name>Security Model</name>
+ <t>
+ We assume that the network is open and thus a fraction of
+ the participating peers is malicious. Malicious peers may
+ create, alter, delay or drop messages. We also assume that
+ an adversary can control (or fake) many peers, thus any kind
+ of voting or punishment of malicious peers would be rather
+ pointless.
+ </t>
+ <t>
+ Honest peers are expected to establish and maintain many
+ connections. We assume that as a result the adversary is
+ generally unable to prevent honest peers from maintaining a
+ sufficient number of direct connections with other honest
+ peers to achieve acceptable performance. As the number of
+ malicious peers and their connections increases, performance
+ of the system SHOULD gracefully degrade, and only collapse
+ for peers that an adversary has fully isolated from the
+ benign network.
+ </t>
+ <t>
+ The main security objectives are to provide honest nodes
+ correct results and to limit the propagation of invalid
+ data. Invalid data includes both invalid key-value pairs as
+ well as invalid routing path data if such routing meta-data
+ is present. While malicious nodes may make up arbitrary
+ key-value pairs and paths within the adversary's domain,
+ invalid key-value pairs SHOULD ideally be discarded at the
+ first honest node, and path data MUST honestly state
+ entry- and exit-points from the honest network into the
+ subset of malicious nodes.
+ </t>
+ </section>
</section>
<section anchor="terminology">
<name>Terminology</name>
