[NTLUG:Discuss] What is the best method to communicate between a device and a server?

[Leroy Tennison]

Kipton Moravec wrote:
> Thanks all. I think I have it narrowed to SSH and HTTP that is a big
> help.
> 
> This is for a $8 16-bit microcontroller, so it does not have a *nix, but
> has a Ethernet stack and already supports HTTP, SNMP, SMTP, and FTP. I
> do not know if it supports SSH. But I am looking into it.
> 
> Kip
> 
> On Fri, 2008-04-04 at 08:34 -0500, Kipton Moravec wrote:
>> I am designing a device or appliance (it does not matter what) that
>> needs to report results to a server, over the Internet and get new
>> instructions once a day or whenever it powers up. (Or had a power
>> failure). There could be thousands of these devices.
>>
>> I have to assume the device will be behind a firewall so the device will
>> have to contact the Linux server and the server will not be able to
>> initiate the communications to the device.
>>
>> The device will send a progress report each day, reporting a few
>> statistics (probably 100 - 200 bytes). The only other time it will
>> report is when things go wrong.
>>
>> When it checks in, it will look for any new commands for itself,
>> including software updates. A command may be to provide additional data,
>> or a recommendation to check in at a specific time (for load balancing
>> on the server). It may be required to download a new program revision,
>> and reprogram itself.
>>
>> I do need to keep track of time, so I am thinking of implementing NTP
>> also. It will have its own clock that is good to a couple of seconds per
>> month.
>>
>> What application protocols are best for something like this?
>>
>> I can see using FTP to upload and download files with the data.
>>
>> I can see using SMTP and a POP server (email) for sending and receiving
>> messages.
>>
>> Some have suggested SNMP which I am not familiar with.
>>
>> Another way is to open a socket to socket custom connection.
>>
>> Someone suggested opening up a secure telnet connection.
>>
>> I am sure there are more ways to do this. But what I do not know is what
>> is the best way to do this. I want something that is robust, and easy.
>> (KISS) And preferably small. 
>>
>> It is hard to predict what will be required in the future so flexibility
>> is good for both sides, the device and the server.
>>
>> Any suggestions? And more importantly why one way would be better than
>> another?
>>
>> Kip

If it does ssh then use it, if it doesn't then answer the question "Does 
security matter?"  I realize that's almost heretical to say in an age of 
malware but there are some things that just don't need encryption.  If 
the data being delivered is mundane or if it provides no context 
allowing it to be understood then you may be OK.

You may need to change the design of your messages (deliver numeric 
codes instead of actual text messages so that a potential attacker gets 
only a string of numbers that's meaningless to them).  You can make up 
for some of the insecurity on the server end by increasing your due 
diligence there.  Examples are: very stringent validation of incoming 
data to assure that it comes from the right source and hasn't been 
tampered with, stringent limits on what machines can deliver data and 
how much/how often to prevent trashing the server disk, writing 
table-driven client code so that downloaded instructions are delivered 
as a table of values (again, numbers or non-meaningful text unless 
someone has the context allowing understanding).

I'm not advocating "security by obscurity" as a standard practice but in 
cases where the data doesn't require that high of a security it may be 
good enough.