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:
|
|
|
|
|
2017-03-18 23:28:46 +11:00
|
|
|
If it's on the parent side, reject if it's prefixed with hostname .. "/",
|
2017-03-20 11:33:06 +11:00
|
|
|
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 "<",
|
2017-03-20 11:33:06 +11:00
|
|
|
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 .. "/",
|
2017-03-20 11:33:06 +11:00
|
|
|
otherwise remove that.
|
2017-03-21 03:20:52 +11:00
|
|
|
(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 "<",
|
2017-03-20 11:33:06 +11:00
|
|
|
otherwise remove that.
|
2017-03-21 03:20:52 +11:00
|
|
|
(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.)
|
2017-03-20 11:33:06 +11:00
|
|
|
|
|
|
|
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
|