[VOIPSEC] Incorrect decryption monitoring feature

[Dustin D. Trammell]

On Mon, 2006-09-25 at 13:10 -0700, Hank Cohen wrote:
> The question of whether to fill in with something other than white noise
> in this
> case is implementation dependent.  The most likely case for
> authentication failure
> is that a packet was corrupted by line noise in transit.  If it is only
> one or two packets
> that fail this way it probably doesn't matter what you do with them.
> Dropping them
> is probably the right choice.  If you have more than a small number of
> corrupted
> packets failing authentication then you have a much more serious problem
> and
> the call should probably be dropped.

Dropping the call entirely would probably not be such a good idea.
SRTP, typically running under an unreliable and connectionless transport
(UDP), is particularly vulnerable to spoofed packet injection.  If the
behavior of receiving unauthenticated packets associated to a media
stream is to drop the entire call, this would make call-teardown DoS
attacks trivial.

Dropping the individual SRTP packets however makes perfect sense.  The
call itself should not be dropped unless the device is instructed to by
signaling or if the user hangs up the device, such as if the user hangs
up because (in the non-malicious case of desync or transit-corruption)
the call audio went silent.  If your implementation needs to alert the
user that the device is no longer receiving valid/authenticated audio
perhaps playing generated white-noise or an audible voice message would
be appropriate.

-- 
Dustin D. Trammell
VoIP Security Research
TippingPoint, a division of 3Com