Hi,
We have been thinking about some new dstar system too.
We had the following idear:
1. Use a VPN network with multiple (failover) servers to connect to, linked
together, geographically spread out. This enables us to create a private
network on top of the internet or any other network medium that can
encapsulate the VPN. We think about using OpenVPN.
2. Ip addresses. Every repeater gets a subnet inside the 10/8 network, this
can be organised as the 44/8 was. Maybe we can even use the 44/8 instead of
10/8 to not interfere with existing networks inside a 10/8
3 Authentication; Radio users do not authenticate, since as you stated, the
callsign is send in cleartext and can be forged by a "pirate. A user
entering the network via RF is thus always trusted. Systems linked over the
internet, must connect to the VPN. To do this you need a valid certificate.
This certificate has to be requested at a central (or multiple) location who
verify that you have a valid license. With this certificate a repeater or
DV-dongle user can connect to the network. This is the 'trust'.
4. Multiple (failover) DNS servers linked together, geographically spread
out, who map callsigns and reflector calls to an IP address within the
subnet of the repeater. The repeaters send updates to these dns servers with
the most recent ip adres of the station. (low TTL)
5. Routing between the repeaters should be done like a BGP system, the
repeater anounces its subnet to the network and the rest of the network
automagicly knows how to reach it. this can even use the real BGP protocols.
This also allows using other networks as 10/8 as long as they are unique
inside the network. (eg in a special case you could use a subnet inside
192.168 or 172
6. Callsign routing; whenever you put a callsign in UR, the system looks up
the IP address of the other station and determines how to route to the
repeater that has this callsign. Then it sends its DV stream to that
repeater.
7. compatibility to the old network (trust servers) can be done by having 1
(or multiple regionally) public IP that acts like a classic G2 with multiple
repeaters.
8. instead of having a lot of different reflector servers the network has a
system comparable to IRC: You have a small network of IRC servers that
contain Channels. In the dstar variant we would have linked reflector 'hubs'
that contain 'channels' (the classic reflectors). Everybody can register a
reflector, but if it hasn't been used for xxx days it might expire. These
reflectors can also be 'made' on the fly, without any setup needed, and can
be perfect for temporary use.
9. local networks (in belgium, most repeaters are linked via a 5ghz wifi
network) should run their local vpn server/reflector hub linked to the rest
of the vpn so that if there is a disaster and internet gets disconnected,
the system is able to run locally as long as the local network still works.
10. the software that does all this should also be able, next to talking to
an ICOM repeater, to also talk to a GSMK node adapter so that its easy to
setup a new repeater.
11. Everything should be lightweight so that it can be run on low-power pc's
(like an PCEngines Alix 800Mhz 128Mb PC)
12. Distro should be free to choose. Debian, Gentoo, Centos, Mandrake,
Ubuntu, whatever, ...
13. Everything has to be CLI based.
these are just our ideas. If you are serious about developing something like
you say, I think we best startup some sort of workgroup and combine the best
ideas. We really like the VPN idea as it offers natural authentication that
is proven to work. The (open)VPN setup can be implemented in the software.
Our preffered language would be Java. I see in your code snipped that you
prefer this too.
Let me (us) know what you think.
73s
Robbie ON4SAX
On Tue, Mar 9, 2010 at 8:59 PM, John Hays <j...@hays.org> wrote:
>
>
> I have been doing a lot of thinking about a new D-STAR Architecture (and
> hope to provide some more concrete material at some point), but this
> discussion brings up some basic ideas that have been percolating in my
> ruminations.
>
> Icom started from a different model than community usage patterns suggest
> is the proper way to do things.
>
> Here are some of the design principles that I think are important:
>
> 1 - Internet connected devices need an easy mechanism for discovery - use
> Secured Dynamic DNS. (Set TTLs based on likelihood of IP Address changes
> (static IPs have very long TTLs, dynamic TTLs very short)
> 2 - Have a low latency, redundant and reliable service to map
> radio/repeater/simplex node/gateway/service Callsign Addresses to DNS names.
> Maybe something like a Cassandra (Apache) cluster. (Use caches on local
> boxes for the "working set of callsigns" that a local system needs, don't
> copy full databases around.)
> 3 - User authentication - completely eliminate registration for RF devices
> that use Callsigns, since Callsign Addresses are sent "in the clear" anyone
> can forge them (pirate the callsign) and pretend that it is a control
> mechanism is ludicrous. Use of false / pirated callsigns is illegal in
> most, if not all, countries. Legal prosecution for false callsigns is
> probably a better deterrent than a silly "registration" system. A fairly
> simple regular expression could filter "MY" callsigns to make sure they at
> least look like a legitimate callsign, here is a Java Example/Test code for
> callsign checking, including a mark for VK foundation licenses (who are not
> permitted to use D-STAR):
>
> import java.io.BufferedReader;
>
> *import java.io.IOException;
> import java.io.InputStreamReader;
> *
>
> *public class DstarCallsignCheck {
> *
>
> * public static void main(String[] args) {
> *
>
> * BufferedReader stdin = new BufferedReader(new
> InputStreamReader(
> System.in));
> String foundation = "^VK[0-9]F[A-Z]{3}.*$"; // Australian
> Foundation Class *
>
> *
>
> String DstarCallsign8c =
> "[A-Z0-9]{1}[A-Z0-9]{0,1}[0-9]{1}[A-Z ]{4,8}
> [A-Z 0-9]{0,1}|CQCQCQ |REF[0-9]{3}[0-9 ]{1}[A-Z 0-9]$";
> *
>
> * while (true) {
> try {
> System.out.print("Callsign: ");
> String call =
> stdin.readLine().toUpperCase();
> while (call.length() < 8) call += " "; //
> Space end padding.
> System.out.println("[" + call + "] " +
> call.length());
> if (call.length() != 8)
> System.err.println("Call must be
> exactly 8 characters"); *
>
> * // too long of callsign
> else {
> System.out.println("D-STAR Call "
> +
> (call.matches(DstarCallsign8c) && ! call.substring
> (0,2).matches("\\d{2}")));
> System.out.println("VK Foundation
> Class Call "
> +
> call.matches(foundation));
> }
> } catch (IOException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> }
> *
>
> * } *
> *} *
>
> 4. Authorization - some system operators will want to control access to
> their radio receiver and transmitter based on user callsigns, provide
> filters in the "gateway" to enable them to have access and deny lists.
> These lists could include, by reference, databases such as are found in the
> G2 "terminal registration", national callsign databases, regional databases,
> and local databases/hashtables for local control. (Those of you who believe
> in "registration" could filter out anyone who was not in one of these
> databases.)
> 5. Callsign routing. It is basic to the protocol and should always be
> permitted. (It may be necessary to "barge in" on a linked repeater for
> emergency or other timely traffic) A gateway/repeater could be designed to
> relay (with buffering) the incoming callsign routed transmission and send an
> automatic reply to the sender informing them of the "linked" or other
> service running that they might be disrupting.
> 6. Linking. All linking should be through a robust and dynamic "reflector"
> system. Even two repeaters should use a reflector to allow a third repeater
> to join the conversation.
> 7. Regional linked systems should be treated as a single gateway by the
> rest of the network, sort of like a super repeater.
> 8. Pure Internet/Non-RF devices (like the DV-Dongle) should have a strong
> authentication/authorization service, but then be treated like peers on the
> network. (Some sort of list of callsigns could be provided by the service
> and used in #4 above to allow or deny them access to a given
> gateway/repeater.)
>
> I have a lot more implementation ideas, and other enhancements, but these
> are the fundamentals. Well known interfaces would permit different authors
> to write the various components.
>
>
> John D. Hays
> Amateur Radio Station K7VE <http://k7ve.org>
> PO Box 1223
> Edmonds, WA 98020-1223
> VOIP/SIP: j...@hays.org
> Email: j...@hays.org
>
>
>
