hamlib-stationserver — Discussion of station server a possible successor to rigctld/rotctld

[Hamlib-stationserver] Terminology

[Nate B. <n0...@n0...>]

In some of the threads I have noted a bit of confusion.  Some of that
may be a "here" thing.  :-D

Of note, it may be helpful to discern between clients and users.  If we
can agree on the following, it should help in further discussion:

Client -- a program that exchanges data with Stationserver.
User --	a person using one of more clients.

At a minimum Stationserver should be designed to manage data between
multiple clients and handle contention between those clients and the
physical device.

Multiple users may require some higher level handling but at their
simplest would appear as multiple clients to Stationserver.  At some
point it may be necessary to discern users/clients as opposed to only
clients.

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

Re: [Hamlib-stationserver] Domain Object Outline: What's in a Station?

[Nate B. <n0...@n0...>]

For some reason my mail program has this message threaded into a prior
thread.  Oh well.  :-)

* On 2014 05 Mar 14:07 -0600, Art Botterell wrote:
> OK, we're starting to get into the tall grass now... not complicated,
> really, just a lot of detail.  And an outline isn't really adequate to
> describe all the details.  Still, before we start drawing UML diagrams
> maybe we can do an initial scope-check.  
> 
> So... here for discussion is a first, top-level and partial, draft for
> discussion of what logical objects we'll need to support in
> StationServer:

This looks complete enough for a good start.  I will note that there
will be requests for certain device specific readings/settings and
provision will need to be made for that.  For example, the K3 has a read
only parameter that gives the  IF center frequency which changes when
the operator uses the Shift control.  This may not seem important but I
know of at least one Hamlib client program that uses this to center an
SDR band scope display.

It seems that one cannot think of everything initially.  Sigh...

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Art B. <ac...@in...>]

On Mar 6, 2014, at 3:33 PM, Tony Langdon <vk...@gm...> wrote:
> I should have said a single user system was my original vision (as 
> documented online late last year). :)

Tony, I have no desire to vandalize your vision... but I didn't realize we were building this just for you!  So what do you need, exactly?

> I see where this came from.  My suggestion was that clients could have 
> the ability to temporarily lock other connected clients out of changing 
> radio settings, so they could perform critical operations (e.g. 
> satellite antenna and Doppler tracking) without being interrupted by 
> stray requests from another client.

Guess I'm not clear on why multiple clients would be interfering in a single-user system.  Is it possible we're really talking about a process priority issue?

- Art KD6O

Re: [Hamlib-stationserver] Access Control (was Re: Updated Requirements Doc)

[Tony L. <vk...@gm...>]

On 7/03/2014 9:06 AM, Art Botterell wrote:
> OK, so how about if we:
>
> * Chang F-1 to read "... in response to queries from the client application(s) over a single IP-based Local Area Network."
>
> * Change F-2 to read "...to the client(s) both spontaneously and in response to queries from the client over a single IP-based Local Area Network."
>
> * Change F-3 to read, "...over a single IP-based Local Area Network."
>
> * Change F-4 to read "Enable the user to change settings and activate functions of connected radios and ancillary devices.";
>
> * Trim F-6 to just say "Support multiple simultaneous client connections." (dropping the whole business of different user identities and access privileges);
>
> * Drop F-7 entirely (no authentication or user identities);
>
> * Drop N-3 entirely (no encryption); and,
>
> * Add a note stating that "Users in order to maintain the required control of Amateur Radio stations by a licensed operator, remote StationServer conenctions across multiple networks or the Internet should be implemented using a Virtual Private Network or some other scheme for encryption and secure routing."

OK, this one works for me.

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Tony L. <vk...@gm...>]

On 7/03/2014 9:17 AM, Art Botterell wrote:
> Respectfully, Tony, Stationserver is intended to be whatever we decide it should be.  Each of us have personal preferences, but I'm not sure any of us should try to dictate.  This is a collaboration... at least I hope it is... and the requirements document is labeled "draft for discussion."
I should have said a single user system was my original vision (as 
documented online late last year). :)
>
> Of course you can write your own code any way you like.
>
> Anyway, the multi-user requirement sprang from what I thought was your suggestion that different client connections should have different capabilities.  But we can certainly drop it if that's the consensus of the folks who speak up.
I I see where this came from.  My suggestion was that clients could have 
the ability to temporarily lock other connected clients out of changing 
radio settings, so they could perform critical operations (e.g. 
satellite antenna and Doppler tracking) without being interrupted by 
stray requests from another client.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: [Hamlib-stationserver] Updated Requirements Doc

[Tony L. <vk...@gm...>]

On 7/03/2014 9:21 AM, Art Botterell wrote:
> Oops, Tony, our notes passed each other in the mail.  Anyway, your note accurately describes at least on aspect of the dilemma, but I'm not sure what you're recommending.
>
> Maybe some other folks on the list would like to add some additional perspectives.
As I said, I'm undecided.  My original vision was for the core system to 
be focused on network aware rig abstraction, and not deal with users and 
authentication, and have those who need such facilities install an 
add-on module to offer these facilities (i.e. a remote base scenario).

I was just thinking out loud and could see where you're coming from Art, 
and I could see scenarios where an entity (most typically a club, but 
could be friends) might offer hams remote access to their station on a 
different level to that offered by a remote base (might be an issue for 
data modes).  However, thinking again, a well written remote base add-on 
might still fit the bill better, and offer a full range of user 
management and access control capabilities, so I'm leaning back towards 
no access control in the core of Stationserver (i.e. your latest 
revision to the specs).

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: [Hamlib-stationserver] Updated Requirements Doc

[Art B. <ac...@in...>]

Oops, Tony, our notes passed each other in the mail.  Anyway, your note accurately describes at least on aspect of the dilemma, but I'm not sure what you're recommending.

Maybe some other folks on the list would like to add some additional perspectives.

- Art KD6O


On Mar 6, 2014, at 2:15 PM, Tony Langdon <vk...@gm...> wrote:

> On 7/03/2014 2:07 AM, Art Botterell wrote:
>> A small update is online at <http://sourceforge.net/projects/hamlib/files/stationserver/documents/requirements/StationServer%20Requirements%20DRAFT%202.pdf/download>
>> 
>> I hope everyone who can will take a few minutes to look it over and comment.
> The thing that caught my eye here was the reference to multiple users.  
> I don't believe it's the job of Stationserver to handle multiple users.  
> I envisaged it as a single user system, with multiple user capabilities 
> being provided by an add-on, such as a remote base add-on, which would 
> handle all the multiple user requirements such as authentication and 
> access control.
> 
> Thinking again though, there may be a use for a (very basic) user 
> authentication mechanism.  The question is whether this is best 
> implemented by default (which would be a nuisance for a single user 
> shack, and especially annoying in the case of someone who runs clients 
> and servers on the one PC - though localhost could always be given 
> permission), as an optional switch or as an add-on.
> 
> I'm somewhere between not having multiuser capability in the core 
> product or having it available via a configuration option, and only a 
> basic set of access controls at this level.  One of the assumptions here 
> is that one entity still manages the entire system - whether that be an 
> individual or a club, and there is a reasonable expectation of a degree 
> of trust and personal knowledge of the users (i.e. regularly in face to 
> face contact and can be personally validated).  If this trust isn't 
> there, then we have a remote base situation.
> 
> -- 
> 73 de Tony VK3JED/VK3IRL
> http://vkradio.com
> 
> 
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works. 
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Hamlib-stationserver mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-stationserver

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Art B. <ac...@in...>]

On Mar 6, 2014, at 2:01 PM, Tony Langdon <vk...@gm...> wrote:
>  Stationserver is not intended to be multi user aware.  
> It's for controlling a single station by a single person, so giving 
> every connection full privilege makes perfect sense here. Multi user 
> capabilities (validation, user auhentication, access control, etc) are 
> best left to an optional remote base add-on.

Respectfully, Tony, Stationserver is intended to be whatever we decide it should be.  Each of us have personal preferences, but I'm not sure any of us should try to dictate.  This is a collaboration... at least I hope it is... and the requirements document is labeled "draft for discussion."

Of course you can write your own code any way you like.

Anyway, the multi-user requirement sprang from what I thought was your suggestion that different client connections should have different capabilities.  But we can certainly drop it if that's the consensus of the folks who speak up.

- Art KD6O

Re: [Hamlib-stationserver] Updated Requirements Doc

[Tony L. <vk...@gm...>]

On 7/03/2014 2:07 AM, Art Botterell wrote:
> A small update is online at <http://sourceforge.net/projects/hamlib/files/stationserver/documents/requirements/StationServer%20Requirements%20DRAFT%202.pdf/download>
>
> I hope everyone who can will take a few minutes to look it over and comment.
The thing that caught my eye here was the reference to multiple users.  
I don't believe it's the job of Stationserver to handle multiple users.  
I envisaged it as a single user system, with multiple user capabilities 
being provided by an add-on, such as a remote base add-on, which would 
handle all the multiple user requirements such as authentication and 
access control.

Thinking again though, there may be a use for a (very basic) user 
authentication mechanism.  The question is whether this is best 
implemented by default (which would be a nuisance for a single user 
shack, and especially annoying in the case of someone who runs clients 
and servers on the one PC - though localhost could always be given 
permission), as an optional switch or as an add-on.

I'm somewhere between not having multiuser capability in the core 
product or having it available via a configuration option, and only a 
basic set of access controls at this level.  One of the assumptions here 
is that one entity still manages the entire system - whether that be an 
individual or a club, and there is a reasonable expectation of a degree 
of trust and personal knowledge of the users (i.e. regularly in face to 
face contact and can be personally validated).  If this trust isn't 
there, then we have a remote base situation.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

[Hamlib-stationserver] Access Control (was Re: Updated Requirements Doc)

[Art B. <ac...@in...>]

On Mar 6, 2014, at 8:21 AM, Nate Bargmann <n0...@n0...> wrote:
> Perhaps it is my inexperience of working with these security blocks that
> forms my thoughts.  I'm not sure that Station Server should be concerned
> with handling those protocols internally.  

OK, so how about if we:

* Chang F-1 to read "... in response to queries from the client application(s) over a single IP-based Local Area Network."

* Change F-2 to read "...to the client(s) both spontaneously and in response to queries from the client over a single IP-based Local Area Network."  

* Change F-3 to read, "...over a single IP-based Local Area Network." 

* Change F-4 to read "Enable the user to change settings and activate functions of connected radios and ancillary devices.";

* Trim F-6 to just say "Support multiple simultaneous client connections." (dropping the whole business of different user identities and access privileges);

* Drop F-7 entirely (no authentication or user identities);

* Drop N-3 entirely (no encryption); and,

* Add a note stating that "Users in order to maintain the required control of Amateur Radio stations by a licensed operator, remote StationServer conenctions across multiple networks or the Internet should be implemented using a Virtual Private Network or some other scheme for encryption and secure routing."

- Art KD6O

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Tony L. <vk...@gm...>]

On 7/03/2014 2:48 AM, Art Botterell wrote:
> It could.  However, that gets back to an underlying requirement, the one for the ability to have multiple client connections with varying levels of privilege (read-only, read-write, admin, etc.)  That varying-levels bit implies being able to verify who's who, else the distinction is pointless... much simpler just to make every connection full-privilege.
I agree here.  Stationserver is not intended to be multi user aware.  
It's for controlling a single station by a single person, so giving 
every connection full privilege makes perfect sense here. Multi user 
capabilities (validation, user auhentication, access control, etc) are 
best left to an optional remote base add-on.
> Yes, that's why I suggested an established, state-of-the-art package like OpenVPN rather than a "roll your own" approach.  It's a turnkey solution, no programming involved, and it's been refined and vetted over a number of years by actual security boffins.  I'd encourage folks to learn about it, if only as another tool in the toolkit.
It is a good package.  I used to use it for VPNs years ago, when I had a 
need for a true VPN - for connecting LAN segments together, as well as 
individual mobile users to the LAN.  The only reason I don't use it 
today is I have inbuilt IPSec support at both ends (router and mobile 
devices), and the router doesn't support OpenVPN - I'd have to install 
it on the one Linux netbook that runs 24x7.  So I am quite familiar with 
OpenVPN and would highly recommend it.
>
> But again... and I'll say it one last time and then give up... using a VPN is about much more than just security.
Well, if we decide to go the mandatory OpenVPN route, we should have the 
Stationserver installer (1) make sure OpenVPN is installed and 
functional, and (2) configure it on the server and clients so it "just 
works" with minimal effort.  While OpenVPN is relatively easy to 
configure, networking tends to baffle most hams, so the more we can do 
for end users, the better.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: [Hamlib-stationserver] Licensing (was Re: Updated Requirements Doc)

[Nate B. <n0...@n0...>]

* On 2014 06 Mar 11:46 -0600, Art Botterell wrote:
> In a separate conversation with Bruce last week he mentioned... and
> from my experience I certainly agree... that rightly or wrongly the
> letters "GPL" are something of a poison pill as far as some potential
> commercial adopters are concerned.  

Yes, this is true

> For what it's worth, we went through all this last year at Carnegie
> Mellon Silicon Valley... the University preferred the permissive MIT
> or Mod-BSD licenses for a variety of reasons, one of which was that
> they relieved the copyright holder of any need to monitor or litigate
> with (or on behalf of) adopters in the future.

Now that is a point that in all the years of commentary over licenses I
do not recall being argued by the arm chair attorneys.  My initial
reaction is that it is inded valid, and may well be the most valid point
for using the more permissive license.

> > Conversely, the utilities included in Hamlib ((rig|rot)ctl[d]) are
> > licensed under the GPL 2.0, for all that entails.
> 
> Which is arguably slightly less that totally Libre, in that it
> prohibits incorporating the code into a differently-licensed
> derivative.  (Indeed, we might be in that box now ourselves, depending
> on how we integrate hamlib moving forward.)  

So long as the C API is used, no issue.  I favor the track that Hamlib
is a short term solution to have access to a lot of radio definitions.
As a native definition method matured the reliance on Hamlib should
disappear.

> Such a restriction might be ideologically correct, but it puts a hurt
> on some folks' business models.  The risk is that in hopes of keeping
> the software rigorously "open" we might inadvertently drive it into an
> evolutionary dead-end.

I'm not too worried about this unless it is probable that our
implementation would be incorporated directly into some
product/software.  I suppose it could happen.

> > The MIT/BSD license was mentioned early on and I honestly do have a
> > bit of heartache about that.  Perhaps some of that is unfounded.  I
> > have always likened those licenses to "throwing it over the wall"
> > where anyone can pick up one's work and run with it in any direction
> > with little obligation other than the license notice.  
> 
> Perhaps you could expand a bit on what you see as being wrong with
> that?

Probably just my perspective due to my leaning more toward the FSF/GPL
stance.

> Personally, my only concern is to make sure nobody can charge rents or
> obstruct progress by taking our code hostage and restricting others'
> freedom to use it and build on it.  And of course attribution is nice
> for the reputation value.

I recall the famous, "Embrace, Extend, Extinguish" meme.  To be fair, I
don't think that would be much of a threat in the ham radio software
space.

> But do I actually plan to spend the rest of my life monitoring and
> litigating over this stuff?  Naah... life's too short and technology
> advances too rapidly.*  Document the prior art and move on!
> 
> But that's just me. ;-)
> 
> - Art KD6O
> 
> * Actually... from an interoperability and public-benefit perspective
> I've come to the conclusion that open interface standards and
> protocols are more important and much more durable than open code.
> Hardware platforms and software frameworks have a relatively short
> half-life.  It's the interface standards that tend to persist, and
> they're what enables future technology evolution (the archetypical
> example being the Internet Protocols.)   But again, that's just my
> opinion.

I'm in full agreement.

There is the saying, "The authors choose the license."  I doubt I will
contribute much code, so the MIT/BSD license is acceptable to me.

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

[Hamlib-stationserver] Licensing (was Re: Updated Requirements Doc)

[Art B. <ac...@in...>]

In a separate conversation with Bruce last week he mentioned... and from my experience I certainly agree... that rightly or wrongly the letters "GPL" are something of a poison pill as far as some potential commercial adopters are concerned.  

For what it's worth, we went through all this last year at Carnegie Mellon Silicon Valley... the University preferred the permissive MIT or Mod-BSD licenses for a variety of reasons, one of which was that they relieved the copyright holder of any need to monitor or litigate with (or on behalf of) adopters in the future.

> Our philosphy for the library has been that we don't wish to
> dictate terms beyond that of assuring that the library source code
> remain Free (Libre) Software.

Exactly... 

> Conversely, the utilities included in Hamlib ((rig|rot)ctl[d]) are
> licensed under the GPL 2.0, for all that entails.

Which is arguably slightly less that totally Libre, in that it prohibits incorporating the code into a differently-licensed derivative.  (Indeed, we might be in that box now ourselves, depending on how we integrate hamlib moving forward.)  

Such a restriction might be ideologically correct, but it puts a hurt on some folks' business models.  The risk is that in hopes of keeping the software rigorously "open" we might inadvertently drive it into an evolutionary dead-end. 

> The MIT/BSD license was mentioned early on and I honestly do have a bit
> of heartache about that.  Perhaps some of that is unfounded.  I have
> always likened those licenses to "throwing it over the wall" where
> anyone can pick up one's work and run with it in any direction with
> little obligation other than the license notice.  

Perhaps you could expand a bit on what you see as being wrong with that?   

Personally, my only concern is to make sure nobody can charge rents or obstruct progress by taking our code hostage and restricting others' freedom to use it and build on it.  And of course attribution is nice for the reputation value.  

But do I actually plan to spend the rest of my life monitoring and litigating over this stuff?  Naah... life's too short and technology advances too rapidly.*  Document the prior art and move on!

But that's just me. ;-)

- Art KD6O

* Actually... from an interoperability and public-benefit perspective I've come to the conclusion that open interface standards and protocols are more important and much more durable than open code.  Hardware platforms and software frameworks have a relatively short half-life.  It's the interface standards that tend to persist, and they're what enables future technology evolution (the archetypical example being the Internet Protocols.)   But again, that's just my opinion.

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Nate B. <n0...@n0...>]

* On 2014 06 Mar 09:51 -0600, Art Botterell wrote:
> But again... and I'll say it one last time and then give up... using a VPN is about much more than just security.

Thanks Art.

I know a broached this subject again in my reply about the requirements
document so no need to rehash it all there again.  :-)

As I stated in that reply, I can be convinced for a good use case and
again, it's my inexperience showing, not opposition.

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

Re: [Hamlib-stationserver] Updated Requirements Doc

[Nate B. <n0...@n0...>]

A few thoughts.

First off, nicely done, Art.

Regarding licensing of future source code.  I have long been in the
GPL/LGPL camp so that is my perspective.  So far we have had good
experience with the LGPL 2.1 for Hamlib.  As Hamlib is a library that
clients link to, either dynamically or statically, certain legal issues
come into play (I'm no expert and will defer to Bruce Perens or the Free
Software Foundation (FSF)).  Using the LGPL draws the "viral" nature of
the GPL at the line of linking to the published API.  This allows
clients with licensing incompatible to the standard GPL to still use
Hamlib.  Our philosphy for the library has been that we don't wish to
dictate terms beyond that of assuring that the library source code
remain Free (Libre) Software.

Conversely, the utilities included in Hamlib ((rig|rot)ctl[d]) are
licensed under the GPL 2.0, for all that entails.

The FSF also offers the Affero GPL for network servers.  I have not ever
investigated it deeply and as Station Server will likely be its own
program/project separate and distinct from Hamlib at some future date,
it needs to have its source code licensed in the manner that is best for
it (I think there is probably unanimous agreement on that point).

The MIT/BSD license was mentioned early on and I honestly do have a bit
of heartache about that.  Perhaps some of that is unfounded.  I have
always likened those licenses to "throwing it over the wall" where
anyone can pick up one's work and run with it in any direction with
little obligation other than the license notice.  I like the LGPL as it
doesn't dictate terms to downstream clients while dictating terms to
everyone equally for the actual source code of the project.  My quick
glance is that the AGPL is much like the LGPL as I have no care how
clients communicating to SS over a network interface are licensed.

I think we should request Bruce's input on this matter.


Regarding points F-3, F-4, F-7, and N-3, authentication, passwords, and
encryption.

Perhaps it is my inexperience of working with these security blocks that
forms my thoughts.  I'm not sure that Station Server should be concerned
with handling those protocols internally.  Working well with secure
tunnels and providing documentation for doing so seems like it would
relieve the project of a lot of concerns.  There is a lot on our plate
already just dealing with the core functionality of the project (I've
already got five gazillion passwords to deal with, I don't think I want
to have to enter one each time I fire up the logger).  I can be
convinced otherwise on this matter, however.


Those are my main thoughts on where we are at the moment.  Everything
else looks like a good goal.

73, de Nate >>


-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Art B. <ac...@in...>]

On Mar 6, 2014, at 4:15 AM, Nate Bargmann <n0...@n0...> wrote:
> As opposed to OpenVPN, how does an SSH tunnel compare?  

SSH tunnels need to be set up individually, one for each data connection (the control and one or more content channels) and all they buy you is encryption.  They don't help with routing or firewall issues and don't bundle the complete network interface into a single identifiable network connection.  They also require that the remote user has at least some system-level privileges on the server.  As far as encryption strength goes they're comparable.

> In other words, is authentication/encryption necessary in Station
> Server?  Could this be handled by a recommended "best practice" for
> a OpenVPN/SSH tunnel by those interested in doing so?  

It could.  However, that gets back to an underlying requirement, the one for the ability to have multiple client connections with varying levels of privilege (read-only, read-write, admin, etc.)  That varying-levels bit implies being able to verify who's who, else the distinction is pointless... much simpler just to make every connection full-privilege.  

And if we're going to distinguish between sessions that means having some sort of shared-secret identity token... a password is the most common, although a shared key (certificate) also works... and it's never good practice to be passing such "secrets" around a network in the clear, even on a LAN.  (I'd point to pretty much any recent day's headlines for examples of what happens when security gets postponed or tossed onto the too-hard stack.)

The existing hamlib is a processor-centered design that does everything inside a single box.  If we want to move to a network-based client-server model we're going to need to learn some new tricks.  Otherwise, we're just refactoring the existing code... which may be a good exercise, albeit a less interesting one.

Anyway, this is a good discussion to be having, and I hope folks will read the requirements document and consider each point carefully, as that's really the stage where we want to define project scope so as not to spin our wheels further down the road.

> I'd rather leave
> security to those who understand it well (I don't understand it well at
> a programming level).

Yes, that's why I suggested an established, state-of-the-art package like OpenVPN rather than a "roll your own" approach.  It's a turnkey solution, no programming involved, and it's been refined and vetted over a number of years by actual security boffins.  I'd encourage folks to learn about it, if only as another tool in the toolkit.

But again... and I'll say it one last time and then give up... using a VPN is about much more than just security.

- Art KD6O

[Hamlib-stationserver] Updated Requirements Doc

[Art B. <ac...@in...>]

A small update is online at <http://sourceforge.net/projects/hamlib/files/stationserver/documents/requirements/StationServer%20Requirements%20DRAFT%202.pdf/download>

I hope everyone who can will take a few minutes to look it over and comment.

Thanks!

- Art KD6O

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Nate B. <n0...@n0...>]

As opposed to OpenVPN, how does an SSH tunnel compare?  I use SSH quite
a bit myself for remote access and with FUSE to provide a mount point.
It took a bit of fiddling to get working to my satisfaction initially
years ago but now I have the recipe so it's the first thing I do on a
new box I plan to admin.

In other words, is authentication/encryption necessary in Station
Server?  Could this be handled by a recommended "best practice" for
a OpenVPN/SSH tunnel by those interested in doing so?  I'd rather leave
security to those who understand it well (I don't understand it well at
a programming level).

73, de Nate >>

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Tony L. <vk...@gm...>]

On 6/03/2014 4:56 PM, Art Botterell wrote:
> Tony -
>
> Like they say in the investment ads up here, "Past performance does not predict future results."  The question I'm asking isn't how most hams have done things the in the past (answer: manually with no processors or networks at all) but rather how new and creative hams will want to do it in the future.
True, but I doubt many will go to the extent of multiple network 
segments.  I think the main thing is whatever we use will have to "just 
work" (aside from the obvious configuration of radios etc). The VPN may 
help with that (especially NAT traversal).
>
> Anyway, IP conflicts are precisely what a VPN resolves, by creating... well, a "virtual private network"... with its own internal address space accessible at all connected locations.
True.  I'm used to running VPNs to link networks, not hosts.  In this 
case, linking hosts would make more sense.
>
> Certainly I'm sorry to hear about your underpowered laptop.  Can't open a PDF in a web browser, really?  And yet it supports IPv6 and IPsec?    And you a computer-industry pro, too!
IPSec is on the router, the laptop doesn't need it.  IPv6 comes with 
Windows.  I did say I can open a PDF, just there is still a bit of 
overhead switching between that and email.
>
> Not sure what to suggest there, really... other than to mention that Raspberry Pi's are pretty cheap.  I really don't see any way we'll be able to move ahead with a project at this level of sophistication without being able to refer to online documents, our own and others.
At this point in time, "pretty cheap" is too expensive.  Hopefully that 
will resolve soon.  I eventually hope to fix the Macbook, which will 
solve the speed issues.  Right now, I'm just keeping what I have going, 
and that's about it.  And I still don't handle referring to large 
documents well, even when the technology is on my side, but that's a 
whole other story, all that can be done is we work with what we have the 
best we can. :)

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Art B. <ac...@in...>]

Tony -

Like they say in the investment ads up here, "Past performance does not predict future results."  The question I'm asking isn't how most hams have done things the in the past (answer: manually with no processors or networks at all) but rather how new and creative hams will want to do it in the future.

Anyway, IP conflicts are precisely what a VPN resolves, by creating... well, a "virtual private network"... with its own internal address space accessible at all connected locations.

Certainly I'm sorry to hear about your underpowered laptop.  Can't open a PDF in a web browser, really?  And yet it supports IPv6 and IPsec?    And you a computer-industry pro, too!  

Not sure what to suggest there, really... other than to mention that Raspberry Pi's are pretty cheap.  I really don't see any way we'll be able to move ahead with a project at this level of sophistication without being able to refer to online documents, our own and others.

Cheers,

- Art KD6O


On Mar 5, 2014, at 8:50 PM, Tony Langdon <vk...@gm...> wrote:

> On 6/03/2014 1:56 PM, Art Botterell wrote:
>> On Mar 5, 2014, at 5:09 PM, Tony Langdon <vk...@gm...> wrote:
>> 
>>> Are these our goals?  Firstly, I can see 50-90% of stations being single
>>> PC (with network connections over 127.0.0.1 or ::1 - more likely the
>>> latter with modern OSs).  Up to 99% will be single site (i.e. the one
>>> physical LAN).
>> Not sure about those numbers.  If we were merely refactoring the existing hamlib codebase they might perforce be accurate, but I'll confess I was thinking somewhat bigger.  And even a single physical site often has more than one IP address space, particularly if there's a mix of wired and wireless networking.
> Most hams I know are lucky to have one computer in the shack, then a 
> healthy minority have a computer and a smartphone.  In my experience, 
> more than one LAN segment is not that common (for many years I was the 
> only ham I knew that ran this way, but have long since dropped it).  
> Also, routing between different sites is fraught with complications, 
> most common being IP address conflicts on both ends.
>> 
>> Anyway, this is why I started by throwing out a requirements draft for discussion.  Maybe I could encourage you to review and comment on that?  (I've sent an update to Nate for posting to SourceForge, rolling in some other recent inputs, but I think these issues arose even in the first version.
> How often are we going to refer to external documents?  For me this has 
> 2 issues:  one is technical - I am running on an underpowered laptop 
> with insufficient RAM, which makes swapping applications tedious, PDF 
> (which thankfully you've used so far) at least is (barely) tolerable, 
> due to the extra RAM required for Adobe reader. Other alternatives get 
> progressively worse.  The second issue is short term memory and 
> contextual recall, which is exacerbated by the slow task switching of 
> this laptop.  FOr this reason, I may rarely refer to external 
> documents.  It's far easier to respond inline to proposals written 
> directly into an email.
>> 
>>> Even my station will be one
>>> physical LAN, and when they can't, the devices I'd be using can't run
>>> OpenVPN (but I can and do use thr native IPSec support on them and the
>>> router already).
>> Um... what devices are you running that can't support OpenVPN?
> Seems they've addressed this.  last time I had to look, only 
> desktop/server OSs were supported, but I see now that iOS and Android 
> are both supported these days.
>> 
>>> What effect will mandatory encryption and the encapsulation of all
>>> protocols into one data stream have on latency?
>> My experience has been that it's minimal compared with the other latencies involved in streaming.  But it's something we'd need to test.
> Yes, I'd test it.  There's also the concept of compromise.  On a LAN, 
> one can tweak for latency, on a WAN, security and bandwidth conservation 
> will be more important.
>> 
>>>  What about network
>>> topology, especially on a LAN?  The implementations of OpenVPN I've used
>>> have required extra IP addresses and subnets, all a bit overkill and
>>> messy.  And what of the other goal of IPv6 capability?
>> The point of the VPN isn't so much the encryption... although anytime we implement user-based access control we do want some way to keep credentials private... but more that it creates a single shared address space where routing would otherwise be necessary.  Not sure whether IPv4 vs v6 is really an issue... and certainly v6 doesn't magically solve the routing problem.
> v6 will (eventually!) resolve some issues.  One big issue with NAT is 
> that most shacks will be running on one of a small number of network 
> segments - 192.168.0.x and 192.168.1.x are particularly popular.  Put 
> that on both ends of your tunnel and see how your routing goes. ;)  
> Bridging is an option but that becomes an issue too, you'd have to 
> selectively block DHCP broadcasts otherwise things get messy really 
> quickly! :)  Even without IPv6 infrastructure, tunneling IPv6 over v4 
> and having Stationserver completely v6 aware might resolve routing 
> issues.  There's a lot more v6 private address space (and some of us 
> like me already have public v6 addresses).
>> 
>>>  Again, I wonder if this is
>>> better handled as an optional "WAN module", which can be optimised for
>>> latency and also offer audio compression, as well as encryption and a
>>> higher level of security, and turned on when needed for distributed (non
>>> remote base) stations.
>>> Also, licensing, if we're using external code.
>>> Hmm, OpenVPN is GPLv2, by the looks of it, which would be an issue if we
>>> wanted to use code, given one of our goals was to release under a BSD or
>>> similar license (to allow for adoption by both free and proprietary
>>> vendors without disclosure of source).
>> Yes, I imagine we'd want to use it as-is rather than changing or incorporating any code.  So that might de-facto be the WAN module concept.  (Personally I'd prefer to see security the default and allow users to turn it off if they choose to.)  Not sure about compression... that also can have latency implications.
> Compression may be useful for some WAN links, particularly for mobile 
> users, who have latency and jitter issues anyway.
> 
> -- 
> 73 de Tony VK3JED/VK3IRL
> http://vkradio.com
> 

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Tony L. <vk...@gm...>]

On 6/03/2014 1:56 PM, Art Botterell wrote:
> On Mar 5, 2014, at 5:09 PM, Tony Langdon <vk...@gm...> wrote:
>
>> Are these our goals?  Firstly, I can see 50-90% of stations being single
>> PC (with network connections over 127.0.0.1 or ::1 - more likely the
>> latter with modern OSs).  Up to 99% will be single site (i.e. the one
>> physical LAN).
> Not sure about those numbers.  If we were merely refactoring the existing hamlib codebase they might perforce be accurate, but I'll confess I was thinking somewhat bigger.  And even a single physical site often has more than one IP address space, particularly if there's a mix of wired and wireless networking.
Most hams I know are lucky to have one computer in the shack, then a 
healthy minority have a computer and a smartphone.  In my experience, 
more than one LAN segment is not that common (for many years I was the 
only ham I knew that ran this way, but have long since dropped it).  
Also, routing between different sites is fraught with complications, 
most common being IP address conflicts on both ends.
>
> Anyway, this is why I started by throwing out a requirements draft for discussion.  Maybe I could encourage you to review and comment on that?  (I've sent an update to Nate for posting to SourceForge, rolling in some other recent inputs, but I think these issues arose even in the first version.
How often are we going to refer to external documents?  For me this has 
2 issues:  one is technical - I am running on an underpowered laptop 
with insufficient RAM, which makes swapping applications tedious, PDF 
(which thankfully you've used so far) at least is (barely) tolerable, 
due to the extra RAM required for Adobe reader. Other alternatives get 
progressively worse.  The second issue is short term memory and 
contextual recall, which is exacerbated by the slow task switching of 
this laptop.  FOr this reason, I may rarely refer to external 
documents.  It's far easier to respond inline to proposals written 
directly into an email.
>
>> Even my station will be one
>> physical LAN, and when they can't, the devices I'd be using can't run
>> OpenVPN (but I can and do use thr native IPSec support on them and the
>> router already).
> Um... what devices are you running that can't support OpenVPN?
Seems they've addressed this.  last time I had to look, only 
desktop/server OSs were supported, but I see now that iOS and Android 
are both supported these days.
>
>> What effect will mandatory encryption and the encapsulation of all
>> protocols into one data stream have on latency?
> My experience has been that it's minimal compared with the other latencies involved in streaming.  But it's something we'd need to test.
Yes, I'd test it.  There's also the concept of compromise.  On a LAN, 
one can tweak for latency, on a WAN, security and bandwidth conservation 
will be more important.
>
>>   What about network
>> topology, especially on a LAN?  The implementations of OpenVPN I've used
>> have required extra IP addresses and subnets, all a bit overkill and
>> messy.  And what of the other goal of IPv6 capability?
> The point of the VPN isn't so much the encryption... although anytime we implement user-based access control we do want some way to keep credentials private... but more that it creates a single shared address space where routing would otherwise be necessary.  Not sure whether IPv4 vs v6 is really an issue... and certainly v6 doesn't magically solve the routing problem.
v6 will (eventually!) resolve some issues.  One big issue with NAT is 
that most shacks will be running on one of a small number of network 
segments - 192.168.0.x and 192.168.1.x are particularly popular.  Put 
that on both ends of your tunnel and see how your routing goes. ;)  
Bridging is an option but that becomes an issue too, you'd have to 
selectively block DHCP broadcasts otherwise things get messy really 
quickly! :)  Even without IPv6 infrastructure, tunneling IPv6 over v4 
and having Stationserver completely v6 aware might resolve routing 
issues.  There's a lot more v6 private address space (and some of us 
like me already have public v6 addresses).
>
>>   Again, I wonder if this is
>> better handled as an optional "WAN module", which can be optimised for
>> latency and also offer audio compression, as well as encryption and a
>> higher level of security, and turned on when needed for distributed (non
>> remote base) stations.
>> Also, licensing, if we're using external code.
>> Hmm, OpenVPN is GPLv2, by the looks of it, which would be an issue if we
>> wanted to use code, given one of our goals was to release under a BSD or
>> similar license (to allow for adoption by both free and proprietary
>> vendors without disclosure of source).
> Yes, I imagine we'd want to use it as-is rather than changing or incorporating any code.  So that might de-facto be the WAN module concept.  (Personally I'd prefer to see security the default and allow users to turn it off if they choose to.)  Not sure about compression... that also can have latency implications.
Compression may be useful for some WAN links, particularly for mobile 
users, who have latency and jitter issues anyway.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Art B. <ac...@in...>]

On Mar 5, 2014, at 5:09 PM, Tony Langdon <vk...@gm...> wrote:

> Are these our goals?  Firstly, I can see 50-90% of stations being single 
> PC (with network connections over 127.0.0.1 or ::1 - more likely the 
> latter with modern OSs).  Up to 99% will be single site (i.e. the one 
> physical LAN).  

Not sure about those numbers.  If we were merely refactoring the existing hamlib codebase they might perforce be accurate, but I'll confess I was thinking somewhat bigger.  And even a single physical site often has more than one IP address space, particularly if there's a mix of wired and wireless networking.

Anyway, this is why I started by throwing out a requirements draft for discussion.  Maybe I could encourage you to review and comment on that?  (I've sent an update to Nate for posting to SourceForge, rolling in some other recent inputs, but I think these issues arose even in the first version.)

> Even my station will be one 
> physical LAN, and when they can't, the devices I'd be using can't run 
> OpenVPN (but I can and do use thr native IPSec support on them and the 
> router already).

Um... what devices are you running that can't support OpenVPN?

> What effect will mandatory encryption and the encapsulation of all 
> protocols into one data stream have on latency?

My experience has been that it's minimal compared with the other latencies involved in streaming.  But it's something we'd need to test.

>  What about network 
> topology, especially on a LAN?  The implementations of OpenVPN I've used 
> have required extra IP addresses and subnets, all a bit overkill and 
> messy.  And what of the other goal of IPv6 capability?

The point of the VPN isn't so much the encryption... although anytime we implement user-based access control we do want some way to keep credentials private... but more that it creates a single shared address space where routing would otherwise be necessary.  Not sure whether IPv4 vs v6 is really an issue... and certainly v6 doesn't magically solve the routing problem.

>  Again, I wonder if this is 
> better handled as an optional "WAN module", which can be optimised for 
> latency and also offer audio compression, as well as encryption and a 
> higher level of security, and turned on when needed for distributed (non 
> remote base) stations.

> Also, licensing, if we're using external code.  
> Hmm, OpenVPN is GPLv2, by the looks of it, which would be an issue if we 
> wanted to use code, given one of our goals was to release under a BSD or 
> similar license (to allow for adoption by both free and proprietary 
> vendors without disclosure of source).

Yes, I imagine we'd want to use it as-is rather than changing or incorporating any code.  So that might de-facto be the WAN module concept.  (Personally I'd prefer to see security the default and allow users to turn it off if they choose to.)  Not sure about compression... that also can have latency implications.

- Art KD6O

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Tony L. <vk...@gm...>]

On 6/03/2014 11:42 AM, Art Botterell wrote:
> Yes, maybe I should have called that out specifically, but I figured somebody would ask. ;-)  Like all the rest it's just a suggestion.
True, but I was pointing out at this early stage, it's probably best to 
keep as open and general as possible.
>
> My thinking, for whatever it might be worth, is as follows:  We're going to have multiple network connections going simultaneously... control data, and various forms of streaming analog and/or digital media TBD.  Wrapping them together in a single VPN session means there's only one port to clear through firewalls.  It also meets our encryption requirement.  And it lays the groundwork for more sophisticated architectures in the future... e.g., clustering multiple stations via a shared VPN server for diversity.
Are these our goals?  Firstly, I can see 50-90% of stations being single 
PC (with network connections over 127.0.0.1 or ::1 - more likely the 
latter with modern OSs).  Up to 99% will be single site (i.e. the one 
physical LAN).  Do these need encryption?  Even my station will be one 
physical LAN, and when they can't, the devices I'd be using can't run 
OpenVPN (but I can and do use thr native IPSec support on them and the 
router already).

What effect will mandatory encryption and the encapsulation of all 
protocols into one data stream have on latency?  What about network 
topology, especially on a LAN?  The implementations of OpenVPN I've used 
have required extra IP addresses and subnets, all a bit overkill and 
messy.  And what of the other goal of IPv6 capability?

Not nit picking, just throwing other considerations into the mix, that 
might have a bearing on how things are done.  Again, I wonder if this is 
better handled as an optional "WAN module", which can be optimised for 
latency and also offer audio compression, as well as encryption and a 
higher level of security, and turned on when needed for distributed (non 
remote base) stations.  Also, licensing, if we're using external code.  
Hmm, OpenVPN is GPLv2, by the looks of it, which would be an issue if we 
wanted to use code, given one of our goals was to release under a BSD or 
similar license (to allow for adoption by both free and proprietary 
vendors without disclosure of source).
>
> Note that a VPN doesn't actually specify any of the individual link protocols... it's just a wrapper that lets us handle routing and encryption issues once instead of repeatedly.  And I only specified OpenVPN because... well, it's open.
Agree, and the methodology could be used in a different way too.
>
> I'm sure there are other ways to meet our requirements although personally I don't know of a more convenient one.  Open to suggestions, as ever.

Interestingly, seems there is now an iOS port of OpenVPN in the iTunes 
App Store, that's a relatively recent development (pardon the pun!).  
Still, IPSec has been the most convenient lately, because it's built 
into my devices and router (and seems to work quite well).  It's been a 
while since I had a Linux box on the edge of my network, too many cheap, 
convenient and power saving routers around these days.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Art B. <ac...@in...>]

Yes, maybe I should have called that out specifically, but I figured somebody would ask. ;-)  Like all the rest it's just a suggestion.

My thinking, for whatever it might be worth, is as follows:  We're going to have multiple network connections going simultaneously... control data, and various forms of streaming analog and/or digital media TBD.  Wrapping them together in a single VPN session means there's only one port to clear through firewalls.  It also meets our encryption requirement.  And it lays the groundwork for more sophisticated architectures in the future... e.g., clustering multiple stations via a shared VPN server for diversity.

Note that a VPN doesn't actually specify any of the individual link protocols... it's just a wrapper that lets us handle routing and encryption issues once instead of repeatedly.  And I only specified OpenVPN because... well, it's open.  

I'm sure there are other ways to meet our requirements although personally I don't know of a more convenient one.  Open to suggestions, as ever.

Thanks!

- Art KD6O

On Mar 5, 2014, at 4:29 PM, Tony Langdon <vk...@gm...> wrote:

> On 6/03/2014 9:57 AM, Art Botterell wrote:
>> Just sketching some ideas... thought I'd share this and make sure I'm on the same page as everyone else... - Art
> Might be getting ahead of ourselves a bit.  OpenVPN?  Sounds rather specific for network links at this early stage.  And it might be overkill for 99% of installations.  For the other 1%, an add-on WAN security module might be better, even if that uses OpenVPN in the background.
> 
> Some form of encryption may be warranted, but the effect of that on latency, especially on lower powered platforms might need to be considered.
> 
> More a flagging it as a "To be considered"/"To be investigated", and not being technoiogy specific at this early stage.
> -- 
> 73 de Tony VK3JED/VK3IRL
> 
> http://vkradio.com

Re: [Hamlib-stationserver] Notional Software "Stack" Diagram for Discussion

[Tony L. <vk...@gm...>]

On 6/03/2014 9:57 AM, Art Botterell wrote:
> Just sketching some ideas... thought I'd share this and make sure I'm 
> on the same page as everyone else... - Art
Might be getting ahead of ourselves a bit.  OpenVPN?  Sounds rather 
specific for network links at this early stage.  And it might be 
overkill for 99% of installations.  For the other 1%, an add-on WAN 
security module might be better, even if that uses OpenVPN in the 
background.

Some form of encryption may be warranted, but the effect of that on 
latency, especially on lower powered platforms might need to be considered.

More a flagging it as a "To be considered"/"To be investigated", and not 
being technoiogy specific at this early stage.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com