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/