Re: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt

[Randell Jesup <rjesup@xxxxxxxxx>]

Cullen Jennings <fluffy@xxxxxxxxx> writes:
>> Because DTLS is between UDP and the application how can DTLS (or UDP) by
>> itself proxy the packets? There is no mechanism that would aloow that.
>> As per definition DTLS has to decrypt the packets before it hands them
>> over to the application that will forward them. Thus we have a hop-to-
>> hop transport level security.
>
>I don't understand your email.
>
>There are three relevant modes that SBCs are used in with respect to  SRTP.
>
>1) the media does not even go through the SBC (this is often called  flow
>around)

Not a problem - SBC isn't on the media path.  Note: this assumes that the
SBC doesn't interfere with signalling-level support that backs up
media-level negotiation (a=zrtp-*, etc).  Note that some SBC's do muck with
a= values they don't understand (remove payloads, remove a= values, reject
entire offers if there's an a= value they can't parse (Asterisk does this),
etc). 

>2) the media does go through the SBC but the SBC does not encrypt/ decrypt

Here's where the fun is.  See above about SBC's mucking with signalling.
Add to that SBCs that muck with the packets - they may block RTCP or RTCP
they don't understand (or is encrypted), header extensions, payload values
they didn't see negotiated, packets that appear "wrong" (for example, in
best-effort-SRTP, if an SBC is "smart" and thinks you're talking G.711,
when you're actually talking G.711 w/ SRTP and auth, it may reject packets
for being "too long" or strip the auth tag), block any/all UDP traffic that
doesn't pass validity checks for the negotiated protocols, etc.

>3) the media does go through the SBC and the SBC does encrypt/decrypt  -
>often the media is only encrypted on one side of the SBC

This is ok in that you're negotiating with the SBC really, not with the
other endpoint.  The SBC is really something of a B2BUA here.  Note also
that this would mean that it would either look like a MITM "attack" to
things like ZRTP, and/or one side would see encrypted and the other
wouldn't.  This might be of *some* benefit in cases where the
most-likely-tapped-link is the (encrypted) link to the SBC.  For example,
calling from a Dangerous Place (wifi cybercafe) through an SBC and on
(unencrypted) to a fairly safe place (wired home connection).  Similar
scenarios exist for things like governments likely to try to tap at the
access link (when the SBC is in another country).  This also maps directly
to a PSTN gateway that supports encrypted IP streams -- encrypted on one
side and not on the other.

>All of these modes seem to easily work with ZRTP, DTLS, or MIKEYv2. I
>don't see what the problem is.
>
>Cullen <with my individual hat on>


-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup@xxxxxxxxx
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)