> As for having to re-do auth, privacy, etc., it seems odd not to just > standardize a TCP service and use SSL if encryption/authentication > is desired. Especially since, in the huge-horking-central-logserver > scenario, SSL would let you use commodity SSL accellerators to buy > the needed performance.
SSL doesn't provide client authentication (at least not easily & on its own). So given such a service you'd still be able to fire up a client to impersonate any other, or indeed any relay, and inject garbage into the logs. Which of course, you can do right now, but you'd be able to do it much more reliably with this :) That would be easily addressed by adding some simple authentication to the protocol itself, but once you go down that road things are already getting complicated. Or alternatively you could perhaps leverage IPSEC to get client authentication. But it's not clear to me how any client device that could do SSL or IPSEC, or for that matter do anything at all worth logging, could not manage BEEP! BEEP has a much lower entry level than either of those. The idea that BEEP is some hugely complicated stack doesn't really bear close scrutiny. (Am I reading an out-of-date BEEP RFC or something? Have they gone and added ASN.1 while I wasn't looking?:) Cheers, Frank
