mirror of
https://github.com/XeonSquared/OC-Copper.git
synced 2024-11-14 13:58:05 +11:00
9df9823a4f
The implementation in the oc/ subfolder of a hierarchial gateway goes with the "allow subnets to cause higher-level broadcasts, and allow higher levels to cause subnet broadcasts, but don't let messages leak" solution That is, the default if hierarchial gateways have no special handling for broadcast addresses.
57 lines
2.3 KiB
Groff
57 lines
2.3 KiB
Groff
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 "<".
|
|
If it's on the child side, reject if it's prefixed with "<",
|
|
otherwise prefix it with hostname .. "/".
|
|
|
|
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 <]*".)
|
|
|
|
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.
|
|
|
|
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
|