On 07/30/2013 12:11 PM, R P Herrold wrote:
> On Tue, 30 Jul 2013, Alan Robertson wrote:
>
>> post on Assimilation message formats - what they are, how they work and
>> why they work that way:
>> http://bit.ly/13Vro4U
>
> reading:
>
>> SignFrame - Digital Signature - currently not cryptographically
>> secure (that's coming)
>
> and yet:
>
>> communication between endpoints can consist of only a handful of
>> packets every few months - or even every few years. By design,
>> silence is the norm
>
> ... so there is the problem of either needing to do long lived
> advanced keying (not desireable, and still rots / expires), or to be
> able to consult a CA (and CRL) on the fly, to know if a given
> transaction should be trusted. As it is UDP, we are not able to do DH
> key exchange to get a smaller session key, and will have to use long keys
I'm not a security expert. I know some. It is my plan to have some
discussions with them about how they might suggest approaching the
problem. We could do something like gpg sign the packets (or the
logical equivalent thereof). I suspect there's a better answer (maybe a
much better answer), but it's better than no answer ;-).
>
> A UDP packet, under normal curcumstances is probably less than an MTU
> long --- call it 1.5k
The overwhelming majority of packets will be unsequenced heartbeat
packets - probably about 300 bytes. The other packets are important,
and can occur in bursts (data center turn-on time).
>
> Is there really room in that specification of: Assimilation Message
> Formats for a payload, possibly with the overhead of a compression
> lookup table, and a cryptographic oversign?
The purpose of compressing is to allow for packets longer than a single
UDP packet (about 60K). If they are smaller than 15-30K they probably
aren't worth compressing. The current _specification_ has room. The
only question is whether the _packets_ have room ;-). Compression
frames are optional, and should remain optional. What we did in
Linux-HA (which was multicast UDP) was that we treated our packets as
little files. It worked well. I expect it will work well here also.
JSON isn't as compressible as XML (which is more like 20:1), but I
suspect it's good enough. I don't view compression as a design issue at
all.
The reason why things (except heartbeats) are so commonly silent is that
we've eliminated 99+% of the communication - so I don't feel any special
need for compression - _except to exceed the UDP limitations_ (which is
important). Our large packets are mostly big JSON chunks going from the
nanoprobes to the CMA. JSON is still quite (12:1) compressible.
>
> just thinking this through, but this seems like a protocol design
> problem, when we get to implementation time
Applying techniques designed for TCP and high-volume communication is
probably not an ideal choice in this kind of communication environment -
which uses UDP and communication volumes are small and typically
infrequent. If our packets are 10x as expensive to process but we have
.1% as many to process - we still win by 100x.
One thing that's very clear is that we need to be able to have room in
the design to sign in potentially many different ways.
We could use a different signing technique for the clients than for the
CMA. Client packets have less raw destructive power than CMA packets ;-).
Meaningful digital signatures and encryption are open design issues. I
could be mistaken, but I don't see these as an architecture issue.
--
Alan Robertson <[email protected]> - @OSSAlanR
"Openness is the foundation and preservative of friendship... Let me claim
from you at all times your undisguised opinions." - William Wilberforce
_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/
