Protocol Action: 'RTP Payload format for G.719' to Proposed Standard

The IESG has approved the following document:

- 'RTP Payload format for G.719 '
   <draft-ietf-avt-rtp-g719-04.txt> as a Proposed Standard

This document is the product of the Audio/Video Transport Working Group. 

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g719-04.txt

 Technical Summary

 This document specifies the payload format for packetization of the
  G.719 full-band codec encoded audio signals into the Real-time
  Transport Protocol (RTP).  The payload format supports transmission
  of multiple channels, multiple frames per payload, and interleaving. 

Working Group Summary

This is a reasonably standard RTP payload format. The document has been
reviewed by the AVT working group and all open issues were addressed 

          Document Quality

Media type review was conducted starting September  18,  2008, with no 
objections raised.  Vendors who contributed to the G.719 specification
have
indicated their intent to support this payload.

          Personnel

Roni Even is the document shepherd. 
The responsible area director is Cullen Jennings.

RFC Editor Note

Section 10:
OLD:

  RTP packets using the payload format defined in this specification
  are subject to the general security considerations discussed in RTP
  [RFC3550] and any applicable profile such as AVP [RFC3551] or SAVP
  [RFC3711].  As this format transports encoded audio, the main
  security issues include confidentiality, integrity protection, and
  data origin authentication of the audio itself.  The payload format
  itself does not have any built-in security mechanisms.  Any suitable
  external mechanisms, such as SRTP [RFC3711], MAY be used.

  This payload format and the G.719 decoder do not exhibit any
  significant non-uniformity in the receiver-side computational
  complexity for packet processing, and thus are unlikely to pose a
  denial-of-service threat due to the receipt of pathological data.
  The payload format or the codec data does not contain any type of
  active content such as scripts.

10.1. Confidentiality

  In order to ensure confidentiality of the encoded audio, all audio
  data bits MUST be encrypted.  There is less need to encrypt the
  payload header or the table of contents since they only carry
  information about the frame type.  This information could also be
  useful to a third party, for example, for quality monitoring.
  However, as there currently don't exist any mechanism supporting
  differential protection, this behavior isn't expected to be supported
  and requirement of the audio data will be what governs the protection
  of the RTP payload.

  The use of interleaving in conjunction with encryption can have a
  negative impact on confidentiality, for a short period of time.
  Consider the following packets (in brackets) containing frame numbers
  as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a popular
  continuous diagonal interleaving pattern).  The originator wishes to
  deny some participants the ability to hear material starting at time
  16.  Simply changing the key on the packet with the timestamp at or
  after 16, and denying that new key to those participants, does not
  achieve this; frames 17, 18, and 21 have been supplied in prior
  packets under the prior key, and error concealment may make the audio
  intelligible at least as far as frame 18 or 19, and possibly further.

10.2. Authentication and Integrity

  To authenticate the sender of the audio-stream, an external mechanism
  MUST be used.  It is RECOMMENDED that such a mechanism protects both
  the complete RTP header and the payload (audio and data bits).  Data
  tampering by a man-in-the-middle attacker could replace audio content
  and also result in erroneous depacketization/decoding that could
  lower the audio quality.

NEW:

  RTP packets using the payload format defined in this specification
  are subject to the security considerations discussed in the RTP
  specification [RFC3550] , and in any applicable RTP profile.  The
  main security considerations for the RTP packet carrying the RTP
  payload format defined within this memo are confidentiality,
  integrity and source authenticity.  Confidentiality is achieved by
  encryption of the RTP payload.  Integrity of the RTP packets through
  suitable cryptographic integrity protection mechanism.  Cryptographic
  system may also allow the authentication of the source of the
  payload.  A suitable security mechanism for this RTP payload format
  should provide confidentiality, integrity protection and at least
  source authentication capable of determining if an RTP packet is from
  a member of the RTP session or not.

  Note that the appropriate mechanism to provide security to RTP and
  payloads following this memo may vary.  It is dependent on the
  application, the transport, and the signalling protocol employed.
  Therefore a single mechanism is not sufficient, although if suitable
  the usage of SRTP [RFC3711] is recommended.  Other mechanism that may
  be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but
  also other alternatives may exist.

  The use of interleaving in conjunction with encryption can have a
  negative impact on confidentiality, for a short period of time.
  Consider the following packets (in brackets) containing frame numbers
  as indicated: {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (a popular
  continuous diagonal interleaving pattern).  The originator wishes to
  deny some participants the ability to hear material starting at time
  16.  Simply changing the key on the packet with the timestamp at or
  after 16, and denying that new key to those participants, does not
  achieve this; frames 17, 18, and 21 have been supplied in prior
  packets under the prior key, and error concealment may make the audio
  intelligible at least as far as frame 18 or 19, and possibly further.

  This RTP payload format and its media decoder do not exhibit any
  significant non-uniformity in the receiver-side computational
  complexity for packet processing, and thus are unlikely to pose a
  denial-of-service threat due to the receipt of pathological data.
  Nor does the RTP payload format contain any active content.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce