Subject: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]

From: Alan Johnston <[email-masked]>
Date: Wed, 25 Oct 2006 11:55:24 -0500

All,

The ZRTP I-D has been updated.  There are lots of changes in the 
document including:

- Discussion of how ZRTP compares using the criteria in 
draft-wing-rtpsec-keying-eval-01.txt

- Discovery and authentication of ZRTP through the signaling channel and 
the definitions and ABNF of three SDP attributes a=zrtp, a=zrtp-sas, 
a=zrtp-sasvalue.

- New Multistream key agreement mode allowing SRTP keys for multiple 
media streams in a session to be derived from a single  ZRTP DH exchange.

- CRC protection of ZRTP messages against transport errors using a 32 
bit CRC algorithm

- Use of RTP no-op packets instead of comfort noise packets

- Simplified shared secret comparison algorithm

- New Stay secure and Disclosure flags

- More details on caching of retained shared secrets including 
expiration intervals

- Removal of Error message - Reason field added to GoClear

- Discussion of the behavior of intermediary devices that might 
implement ZRTP

We will be discussing the changes in the ZRTP protocol in the AVT 
working group and the SDP attributes in MMUSIC.

As always, comments and feedback are most welcome.

Thanks,
Alan

-------- Original Message --------
Subject: 	I-D ACTION:draft-zimmermann-avt-zrtp-02.txt
Date: 	Tue, 24 Oct 2006 15:50:02 -0400
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP
	Author(s)	: P. Zimmermann, et al.
	Filename	: draft-zimmermann-avt-zrtp-02.txt
	Pages		: 52
	Date		: 2006-10-24
	
This document defines ZRTP, RTP (Real-time Transport Protocol) header
   extensions for a Diffie-Hellman exchange to agree on a session key
   and parameters for establishing Secure RTP (SRTP) sessions.  The ZRTP
   protocol is completely self-contained in RTP and does not require
   support in the signaling protocol or assume a Public Key
   Infrastructure (PKI) infrastructure.  For the media session, ZRTP
   provides confidentiality, protection against Man in the Middle (MitM)
   attacks, and, in cases where a secret is available from the signaling
   protocol, authentication.  ZRTP can utilize three Session Description
   Protocol (SDP) attributes to provide discovery and authentication
   through the signaling channel.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-zimmermann-avt-zrtp-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-zimmermann-avt-zrtp-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Philip Zimmermann <[email-masked]>
Date: Wed, 25 Oct 2006 10:30:27 -0700

In the category of full disclosure, I wanted everyone to be aware of  
an Intellectual Property disclosure I just made to the IETF.  The  
full text can be found at:

     https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=752

While patents are distasteful to me, and I have seen how they have  
been damaging in the crypto world, this is a purely defensive patent  
that I have filed.  My intention is to provide royalty-free licenses  
to anyone implementing ZRTP under most circumstances.  Provided they  
are not suing me or my customers for infringing a patent. ;-)

The exact text is:

"In relation to any IETF standard incorporating the technology in the  
ZRTP
specification ("ZRTP Technology"), Philip Zimmermann (together with his
successors and assignees, “PRZ”) will grant a royalty-free, non- 
exclusive
license to Qualified Parties to use the ZRTP Technology solely to the  
extent
necessary to implement and practice such IETF standards in strict  
conformance
with the IETF standards.  As used herein, Qualified Parties means a  
party who
has not, does not and will not assert, in litigation or otherwise,  
including in
licensing discussions, any patent or other intellectual property  
right against
PRZ or any licensee of the libZRTP SDK.  Any such license to a  
Qualified Party
shall terminate at once if such party asserts a patent or other  
intellectual
property right against PRZ or any licensee of the libZRTP SDK.  PRZ  
will grant
non-exclusive licenses to Non-Qualified Parties on reasonable,  
reciprocal
non-discriminatory terms and conditions."

I also wanted to use this to give some incentive for ZRTP  
implementors to truthfully implement the ZRTP disclosure flag in  
Appendix B of the new ZRTP Internet draft.  See http:// 
zfoneproject.com/disclosureflag.html

I will be in San Diego and would be happy to discuss this further  
with anyone who wishes.

-prz

On Oct 25, 2006, at 9:55 AM, Alan Johnston wrote:

> - Discussion of how ZRTP compares using the criteria in draft-wing- 
> rtpsec-keying-eval-01.txt
>
> - Discovery and authentication of ZRTP through the signaling  
> channel and the definitions and ABNF of three SDP attributes  
> a=zrtp, a=zrtp-sas, a=zrtp-sasvalue.
>
> - New Multistream key agreement mode allowing SRTP keys for  
> multiple media streams in a session to be derived from a single   
> ZRTP DH exchange.
>
> - CRC protection of ZRTP messages against transport errors using a  
> 32 bit CRC algorithm
>
> To remove yourself from the I-D Announcement list, send a message  
> to [email-masked] with the word unsubscribe in the  
> body of the message. You can also visit https://www1.ietf.org/ 
> mailman/listinfo/I-D-announce to change your subscription settings.
>
> logging in, type "cd internet-drafts" and then "get draft- 
> zimmermann-avt-zrtp-02.txt".
>
> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow- 
> sites.txt
>

----------------------------------------------
Philip R Zimmermann        [email-masked]
http://philzimmermann.com  tel +1 650 322-7223
(spelled with 2 n's)       fax +1 650 322-7877

---

From: Randell Jesup <[email-masked]>
Date: Wed, 25 Oct 2006 13:54:14 -0400

Philip Zimmermann <[email-masked]> writes:
>While patents are distasteful to me, and I have seen how they have  been
>damaging in the crypto world, this is a purely defensive patent  that I
>have filed.  My intention is to provide royalty-free licenses  to anyone
>implementing ZRTP under most circumstances.  Provided they  are not suing
>me or my customers for infringing a patent. ;-)
>
>The exact text is:
>
>"In relation to any IETF standard incorporating the technology in the ZRTP
>successors and assignees, "PRZ") will grant a royalty-free, non-
>exclusive license to Qualified Parties to use the ZRTP Technology solely
>to the extent necessary to implement and practice such IETF standards in
>strict conformance with the IETF standards.  As used herein, Qualified
>Parties means a party who has not, does not and will not assert, in
>litigation or otherwise, including in licensing discussions, any patent or
>other intellectual property right against PRZ or any licensee of the
>libZRTP SDK.  Any such license to a Qualified Party shall terminate at
>once if such party asserts a patent or other intellectual property right
>against PRZ or any licensee of the libZRTP SDK.  PRZ will grant
>non-exclusive licenses to Non-Qualified Parties on reasonable, reciprocal

Philip -

	It appears from that text that a licensee of ZRTP not only can't
assert a patent right against someone concerning their use of ZRTP, but
that they can't assert any patent, even in a wildly different field or
different project, against any other licensee.  So if Nokia licenses ZRTP
(even if they never use it), and if Motorola licenses ZRTP (again, even if
they never use it), than neither of them can enforce any patent (or
copyright!) on *anything* against the other.  Motorola could clone a Nokia
phone including the software, put "Motorola" on the front, and sell it.

	Was this written by a lawyer?

Disclaimer: IANAL either, but I spend WAY too much time reading FCC rulings.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]

---

From: Philip Zimmermann <[email-masked]>
Date: Wed, 25 Oct 2006 12:04:42 -0700

This is not the actual legal language of a license, it's just a summary.

I'm getting on an airplane for the rest of the day, so I'll address  
this later.

I have a long-standing reputation of not being a patent troll.   
Nobody's going to be shut out of ZRTP because of a patent.  I am  
going out of my way to make sure that doesn't happen.

---

From: Ralph Giles <[email-masked]>
Date: Wed, 25 Oct 2006 12:22:31 -0700

> going out of my way to make sure that doesn't happen.

Is your patent license compatible with "patentleft" clauses like the MPL 
has? I'm worried about the interpretation of the assertion "...does not 
and will not assert, in litigation or otherwise, including in licensing 
discussions, any patent or other intellectual property right against 
PRZ."

 -r

---

From: Randell Jesup <[email-masked]>
Date: Wed, 25 Oct 2006 18:22:40 -0400

>>> The exact text is:
(quoted text)

That made me assume this was the exact text of the license.

>I have a long-standing reputation of not being a patent troll.   Nobody's
>going to be shut out of ZRTP because of a patent.  I am  going out of my
>way to make sure that doesn't happen.

I was certain you didn't mean it to be the way that was written, which was
why I asked for clarification.  Thanks.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"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)

---

From: Colin Perkins <[email-masked]>
Date: Thu, 26 Oct 2006 16:21:00 +0100

[This is being sent to [email-masked] with a bcc to rtpsec; response to  
avt please since that is the group responsible for RTP]

I have reviewed draft-zimmerman-avt-zrtp-02.txt and have some serious  
concerns regarding the way ZRTP integrates with the RTP architecture.  
In particular, I believe this draft misuses both the RTP  
synchronisation source (SSRC) and the RTP header extension mechanism.

1) Misuse of the RTP synchronisation source (SSRC): the latest draft  
states (section 5) that ZRTP endpoints "MAY use a different SSRC for  
ZRTP messages than for RTP media" since this allows "for very loose  
coupling between the ZRTP application and the RTP media application".  
This violates RFC 3550 in several fundamental ways:

a) RFC 3550 specifies that the SSRC identifies the "source of a  
stream of RTP packet" and requires receivers to group packets  
according to SSRC for playout and other processing. Using a separate  
SSRC for ZRTP and RTP data belonging to a single flow breaks playout  
buffer operation, and requires receivers to ignore the RFC 3550 rules  
on source identification.

b) If a different SSRC is used for ZRTP packets than for RTP packets,  
it is not possible to differentiate packets from different  
participants, unless unicast sessions with only two parties are  
assumed. This breaks multicast and multiparty RTP, as well as mixers  
and translators operating according under RFC 3550.

c) Use of a different SSRC for ZRTP and RTP packets can disrupt the  
correct operation of the RTP collision and loop detection algorithm.

In addition, use of a different SSRC for ZRTP and RTP packets will  
disrupt RTP header compression efficiency.

2) Misuse of the RTP header extension: the RTP architecture provides  
for a clean separation between media data and media path control  
data, providing a control channel in the form of RTCP associated with  
every data flow. ZRTP ignores this control channel, and instead mixes  
control and data traffic in an RTP header extension. This is a gross  
and needless violation of the architecture, which significantly  
complicates the resulting system. It also has several practical  
problems:

a) The header extension will significantly expand the size of ZRTP  
packets, likely leading to them being discarded when traversing  
optimized paths (for example, various wireless links).

b) ZRTP cannot be used in conjunction with the general mechanism for  
RTP header extensions defined in draft-ietf-avt-rtp-hdrext-06.txt.

None of these problems need exist. ZRTP can be trivially reworked to  
use a new RTCP packet type, potentially multiplexed onto the same  
port as the data, with the same SSRC as the stream it is protecting.  
This would have the same security properties as the current draft,  
but would conform to the RTP architecture and avoid the breakage  
listed above, would work in a wider range of environments, and would  
encourage the take-up of RTCP (which is already needed to support a  
range of features of RTP such as lip-synchronisation, codec control,  
etc.).

We have an architecture which cleanly supports all the features that  
ZRTP needs. Please use it, rather than trying to perpetuate the  
(broken) PSTN secure phone model.

Colin

---

From: Alan Johnston <[email-masked]>
Date: Fri, 27 Oct 2006 06:46:24 -0500

Colin,

Thanks for your comments on the draft.

On SSRCs, the case where ZRTP can use a separate SSRC is precisely the 
case where RTP packets are coming from another source - remember this is 
the loosely coupled case where the ZRTP endpoint may be an in-line 
media-only device. For such a device to generate RTP packets and reuse 
another endpoint's SSRC would seem to be the real violation and cause 
significant problems.  In general, we feel that ZRTP should be 
integrated with the media stack and hence should use the same SSRC.  We 
will make this clearer in the next version of the draft.

On the use of RTCP, this is a possibility in the future.  Since the ZRTP 
protocol is designed to be deployable in the real world, a requirement 
is that it not require additional NAT bindings - this is a major 
obstacle today to the deployment of RTCP.  Another requirement of ZRTP 
is that it not be dependent on the signaling channel.  It can use the 
signaling channel as an additional out-of-band discovery and 
authentication channel, but it can not have any dependency.  So, if your 
draft defining the multiplexing of RTCP on RTP ports is adopted as a 
Working Group item, and there are no additional requirements for 
signaling, then ZRTP should be able to make use of RTCP transport.  We 
will investigate this in the next version of the draft as this topic 
develops.

And on the question of draft-ietf-avt-rtp-hdrext-06.txt, on 6/23/06 you 
emailed to the list that it does not affect ZRTP's use of header extensions.

Thanks,
Alan

Colin Perkins wrote:
> a) RFC 3550 specifies that the SSRC identifies the "source of a stream 
> of RTP packet" and requires receivers to group packets according to 
> SSRC for playout and other processing. Using a separate SSRC for ZRTP 
> and RTP data belonging to a single flow breaks playout buffer 
> operation, and requires receivers to ignore the RFC 3550 rules on 
> source identification.
>
> for a clean separation between media data and media path control data, 
> providing a control channel in the form of RTCP associated with every 
> data flow. ZRTP ignores this control channel, and instead mixes 
> complicates the resulting system. It also has several practical problems:
>
> use a new RTCP packet type, potentially multiplexed onto the same port 
> as the data, with the same SSRC as the stream it is protecting. This 
> would have the same security properties as the current draft, but 
> would conform to the RTP architecture and avoid the breakage listed 
> above, would work in a wider range of environments, and would 
>> - Discovery and authentication of ZRTP through the signaling channel 
>> and the definitions and ABNF of three SDP attributes a=zrtp, 
>> a=zrtp-sas, a=zrtp-sasvalue.
>>
>> [email-masked] with the word unsubscribe in the body 
>> of the message. You can also visit 
>> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your 
>> subscription settings.
>>
>> logging in, type "cd internet-drafts" and then "get 
>> draft-zimmermann-avt-zrtp-02.txt".
>>
>> http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 27 Oct 2006 13:53:37 +0100

Alan,

On 27 Oct 2006, at 12:46, Alan Johnston wrote:
> On SSRCs, the case where ZRTP can use a separate SSRC is precisely  
> the case where RTP packets are coming from another source -  
> remember this is the loosely coupled case where the ZRTP endpoint  
> may be an in-line media-only device. For such a device to generate  
> RTP packets and reuse another endpoint's SSRC would seem to be the  
> real violation and cause significant problems.

Sure. However using a separate SSRC also causes problems. I don't  
think you can de-couple the ZRTP processing to the degree you suggest.

> In general, we feel that ZRTP should be integrated with the media  
> stack and hence should use the same SSRC.  We will make this  
> clearer in the next version of the draft.

I would go further: it MUST use the SSRC of the media stream it is  
protecting, otherwise things break.

> On the use of RTCP, this is a possibility in the future.  Since the  
> ZRTP protocol is designed to be deployable in the real world, a  
> requirement is that it not require additional NAT bindings - this  
> is a major obstacle today to the deployment of RTCP.

I'm not sure I believe that argument. The complexity comes from  
implementing ICE to open any ports. Once you have an ICE  
implementation, running it again to open an RTCP port is not an  
issue. Also, as I described, there are deployment issues with ZRTP as  
currently specified.

> Another requirement of ZRTP is that it not be dependent on the  
> signaling channel.

That's not possible: RTP requires there be an out-of-band signalling  
channel to negotiate payload formats, etc. I assume you mean there is  
a requirement that the security is not dependent on the signalling,  
but that is independent of the use of RTCP to convey ZRTP messages.

> It can use the signaling channel as an additional out-of-band  
> discovery and authentication channel, but it can not have any  
> dependency.  So, if your draft defining the multiplexing of RTCP on  
> RTP ports is adopted as a Working Group item, and there are no  
> additional requirements for signaling, then ZRTP should be able to  
> make use of RTCP transport.  We will investigate this in the next  
> version of the draft as this topic develops.

My draft has already been adopted as an AVT work item. It does  
require some signalling support, using the a=rtcp: attribute, but  
that attribute is also required for ICE to work. [Note, also, that  
sending ZRTP-in-RTCP on the RTP port without signalling is vastly  
preferable to using an RTP header extension to send ZRTP messages,  
since it keeps control information out of the data packets].

> And on the question of draft-ietf-avt-rtp-hdrext-06.txt, on 6/23/06  
> you emailed to the list that it does not affect ZRTP's use of  
> header extensions.

The issue is that only one header extension can be present in RTP  
packets. If you use ZRTP, you cannot use hdrext, and vice-versa.  
Using RTCP to convey the ZRTP messages would remove that constraint.

Colin

---

From: David R Oran <[email-masked]>
Date: Fri, 27 Oct 2006 09:35:25 -0400

I find myself in complete agreement with Colin's points, especially  
the point about using RTCP as the control channel for zrtp control  
messages.

Dave Oran.

On Oct 26, 2006, at 11:21 AM, Colin Perkins wrote:

> [This is being sent to [email-masked] with a bcc to rtpsec; response  
> to avt please since that is the group responsible for RTP]
>
>
> I have reviewed draft-zimmerman-avt-zrtp-02.txt and have some  
> serious concerns regarding the way ZRTP integrates with the RTP  
> architecture. In particular, I believe this draft misuses both the  
> RTP synchronisation source (SSRC) and the RTP header extension  
> mechanism.
>
>
> 1) Misuse of the RTP synchronisation source (SSRC): the latest  
> draft states (section 5) that ZRTP endpoints "MAY use a different  
> SSRC for ZRTP messages than for RTP media" since this allows "for  
> very loose coupling between the ZRTP application and the RTP media  
> application". This violates RFC 3550 in several fundamental ways:
>
> according to SSRC for playout and other processing. Using a  
> separate SSRC for ZRTP and RTP data belonging to a single flow  
> breaks playout buffer operation, and requires receivers to ignore  
> the RFC 3550 rules on source identification.
>
> b) If a different SSRC is used for ZRTP packets than for RTP  
> packets, it is not possible to differentiate packets from different  
> assumed. This breaks multicast and multiparty RTP, as well as  
> mixers and translators operating according under RFC 3550.
>
> 2) Misuse of the RTP header extension: the RTP architecture  
> provides for a clean separation between media data and media path  
> control data, providing a control channel in the form of RTCP  
> associated with every data flow. ZRTP ignores this control channel,  
> and instead mixes control and data traffic in an RTP header  
> extension. This is a gross and needless violation of the  
> architecture, which significantly complicates the resulting system.  
> It also has several practical problems:
>
> b) ZRTP cannot be used in conjunction with the general mechanism  
> for RTP header extensions defined in draft-ietf-avt-rtp-hdrext-06.txt.
>
>
> None of these problems need exist. ZRTP can be trivially reworked  
> to use a new RTCP packet type, potentially multiplexed onto the  
> same port as the data, with the same SSRC as the stream it is  
> protecting. This would have the same security properties as the  
> current draft, but would conform to the RTP architecture and avoid  
> the breakage listed above, would work in a wider range of  
> environments, and would encourage the take-up of RTCP (which is  
> already needed to support a range of features of RTP such as lip- 
> synchronisation, codec control, etc.).
>
> We have an architecture which cleanly supports all the features  
> that ZRTP needs. Please use it, rather than trying to perpetuate  
> the (broken) PSTN secure phone model.
>
> Colin
>
>
>
>
>> Internet-Drafts are also available by anonymous FTP. Login with  
>> the username "anonymous" and a password of your e-mail address.  
>> After logging in, type "cd internet-drafts" and then "get draft-

---

From: David R Oran <[email-masked]>
Date: Fri, 27 Oct 2006 09:40:54 -0400

On Oct 27, 2006, at 7:46 AM, Alan Johnston wrote:

> real violation and cause significant problems.  In general, we feel  
> that ZRTP should be integrated with the media stack and hence  
> should use the same SSRC.  We will make this clearer in the next  
> version of the draft.
>
If the zrtp device is deployed inline with this kind of approach,  
then it is an RTP mixer/translator and what should be coming out are  
packets with the zrtp SSRC on all packets, and the original RTP  
packets identified with a CSRC. Is that really what you want to do  
though?

> is a major obstacle today to the deployment of RTCP.
Then do rtp/rtcp port multiplexing.

> signaling channel.  It can use the signaling channel as an  
> additional out-of-band discovery and authentication channel, but it  
> can not have any dependency.  So, if your draft defining the  
> multiplexing of RTCP on RTP ports is adopted as a Working Group  
> item, and there are no additional requirements for signaling, then  
> ZRTP should be able to make use of RTCP transport.  We will  
> investigate this in the next version of the draft as this topic  
> develops.
>
I would prefer if you specified it NOW as RTCP as the control  
channel. For devices that do RTCP correctly, it will work now, and  
for those behind nats and don't understand how to open two ports  
through the nat, you can exploit port multiplexing.

>> packets, it is not possible to differentiate packets from  
>> different participants, unless unicast sessions with only two  
>> parties are assumed. This breaks multicast and multiparty RTP, as  
>> well as mixers and translators operating according under RFC 3550.
>>
>> c) Use of a different SSRC for ZRTP and RTP packets can disrupt  
>> the correct operation of the RTP collision and loop detection  
>> algorithm.
>>
>> associated with every data flow. ZRTP ignores this control  
>> channel, and instead mixes control and data traffic in an RTP  
>> header extension. This is a gross and needless violation of the  
>> architecture, which significantly complicates the resulting  
>> system. It also has several practical problems:
>>
>>> - Discussion of how ZRTP compares using the criteria in draft- 
>>> wing-rtpsec-keying-eval-01.txt
>>>
>>> - CRC protection of ZRTP messages against transport errors using  
>>> a 32 bit CRC algorithm
>>>
>>> A New Internet-Draft is available from the on-line Internet- 
>>> Drafts directories.
>>>
>>>
>>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/ 
>>> 1shadow-sites.txt
>>>

---

From: Alan Johnston <[email-masked]>
Date: Fri, 27 Oct 2006 10:17:49 -0500

Colin,

See my comments below.

Thanks,
Alan

Colin Perkins wrote:
>> the case where RTP packets are coming from another source - remember 
>> this is the loosely coupled case where the ZRTP endpoint may be an 
>> in-line media-only device. For such a device to generate RTP packets 
>> and reuse another endpoint's SSRC would seem to be the real violation 
>> and cause significant problems.
>
>> stack and hence should use the same SSRC.  We will make this clearer 
>> in the next version of the draft.
>
This is not true.  Real world implementations are not nearly so brittle 
with respect to SSRC as you suggest.  If they were, common scenarios 
such as forwarding, retargeting, forking, IVRs, etc would all cause 
these implementations to break.  Especially at the start of a session, 
it is *very* common to get RTP from multiple SSRC and all 
implementations deal with this today.
>> requirement is that it not require additional NAT bindings - this is 
>> a major obstacle today to the deployment of RTCP.
>
> implementation, running it again to open an RTCP port is not an issue. 
> Also, as I described, there are deployment issues with ZRTP as 
> currently specified.
>
Your deployment issues with ZRTP are theoretical - ZRTP is a deployed 
protocol on the Internet today and has been tested at a SIPit against 
all UAs - things are not broken.  I'm not saying ZRTP will work in every 
RTP application - some where there is tight coupling between the 
transport an application layers there may be problems - but ZRTP isn't 
designed for every environment - it is designed to provide badly needed 
security for Internet VoIP and multimedia.
> My draft has already been adopted as an AVT work item. It does require 
> some signalling support, using the a=rtcp: attribute, but that 
> attribute is also required for ICE to work. [Note, also, that sending 
> ZRTP-in-RTCP on the RTP port without signalling is vastly preferable 
> to using an RTP header extension to send ZRTP messages, since it keeps 
> control information out of the data packets].
>
>> you emailed to the list that it does not affect ZRTP's use of header 
>> extensions.
>
> packets. If you use ZRTP, you cannot use hdrext, and vice-versa. Using 
> RTCP to convey the ZRTP messages would remove that constraint.
>
There is never a case when another header extension will be present in a 
no-op RTP packet *generated* by a ZRTP endpoint.   ZRTP never inserts a 
header extension in an RTP packet carrying media, so it will never try 
to insert one where there is already one present. There is no conflict 
between ZRTP and draft-ietf-avt-rtp-hdrext-06.txt.

---

From: Alan Johnston <[email-masked]>
Date: Fri, 27 Oct 2006 10:30:58 -0500

Dave,

Thanks for your comments on the draft.   See mine below.

Thanks,
Alan

David R Oran wrote:
>> and cause significant problems.  In general, we feel that ZRTP should 
>> be integrated with the media stack and hence should use the same 
>> SSRC.  We will make this clearer in the next version of the draft.
>>
> If the zrtp device is deployed inline with this kind of approach, then 
> it is an RTP mixer/translator and what should be coming out are 
Here is the exact scenario.  At the start of the RTP session, the inline 
ZRTP device needs to insert a couple of no-op packets to carry ZRTP 
Hello messages in the header extension field.  This is for discovery 
independent of the signaling channel.  If the inline ZRTP device does 
not see any ZRTP replies, it just goes dormant and sends no further  RTP 
packets in the session.  The RTP media continues end-to-end.  Only if 
ZRTP responses come back does the inline ZRTP device insert itself in 
the media path and begins the key negotiation.  Once this happens, the 
ZRTP device is acting as a media relay.  It certainly isn't a mixer.  
I'm not sure it can be modeled as a translator, either, although I am 
less sure of this.
>> signaling channel.  It can use the signaling channel as an additional 
>> out-of-band discovery and authentication channel, but it can not have 
>> any dependency.  So, if your draft defining the multiplexing of RTCP 
>> on RTP ports is adopted as a Working Group item, and there are no 
> I would prefer if you specified it NOW as RTCP as the control channel. 
> For devices that do RTCP correctly, it will work now, and for those 
> behind nats and don't understand how to open two ports through the 
> nat, you can exploit port multiplexing.
>
We will investigate RTCP with port multiplexing.  We will need to make 
sure that there aren't bandwidth and message retransmission limitations 
that could make this unworkable.
>>> coupling between the ZRTP application and the RTP media 
>>> buffer operation, and requires receivers to ignore the RFC 3550 
>>> rules on source identification.
>>>
>>> data, providing a control channel in the form of RTCP associated 
>>> with every data flow. ZRTP ignores this control channel, and instead 
>>> mixes control and data traffic in an RTP header extension. This is a 
>>> gross and needless violation of the architecture, which 
>>> significantly complicates the resulting system. It also has several 
>>> practical problems:
>>>
>>>> body of the message. You can also visit

---

From: Colin Perkins <[email-masked]>
Date: Fri, 27 Oct 2006 17:29:27 +0100

On 27 Oct 2006, at 16:17, Alan Johnston wrote:
>>> On SSRCs, the case where ZRTP can use a separate SSRC is  
>>> precisely the case where RTP packets are coming from another  
>>> source - remember this is the loosely coupled case where the ZRTP  
>>> endpoint may be an in-line media-only device. For such a device  
>>> to generate RTP packets and reuse another endpoint's SSRC would  
>>> seem to be the real violation and cause significant problems.
>>
> This is not true.

Yes, it is, once you have multiple senders in a session. See RFC 3550  
section 3. This is the entire reason why RTP includes an SSRC value,  
and cannot be ignored in AVT drafts.

> Real world implementations are not nearly so brittle with respect  
> to SSRC as you suggest.  If they were, common scenarios such as  
> forwarding, retargeting, forking, IVRs, etc would all cause these  
> implementations to break.  Especially at the start of a session, it  
> is *very* common to get RTP from multiple SSRC and all  

Of course they get RTP with multiple SSRCs from different devices,  
that is why there is an SSRC: it lets the receiver distinguish the  
different devices that are sending it media. However, that's not the  
same as using several SSRCs for the same source, which is what you  
propose in the ZRTP draft. Using different SSRC values for the same  
source only works if the receiver assumes a point to point session.  
It will not work if there are multiple active senders, since it gives  
no way to associate ZRTP packets with particular senders.

>>> On the use of RTCP, this is a possibility in the future.  Since  
>>> the ZRTP protocol is designed to be deployable in the real world,  
>>> a requirement is that it not require additional NAT bindings -  
>>> this is a major obstacle today to the deployment of RTCP.
>>
>> issue. Also, as I described, there are deployment issues with ZRTP  
>> as currently specified.
>>
> Your deployment issues with ZRTP are theoretical - ZRTP is a  
> deployed protocol on the Internet today and has been tested at a  
> SIPit against all UAs - things are not broken.  I'm not saying ZRTP  
> will work in every RTP application - some where there is tight  
> coupling between the transport an application layers there may be  
> problems - but ZRTP isn't designed for every environment - it is  
> designed to provide badly needed security for Internet VoIP and  
> multimedia.

If you only test against point-to-point implementations on an  
Ethernet, they're theoretical issues. RTP is used in many more  
environments than that, however, and your lack of testing in those  
environments will not make them go away, nor does it mean you can  
ignore them in drafts submitted to AVT.

>> That's not possible: RTP requires there be an out-of-band  
>> signalling channel to negotiate payload formats, etc. I assume you  
>> mean there is a requirement that the security is not dependent on  
>> the signalling, but that is independent of the use of RTCP to  
>> convey ZRTP messages.
>>
>>> dependency.  So, if your draft defining the multiplexing of RTCP  
>>> additional requirements for signaling, then ZRTP should be able  
>>> to make use of RTCP transport.  We will investigate this in the  
>>> next version of the draft as this topic develops.
>>
>>> And on the question of draft-ietf-avt-rtp-hdrext-06.txt, on  
>>> 6/23/06 you emailed to the list that it does not affect ZRTP's  
>>> use of header extensions.
>>
> There is never a case when another header extension will be present  
> in a no-op RTP packet *generated* by a ZRTP endpoint.   ZRTP never  
> inserts a header extension in an RTP packet carrying media, so it  
> will never try to insert one where there is already one present.  
> There is no conflict between ZRTP and draft-ietf-avt-rtp- 
> hdrext-06.txt.

Of course there is a conflict - you've just decided it doesn't matter  
for your current use cases. That said, the conflict with rtp-hdrext  
is the least of the problems with ZRTP, as currently specified.

I like ZRTP as an idea. I think it provides great security features.  
However, the way that idea is implemented as an RTP header extension  
is fundamentally broken. Build it using RTCP multiplexed on the same  
port: sending an RTCP format packet containing a ZRTP message is no  
more complex than sending an RTP No-op packet containing the same  
message, it is no harder to deploy, does not lose any of the security  
properties you care about, makes it easier to de-couple security  
association setup from the media, and avoids all of the problems I'm  
discussing.

Colin

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Oct 2006 17:42:21 -0700

> > implementations to break.  Especially at the start of a 
> > session, it is *very* common to get RTP from multiple SSRC and 
> > all implementations deal with this today.
> 
> It will not work if there are multiple active senders, since 
> it gives no way to associate ZRTP packets with particular senders.

Right -- like forking to multiple ZRTP answerers.  RTP is not
supposed to care about the source transport address of a packet, 
but ZRTP must be using the source transport address to associate 
the two SSRCs with each other.

...
> I like ZRTP as an idea.  I think it provides great security
> features.  However, the way that idea is implemented as an RTP
> header extension is fundamentally broken.  Build it using RTCP
> multiplexed on the same port: sending an RTCP format packet
> containing a ZRTP message is no more complex than sending an RTP
> No-op packet containing the same message, it is no harder to deploy,
> does not lose any of the security properties you care about, makes
> it easier to de-couple security association setup from the media,
> and avoids all of the problems I'm discussing.

Colin, what of the RTCP transmit limits that Alan was concerned
about (in Alan's other reply to Dave Oran)?

-d

---

From: Colin Perkins <[email-masked]>
Date: Sat, 28 Oct 2006 07:52:45 +0100

> about (in Alan's other reply to Dave Oran)?

RFC 3550 allows you to send the first RTCP packet immediately for  
unicast sessions. When coupled with AVPF, that should get an initial  
handshake without violating any of the timing rules. If that's not  
sufficient, then a change to the RTCP timing to allow ZRTP would be  
much less of a concern than piggybacking control in RTP header  
extensions.

Colin

---

From: Alan Johnston <[email-masked]>
Date: Sat, 28 Oct 2006 08:36:20 -0500

> much less of a concern than piggybacking control in RTP header 
We are still reading up on RTCP - somehow I failed to notice the 
progress of Colin's RTP/RTCP multiplex draft but here are some initial 
thoughts.

ZRTP at an absolute minimum requires 4 messages to be exchanged.  With 
the packet loss that we commonly observer at the start of a media 
session, there are often a few retransmissions as well.

The ZRTP exchange totals about 11.7k bits and needs to complete in about 
a second.  We could optimize this a little, but DH public values are 
large.  RFC 4585 talks about 1,600 bits per second for RTCP in each 
direction for a 64 kb/s audio session.  So to complete a ZRTP exchange 
in a timely fashion, we'd need to utilize at least 20% of the stream 
bandwidth and send 4 or more RTCP messages in the first second of the 
media stream.

Thanks,
Alan

---

From: Colin Perkins <[email-masked]>
Date: Sat, 28 Oct 2006 14:58:20 +0100

On 28 Oct 2006, at 14:36, Alan Johnston wrote:
>> unicast sessions. When coupled with AVPF, that should get an  
>> initial handshake without violating any of the timing rules. If  
>> that's not sufficient, then a change to the RTCP timing to allow  
>> ZRTP would be much less of a concern than piggybacking control in  
>> RTP header extensions.
>>
> progress of Colin's RTP/RTCP multiplex draft but here are some  
> initial thoughts.
>
> ZRTP at an absolute minimum requires 4 messages to be exchanged.   
> With the packet loss that we commonly observer at the start of a  
> media session, there are often a few retransmissions as well.
>
> The ZRTP exchange totals about 11.7k bits and needs to complete in  
> about a second.  We could optimize this a little, but DH public  
> values are large.  RFC 4585 talks about 1,600 bits per second for  
> RTCP in each direction for a 64 kb/s audio session.  So to complete  
> a ZRTP exchange in a timely fashion, we'd need to utilize at least  
> 20% of the stream bandwidth and send 4 or more RTCP messages in the  
> first second of the media stream.

I don't see that being a problem.

Colin

---

From: David R Oran <[email-masked]>
Date: Sat, 28 Oct 2006 10:16:45 -0400

On Oct 28, 2006, at 9:58 AM, Colin Perkins wrote:

>> RTCP in each direction for a 64 kb/s audio session.  So to  
>> complete a ZRTP exchange in a timely fashion, we'd need to utilize  
>> at least 20% of the stream bandwidth and send 4 or more RTCP  
>> messages in the first second of the media stream.
>
Especially if there's no media flowing at the same time. Perhaps it's  
worth having a statement in the next version of RFC3550 that the  
bandwidth restrictions of RTCP only apply when media is flowing?

---

From: Randell Jesup <[email-masked]>
Date: Sun, 29 Oct 2006 22:24:26 -0500

>> progress of Colin's RTP/RTCP multiplex draft but here are some  initial

Multiplex in Colin's draft requires a=rtcp support currently (though I have
a few issues with that still (I think)).  That means that to exchange keys,
the endpoints need to negotiate a viable RTCP connection (normal or
multiplex).  If multiplex, any network elements in the media stream need to
pass the RTCP properly, AND need to not break a=rtcp (which is one of my
problems with it - some will break it by ignoring it).  

>> bandwidth and send 4 or more RTCP messages in the  first second of the

Raw RTCP BW should be more like 4000 bits/s for G.711 at 20ms.

>I don't see that being a problem.

Why is that not a problem?  If you have a more-typical 24K (including
overhead) G.729 stream you only have 1200 bits for RTCP - and from that you
have to subtract an RR or SR, a header, etc.  And more importantly, without
AVPF you need longer intervals between individual RTCPs (though perhaps
some of those are SHOULD not MUST).  There's nothing about "but at startup
it's OK to ignore the rules", or "only applies if media is flowing" in
RTCP.

Realize, I like the idea of using RTCP for the key exchange here.  But
there are issues to address, including issues of network element support
for AVPF (which looks like it would be required).

There are other options:
*Use a separate media (m=data) stream for key exchanges.  There are some
 obvious issues since it's now separate from the media ports, and some
 elements might not like another port (pair) being allocated.
*Use the same media stream, but with the initial payload being ZRTP data.
 (a=rtpmap:99 ZRTP).  Exchange data as payload type 99, then start sending
 encrypted data using one of the other payload types.  This is also an
 intriguing option, and doesn't need extra ports or a=rtcp or AVPF
 support.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 30 Oct 2006 09:24:25 +0000

On 30 Oct 2006, at 03:24, Randell Jesup wrote:
>>> initial

ICE also requires "a=rtcp:" support, so I expect it to be widely  
deployed in the not-too-distant future.

And, being pragmatic, I prefer that RTCP is sometimes sent on the RTP  
port without signalling, than always sending control messages in the  
RTP stream. Updating middlebox implementations to support "a=rtcp:"  
is much easier than fixing a broken architecture that mixes control  
plane and data plane.

> it's OK to ignore the rules", or "only applies if media is flowing" in

Sure, but again, a minor change to the RTCP timing rules to allow  
ZRTP is much preferable to a major architectural change to allow  
control messages within an RTP data stream.

>  elements might not like another port (pair) being allocated.

Reasonable, but would need signalling support and extra ports.

>  intriguing option, and doesn't need extra ports or a=rtcp or AVPF

It's architecturally pretty ugly: a media stream shouldn't contain  
control data. I would much prefer RTCP, whether signalled or not, or  
another protocol that is multiplexed on the same port (as done with  
STUN).

Colin

---

From: Randell Jesup <[email-masked]>
Date: Mon, 30 Oct 2006 12:19:57 -0500

Colin Perkins <[email-masked]> writes:
>> Multiplex in Colin's draft requires a=rtcp support currently (though I
>> have a few issues with that still (I think)).  That means that to
>> exchange keys, the endpoints need to negotiate a viable RTCP connection
>> (normal or multiplex).  If multiplex, any network elements in the media
>> stream need to pass the RTCP properly, AND need to not break a=rtcp
>> (which is one of my problems with it - some will break it by ignoring
>> it).
>
>ICE also requires "a=rtcp:" support, so I expect it to be widely  deployed
>in the not-too-distant future.

Uh... yeah.  Depends on how you define "not-too-distant".  The kicker is
that all these existing network elements that will not work with it (SBCs
mostly), and from experience many of them are often running
far-from-up-to-date software, or are written in-house, buggy, etc.  Lots of
them don't even *pass* RTCP, let along support a=rtcp.

>And, being pragmatic, I prefer that RTCP is sometimes sent on the RTP  port
>without signalling, than always sending control messages in the  RTP
>stream. Updating middlebox implementations to support "a=rtcp:"  is much
>easier than fixing a broken architecture that mixes control  plane and data
>plane.

Um, how will it get sent on the RTP port?  To the receiver, it will look
like the sender wanted RTP on (mapped by SBC) port foo, and rtcp on
(ignored by SBC) port bar.  And the receiver will happily comply, and their
RTCP packets will go into the bit-bucket.  Maybe the implementations can
notice the problems or use a side-channel to suss out what the SBC (didn't)
do, but I wouldn't bet encryption on it.

You could mandate support for RTCP-on-RTP even if not signalled, perhaps.

>> overhead) G.729 stream you only have 1200 bits for RTCP - and from that
>> you have to subtract an RR or SR, a header, etc.  And more importantly,
>> without AVPF you need longer intervals between individual RTCPs (though
>> perhaps some of those are SHOULD not MUST).  There's nothing about "but
>> at startup it's OK to ignore the rules", or "only applies if media is
>> flowing" in RTCP.
>
>Sure, but again, a minor change to the RTCP timing rules to allow  ZRTP is
>much preferable to a major architectural change to allow  control messages
>within an RTP data stream.

Isn't this the same sort of "minor timing change" that required an entire
new set of N profiles (i.e. AVPF)?  And this wouldn't fit in the AVPF
rules, so we'd have to have AVPZ... 1/2 :-)

I admit, I like the idea of RTCP, but I don't see how we can avoid badly
breaking the RTCP rules.  If everyone is willing to break them for this,
and it doesn't mean another horrible mess like AVPF/SAVPF has turned into
(because of SDP and how profiles are negotiated), ok. 

>Reasonable, but would need signalling support and extra ports.

This probably could be done.  Yes, it requires another port-pair. (In
theory I don't think there's anything *mandating* that a set of media
streams use different ports - but people want to use that as a way to try
to do profile negotiation.)

>>  (a=rtpmap:99 ZRTP).  Exchange data as payload type 99, then start
>>  sending encrypted data using one of the other payload types.  This is
>>  also an intriguing option, and doesn't need extra ports or a=rtcp or
>>  AVPF support.
>
>It's architecturally pretty ugly: a media stream shouldn't contain  control
>data. I would much prefer RTCP, whether signalled or not, or  another
>protocol that is multiplexed on the same port (as done with  STUN).

Well, I think this is architecturally much better than the header
extension/NOOP idea, avoids the RTCP BW limit issues, doesn't conflict with
hdrext, avoids SSRC issues, etc.  It provides a negotiated (you can reject
it) media-path control-plane for this specific purpose with no bandwidth
limitations and less overhead than RTCP (no RR/SR).  The major downside
architecturally is that the data in the packets is not per-se audio or
video (or whatever m=data type), but what the packets contain is being
signalled.  It doesn't interfere with existing applications, should be
totally transparent to all but the worst-written network elements, and
doesn't interfere with normal traffic/packet-sizes/RTCP calculations/etc.

Multiplexing another protocol in the same port as RTP is an option, of
course, though probably more network elements would block it than would
the payload idea.  I would probably consider that as the strongest
alternative to the payload idea above, and put both above the current
header-extension/NOOP plan.  I prefer the payload plan because it avoids
some issues with the application having to intuit the type of incoming
packets, and in general it just seems odd to me.  I know why it was needed
for ICE/STUN, from a technical point of view, but that's not needed here.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Oct 2006 17:17:48 -0800

I like the separate payload idea; it also fits nicely with port mapping
being discussed on MMUSIC (see thread with subject "RE: [MMUSIC] RE: I-D
ACTION:draft-kaplan-mmusic-best-effort-srtp-01.txt").

-d

> -----Original Message-----
> From: Randell Jesup [mailto:[email-masked]] 
> Sent: Monday, October 30, 2006 9:20 AM
> To: Colin Perkins
> Cc: [email-masked]; Dan Wing
> Subject: Re: [AVT] [Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-02.txt]
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Oct 2006 11:13:40 +0100

Hi,

Generally I am agreeing with Colin here. Putting ZRTP handshake into 
RTCP is a clean solution. When it comes to broken boxes, like SBC I 
think it is fine to consider them but we shouldn't change everything 
simply to accommodate them. They are after all broken if they aren't 
supporting RTCP. Too broken boxes will need to be upgraded.

In regards to the bandwidth. Independent on if the handshake happens in 
RTP or RTCP there needs to be some checks on the bit-rate. We can't 
ignore congestion control when being deployed on a best effort network. 
Thus ZRTP should take care not to require completion within a specific 
time. Because the transfer of particular amount of data may take some 
time. So thinking that RTP will be better than RTCP in this regard may 
very well be an illusion. Also I think people are very looked into the 
5% BW rule instead of considering what RR and RS bandwidth modifier 
combined with AVPF actually can accomplish. For example RTCP can be 
configured to have low average BW and still allow substantially higher 
rates when needed.

Also I wonder how well ZRTP handles the mixer translator cases. I am 
sorry to say that I haven't read the latest ZRTP version. However I will 
try to do it before the meeting. Have the authors consider the example 
of topologies that can be existing as described in
http://tools.ietf.org/wg/avt/draft-ietf-avt-topologies/draft-ietf-avt-topologies-02.txt

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Tue, 31 Oct 2006 07:13:09 -0500

Magnus Westerlund <[email-masked]> writes:
>Generally I am agreeing with Colin here. Putting ZRTP handshake into RTCP
>is a clean solution. When it comes to broken boxes, like SBC I think it is
>fine to consider them but we shouldn't change everything simply to
>accommodate them. They are after all broken if they aren't supporting
>RTCP. Too broken boxes will need to be upgraded.

Sure, but it won't happen overnight.

>In regards to the bandwidth. Independent on if the handshake happens in RTP
>or RTCP there needs to be some checks on the bit-rate. We can't ignore
>congestion control when being deployed on a best effort network. Thus ZRTP
>should take care not to require completion within a specific time. Because
>the transfer of particular amount of data may take some time.

Sure.  Also (and I know they know this) handling packet loss.

>So thinking that RTP will be better than RTCP in this regard may very well
>be an illusion. Also I think people are very looked into the 5% BW rule
>instead of considering what RR and RS bandwidth modifier combined with
>AVPF actually can accomplish. For example RTCP can be configured to have
>low average BW and still allow substantially higher rates when needed.

If you configure it for high RR/RS, then normal RTCP for the rest of the
call can use a lot, and more importantly QoS network elements have to
reserve that bandwidth for the entire call, whether or not it's used.
This is a huge restriction on RTCP for many usages.  The effect would be
that it could take several seconds (ignoring packet loss) to exchange
keys.  In some cases perhaps 10 seconds.  Admittedly, these are large
key exchanges, but even if trimmed somehow I think it's still way too long
(not just a little too long).

>Also I wonder how well ZRTP handles the mixer translator cases. I am sorry
>to say that I haven't read the latest ZRTP version. However I will try to
>do it before the meeting. Have the authors consider the example of
>topologies that can be existing as described in

I haven't either, but I suspect a payload-type-based solution will handle
mixers (and other cases being considered) as well as RTCP.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Oct 2006 13:20:52 +0100

> (not just a little too long).

No, not if you use AVPF, then you can use a small bandwidth for regular 
reports and more for RTCP that contains events, such as ZRTP 
key-exchanges. From my perspective one could also investigate how to 
overtax the RTCP bandwidth at startup.

Cheers

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Tue, 31 Oct 2006 09:18:55 -0500

>overtax the RTCP bandwidth at startup.

AVPF lets you send more often or immediately, but it does not change the
amount of bandwidth available for RTCP in total.  You're still limited to
5% of RTP (or the value overriding that).  You cannot "target" bandwidth in
AVPF for a specific purpose.  You can use any otherwise-unused RTCP
bandwidth, but that's limited by the maximums we've been discussion, and
overriding the default 5% means that the larger RTCP bandwidth will need to
be reserved for the entire session.  (And reinvite after key-exchange isn't
an answer).

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Oct 2006 16:08:15 +0100

> be reserved for the entire session.  (And reinvite after key-exchange isn't

There is a minimal RTCP interval parameter for AVPF. That allows you to 
restrict the frequency with which regular packets are sent. Thus 
creating a difference between sending Event packets and Regular packets. 
  Events are sent using the full bit-rate available, while regulars are 
dialed back. Thus your BW usage can very between what is needed to send 
with minimal interval up to full RR+RS bandwidth or even beyond it if 
you use immediate and have miscalculated your event rate.

cheers

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Tue, 31 Oct 2006 12:01:33 -0500

Magnus Westerlund <[email-masked]> writes:
>restrict the frequency with which regular packets are sent. Thus creating a
>difference between sending Event packets and Regular packets. Events are
>sent using the full bit-rate available, while regulars are dialed
>back. Thus your BW usage can very between what is needed to send with
>minimal interval up to full RR+RS bandwidth or even beyond it if you use
>immediate and have miscalculated your event rate.

The "full bit-rate available" is the RTCP bitrate (RR+RS if they're
specified as you mention, or 5% if they're not), not the RTP bitrate.
Which is my point; you either take a "long time" to exchange the keys (due
to the 5% restriction), or you bump RR+RS a lot to allow high usage by
RTCP, but then any QoS link will reserve that bandwidth *in addition to*
the normal (AS) bandwidth, and keep that reservation in place for the
session.  Or fail the call because of too much bandwidth requested.  Or
ignore RR+RS and limit you to 5% (just because RFC 3556 exists doesn't mean
everyone implements it).  Etc.

So if a D-H exchange requires circa >10K bits in 4 (or more) messages, 
under the 5% rule even with an 80Kbps (G.711) channel you're talking a
minimum of 2.5 seconds and probably more.  If it's a 24Kbps channel (G.729)
it's more like 8 seconds and probably more.  If you use RR+RS to bump 
RTCP up to 100%, then it's <1/2 second, but you've doubled the bandwidth
reservation requirements (and it could have a big effect on future
non-key-exchange RTCP traffic, since those values feed into the
algorithms).

http://www.isi.edu/in-notes/rfc4586.txt
   4.  RTCP Bit Rate Measurements

   The new timing rules allow more frequent RTCP feedback for small
   multicast groups.  In large groups, the algorithm behaves similarly
   to the normal RTCP timing rules.  While it is generally good to
   have more frequent feedback, it cannot be allowed at all to
   increase the bit rate used for RTCP above a fixed limit, i.e., 5%
   of the total RTP bandwidth according to RTP.  This section shows
   that the new timing rules keep RTCP bandwidth usage under the 5%
   limit for all investigated scenarios, topologies, and group sizes.
   Furthermore, we show that mixed groups (some members using
   AVP, some AVPF) can be allowed and that each session member behaves
   fairly according to its corresponding specification.  Note that
   other values for the RTCP bandwidth limit may be specified using
   the RTCP bandwidth modifiers as in [10].

and
http://www.faqs.org/rfcs/rfc3556.html
      o  The total RTCP bandwidth is 5% of the session bandwidth.  If
         one of these RTCP bandwidth specifiers is omitted, its value is
         5% minus the value of the other one, but not less than zero.
         If both are omitted, the sender and receiver RTCP bandwidths
         are 1.25% and 3.75% of the session bandwidth, respectively.

(if both are specified, the total for RTCP can be higher than 5%)

---

From: Colin Perkins <[email-masked]>
Date: Tue, 31 Oct 2006 18:10:51 +0000

> You could mandate support for RTCP-on-RTP even if not signalled,  

You could certainly mandate that ZRTP messages are sent as RTCP on  
the RTP port, irrespective of the signalling, until the middleboxes  
are fixed. It's not ideal, but it doesn't break the architecture, and  
those middleboxes will eventually be fixed to support "a=rtcp:".

>> ZRTP is

I'd prefer ZRTP to use RTCP packets ignoring the timing rules for the  
initial negotiation, than for it to embed control information into  
RTP media packets. Neither is ideal, but this seems the least bad  
alternative architecturally, given that the community seems to have  
decided to punt the keying problem onto this group, rather than  
fixing the SIP layer.

Colin

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 11:05:00 -0800

Magnus Westerlund wrote:

> sorry to say that I haven't read the latest ZRTP version. 
> However I will try to do it before the meeting.  Have the 
> authors consider the example of topologies that can be existing 
> as described in

In Montreal at the RTPSEC BoF there was consensus that we first solve
unicast point-to-point keying in a secure manner (such as not
disclosing keys to uninvolved parties).  It was our intent to capture
those requirements from the RTPSEC BoF in
draft-wing-media-security-requirements-00.txt.  Although that document
doesn't currently cite draft-ietf-avt-topologies-02.txt, I believe the
RTPSEC BoF found only consensus for "Topo-Point-to-Point" as described
in draft-ietf-avt-topologies-02.txt.

We can revisit this, but it's important for the authors of MIKEYv2, 
ZRTP, and DTLS-SRTP to know their design requirements.

-d

---

From: Randell Jesup <[email-masked]>
Date: Tue, 31 Oct 2006 14:19:29 -0500

Colin Perkins <[email-masked]> writes:
>You could certainly mandate that ZRTP messages are sent as RTCP on  the RTP
>port, irrespective of the signalling, until the middleboxes  are
>fixed. It's not ideal, but it doesn't break the architecture, and  those
>middleboxes will eventually be fixed to support "a=rtcp:".

Except those middleboxes may well reject unknown packets on the RTP port.
And in any case, we're putting bandaids on bandaids here - and even with
this, there are serious bandwidth issues.

>initial negotiation, than for it to embed control information into  RTP
>media packets. Neither is ideal, but this seems the least bad  alternative
>architecturally, given that the community seems to have  decided to punt
>the keying problem onto this group, rather than  fixing the SIP layer.

Ignoring the timing rules, or timing and bandwidth?  If you're ignoring
bandwidth rules, you probably won't work in a QoS-enabled network. (For
example, cable companies sniff SDP to do QoS reservation over PacketCable
for SIP traffic; if you violate the limits your packets will either be
delayed or quite possibly dropped.)  Obviously it would also affect
wireless QoS links as well (802.11e, for example).  Etc, etc.

And "violating" the RTCP rules (either AVP or AVPF rules) requires a new
profile by IETF standards.  (And yet more combinatorial profile explosion,
and excessive fun in call setup...)

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 11:40:30 -0800

Randell Jesup wrote:

> And "violating" the RTCP rules (either AVP or AVPF rules) 
> requires a new profile by IETF standards.  (And yet more 
> combinatorial profile explosion, and excessive fun in 
> call setup...)

Yes, this needs to be fixed (in MMUSIC, as it's the fault of
SDP).  I hope we can have fruitful discussions on mechanisms
to move this problem forward using SDP.

-d

---

From: Colin Perkins <[email-masked]>
Date: Tue, 31 Oct 2006 19:59:21 +0000

> this, there are serious bandwidth issues.

We standardised the mechanism to signal to those middleboxes three  
years ago. Push on the vendors and operators to implement them and  
those kludges go away. It's not like the "a=rtcp:" attribute is  
difficult, compared to some of the stuff that does get implemented...

> Ignoring the timing rules, or timing and bandwidth?

The timing rules. I see no need to violate the bandwidth rules, on  
average (and there are no short-term guarantees with RTCP anyway, due  
to it's statistical nature).

Colin

---

From: Randell Jesup <[email-masked]>
Date: Tue, 31 Oct 2006 15:19:31 -0500

Colin Perkins <[email-masked]> writes:
>We standardised the mechanism to signal to those middleboxes three  years
>ago. Push on the vendors and operators to implement them and  those kludges
>go away. It's not like the "a=rtcp:" attribute is  difficult, compared to
>some of the stuff that does get implemented...

True.  But there are a zillion RFCs, and unless there's an application/
business requirement for one of them, many or even most of them don't get
implemented.  From their point of view, should they spend that time
(including regression testing!!) on this, or should they put it onto the
Next Big Feature that everyone is clamoring for?  Plus, even if
implemented, many vendors won't update a box unless they must.  They often
run years-old software versions.

We can say all we want that they "should" implement them.  That, and $5+
will get you a coffee at Starbucks.  ;-)

>>> media packets. Neither is ideal, but this seems the least bad
>>> decided to punt the keying problem onto this group, rather than fixing
>>> the SIP layer.
>>
>The timing rules. I see no need to violate the bandwidth rules, on  average
>(and there are no short-term guarantees with RTCP anyway, due  to it's
>statistical nature).

There's less need to violate the timing rules (I think) with AVPF.
However, the bandwidth rules still mean an up-to-10-second key negotiation
(ignoring packet losses).  That's simply unusable, and that sort of issue
is why they're doing something even uglier in the current draft (header
extensions).

What's your objection to something like:

m=audio 4321 RTP/AVP 0 99
a=rtpmap:99 ZRTP/8000
a=rtpmap:0 PCMU/8000

---

From: Colin Perkins <[email-masked]>
Date: Tue, 31 Oct 2006 20:58:22 +0000

> run years-old software versions.

NAT traversal and security aren't the Next Big Thing?

...
>>>> fixing

I don't see why you can't send the ZRTP exchange at *exactly* the  
same rate as in the current draft, while still using RTCP. You do the  
key exchange quickly, then delay your next RTCP packet to compensate.  
Overall bandwidth fraction the same as with standard RTCP, but  
violates the timing rules a little (in the same way AVPF does, but  
for several (two?) packets, rather than just for one packet).

> m=audio 4321 RTP/AVP 0 99

ZRTP keying negotiation packets aren't audio data.

Colin

---

From: David R Oran <[email-masked]>
Date: Tue, 31 Oct 2006 16:10:03 -0500

Excuse me, but this whole RTCP bandwidth discussion is making my  
brain hurt. Some folks seem to be tied up in Talmudic examination of  
the specs (probably with the ulterior motive of supporting a  
conclusion they've already reached) when I the situation strikes me  
as VERY simple:

Either zrtp:
a) does not send SRTP packets until the key management exchange  
finishes, or
b) sends insecure RTP packets until the key management protocol  
finishes and zrtp allows the beginning of the conversation to occur  
in an insecure mode.

If (a), then the whole session bandwidth is actually available to  
RTCP since the bandwidth restrictions on RTCP are intended to keep  
the total bandwidth of RTP+RTCP below the session bandwidth.

If (b) you just tolerate a little longer before you start sending  
those realtime text messages to your page friends (with apologies to  
the non-US participants who may not get the ironic reference).

What am I missing?

On Oct 31, 2006, at 2:19 PM, Randell Jesup wrote:

>> alternative

---

From: Randell Jesup <[email-masked]>
Date: Tue, 31 Oct 2006 18:44:15 -0500

Colin Perkins <[email-masked]> writes:
>> business requirement for one of them, many or even most of them don't
>> get implemented.  From their point of view, should they spend that time
>> implemented, many vendors won't update a box unless they must.  They
>> often run years-old software versions.
>

Not for an SBC; they generally don't care.  (I may be wrong, and certainly
ICE has pushed things forward in this area - but if ICE/etc didn't demand
a=rtcp, you can bet they wouldn't be very motivated about it.)

>> However, the bandwidth rules still mean an up-to-10-second key
>> negotiation (ignoring packet losses).  That's simply unusable, and that
>> sort of issue is why they're doing something even uglier in the current
>> draft (header extensions).
>
>I don't see why you can't send the ZRTP exchange at *exactly* the  same
>rate as in the current draft, while still using RTCP. You do the  key
>exchange quickly, then delay your next RTCP packet to compensate.

Quickly?  It's 4 packets (or more), and over 10Kbits.  It would be around
8-10 seconds before you could exchange the final packet (I think if you
look at the handshakes, etc, you might end up in 10-15 seconds of wall
time for a G.729 20ms stream - more for 30ms).

>Overall bandwidth fraction the same as with standard RTCP, but violates
>the timing rules a little (in the same way AVPF does, but for several
>(two?) packets, rather than just for one packet).

4 packets, plus any re-xmits for lost packets, etc.  And AVPF violating the
timing rules of AVP is why AVPF is a profile.  If you want to violate the
timings for those first 4 (or more!)  RTCP packets, you need an alternative
profile.  And you may still have problems with QoS links.  Otherwise, if
you sent the RTCP without waiting, the QoS for that RTCP stream may either
delay it (until it fits into 5%) or more likely just drop it (valid in UDP
if you over-send to a QoS-defined channel).  There's NO guarantee I know of
that RTCP (or RTP) can burst over bandwidth for more than a single packet.
After that you have to assume it has to wait.

>ZRTP keying negotiation packets aren't audio data.

True.  Neither are RTP headers, nor random header-extensions, nor APP
messages in RTCP, nor ZRTP key-exhange in RTCP, etc.  (I'm stretching on
the RTP headers, but not on header extensions or other RTCP data.) They
_would_ be well-identified this way, and they are part of the stream, and
they can be rejected at the signalling level before the call starts (which
the current ZRTP header-ext stuff doesn't really allow).  In fact, that's
the biggest minus of this for me - a SIP proxy can block a ZRTP handshake
(though it could anyways by routing the media through an RTP proxy and
filtering the header-exts, so it's not a huge deal).

---

From: Randell Jesup <[email-masked]>
Date: Tue, 31 Oct 2006 19:09:45 -0500

David R Oran <[email-masked]> writes:
>Excuse me, but this whole RTCP bandwidth discussion is making my  brain
>hurt. Some folks seem to be tied up in Talmudic examination of  the specs
>(probably with the ulterior motive of supporting a  conclusion they've
>already reached) when I the situation strikes me  as VERY simple:
>
>Either zrtp:
>a) does not send SRTP packets until the key management exchange  finishes,
>or
>b) sends insecure RTP packets until the key management protocol  finishes
>and zrtp allows the beginning of the conversation to occur  in an insecure
>mode.
>
>If (a), then the whole session bandwidth is actually available to  RTCP
>since the bandwidth restrictions on RTCP are intended to keep  the total
>bandwidth of RTP+RTCP below the session bandwidth.

That would be the case - except that QoS channels are typically tied to
ports, and so (for example) if you have a b=AS:100 on a stream on port
X, comcast/packetcable reserves around 100Kbps for X, and around 5Kbps for
port X+1 (or the a=rtcp port).  So even if you don't use port X, you may
not be able to send more than 5Kbps on X+1.  Similar problems may crop up
for other tight-bandwidth/QoS channels like 3G, 802.11e, etc.

So, a) doesn't help you.  In some cases it does, but you can't count on it,
and you can't even know if a channel (like PacketCable) invoked QoS for you
(and yes, they can do it).  I wish a wand could be waved and do that.  The
closest I can come is to explicitly put it into the RTP stream as a payload
type.

>If (b) you just tolerate a little longer before you start sending  those
>realtime text messages to your page friends (with apologies to  the non-US
>participants who may not get the ironic reference).

Like I said, it could be a pretty long time - and many secure apps send
silence while negotiating keys, or that's an option.

And they'll just record the messages after they're decrypted anyways. ;-)

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 16:39:10 -0800

...
> Like I said, it could be a pretty long time - and many secure 
> apps send silence while negotiating keys, or that's an option.

Although considered by many to be too heavy, security preconditions
(draft-ietf-mmusic-securityprecondition) could be used to allow keys
to be negotiated before ringing the called party.

> And they'll just record the messages after they're decrypted 

Richard Nixon would be proud!

-d

---

From: David R Oran <[email-masked]>
Date: Tue, 31 Oct 2006 23:11:07 -0500

On Oct 31, 2006, at 7:09 PM, Randell Jesup wrote:

>> brain
>> finishes,
>> finishes
>> RTCP
Oh, come on. the dead fish are just piling up on the table. If 3G is  
policing per port, they got to be nuts.
If you can't get a best effort key exchange through on a random UDP  
port, lots of things are going to break and zrtp won't be the only one.

> So, a) doesn't help you.
I beg to differ.

> In some cases it does, but you can't count on it,
In the IP world, you can't count on anything in the sense you're  
raising objections.
I suppose one could say that these silly policers are doing DPI and  
stomping on the precious zrtp payload types too.

> closest I can come is to explicitly put it into the RTP stream as a  
I don't think we're going to convince each other of any of this.
Sigh.

>> those

---

From: Philip Zimmermann <[email-masked]>
Date: Tue, 31 Oct 2006 20:39:37 -0800

We do up to 20 retries of the Hello packet, because we empirically  
observe a high packet loss rate at the start of media stream, which  
only lasts a second.  This is exactly the same period that we do our  
entire ZRTP protocol.  We used to have a retry limit of 10, but that  
was not enough.  So don't assume that this won't impact RTCP  
bandwidth quotas.

On Oct 31, 2006, at 12:58 PM, Colin Perkins wrote:

>> negotiation
> same rate as in the current draft, while still using RTCP. You do  
> the key exchange quickly, then delay your next RTCP packet to  
> compensate. Overall bandwidth fraction the same as with standard  
> RTCP, but violates the timing rules a little (in the same way AVPF  
> does, but for several (two?) packets, rather than just for one  
> packet).
>