Latencies and security: In the case of PKCS (public key cryptosystem) the latencies are relatively high compared to say a (symmetric key) software DES implementation. For a 133 Pentium, software DES can decrypt roughly 600 kbytes per second whereas RSA would be in the sub-10kbyte/sec range (roughly 100:1 processing bandwidth difference). Of course, this depends on lots of things, like other system parameters and applications running. Also, RSA is generally used at initialization of the secure link, and a faster symmetric key algorithm is used for the bulk data transfer. Since (single)DES is now considered compromised, it's only used in cases where the key lifetime is very short (a phone conversation might qualify for this). Triple-DES would significantly increase the latency because of the increased processing load, but I have no numbers for that.
As you mentioned, the need to go to another server for certificates or whatever could without a doubt cause a latency that would preclude real-time anything. Fortunately, this should only be a start-up problem for the call initialization (unless I misunderstood your comment). There's also the question of the degree of security needed for telephony. Is IP telephony billed as a secure communications link, or just semi-safe? Lots of liability issues involved in making generic security claims; most providers are unwilling to assume that liability, and probably won't until they are forced to by competition (can't blame ‘em).
Still, the underlying internet doesn't guarantee bit rates, even if the system processing bandwidth isn't being taxed . IEEE802.14 addressed QoS by adopting the ITU-defined service categories of: constant bit rate, non-real-time variable bit rate, unspecified bit rate, and available bit rate. There was also a real-time variable bit rate category. Haven't really been following 802.14 recently, but I believe the DAVIC spec and 802.14 were closely aligned. But, this would only apply to the private portion of the network anyway.
You know, come to think of it, not one of the latency calculations I've seen(or "latency schedules") took delays in the security processing into consideration. I'm sure that's partly because security has taken a back seat (locked in the trunk might be a better phrase) in the spec-generating process, and partly because it is dependent on the user's system capabilities, and....
Also, what ever happened with Ipv6? DHCP would go away, and a host of other improvements related to security and quality of service. There was even a plan for a seamless transfer from Ipv4 where the 2 could coexist until the transition was complete. Last I remember (about a year ago), only the router protocols and some key management issues (i.e. management of security keying information--not "important managerial" issues) remained as unsolved (or unagreed upon). Anyone know the status?
(Frank: not sure if this addressed your question. If not, please re-phrase)
dh
Prediction: Future systems (3-5 years out) will have a dedicated "communications processor" which handles the broadband (soft cable modem--demod and FEC (may sound crazy today)) and handles the security, in order to offload the main system processor. May even handle the A/V decode. Fixed/hard solutions won't cut it--too inflexible. This will be on the "always awake" part of the motherboard. Why? Computational needs (or potential computational needs) are growing at a much greater rate than computational power or process shrinks. There's also a fairly clean demarcation of the sections that must be "always awake."
|
