1
0
mirror of https://github.com/XeonSquared/OC-Copper.git synced 2024-11-16 23:08:06 +11:00
OC-Copper/protocol.1

57 lines
2.3 KiB
Groff
Raw Normal View History

2017-03-18 20:34:13 +11:00
Copper Protocol :: Hierarchial Gateways
20kdc, 2017
"Hierarchial Gateways" are a system for ISP-like bodies to prevent their
users from causing havoc.
They are simply base low-level Copper nodes with two interfaces and the
following rules:
For the FROM address:
If it's on the parent side, reject if it's prefixed with hostname .. "/",
otherwise prefix it with "<".
2017-03-18 20:34:13 +11:00
If it's on the child side, reject if it's prefixed with "<",
otherwise prefix it with hostname .. "/".
2017-03-18 20:34:13 +11:00
For the TO address:
If it's on the parent side, reject unless prefixed with hostname .. "/",
otherwise remove that.
(Optionally, if the name is "*", bypass this rule completely.
This is not recommended, though, as this allows sending a "complete broadcast packet" via "[some amount of <]*".)
2017-03-18 20:34:13 +11:00
If it's on the child side, reject unless prefixed with "<",
otherwise remove that.
(Optionally, if the name is "<*", reject anyway.
This is a measure which you may or may not wish to take - if the above 'complete broadcast' possibility has been implemented, then it is a must.)
For the packet's general routing:
If it's on the parent side, run the rules above on the addresses,
and forward to child side if not rejected.
If it's on the child side, run the rules above on the addresses,
and forward to parent side if not rejected.
Notably, the hops field should be incremented as if going through a normal routing node -
this prevents system misconfiguration from causing a complete meltdown.
2017-03-18 20:34:13 +11:00
This introduces a simple hierarchial structure that does not require any
support code apart from in the nodes supporting the hierarchy.
There are only two downsides:
1. Nodes connected to two gateways
could have multiple addresses but believe they only have one
2. Nodes behind two nested gateways can address themselves in two ways
However, this should all work out as long as people make a deliberate
effort not to notice the hierarchial structure system in their code.
Specifically, problem 2 only causes an issue should some nodes not
directly involved in gateway activities be
attempting to parse hierarchial addresses.
Possible uses of hierarchial gateways:
1. A safe (untrusting of servers in it) inter-server networking hub,
following the same protocol as everything else in Copper,
unlike certain competitors
2. ISPs within servers, perhaps those using the hubs