Subject: [AVT] Draft-ietf-avt-rtp-g719

From: Magnus Westerlund <[email-masked]>
Date: Fri, 12 Dec 2008 10:57:38 +0100

Hi,

The RTP payload for G.719 was approved by the IESG yesterday. In the
discussion we made one change to the document. The Security
consideration section was updated by taking the one from the RTP HOW TO
template and keeping the interleaving and confidentiality paragraph.
This resulted in the below RFC-editor note where you can read the
resulting text that replaces the whole body of the security consideration:

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.

I hope everyone is fine with this.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt