[55941] in North American Network Operators' Group
Re: VoIP over IPsec
daemon@ATHENA.MIT.EDU (Stephen Sprunk)
Tue Feb 18 14:13:19 2003
From: "Stephen Sprunk" <stephen@sprunk.org>
To: "Vadim Antonov" <avg@kotovnik.com>,
"David Luyer" <david@luyer.net>
Cc: <nanog@merit.edu>
Date: Tue, 18 Feb 2003 13:11:31 -0600
Errors-To: owner-nanog-outgoing@merit.edu
Thus spake "Vadim Antonov" <avg@kotovnik.com>
> In fact, a method to encrypt small parcels of data efficiently is
> well-known for decades. It is called "stream cypher" (surprise).
> Besides LFSR-based and other stream cyphers, any block cypher
> can be used in this mode. Its application to RTP is trivial and
> straight-forward. Just leave sequence number in clear text, so that
> position in the stream is recoverable in case of packet loss.
Most stream modes are chained in some way to intentionally disrupt
decryption if part of the ciphertext is missing; that is why IPsec resets
the stream for each packet (currently).
When NIST was standardizing AES, they added CTR mode specifically to address
IPsec implementations. I think there's already been a draft out of the IRTF
on how to modify IPsec for this, but it's not something I've followed
closely.
> It also allows precomputation of the key stream, adding nearly zero
> latency/jitter to the actual packet processing.
You fail to note that this requires precomputing and storing a keystream for
every SA on the encrypting device, which often number in the thousands.
This isn't feasible in a software implementation, and it's unnecessary in
hardware.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
