Thanks for this. I seen the trend where past data driven models have moved to honeypots; because it is too costly to prove and (for them to) explain why. I know where I can write scripts for transformation proxies (and resolve), and I want that VM specifications written with appropriate authentication schemes, especially compatible unto adhoc cloud-containers and USB sticks; however, it is not work for engineers until after the scripts are written. I like this political argument, and there are (express) standards already in place. On Monday, July 23, 2012, Nicolas Mailhot wrote: > > Le Lun 23 juillet 2012 13:08, Stephen Farrell a écrit : > > > We've done those, e.g. [1,2]. > > Not exactly this is a general purpose network, I'm referencing direct > endnode to central data collecting node system. > > >> For this particular use case the latency and processing induced by > >> setting > >> up a crypto tunnel is a killer, > > > > Disagree. Attempting HTTP e2e would be a killer, as would > > anything needing e2e TCP. Nothing to do with crypto. > > Nope, has been done for decades (used to be un-secured ftp exchanges, > moved to http nowadays, ssl has been rejected by manufacturers so far). > > In the monitoring station use case most of the money goes into the > instrument themselves and the coms stack is built using generic > off-the-shelf commodity tech (in extreme flash-flood warning systems the > stations are designed to be cheap enough it's ok if some of them get lost > due to the flood itself) > > -- > Nicolas Mailhot > > >
Received on Monday, 23 July 2012 17:39:51 UTC