draft-ietf-perc-private-media-framework-06.txt		draft-ietf-perc-private-media-framework-07.txt
	Network Working Group P. Jones		Network Working Group P. Jones
	Internet-Draft D. Benham		Internet-Draft Cisco
	Intended status: Standards Track Cisco		Intended status: Standards Track D. Benham
	Expires: September 6, 2018 C. Groves		Expires: March 8, 2019 C. Groves
	Independent		Independent
	March 5, 2018		September 4, 2018
	A Solution Framework for Private Media in Privacy Enhanced RTP		A Solution Framework for Private Media in Privacy Enhanced RTP
	Conferencing		Conferencing
	draft-ietf-perc-private-media-framework-06		draft-ietf-perc-private-media-framework-07
	Abstract		Abstract
	This document describes a solution framework for ensuring that media		This document describes a solution framework for ensuring that media
	confidentiality and integrity are maintained end-to-end within the		confidentiality and integrity are maintained end-to-end within the
	context of a switched conferencing environment where media		context of a switched conferencing environment where media
	distributors are not trusted with the end-to-end media encryption		distributors are not trusted with the end-to-end media encryption
	keys. The solution aims to build upon existing security mechanisms		keys. The solution aims to build upon existing security mechanisms
	defined for the real-time transport protocol (RTP).		defined for the real-time transport protocol (RTP).
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 6, 2018.		This Internet-Draft will expire on March 8, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 14		6.1. Third Party Attacks . . . . . . . . . . . . . . . . . . . 14
	6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 15		6.2. Media Distributor Attacks . . . . . . . . . . . . . . . . 15
	6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 15		6.2.1. Denial of service . . . . . . . . . . . . . . . . . . 15
	6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 16		6.2.2. Replay Attack . . . . . . . . . . . . . . . . . . . . 16
	6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 16		6.2.3. Delayed Playout Attack . . . . . . . . . . . . . . . 16
	6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 16		6.2.4. Splicing Attack . . . . . . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . 17
	9.2. Informative References . . . . . . . . . . . . . . . . . 18		9.2. Informative References . . . . . . . . . . . . . . . . . 17
	Appendix A. PERC Key Inventory . . . . . . . . . . . . . . . . . 19		Appendix A. PERC Key Inventory . . . . . . . . . . . . . . . . . 19
	A.1. DTLS-SRTP Exchange Yields HBH Keys . . . . . . . . . . . 20		A.1. DTLS-SRTP Exchange Yields HBH Keys . . . . . . . . . . . 20
	A.2. The Key Distributor Transmits the KEK (EKT Key) . . . . . 20		A.2. The Key Distributor Transmits the KEK (EKT Key) . . . . . 20
	A.3. Endpoints fabricate an SRTP Master Key . . . . . . . . . 21		A.3. Endpoints fabricate an SRTP Master Key . . . . . . . . . 21
	A.4. Who has What Key . . . . . . . . . . . . . . . . . . . . 21		A.4. Who has What Key . . . . . . . . . . . . . . . . . . . . 21
	Appendix B. PERC Packet Format . . . . . . . . . . . . . . . . . 22		Appendix B. PERC Packet Format . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	skipping to change at page 8, line 49 ¶		skipping to change at page 8, line 45 ¶
	# | | *---- HBH Key (AX) HBH Key (YB) ----* | | #		# | | *---- HBH Key (AX) HBH Key (YB) ----* | | #
	# | | # # | | #		# | | # # | | #
	# *--------- E2E Key (A) E2E Key (A) ---------* #		# *--------- E2E Key (A) E2E Key (A) ---------* #
	# | *------- E2E Key (B) E2E Key (B) -------* | #		# | *------- E2E Key (B) E2E Key (B) -------* | #
	# | | # # | | #		# | | # # | | #
	# | v # # | v #		# | v # # | v #
	+-------------+ +-------------+		+-------------+ +-------------+
	| Endpoint A | | Endpoint B |		| Endpoint A | | Endpoint B |
	+-------------+ +-------------+		+-------------+ +-------------+
	E2E and HBH Keys Used for Authenticated Encryption of SRTP Packets		Figure 2: E2E and HBH Keys Used for Authenticated Encryption of SRTP
			Packets
	The PERC Double transform [I-D.ietf-perc-double] enables endpoints to		The PERC Double transform [I-D.ietf-perc-double] enables endpoints to
	perform encryption using both the E2E and HBH contexts while still		perform encryption using both the E2E and HBH contexts while still
	preserving the same overall interface as other SRTP transforms. The		preserving the same overall interface as other SRTP transforms. The
	Media Distributor simply uses the corresponding normal (single) AES-		Media Distributor simply uses the corresponding normal (single) AES-
	GCM transform, keyed with the appropriate HBH keys. See Appendix A		GCM transform, keyed with the appropriate HBH keys. See Appendix A
	for a description of the keys used in PERC and Appendix B for an		for a description of the keys used in PERC and Appendix B for an
	overview of how the packet appears on the wire.		overview of how the packet appears on the wire.
	RTCP can only be encrypted hop-by-hop, not end-to-end. This		RTCP can only be encrypted hop-by-hop, not end-to-end. This
	skipping to change at page 11, line 32 ¶		skipping to change at page 11, line 32 ¶
	+-----------+		+-----------+
	# ^ ^ #		# ^ ^ #
	# | | #--- Tunnel		# | | #--- Tunnel
	# | | #		# | | #
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	| Endpoint | DTLS | Media | DTLS | Endpoint |		| Endpoint | DTLS | Media | DTLS | Endpoint |
	| KEK |<------------|Distributor|------------>| KEK |		| KEK |<------------|Distributor|------------>| KEK |
	| HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key |		| HBH Key | to Key Dist | HBH Keys | to Key Dist | HBH Key |
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	Figure 2: Exchanging Key Information Between Entities		Figure 3: Exchanging Key Information Between Entities
	Endpoints will establish a DTLS-SRTP [RFC5764] association over the		Endpoints will establish a DTLS-SRTP [RFC5764] association over the
	RTP session's media ports for the purposes of key information		RTP session's media ports for the purposes of key information
	exchange with the Key Distributor. The Media Distributor will not		exchange with the Key Distributor. The Media Distributor will not
	terminate the DTLS signaling, but will instead forward DTLS packets		terminate the DTLS signaling, but will instead forward DTLS packets
	received from an endpoint on to the Key Distributor (and vice versa)		received from an endpoint on to the Key Distributor (and vice versa)
	via a tunnel established between Media Distributor and the Key		via a tunnel established between Media Distributor and the Key
	Distributor. This tunnel is used to encapsulate the DTLS-SRTP		Distributor. This tunnel is used to encapsulate the DTLS-SRTP
	signaling between the Key Distributor and endpoints will also be used		signaling between the Key Distributor and endpoints will also be used
	to convey HBH key information from the Key Distributor to the Media		to convey HBH key information from the Key Distributor to the Media
	skipping to change at page 17, line 18 ¶		skipping to change at page 17, line 18 ¶
	invaluable input on this document. Also, we would like to		invaluable input on this document. Also, we would like to
	acknowledge Nermeen Ismail for serving on the initial versions of		acknowledge Nermeen Ismail for serving on the initial versions of
	this document as a co-author.		this document as a co-author.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-perc-double]		[I-D.ietf-perc-double]
	Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP		Jennings, C., Jones, P., Barnes, R., and A. Roach, "SRTP
	Double Encryption Procedures", draft-ietf-perc-double-08		Double Encryption Procedures", draft-ietf-perc-double-09
	(work in progress), March 2018.		(work in progress), May 2018.
	[I-D.ietf-perc-dtls-tunnel]		[I-D.ietf-perc-dtls-tunnel]
	Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel		Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
	between a Media Distributor and Key Distributor to		between a Media Distributor and Key Distributor to
	Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-02		Facilitate Key Exchange", draft-ietf-perc-dtls-tunnel-03
	(work in progress), October 2017.		(work in progress), April 2018.
	[I-D.ietf-perc-srtp-ekt-diet]		[I-D.ietf-perc-srtp-ekt-diet]
	Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F.		Jennings, C., Mattsson, J., McGrew, D., Wing, D., and F.
	Andreasen, "Encrypted Key Transport for DTLS and Secure		Andreasen, "Encrypted Key Transport for DTLS and Secure
	RTP", draft-ietf-perc-srtp-ekt-diet-07 (work in progress),		RTP", draft-ietf-perc-srtp-ekt-diet-08 (work in progress),
	March 2018.		July 2018.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
	Jacobson, "RTP: A Transport Protocol for Real-Time		Jacobson, "RTP: A Transport Protocol for Real-Time
	Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,		Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
	July 2003, <https://www.rfc-editor.org/info/rfc3550>.		July 2003, <https://www.rfc-editor.org/info/rfc3550>.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, DOI 10.17487/RFC3711, March 2004,
	<https://www.rfc-editor.org/info/rfc3711>.
	[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
	Security (DTLS) Extension to Establish Keys for the Secure
	Real-time Transport Protocol (SRTP)", RFC 5764,
	DOI 10.17487/RFC5764, May 2010,
	<https://www.rfc-editor.org/info/rfc5764>.
	[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure		[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
	Real-time Transport Protocol (SRTP)", RFC 6904,		Real-time Transport Protocol (SRTP)", RFC 6904,
	DOI 10.17487/RFC6904, April 2013,		DOI 10.17487/RFC6904, April 2013,
	<https://www.rfc-editor.org/info/rfc6904>.		<https://www.rfc-editor.org/info/rfc6904>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-rtcweb-security-arch]		[I-D.ietf-rtcweb-security-arch]
	Rescorla, E., "WebRTC Security Architecture", draft-ietf-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	rtcweb-security-arch-13 (work in progress), October 2017.		rtcweb-security-arch-15 (work in progress), July 2018.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<https://www.rfc-editor.org/info/rfc3261>.		<https://www.rfc-editor.org/info/rfc3261>.
			[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
			Norrman, "The Secure Real-time Transport Protocol (SRTP)",
			RFC 3711, DOI 10.17487/RFC3711, March 2004,
			<https://www.rfc-editor.org/info/rfc3711>.
	[RFC4353] Rosenberg, J., "A Framework for Conferencing with the		[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
	Session Initiation Protocol (SIP)", RFC 4353,		Session Initiation Protocol (SIP)", RFC 4353,
	DOI 10.17487/RFC4353, February 2006,		DOI 10.17487/RFC4353, February 2006,
	<https://www.rfc-editor.org/info/rfc4353>.		<https://www.rfc-editor.org/info/rfc4353>.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474,		Initiation Protocol (SIP)", RFC 4474,
	DOI 10.17487/RFC4474, August 2006,		DOI 10.17487/RFC4474, August 2006,
	<https://www.rfc-editor.org/info/rfc4474>.		<https://www.rfc-editor.org/info/rfc4474>.
	skipping to change at page 18, line 43 ¶		skipping to change at page 18, line 37 ¶
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, DOI 10.17487/RFC4566,		Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
	July 2006, <https://www.rfc-editor.org/info/rfc4566>.		July 2006, <https://www.rfc-editor.org/info/rfc4566>.
	[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework		[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
	for Establishing a Secure Real-time Transport Protocol		for Establishing a Secure Real-time Transport Protocol
	(SRTP) Security Context Using Datagram Transport Layer		(SRTP) Security Context Using Datagram Transport Layer
	Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May		Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
	2010, <https://www.rfc-editor.org/info/rfc5763>.		2010, <https://www.rfc-editor.org/info/rfc5763>.
			[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
			Security (DTLS) Extension to Establish Keys for the Secure
			Real-time Transport Protocol (SRTP)", RFC 5764,
			DOI 10.17487/RFC5764, May 2010,
			<https://www.rfc-editor.org/info/rfc5764>.
	[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time		[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
	Transport Protocol (RTP) Header Extension for Client-to-		Transport Protocol (RTP) Header Extension for Client-to-
	Mixer Audio Level Indication", RFC 6464,		Mixer Audio Level Indication", RFC 6464,
	DOI 10.17487/RFC6464, December 2011,		DOI 10.17487/RFC6464, December 2011,
	<https://www.rfc-editor.org/info/rfc6464>.		<https://www.rfc-editor.org/info/rfc6464>.
	[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,		[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
	DOI 10.17487/RFC7667, November 2015,		DOI 10.17487/RFC7667, November 2015,
	<https://www.rfc-editor.org/info/rfc7667>.		<https://www.rfc-editor.org/info/rfc7667>.
	Appendix A. PERC Key Inventory		Appendix A. PERC Key Inventory
	PERC specifies the use of a number of different keys and,		PERC specifies the use of a number of different keys and,
	understandably, it looks complicated or confusing on the surface.		understandably, it looks complicated or confusing on the surface.
	This section summarizes the various keys used in the system, how they		This section summarizes the various keys used in the system, how they
	are generated, and what purpose they serve.		are generated, and what purpose they serve.
	The keys are described in the order in which they would typically be		The keys are described in the order in which they would typically be
	acquired.		acquired.
	The various keys used in PERC are shown in Figure 3 below.		The various keys used in PERC are shown in Figure 4 below.
	+-----------+----------------------------------------------------+		+-----------+----------------------------------------------------+
	| Key | Description |		| Key | Description |
	+-----------+----------------------------------------------------+		+-----------+----------------------------------------------------+
	| KEK | Key shared by all endpoints and used to encrypt |		| KEK | Key shared by all endpoints and used to encrypt |
	| (EKT Key) | each endpoint's SRTP master key so receiving |		| (EKT Key) | each endpoint's SRTP master key so receiving |
	| | endpoints can decrypt media. |		| | endpoints can decrypt media. |
	+-----------+----------------------------------------------------+		+-----------+----------------------------------------------------+
	| HBH Key | Key used to encrypt media hop-by-hop. |		| HBH Key | Key used to encrypt media hop-by-hop. |
	+-----------+----------------------------------------------------+		+-----------+----------------------------------------------------+
	| E2E Key | Key used to encrypt media end-to-end. |		| E2E Key | Key used to encrypt media end-to-end. |
	+-----------+----------------------------------------------------+		+-----------+----------------------------------------------------+
	Figure 3: Key Inventory		Figure 4: Key Inventory
	As you can see, the number key types is very small. However, what		As you can see, the number key types is very small. However, what
	can be challenging is keeping track of all of the distinct E2E keys		can be challenging is keeping track of all of the distinct E2E keys
	as the conference grows in size. With 1,000 participants in a		as the conference grows in size. With 1,000 participants in a
	conference, there will be 1,000 distinct SRTP master keys, all of		conference, there will be 1,000 distinct SRTP master keys, all of
	which share the same master salt. Each of those keys are passed		which share the same master salt. Each of those keys are passed
	through the KDF defined in [RFC3711] to produce the actual encryption		through the KDF defined in [RFC3711] to produce the actual encryption
	and authentication keys. Complicating key management is the fact		and authentication keys. Complicating key management is the fact
	that the KEK can change and, when it does, the endpoints generate new		that the KEK can change and, when it does, the endpoints generate new
	SRTP master keys. And, of course, there is a new SRTP master salt to		SRTP master keys. And, of course, there is a new SRTP master salt to
	skipping to change at page 22, line 12 ¶		skipping to change at page 22, line 12 ¶
	Every HBH key is distinct for a given endpoint, thus Endpoint A and		Every HBH key is distinct for a given endpoint, thus Endpoint A and
	endpoint B do not have knowledge of the other's HBH key.		endpoint B do not have knowledge of the other's HBH key.
	Each endpoint generates its own E2E Key (SRTP master key), thus the		Each endpoint generates its own E2E Key (SRTP master key), thus the
	key distinct per endpoint. This key is transmitted (encrypted) via		key distinct per endpoint. This key is transmitted (encrypted) via
	the EKT Field to other endpoints. Endpoints that receive media from		the EKT Field to other endpoints. Endpoints that receive media from
	a given transmitting endpoint will therefore have knowledge of the		a given transmitting endpoint will therefore have knowledge of the
	transmitter's E2E key.		transmitter's E2E key.
	To summarize the various keys and which entity is in possession of a		To summarize the various keys and which entity is in possession of a
	given key, refer to Figure 4.		given key, refer to Figure 5.
	+----------------------+------------+-------+-------+------------+		+----------------------+------------+-------+-------+------------+
	| Key / Entity | Endpoint A | MD X | MD Y | Endpoint B |		| Key / Entity | Endpoint A | MD X | MD Y | Endpoint B |
	+----------------------+------------+-------+-------+------------+		+----------------------+------------+-------+-------+------------+
	| KEK | Yes | No | No | Yes |		| KEK | Yes | No | No | Yes |
	+----------------------+------------+-------+-------+------------+		+----------------------+------------+-------+-------+------------+
	| E2E Key (A and B) | Yes | No | No | Yes |		| E2E Key (A and B) | Yes | No | No | Yes |
	+----------------------+------------+-------+-------+------------+		+----------------------+------------+-------+-------+------------+
	| HBH Key (A<=>MD X) | Yes | Yes | No | No |		| HBH Key (A<=>MD X) | Yes | Yes | No | No |
	+----------------------+------------+-------+-------+------------+		+----------------------+------------+-------+-------+------------+
	| HBH Key (B<=>MD Y) | No | No | Yes | Yes |		| HBH Key (B<=>MD Y) | No | No | Yes | Yes |
	+----------------------+------------+---------------+------------+		+----------------------+------------+---------------+------------+
	| HBH Key (MD X<=>MD Y)| No | Yes | Yes | No |		| HBH Key (MD X<=>MD Y)| No | Yes | Yes | No |
	+----------------------+------------+---------------+------------+		+----------------------+------------+---------------+------------+
	Figure 4: Keys per Entity		Figure 5: Keys per Entity
	Appendix B. PERC Packet Format		Appendix B. PERC Packet Format
	Figure 5 presents a complete picture of what a PERC packet looks like		Figure 6 presents a complete picture of what a PERC packet looks like
	when transmitted over the wire.		when transmitted over the wire.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	A |V=2|P|X| CC |M| PT | sequence number |		A |V=2|P|X| CC |M| PT | sequence number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	A | timestamp |		A | timestamp |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	A | synchronization source (SSRC) identifier |		A | synchronization source (SSRC) identifier |
	skipping to change at page 23, line 34 ¶		skipping to change at page 23, line 34 ¶
	R : :		R : :
	R : EKT Field :		R : EKT Field :
	R : :		R : :
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	C = Ciphertext (encrypted and authenticated)		C = Ciphertext (encrypted and authenticated)
	A = Associated Data (authenticated only)		A = Associated Data (authenticated only)
	R = neither encrypted nor authenticated, added		R = neither encrypted nor authenticated, added
	after Authenticated Encryption completed		after Authenticated Encryption completed
	Figure 5: PERC Packet Format		Figure 6: PERC Packet Format
	Authors' Addresses		Authors' Addresses
	Paul E. Jones		Paul E. Jones
	Cisco		Cisco
	7025 Kit Creek Rd.		7025 Kit Creek Rd.
	Research Triangle Park, North Carolina 27709		Research Triangle Park, North Carolina 27709
	USA		USA
	Phone: +1 919 476 2048		Phone: +1 919 476 2048
	Email: paulej@packetizer.com		Email: paulej@packetizer.com
	David Benham
	Cisco
	170 West Tasman Drive
	San Jose, California 95134
	USA
	Email: dbenham@cisco.com		David Benham
			Independent
			Email: dabenham@gmail.com
	Christian Groves		Christian Groves
	Independent		Independent
	Melbourne		Melbourne
	Australia		Australia
	Email: Christian.Groves@nteczone.com		Email: Christian.Groves@nteczone.com
End of changes. 23 change blocks.
	39 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/