From kevin.gross@avanw.com Tue Oct 1 08:58:53 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7601111E81B9 for ; Tue, 1 Oct 2013 08:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.014 X-Spam-Level: **** X-Spam-Status: No, score=4.014 tagged_above=-999 required=5 tests=[AWL=3.828, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIjbBMrnegIg for ; Tue, 1 Oct 2013 08:58:44 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by ietfa.amsl.com (Postfix) with ESMTP id DC07011E8153 for ; Tue, 1 Oct 2013 08:58:42 -0700 (PDT) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta10.emeryville.ca.mail.comcast.net with comcast id Xpc41m0021Y3wxoAAryi1B; Tue, 01 Oct 2013 15:58:42 +0000 Received: from mail-wg0-x230.google.com ([IPv6:2a00:1450:400c:c00::230]) by omta15.emeryville.ca.mail.comcast.net with comcast id Xryg1m00643KiFR8bryhqV; Tue, 01 Oct 2013 15:58:42 +0000 Received: by mail-wg0-f48.google.com with SMTP id n12so7538349wgh.15 for ; Tue, 01 Oct 2013 08:58:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rTSqVUz2y+j/vqRO6vJSJX8lBugT3jw31zFfLM2dY8Q=; b=UqdsQidwHLpnyxYswJC61FlYNGYCZA/O05NAO0E3Q9754MQ2sp1zZT34AyjKDSA7a9 dIOdbIo1DwjqZbcimBw80oY/Gpx56KWzS3PISxvOODq8C/j0uNq3iCEAuUkgKQJrih8G 8/Ufqp/eSZFW/ycjT3OL226rRaB7k/GY550L7zDAlyd+CnZp93KTJaPBC/qj8gEnT3/8 cQA9gu1EvHgt6o2c5dU0zW1uKo61y1UQB4of4PJhHJpeDVGg2T8nt/Ao8oR1kYhX8AYO M6AQnMpmiHrH+P86F2/GjUJNNfxxN4PVjNTo2oDue4bvOsmDuHRiJthYYZo5NM0RQHRO TPXQ== MIME-Version: 1.0 X-Received: by 10.194.250.6 with SMTP id yy6mr23379941wjc.13.1380643119755; Tue, 01 Oct 2013 08:58:39 -0700 (PDT) Received: by 10.216.97.1 with HTTP; Tue, 1 Oct 2013 08:58:39 -0700 (PDT) In-Reply-To: <5230CB8B.5070202@cs.ucla.edu> References: <5230CB8B.5070202@cs.ucla.edu> Date: Tue, 1 Oct 2013 09:58:39 -0600 Message-ID: From: Kevin Gross To: "avt@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1ba4ab6f9ca04e7b00676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380643122; bh=rTSqVUz2y+j/vqRO6vJSJX8lBugT3jw31zFfLM2dY8Q=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=ke6BI2KIyYBxSj1su3Ymfvu02o9BuA/4D44uVnKpZsm3+4srNfGGceXiWckazLGAc njz+tTVYdhpEMhowT65cIvwT7B5+2vZ8KaA5eGaZsmL++0JYS3jLdvarW9R51Vg2VV c569NrHiJX/aOxEraNL7B3OTk0Kpsed2etXnM3n1DFf7hAWuS/vZ0W+ebJZ5GXLwSL XkL7QeasOB/KTDTZenmRbFIVKsoL67oA8zRkQXVTCObkZaGSLXtUs2o0ij5zyYSsS6 aeTmERTANtHzCKyUbgciu4lsujeV7HmwV5aTaAm+iLAdMhXBk14SaQEG3c+nDw0cev t+ZJ+7ozW9P0Q== Cc: Paul Eggert Subject: [AVTCORE] Fwd: POSIX time in draft-ietf-avtcore-leap-second-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 15:58:53 -0000 --001a11c1ba4ab6f9ca04e7b00676 Content-Type: text/plain; charset=ISO-8859-1 I received some comments on my leap seconds draft from Paul Eggart. I am submittig a new revision which adds three new references, brings the POSIX discussion in line with IEEE 1003.1 and mentions the warping techniques. Are there any other last-call comments from the group? Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com ---------- Forwarded message ---------- From: Paul Eggert Date: Wed, Sep 11, 2013 at 1:59 PM Subject: POSIX time in draft-ietf-avtcore-leap-second-04 To: Kevin Gross Cc: Ray van Brandenburg The topic of POSIX time came up recently on the IANA tz list and draft-ietf-avtcore-leap-second-04 was mentioned . I think it'd be helpful to cover the newly-raised points in the draft. Perhaps something like the following? --- draft-ietf-avtcore-leap-second-04.txt 2013-08-27 08:31:12.000000000 -0700 +++ new.txt 2013-09-11 12:56:46.328133398 -0700 @@ -157,12 +157,18 @@ Internet-Draft RTP Leap Sec 3.3. POSIX behavior during positive leap second - Most POSIX systems insert the positive leap second at the end of the + Strictly speaking, POSIX systems are supposed to insert the + positive leap second at the end of the last second of the day. This results in repetition of the last second. A timestamp within the last second of the day is therefore ambiguous in that it can refer to a moment in time in either of the last two seconds of a day containing a leap second. + In practice, many POSIX systems ignore this requirement, and + instead use a monotone-definite-increasing approximation to POSIX + time, e.g., by adding infinitesimal amounts to the POSIX clock + whenever the time is requested during a leap second,[9] or by + smearing the POSIX clock linearly near the transition.[10,11] Gross & van Brandenburg Expires February 28, 2014 [Page 3] @@ -181,7 +187,7 @@ Internet-Draft RTP Leap Sec second intervals. +-------+--------------+--------------+--------------+--------------+ - | RTP | TAI | UTC | POSIX | NTP | + | RTP | TAI | UTC | POSIX* | NTP | +-------+--------------+--------------+--------------+--------------+ | 8000 | 00:00:32.500 | 23:59:58.500 | 23:59:58.500 | 23:59:58.500 | | 12000 | 00:00:33.000 | 23:59:59.000 | 23:59:59.000 | 23:59:59.000 | @@ -194,15 +200,21 @@ Internet-Draft RTP Leap Sec Table 1 - NOTE- Some NTP implementations do not entirely freeze the clock while + NOTE 1- Some NTP implementations do not entirely freeze the clock while the leap second is inserted. Successive calls to retrieve system time return infinitesimally larger (e.g. 1 microsecond or 1 nanosecond larger) time values. This behavior is designed to satisfy - assumptions applications may make that time increases monotonically. + assumptions applications may make that time increases monotonically.[9] This behavior occurs in the least-significant bits of the time value and so is not typically visible in the human-readable format shown in the table. + NOTE 2- Some other implementations use a linear smearing near the + transition. This lessens interval-length error as well as + satisfying monotonicity.[10,11] This behavior may affect the + low-order human-readable bits of the POSIX time values shown + in Table 1. + 4. Receiver behavior during leap second Timestamps generated during a leap second may be ambiguous or @@ -380,6 +392,19 @@ Internet-Draft RTP Leap Sec [8] BIPM, "Circular T", May 2012. + [9] Mills, D., "The NTP Timescale and Leap Seconds", + , + 12 May 2012 23:43 UTC, retrieved 11 September 2013. + + [10] Kuhn, M., "Coordinated Universal Time with Smoothed Leap + Seconds (UTC-SLS)", January 2006, Internet Draft, + . + + [11] Pascoe, C., "Time, technology and leaping seconds", + 15 September 2011, Google Official Blog, + < http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html >, + retrieved 11 September 2013. + Authors' Addresses --001a11c1ba4ab6f9ca04e7b00676 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I received some comments on my leap seconds draft from Pau= l Eggart. I am submittig a new revision which adds three new references, br= ings the POSIX discussion in line with IEEE 1003.1 and mentions the warping= techniques.

Are there any other last-call comments from the group?

Kevin Gross
+1-303-447-0= 517
Media Network Consultant
AVA Networks -=A0www.AVAnw.com


---------- Forwarded message ----------<= br>From: Paul Eggert &l= t;eggert@cs.ucla.edu>Date: Wed, Sep 11, 2013 at 1:59 PM
Subject: POSIX time in draft-ietf-avtcore-leap-second-04
To: Kevin Gross= <kevin.gross@avanw.com>=
Cc: Ray van Brandenburg <ray.vanbrandenburg@tno.nl>


The topic of POSIX time came up recently on the IANA tz list
and draft-ietf-avtcore-leap-second-04 was mentioned
<http://mm.icann.org/pipermail/tz/2013-September/020156.h= tml>
<http://mm.icann.org/pipermail/tz/2013-September/020158.h= tml>.
I think it'd be helpful to cover the newly-raised points in the draft.<= br> Perhaps something like the following?

--- draft-ietf-avtcore-leap-second-04.txt =A0 =A02013-08-27
08:31:12.000000000 -0700
+++ new.txt =A0 =A02013-09-11 12:56:46.328133398 -0700
@@ -157,12 +157,18 @@ Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0RTP Leap Se= c

=A03.3. =A0POSIX behavior during positive leap second

- =A0 Most POSIX systems insert the positive leap second at the end of the<= br> + =A0 Strictly speaking, POSIX systems are supposed to insert the
+ =A0 positive leap second at the end of the
=A0 =A0 last second of the day. =A0This results in repetition of the last =A0 =A0 second. =A0A timestamp within the last second of the day is therefo= re
=A0 =A0 ambiguous in that it can refer to a moment in time in either of the=
=A0 =A0 last two seconds of a day containing a leap second.

+ =A0 In practice, many POSIX systems ignore this requirement, and
+ =A0 instead use a monotone-definite-increasing approximation to POSIX
+ =A0 time, e.g., by adding infinitesimal amounts to the POSIX clock
+ =A0 whenever the time is requested during a leap second,[9] or by
+ =A0 smearing the POSIX clock linearly near the transition.[10,11]


=A0Gross & van Brandenburg Expires February 28, 2014 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 [Page 3]
@@ -181,7 +187,7 @@ Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0RTP Leap Sec<= br> =A0 =A0 second intervals.

=A0 =A0 +-------+--------------+--------------+--------------+-------------= -+
- =A0 | =A0RTP =A0| =A0 =A0 TAI =A0 =A0 =A0| =A0 =A0 UTC =A0 =A0 =A0| =A0 = =A0POSIX =A0 =A0 | =A0 =A0 NTP =A0 =A0 =A0|
+ =A0 | =A0RTP =A0| =A0 =A0 TAI =A0 =A0 =A0| =A0 =A0 UTC =A0 =A0 =A0| =A0 = =A0POSIX* =A0 =A0| =A0 =A0 NTP =A0 =A0 =A0|
=A0 =A0 +-------+--------------+--------------+--------------+-------------= -+
=A0 =A0 | =A08000 | 00:00:32.500 | 23:59:58.500 | 23:59:58.500 | 23:59:58.5= 00 |
=A0 =A0 | 12000 | 00:00:33.000 | 23:59:59.000 | 23:59:59.000 | 23:59:59.000= |
@@ -194,15 +200,21 @@ Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0RTP Leap Se= c

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tabl= e 1

- =A0 NOTE- Some NTP implementations do not entirely freeze the clock while=
+ =A0 NOTE 1- Some NTP implementations do not entirely freeze the clock whi= le
=A0 =A0 the leap second is inserted. =A0Successive calls to retrieve system=
=A0 =A0 time return infinitesimally larger (e.g. 1 microsecond or 1
=A0 =A0 nanosecond larger) time values. =A0This behavior is designed to sat= isfy
- =A0 assumptions applications may make that time increases monotonically.<= br> + =A0 assumptions applications may make that time increases monotonically.[= 9]
=A0 =A0 This behavior occurs in the least-significant bits of the time valu= e
=A0 =A0 and so is not typically visible in the human-readable format shown = in
=A0 =A0 the table.

+ =A0 NOTE 2- Some other implementations use a linear smearing near the
+ =A0 transition. =A0This lessens interval-length error as well as
+ =A0 satisfying monotonicity.[10,11] =A0This behavior may affect the
+ =A0 low-order human-readable bits of the POSIX time values shown
+ =A0 in Table 1.
+
=A04. =A0Receiver behavior during leap second

=A0 =A0 Timestamps generated during a leap second may be ambiguous or
@@ -380,6 +392,19 @@ Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0RTP Leap Sec=

=A0 =A0 [8] =A0 =A0 =A0 =A0BIPM, "Circular T", May 2012.

+ =A0 [9] =A0 =A0 =A0 =A0Mills, D., "The NTP Timescale and Leap Second= s",
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0<http://www.eecis.udel.edu/~mills/leap.html>,
+ =A0 =A0 =A0 =A0 =A0 =A0 =A012 May 2012 23:43 UTC, retrieved 11 September = 2013.
+
+ =A0 [10] =A0 =A0 =A0 Kuhn, M., "Coordinated Universal Time with Smoo= thed Leap
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0Seconds (UTC-SLS)", January 2006, Interne= t Draft,
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0<http://tools.ietf.org/html/draft-ku= hn-leapsecond-00>.
+
+ =A0 [11] =A0 =A0 =A0 Pascoe, C., "Time, technology and leaping secon= ds",
+ =A0 =A0 =A0 =A0 =A0 =A0 =A015 September 2011, Google Official Blog,
+
<http://googleblog.blogspot.com/2011/= 09/time-technology-and-leaping-seconds.html>,
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0retrieved 11 September 2013.
+
=A0Authors' Addresses




--001a11c1ba4ab6f9ca04e7b00676-- From internet-drafts@ietf.org Tue Oct 1 09:07:37 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04BA11E8143; Tue, 1 Oct 2013 09:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN-nbDB88Eqc; Tue, 1 Oct 2013 09:07:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E9121E805F; Tue, 1 Oct 2013 09:07:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131001160737.21382.20160.idtracker@ietfa.amsl.com> Date: Tue, 01 Oct 2013 09:07:37 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-leap-second-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 16:07:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP and Leap Seconds Author(s) : Kevin Gross Ray van Brandenburg Filename : draft-ietf-avtcore-leap-second-05.txt Pages : 8 Date : 2013-10-01 Abstract: This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders and receivers should behave in the presence of leap seconds. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-leap-second-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mpeck@mitre.org Wed Oct 2 08:23:29 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9EB21F8B4E for ; Wed, 2 Oct 2013 08:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkuH8pO3+orX for ; Wed, 2 Oct 2013 08:23:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4965121F9385 for ; Wed, 2 Oct 2013 08:22:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1879E1F0640 for ; Wed, 2 Oct 2013 11:22:37 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 090A21F0728 for ; Wed, 2 Oct 2013 11:22:37 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.65]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0158.001; Wed, 2 Oct 2013 11:22:36 -0400 From: "Peck, Michael A" To: "avt@ietf.org" Thread-Topic: draft-ietf-avtcore-rtp-security-options-06 review Thread-Index: AQHOv4M4GbdvZePjLUiH9aLkz6HuUA== Date: Wed, 2 Oct 2013 15:22:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [128.29.194.92] Content-Type: multipart/alternative; boundary="_000_CE71A95A68A1mpeckmitreorg_" MIME-Version: 1.0 Subject: [AVTCORE] draft-ietf-avtcore-rtp-security-options-06 review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 15:23:29 -0000 --_000_CE71A95A68A1mpeckmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I reviewed draft-ietf-avtcore-rtp-security-options-06. It looks good, I ha= ve a few minor comments. Section 3.1: I suggest removing the phrase "=85and NSA Suite B included cryptographic tr= ansforms." from the "AES-192 and AES-256:" paragraph. The RFC6188 crypto suites are technically not Suite B compliant because the= y use HMAC-SHA1 for authentication, and SHA-1 is not part of Suite B. Section 3.3: Another downside of IPsec perhaps worth pointing out is that if it's relied= upon instead of a higher layer mechanism, information about the authentica= ted identities of the endpoints, or an indication of whether encryption is = even in place at all, are generally not available at the application layer = to present through the user interface. Editorial comments: Introduction: "so it worth" -> "so it is worth" 3.6: "such the fact" -> "such as the fact" --_000_CE71A95A68A1mpeckmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5ACE0C3FD730594E885A1FC8194E5652@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
Hi,

I reviewed draft-ietf-avtcore-rtp-security-options-06.  It looks = good, I have a few minor comments.

Section 3.1: 
I suggest removing the phrase "=85and NSA Suite B included crypto= graphic transforms." from the "AES-192 and AES-256:" paragra= ph.
The RFC6188 crypto suites are technically not Suite B compliant becaus= e they use HMAC-SHA1 for authentication, and SHA-1 is not part of Suite B.<= /div>

Section 3.3:
Another downside of IPsec perhaps worth pointing out is that if it's r= elied upon instead of a higher layer mechanism, information about the authe= nticated identities of the endpoints, or an indication of whether encryptio= n is even in place at all, are generally not available at the application layer to present through the user interfa= ce.

Editorial comments:

Introduction:
"so it worth" -> "so it is worth"

3.6:
"such the fact" -> "such as the fact"


--_000_CE71A95A68A1mpeckmitreorg_-- From internet-drafts@ietf.org Wed Oct 2 08:27:20 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2040E21F9CA4; Wed, 2 Oct 2013 08:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.349 X-Spam-Level: X-Spam-Status: No, score=-98.349 tagged_above=-999 required=5 tests=[AWL=-4.081, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, NO_RELAYS=-0.001, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iKcPbwQI94S; Wed, 2 Oct 2013 08:27:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F4721F92E7; Wed, 2 Oct 2013 08:24:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131002152422.20697.17802.idtracker@ietfa.amsl.com> Date: Wed, 02 Oct 2013 08:24:22 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 15:27:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP Clock Source Signalling Author(s) : Aidan Williams Kevin Gross Ray van Brandenburg Hans Stokking Filename : draft-ietf-avtcore-clksrc-07.txt Pages : 27 Date : 2013-10-02 Abstract: NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies SDP signalling identifying timestamp reference clock sources and SDP signalling identifying the media clock sources in a multimedia session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-clksrc-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From foleyj@cisco.com Wed Oct 2 04:46:48 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F8621F9360 for ; Wed, 2 Oct 2013 04:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qASECze-zPet for ; Wed, 2 Oct 2013 04:46:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DDE6221F9343 for ; Wed, 2 Oct 2013 04:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=441; q=dns/txt; s=iport; t=1380714378; x=1381923978; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=C7W7W3xxU6qGyu9LnpUhG6E2YMrZLMw/c2rCzfotKsU=; b=b8HJyqJ9HYuhcjsSTuXQMBhpMeP6gQUNxqV1jnFOCXeijUq7108I1vNX XGr1LF/i2ZjSp3kmr8GssOl/4o17znUI0osW7v9JJ/XuMYIJb+VhP675S TSiP2nPL/hD3U3zlvDFOSLAmiJyF8eH6rAz01HY2EpvkQ5Wxk1u6hjnuC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAUHTFKtJXG9/2dsb2JhbABYgwc4wn8WdIMfBT0WGAMCAQIBWAgBAYgCDJtVoTwEj26EDQOXf4Yzi0iDQCA X-IronPort-AV: E=Sophos;i="4.90,1018,1371081600"; d="scan'208";a="267042553" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 02 Oct 2013 11:46:16 +0000 Received: from [10.82.251.101] (rtp-vpn6-866.cisco.com [10.82.251.101]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r92BkFur031018 for ; Wed, 2 Oct 2013 11:46:15 GMT Message-ID: <524C0786.4050409@cisco.com> Date: Wed, 02 Oct 2013 07:46:14 -0400 From: John Foley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: avt@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 02 Oct 2013 09:38:52 -0700 Subject: [AVTCORE] [draft-ietf-avtcore-srtp-aes-gcm] now available in libsrtp X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 11:46:48 -0000 Hello WG: For those of you that may be interested, support for GCM mode as defined in [draft-ietf-avtcore-srtp-aes-gcm-07] has been added to libsrtp. This is available in the feature-openssl branch of libsrtp on Github at the following location: https://github.com/cisco/libsrtp/tree/feature-openssl Please be aware that support for GCM mode requires linking libsrtp against OpenSSL (libcrypto.so). Sincerely, John Foley From magnus.westerlund@ericsson.com Mon Oct 7 01:58:57 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FF921E80F5 for ; Mon, 7 Oct 2013 01:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.154 X-Spam-Level: X-Spam-Status: No, score=-105.154 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXrh9ePK9L3m for ; Mon, 7 Oct 2013 01:58:50 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B21E921E80FD for ; Mon, 7 Oct 2013 01:58:49 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-87-525277c7e0e0 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CD.59.16099.7C772525; Mon, 7 Oct 2013 10:58:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Mon, 7 Oct 2013 10:58:47 +0200 Message-ID: <525277F6.2020104@ericsson.com> Date: Mon, 7 Oct 2013 10:59:34 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Peck, Michael A" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VvdEeVCQwQlBi5c9K9ktTt96zuzA 5LFkyU8mj7cNV9kDmKK4bFJSczLLUov07RK4MnqO/mMqOCdY0XV2GnsD40S+LkZODgkBE4n/ s2azQNhiEhfurWfrYuTiEBI4zCjx4NETVghnGaPE1YMdjCBVvALaEtP+/QGzWQRUJLb/fscK YrMJWEjc/NHIBmKLCgRLtG//ygZRLyhxcuYTsA0iAuoSfYd7gGwODmYBRYlJ7ZIgYWEBD4kD +56ClQgBjV8/4SeYzSmgI7F0wQV2iOMkJbYtOgZmMwsYSBxZNIcVwpaXaN46mxmmt6Gpg3UC o9AsJJtnIWmZhaRlASPzKkb23MTMnPRyw02MwEA9uOW37g7GU+dEDjFKc7AoifN+eOscJCSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoGx9MmELOtFi3z5oq9M1BaPTl2+RcOCRU+bW+2Iwu7j st9qI3cZi7LZZ587bMFzR2eX/Gv2hhlFZ3Zsn512qOb61wdflV9zPxYt+F977PWGHi9Z05Qn DydOc7zI6Xwx/fY7xa/8l90tPaqmuJgc5rhazC5o0jHRzW6LwqMDXHHn9jxXaxRcsf+SEktx RqKhFnNRcSIAwHUh5yICAAA= Cc: "avt@ietf.org" Subject: Re: [AVTCORE] draft-ietf-avtcore-rtp-security-options-06 review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 08:58:57 -0000 Hi Michael, Thanks for the review. On 2013-10-02 17:22, Peck, Michael A wrote: > Hi, > > I reviewed draft-ietf-avtcore-rtp-security-options-06. It looks good, I > have a few minor comments. > > Section 3.1: > I suggest removing the phrase "…and NSA Suite B included cryptographic > transforms." from the "AES-192 and AES-256:" paragraph. > The RFC6188 crypto suites are technically not Suite B compliant because > they use HMAC-SHA1 for authentication, and SHA-1 is not part of Suite B. Ok, done. > > Section 3.3: > Another downside of IPsec perhaps worth pointing out is that if it's > relied upon instead of a higher layer mechanism, information about the > authenticated identities of the endpoints, or an indication of whether > encryption is even in place at all, are generally not available at the > application layer to present through the user interface. I have added a sentence to the end of this paragraph: The main concern with using IPsec to protect RTP traffic is that in most cases using a VPN approach that terminates the security association at some node prior to the RTP end-point leaves the traffic vulnerable to attack between the VPN termination node and the end-point. Thus usage of IPsec requires careful thought and design of its usage so that it meets the security goals. A important question is how one ensures the IPsec terminating peer and the ultimate destination are the same. Applications can have issues using existing APIs with determining if IPsec is being used or not, and when used who the authenticated peer entity is. Below has been edited in. > > Editorial comments: > > Introduction: > "so it worth" -> "so it is worth" > > 3.6: > "such the fact" -> "such as the fact" > Cheers Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Mon Oct 7 02:14:05 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A749B21E81B1; Mon, 7 Oct 2013 02:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTgx0AVHnCvm; Mon, 7 Oct 2013 02:14:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3283521E81AE; Mon, 7 Oct 2013 02:14:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131007091403.16131.49959.idtracker@ietfa.amsl.com> Date: Mon, 07 Oct 2013 02:14:03 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 09:14:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Options for Securing RTP Sessions Author(s) : Magnus Westerlund Colin Perkins Filename : draft-ietf-avtcore-rtp-security-options-07.txt Pages : 32 Date : 2013-10-07 Abstract: The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity and source authentication of RTP/RTCP packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP, and gives guidance for developers on how to choose the appropriate security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-security-options-= 07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Mon Oct 7 02:17:35 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D657521E81B7 for ; Mon, 7 Oct 2013 02:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEMDiDpnUO5L for ; Mon, 7 Oct 2013 02:17:28 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5E80521E81AA for ; Mon, 7 Oct 2013 02:17:26 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-7b-52527c257d37 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 9A.9A.25272.52C72525; Mon, 7 Oct 2013 11:17:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.328.9; Mon, 7 Oct 2013 11:17:24 +0200 Message-ID: <52527C54.3070409@ericsson.com> Date: Mon, 7 Oct 2013 11:18:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: IETF AVTCore WG References: <20131007091403.16131.49959.idtracker@ietfa.amsl.com> In-Reply-To: <20131007091403.16131.49959.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+Jvra5qTVCQwcEL4hYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/HUooJG8YrHvx+wNTBuF+pi5OSQEDCR2DDzKBuELSZx4d56 IJuLQ0jgKKPE10MXmSGcZYwSi7d8ZgKp4hXQlji68Rs7iM0ioCKxcs0PsG42AQuJmz8awWxR gWCJ9u1f2SDqBSVOznzCAmKLCChJ7Ji0jRnEFhZwl+h99xBsjpCAo8S1k/sZQWxOASeJmbu6 2CEukpTYtugYmM0soCcx5WoLI4QtL9G8dTYzRK+2RENTB+sERsFZSNbNQtIyC0nLAkbmVYwc xanFSbnpRgabGIEBeHDLb4sdjJf/2hxilOZgURLn/fjWOUhIID2xJDU7NbUgtSi+qDQntfgQ IxMHp1QD495Zcvwt19+uF2UME+2cpM7KuJU9+unNqPbAkkU/Zr89pGbxNXbn3gcCp+cXSE7/ ZjhpA1PMk57FE94b3lea+ucCd/XFCS39nlMtOaYnxP4NPiRT+V3269wr7y7NV5vE6fjw4IZV fbsqVk9g++Uv+m4FZ/LDJx+PxG0S1lq6WSOJIX3XMiXbR/1KLMUZiYZazEXFiQA4k39EDgIA AA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 09:17:35 -0000 WG, This update addressed Michael Peck's comments during the WG last call. We have also updated one reference to use the now published RFC, rather than draft (RFC 7022) and included a unused reference for what MBMS is rather than just the security reference. See the diff for the changes. Cheers Magnus On 2013-10-07 11:14, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Options for Securing RTP Sessions > Author(s) : Magnus Westerlund > Colin Perkins > Filename : draft-ietf-avtcore-rtp-security-options-07.txt > Pages : 32 > Date : 2013-10-07 > > Abstract: > The Real-time Transport Protocol (RTP) is used in a large number of > different application domains and environments. This heterogeneity > implies that different security mechanisms are needed to provide > services such as confidentiality, integrity and source authentication > of RTP/RTCP packets suitable for the various environments. The range > of solutions makes it difficult for RTP-based application developers > to pick the most suitable mechanism. This document provides an > overview of a number of security solutions for RTP, and gives > guidance for developers on how to choose the appropriate security > mechanism. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-security-options-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Wed Oct 9 09:08:53 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F89D21F9EAE; Wed, 9 Oct 2013 09:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uP+aaXrj054; Wed, 9 Oct 2013 09:08:42 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 12E7521F9B9F; Wed, 9 Oct 2013 09:07:19 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so1273361pab.27 for ; Wed, 09 Oct 2013 09:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=f7B2TOUpkGL8TTxJ9tvv0uTa64DB9G/QfBzCu49XyHg=; b=PfFXkdWJkxgiGWoYE+sQZnuu29XtpmPH6rfnxdhaB1UmNxl+tRPtlZa+40cYBJJTwW uOYcvRmd/D0vTVS32hNRb/6DOEQPtEiO7s3CUGOl+OiNBHvNHikmASByj8xpJs48aM4c RZeUQP7HRgyWCWS8SBt4Uc/b36OSqUbn1ei6Ck2tVuvoH75P9NZN5nl3LvZin7/SRVhS fexqi9w6GhyP9ApPaUpaUmtbL9Alu4m4AzT/5o9tjQKjf8Sbw7PIT1S4Cpc2aZ2gFPe5 Ozkv5HAxInbT7YApOyaXf18MfLAtFkp6FyVoUNFkNsbpU+c5pNPaQQLvqth1SEOwipAP lsQA== X-Received: by 10.68.28.36 with SMTP id y4mr2498131pbg.201.1381334838684; Wed, 09 Oct 2013 09:07:18 -0700 (PDT) Received: from RoniE ([59.37.12.1]) by mx.google.com with ESMTPSA id ye1sm55861864pab.19.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Oct 2013 09:07:17 -0700 (PDT) From: "Roni Even" To: Date: Wed, 9 Oct 2013 19:04:04 +0300 Message-ID: <007e01cec509$32acb540$98061fc0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01CEC522.57FAB090" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7FBop7wk2pTVLoSW2aKCqf/0iaxw== Content-Language: en-us Cc: payload@ietf.org Subject: [AVTCORE] AVTcore at IETF88 - agenda time requests X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 16:08:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007F_01CEC522.57FAB090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the preliminary agenda: Please send the WG chairs requests for agenda time. We may allocate some agenda time to payload based on available time avtcore Session Thursday , afternoon session II 15:20 - 17:20 Room Name: Regency C Some important dates: * 2013-10-11 (Friday): Final agenda to be published. * 2013-10-21 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 24:00, upload using IETF ID Submission Tool . * 2013-10-23 (Wednesday): Draft Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool . * 2013-10-25 (Friday): Early Bird registration and payment cut-off at UTC 24:00. * 2013-10-28 (Monday): Revised Working Group agendas due by UTC 24:00, upload using IETF Meeting Materials Management Tool . Roni Even AVTcore chair ------=_NextPart_000_007F_01CEC522.57FAB090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = preliminary agenda:

 

Please send = the WG chairs requests for agenda time. We may allocate some agenda time = to payload based on available time

 

    avtcore Session =

Thursday  , afternoon = session II 15:20 – 17:20

    Room Name: Regency = C

 

       =

Some important = dates:

 

  • 2013-10-11 = (Friday): Final = agenda to be published.
  • 2013-10-21 = (Monday): Internet = Draft submission cut-off (for all drafts, including -00) by UTC 24:00, = upload using IETF ID Submission = Tool.
  • 2013-10-23 = (Wednesday): Draft = Working Group agendas due by UTC 24:00, upload using IETF = Meeting Materials Management Tool.
  • 2013-10-25 = (Friday): Early Bird = registration and payment cut-off at UTC 24:00.
  • 2013-10-28 = (Monday): Revised = Working Group agendas due by UTC 24:00, upload using IETF = Meeting Materials Management Tool.

 

Roni Even =

AVTcore = chair

------=_NextPart_000_007F_01CEC522.57FAB090-- From magnus.westerlund@ericsson.com Wed Oct 9 23:56:38 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B09421F9E69 for ; Wed, 9 Oct 2013 23:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.088 X-Spam-Level: X-Spam-Status: No, score=-101.088 tagged_above=-999 required=5 tests=[AWL=-3.171, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUBI6KhR5pkG for ; Wed, 9 Oct 2013 23:56:33 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0EF21F9FCF for ; Wed, 9 Oct 2013 23:56:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-d3-52564f8c2d55 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8D.A2.16099.D8F46525; Thu, 10 Oct 2013 08:56:13 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.328.9; Thu, 10 Oct 2013 08:56:12 +0200 Message-ID: <52564FCB.7060101@ericsson.com> Date: Thu, 10 Oct 2013 08:57:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: IETF AVTCore WG References: <20131002152422.20697.17802.idtracker@ietfa.amsl.com> In-Reply-To: <20131002152422.20697.17802.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+JvrW6vf1iQQe8zXouXPSvZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcf7FXMaCR0IVp1crNzCe5+ti5OSQEDCR2Lh8FSOELSZx4d56 ti5GLg4hgcOMEsv/zmIDSQgJLGeU2D23FMTmFdCW+LR0LlgDi4CqxMyv05hBbDYBC4mbPxrB 6kUFgiXat39lg6gXlDg58wkLiC0ioCSxY9I2sHphAUuJ+fP7mSDmO0pc/bKBvYuRg4NTwEli RrM9xD2SEtsWHWMHsZkF9CSmXG1hhLDlJZq3zmaGaNWWaGjqYJ3AKDgLybZZSFpmIWlZwMi8 ipE9NzEzJ73ccBMjMPQObvmtu4Px1DmRQ4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQW H2Jk4uCUamAMzvWonmVy09H70uT21V+/bzPXctkkUSC9vPrIghS3g8enq/90LE/WOJbxceIE k0Xe+34XCB8SP36siY3VNvpF5u/Fj44tfeBdWfWbI/r/6x1hc3J4kroFlBy4yq58mCr0WahI w7q8ol31f8jxb1uev0opEptmZzkvfbfVF9dwxpD9shfKtF2VWIozEg21mIuKEwGU73vjCwIA AA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-clksrc-07.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 06:56:38 -0000 WG, As Individual I am happy with this version. I think it can be progressed to publication request. Cheers Magnus On 2013-10-02 17:24, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : RTP Clock Source Signalling > Author(s) : Aidan Williams > Kevin Gross > Ray van Brandenburg > Hans Stokking > Filename : draft-ietf-avtcore-clksrc-07.txt > Pages : 27 > Date : 2013-10-02 > > Abstract: > NTP format timestamps are used by several RTP protocols for > synchronisation and statistical measurements. This memo specifies > SDP signalling identifying timestamp reference clock sources and SDP > signalling identifying the media clock sources in a multimedia > session. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-clksrc > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-clksrc-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -- Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From john.mattsson@ericsson.com Fri Oct 11 02:51:26 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5546A21E81B3 for ; Fri, 11 Oct 2013 02:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.249 X-Spam-Level: X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg5xBesAxSs3 for ; Fri, 11 Oct 2013 02:51:21 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 67E9421E80BC for ; Fri, 11 Oct 2013 02:51:16 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-91-5257ca12b33f Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BC.26.16099.21AC7525; Fri, 11 Oct 2013 11:51:14 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.84]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Fri, 11 Oct 2013 11:51:14 +0200 From: John Mattsson To: "avt@ietf.org" Thread-Topic: draft-ietf-avt-srtp-not-mandatory-13 review Thread-Index: Ac7GZd+eDDCGJMYlR8SqgClwTR0Q+g== Date: Fri, 11 Oct 2013 09:51:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvra7QqfAgg+VndCxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqVbm9gL2rgrDj3zaWBs4uxi5OSQEDCR2N7zix3CFpO4cG89 WxcjF4eQwGFGiZPXtzJBOIsZJS71v2IBqWITMJCYu6eBDcQWEVCUaL32mRHEFgaatPXjCnaI uKVE++V+qBo9iYWr7zGD2CwCqhKb/34Ds3kFvCU+b3jMBGIzAm3+fmoNmM0sIC5x68l8JoiL BCSW7DnPDGGLSrx8/I8VwlaUuDp9OVS9nsSNqVPYIGxtiWULX0PNF5Q4OfMJywRG4VlIxs5C 0jILScssJC0LGFlWMbLnJmbmpJcbbmIEhvHBLb91dzCeOidyiFGag0VJnPfDW+cgIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYy9vdZBct/9uDO9/E70P5glPV/68onPv9wdgldPm/Zs0gxd jUUagmvP//uR9dtG13hL6XqOpynN3/XW3Fi81bZ+hj33U847P388ULTd0nN90aczxzIl94Vq P3zx0lFy+ovm2UX9YdV87N2Zmif4mzunTZV1qNzpFzaLM4J1Tl+VBP/Mxy/SHixUYinOSDTU Yi4qTgQAKFLRszECAAA= Subject: [AVTCORE] draft-ietf-avt-srtp-not-mandatory-13 review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 09:51:26 -0000 Hi, I reviewed draft-ietf-avt-srtp-not-mandatory-13. Sorry for missing WGLC. I think it looks very good and I only have a few minor editorial comments: - Choose either:=20 "RTP Control Protocol" or "RTP control protocol" "RTP Payload Format" or "RTP payload format" "RTP Profiles" or "RTP profiles" - [p2] "Source-specific multicast (SSM)" and "multipoint conference unit (M= CU)" First letters should probably be capitalized in all or none of the abbrevia= tions c.f. "Real-time Transport Protocol (RTP)" and "Secure RTP (SRTP)" - [p2] semicolon at the end of first bullet (telephony;), but not at the en= d of any other bullet. - [p2] "Any Source Multicast video (ASM) conferencing" -> "Any Source Multi= cast (ASM) video conferencing" - [p6] "and it's associated" -> "and its associated" - [p6] "that are can be independent" -> "are" or "can be" /John ---------------------------------------------------------------------- JOHN MATTSSON MSc Engineering Physics, MSc Business Administration and Economics=20 Senior Researcher, Security=20 Ericsson AB Security Research F=E4r=F6gatan 6 SE-164 80 Stockholm, Sweden Phone +46 10 71 43 501 SMS/MMS +46 76 11 53 501 john.mattsson@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 From john.mattsson@ericsson.com Fri Oct 11 07:07:51 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE2811E81B5 for ; Fri, 11 Oct 2013 07:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.949 X-Spam-Level: X-Spam-Status: No, score=-7.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYoow-qPQcr6 for ; Fri, 11 Oct 2013 07:07:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A34C21E81B2 for ; Fri, 11 Oct 2013 07:04:39 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-be-52580575ca6b Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5F.93.16099.57508525; Fri, 11 Oct 2013 16:04:37 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.84]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Fri, 11 Oct 2013 16:04:37 +0200 From: John Mattsson To: "avt@ietf.org" Thread-Topic: draft-ietf-avtcore-rtp-security-options-07 review Thread-Index: Ac7GiYoSAm8g11DdR0OKzW8JZhd4cA== Date: Fri, 11 Oct 2013 14:04:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+JvrW4pa0SQweRrhhYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoEr43/DD6aCZaEVd6fuZW5gPOfaxcjJISFgIrFs2nxmCFtM4sK9 9WxdjFwcQgKHGSU2T13CBOEsZpTob5zJCFLFJmAgMXdPAxuILSKgKNF67TNYXFjASuLY/TNM EHF7ievLF0HV6El0r3wCFmcRUJWYcnM7WD2vgLfE583bwWoYgTZ/P7UGrIZZQFzi1pP5TBAX CUgs2XMe6jpRiZeP/7FC2IoSV6cvh6rXk7gxdQobhK0tsWzha2aI+YISJ2c+YZnAKDwLydhZ SFpmIWmZhaRlASPLKkb23MTMnPRyw02MwEA+uOW37g7GU+dEDjFKc7AoifN+eOscJCSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoHR9BnfrFPXuFcdf9ic78V+bato95LJJxTctr8yff+zvldC UiR+D/vjyUaOkhqi26efVthzWvTM20XdhTumSky7Y3xLOrZ2Xbzy1zu710gdn+a1vrLhWoi6 n8Dv286fZ72e93mNpeX6DetSt/Zqy3wqPt0tseKlWs2JDQZCF++LrHX/enSO68J5N5RYijMS DbWYi4oTAXFHfPIyAgAA Subject: [AVTCORE] draft-ietf-avtcore-rtp-security-options-07 review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 14:07:51 -0000 Hi, I reviewed draft-ietf-avtcore-rtp-security-options-07. Sorry for missing th= e WGLC deadline. Generally the draft is excellent! Just the kind of document I wish had been= available when I read up on RTP security many years ago. I have some comme= nts though: /John Comments on draft-ietf-avtcore-rtp-security-options-07 ------------------------------------------------------------------------- - [s2] While the section provides an excellent review of topologies on the = RTP user plane, it lacks description of different topologies and trust rela= tionships in the control plane, which very often do not involve the same no= des as the user plane and is equally (or even more) important for the key m= anagement. Some information is provided in section 4, but structuring it as= in section 2 would be good. - I suggest slightly refining the sentences about groups with shared securi= ty contexts: [p5] "trusted device that is part of the security context" [p6] "without needing to be in the security context" [p6] "needs to be a trusted part of the application security context" [p7] "that is part of the security context" [p7] "participants in the group security context" [p7] "individual sources within the security context" [p16] "do not include the media server in the security context" =20 At least for SRTP, the identities of the participants are not part of the s= ecurity context (except maybe for the receiver=B4s own IP which may be used= to identify the context). General suggestions: "has access/knowledge of the security context" "is part of/participates in the group sharing the security context" "needs to be trusted with the security context" - I would remove the uses of the word symmetric that does not refer to symm= etric crypto [p7] "Thus use of any symmetric security functions fails ..." [p8] "and a non-symmetrical verification of who sent" I suggest:=20 "Thus use of any group security context fails ..." "and an individual verification of who sent" - [p8] The feedback targets FT1 and FT2 in Figure 6 are not mentioned in th= e text? Why are there exactly 2 and why do they receive traffic from the di= stribution source? - [s3.1] The difference between SRTP transforms, SRTP crypto suites, and SR= TP protection profiles needs to be explained. Suggestion: "SRTP and MIKEY works with transforms where any combination of encryption a= lgorithm, authentication algorithm, and PRF can be used and the authenticat= ion tag length can be set to any value. This gives flexibility but requires= more security knowledge by the application developer. To simplify things, = Security Descriptions and DTLS-SRTP uses SRTP crypto suites and SRTP protec= tion profiles that bundles together transforms and other parameters. This g= ives less flexibility but it easier to use." I would recommend that the document first discusses SRTP transforms, and th= en SRTP crypto suites and SRTP protection profiles. =20 - [p9] "The following transforms are defined..." but then the defined crypt= o suites are listed... - [p9] "AES Counter Mode encryption with 128 bits keys combined with 128 bi= ts keyed HMAC-SHA-1 using 80- or 32-bits authentication tags. This is the d= efault cryptographic transform that needs to be supported. Defined in SRTP = [RFC3711]." 1. HMAC-SHA-1 uses 160 bit keys so "combined with 160 bits keyed HMAC-SHA-1= ". 2. 32-bit authentication tags are not default and not mandatory to support. 3. While the mentioned transforms are defined in [RFC3711], the crypto suit= es were defined in [RFC4568] and the protection profiles in [RFC5764].=20 - [p9] "AES-f8 and HMAC-SHA-1: AES f8 mode encryption with 128-bits keys c= ombined with keyed HMAC-SHA-1 using 80- or 32-bit authentication. Defined i= n SRTP [RFC3711]." While the mentioned transforms are defined in [RFC3711], the crypto suite F= 8_128_HMAC_SHA1_80 is defined in [RFC4568]. There is no F8_128_HMAC_SHA1_32= crypto suite, and no f8 protection profiles. - [p9] "The TESLA transform for SRTP is defined in [RFC4383]". Yes, but if the list is for crypto suites, there are no crypto suites for T= ESLA (nor protection profile), i.e. you can only use TESLA with MIKEY (or s= ome proprietary protocol). As TESLA is not an ordinary SRTP authentication = transforms (it introduces new fields and may be used together with an ordin= ary SRTP authentication transform), it might be better to describe it in th= e same part as RFC4771. - [p9,10] In the bullets on SEED and ARIA. "It has three modes" and "It has= also three modes. I know that RFC5669 states that: "We define three modes = of running SEED: (1) SEED in counter mode, (2) SEED in counter mode with CB= C-MAC" But the word "mode" is a really poor choice (as mode is used to desc= ribe blockcipher mode, even it that same sentence) better to use "options",= "variants", or "crypto suites". - [p10] "AES-192 and AES-256: cryptographic transforms for SRTP based on A= ES-192 and AES-256 counter mode encryption and 160-bit keyed HMAC-SHA-1 wit= h 80- and 32-bit authentication tags. Thus providing 192 and 256 bits encr= yption keys. Defined in [RFC6188]." AES-192 and AES-256 are the block ciphers, the transforms would be AES_192_= CM and AES_256_CM. Debatable if AES_192_CM and AES_256_CM are different SRT= P transforms from AES CM. MIKEY sees them as the AES CM transform with diff= erent key lengths. The transforms were defined already in [RFCR3711]. [RFC6= 188] better describes the use of AES-192, AES-256, provides test data and d= efine the crypto suites. Maybe "Defined in [RFC3711], [RFC6188]" - [p10] "AES-GCM: Galois Counter Mode and AES-CCM (Counter with CBC)" The colon should be moved to include AES-CCM "AES-GCM and AES-CCM:" or "AES= -GCM (Galois Counter Mode) and AES-CCM (Counter with CBC-MAC):" Note that CCM is abbreviation of Counter with CBC-MAC. - [s3.1] The NULL transforms defined in [RFC3711] should be mentioned someh= ow. - [s3.1] The MKI mechanism for rekeying defined in [RFC3711] should be ment= ioned somehow. - After "is the most common used" I would suggest adding:=20 "AES-GCM, AES_192_CM, and AES_256_CM are expected to gain usage in the futu= re, especially due to the AES- and GCM-specific instructions on new CPUs. - [s3.1.1, s5.1] I think the texts regarding DTLS-SRTP is a little bit too = optimistic, and fails to mention the weaknesses. If used with PKI (or some = other trusted third party solution), the security may of course be great, b= ut in practice it is used with self-signed certificates. And while DTLS-SRT= P with self-signed certificates might be close to optimal for point-to-poin= t SIP over Internet or WebRTC, it was not chosen because of the perfect sec= urity, it was chosen because it offers fair security while not requiring co= mplicated setup or trust in a third party. The normal usage of DTLS-SRTP wi= th self-signed certificates still relies on trust in the signaling or the a= ssumption that nobody was spying during the first call, and for a call over= the Internet, you cannot normally make either of these assumptions... - [p11] "It is mandatory to support in WebRTC" -> "to use" or "to support and use" - [p12] MIKEY might establish a TEK directly without any TGK. Maybe better = to just write "cryptographic method used to establish the session keys actu= ally used by the security protocol, like SRTP" Then also change "TGK" to "s= ession key" in the following bullets. - [p12] Maybe write a little bit more about TICKET. Suggestion: "TICKET: [RFC6043] is a MIKEY extension using a trusted centralized key ma= nagement service (KMS). The Initiator and the Responder do not share any cr= edentials; instead, they trust a third party, the KMS, with which they both= have or can establish shared credentials." - [p13] In the paragraph "MIKEY messages have several ..." Should mention the application/mikey MIME media type. Suggestion: "[RFC3830] defines the application/mikey MIME media type allowing MIKEY to = be used in e.g. emails and HTTP." - [p13] In the paragraph "MIKEY with pre-shared ...", it would be good to a= dd: "IMS media security [T3GPP.33.328] specifies use of the TICKET mode transpo= rted over SIP and HTTP." - [s3.1.3] I suggest adding: "Security Descriptions are used for access pro= tection in IMS Media Security [T3GPP.33.328]." - [s3.5] I suggest stating that as DTLS build upon TLS, they are almost equ= ivalent from a security perspective (and many other aspects), and then ONLY= mention any differences from DTLS. - [s5] I think IMS media security using Security Descriptions for e2ae secu= rity (specified in 3GPP TS 33.328) should be one of examples. The trust and= architecture is quite different from SIP over Internet. (If you want I can= write the example text). - [s5.2] Maybe a little bit too detailed; At least the text cannot recommen= d use of new self-signed certificates each session without discussing the n= egative security consequences of doing so, i.e. no continuity of authentica= tion. Maybe better to move all privacy discussions to section 4.1.5. - [s5.3] I would suggest the word "copied" instead of "captured" Editorial comments on draft-ietf-avtcore-rtp-security-options-07 ------------------------------------------------------------------------- - Varying capitalization/spelling of several terms: [p4] "Point to point" vs. "point-to-point"=20 [p6] "Any source Multicast" -> "Any Source Multicast" [p7] "Source-Specific Multicast" vs. "Source Specific Multicast"=20 [p9] "128 bits keys" vs. "128-bits keys" - Some figure texts capitalizes first letters in words while others do not. - [p7] "needs to be trusted device" -> "needs to be a trusted device" or "n= eeds to be trusted" - [p8] "The goal is to help applications designer by giving reviewing the t= ypes of solution that are available." Something is wrong with this sentence. - [p9] "membership by not sources" -> "membership but not sources" - [p13] "It's features" -> "Its features" - [s5.3] "ISMA Crypt 2.0" -> "ISMACryp 2.0" - [p28] "[ISMACrypt2]" -> "[ISMACryp2]" And maybe refer to Open IPTV Forum = as they are keeping the old ISMA/MPEGIF documents ---------------------------------------------------------------------------= --------- JOHN MATTSSON MSc Engineering Physics, MSc Business Administration and Economics=20 Senior Researcher, Security=20 Ericsson AB Security Research F=E4r=F6gatan 6 SE-164 80 Stockholm, Sweden Phone +46 10 71 43 501 SMS/MMS +46 76 11 53 501 john.mattsson at ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 From john.mattsson@ericsson.com Mon Oct 14 06:12:25 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FC011E8186 for ; Mon, 14 Oct 2013 06:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=-1.675, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF2y97qg+eZd for ; Mon, 14 Oct 2013 06:12:19 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id BFBF111E818A for ; Mon, 14 Oct 2013 06:12:18 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-eb-525bedb04239 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 84.AA.25272.0BDEB525; Mon, 14 Oct 2013 15:12:17 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.84]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Mon, 14 Oct 2013 15:09:47 +0200 From: John Mattsson To: "avt@ietf.org" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" Thread-Topic: draft-ietf-avtcore-srtp-aes-gcm-10 review Thread-Index: Ac7I3KoMq4YJWcF+RZ2qUP93gMGt0A== Date: Mon, 14 Oct 2013 13:09:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvre7Gt9FBBod3S1m87FnJbrH2SKID k8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlfH0h1dBa1TFxLULWBsYP7t3MXJySAiYSJw5 uJsVwhaTuHBvPVsXIxeHkMBRRolra/+ygySEBBYzSpyfnAdiswkYSMzd08AGYosIdDBKdO2X ALGFBYwkXmzfARTnAIqbS2zb7g9Roifxp3kfM4jNIqAq8eTHXjCbV8BbYufmk2A2I9De76fW MIHYzALiEreezGeCuEdAYsme88wQtqjEy8f/oO5UlLg6fTlUvZ7EjalT2CBsbYllC19DzReU ODnzCcsERuFZSMbOQtIyC0nLLCQtCxhZVjFyFKcWJ+WmGxlsYgSG9cEtvy12MF7+a3OIUZqD RUmc9+Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjOevvPzPxC5yZ06M9O3ILYFKzB2B t9LmfZ7KVNoceSmzuUnT20Gf/++1H6+2GzZ3PnDpPnQy16S8SMg4SKVUTbPpqaVBofgTSetV xTs1Xuxz5P7498AFwSufT8nJarNeWZ66vaH8Rn3OmRvJ+RXsB3pWJJ9c8uvaWS6x0yyW/cZ7 J08zSSgTUmIpzkg01GIuKk4EAO/U2PY5AgAA Subject: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-10 review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 13:12:25 -0000 Hi, I reviewed draft-ietf-avtcore-srtp-aes-gcm-10. Sorry for commenting after t= he publication request. I support the publication, but I have some comments that should probably be= addressed before proceeding to the IESG review: /John Comments and suggestions on draft-ietf-avtcore-srtp-aes-gcm-10 ------------------------------------------------------------------------- - [s6] The values for the maximum keystream/plaintext length do not seem to= agree with the P_MAX values in [RFC5116]. Section 6 states: "up to (2^28)-16 octets for AES-CCM and up to (2^36)-32 octets for AES-GCM.= " [RFC5116] states: "P_MAX is 2^36 - 31 octets" for GCM and "P_MAX is 2^24 - 1 octets" for CCM.= =20 While lowering the value for GCM with 1 octet would be ok, increasing the v= alues with a factor of 16 for CCM would require some motivation. Might this= this actually be a typo in [RFC5116]?=20 Why were the values from [RFC5116] not followed directly? I assume it was d= one to match an integer number of blocks. I suggest adding a short motivati= on. - [s11] The values for C_MAX in Section 11 do not agree with the values for= keystream/plaintext length in Section 6. Section 11 states: "C_MAX maximum ciphertext GCM: MUST be <=3D 2^36-16 octets. length per invocation CCM: MUST be <=3D 2^28-16 octets." As the minimum AEAD tag length is 8 octets this would mean that the maximum= keystream length is 2^28-24. Assuming the values in Section 6 is correct, = the correct value should probably be: "CCM: MUST be <=3D 2^28 octets." - [s14.1] The text describing the handling of the block counters do not see= m correct. Section 14.1 states: " At the start of each packet, the block counter MUST be reset (to 0 for CC= M, to 1 for GCM). The block counter is incremented after each block key has= been produced, but it MUST NOT be allowed to exceed 2^32 for GCM and 2^24 = for CCM."=20 1. While the number of blocks could exceed 2^32 for GCM and 2^24 for CCM, t= he block counter can never exceed 2^32-1 for GCM and 2^24-1 for CCM. 2. Even with a block counter value of 2^24-1, CCM would have exceeded maxim= um keystream length of (2^28)-16 octets specified in Section 6. Assuming that the keystream limits in Section 6 are correct, I think the co= rrect values should be: "The block counter is incremented after each block key has been produced, b= ut it MUST NOT be allowed to exceed (2^32) - 2 for GCM and (2^24) - 2 for C= CM. - The values for the maximum Ciphertext length for GCM_8 do not seem to agr= ee with the constraints in Appendix C of 800-38D: "For any implementation t= hat supports 32-bit or 64-bit tags, one of the rows in Table 1 or Table 2, = respectively, shall be enforced." This seems to be missing in RFC5285 as we= ll.=20 - The values for the maximum number on invocations (2^48 and 2^31) for GCM_= 8 do not seem to agree with the constraints in Appendix C of 800-38D. This = seems to be missing in RFC5285 as well. I have not had time to read the actual papers behind Appendix B and C in 80= 0-38D, but if Appendix C for some reason do not apply to draft-ietf-avtcore= -srtp-aes-gcm-10 (and RFC5285), this should be mentioned and motivated. Oth= erwise, would there be any additional constraints on Ciphertext length and = maximum number on invocations for GCM_12? - The document decreases the session salt length from the RFC3711 default o= f 112 to 96. Whether it is to follow the recommendations in RFC5116 or allo= wing longer keystreams, it should be motivated. And even if the negative se= curity implications against pre-computation and TMTO attacks are theoretica= l (2^96 keys in use instead of 2^112) the negative security implications co= mpared to RFC3711 should be discussed (shortly). - The document decreases the session salt length from the RFC3711 default o= f 112 to 96, but it does not mention weather the default length of the mast= er salt is also changed to 96 or if it is still 112. - There is a lot of "optional", "must" and "not recommended" etc. written w= ith lower case. Both in text and figures. Should all be CAPITAL I think.=20 - [s3] As this section gives an overview of the security architecture in th= e draft rather than general SRTP I would suggest: "SRTP/SRTCP security" -> "SRTP/SRTCP AEAD security" - [p4] "A Key Derivation Function is applied to the shared master key value= to form separate encryption keys, authentication keys and salting keys for= SRTP and for SRTCP (a total of six keys). This process is described in se= ctions 4.3.1 and 4.3.3 of [RFC3711]." Key derivation for SRTCP is described in section 4.3.2. Maybe best to write= "This process is described in section 4.3 of [RFC3711]." - [s4] The defined terms are barely used at all: "Crypto Context" is not used at all in the text. "Instantiation" is used exactly 1 time after the definition. "Invocation" is used only 3 times.=20 Should be fixed in one way or another. - [s5.2] 5.2.1 specifies the encrypt input for Associated data and Plaintex= t as "Bit string", while 5.2.2 defines them defines them as "Octet string".= I assume both should be "Octet string".=20 - [s5.2.1] "cannot", should this maybe be "MUST NOT" or "SHOULD NOT" instea= d? - [s6] As the output of GCM_keystream and CCM_keystream is key_stream and n= ot Ciphertext, the input should probably be len(Plaintext) instead of Plain= text. - [s8.2] Should probably use ""NOT RECOMMENDED". - [s8.2] Maybe give VBR codecs as an example. - [s9.2] Marker (M) and Payload Type (PT) is missing from the list of Assoc= iated Data fields. - [Figure 2] While PT means "Packet Type" in RTCP it means "Payload Type" i= n RTP. - [Figure 2,4,5] I suggest writing "SRTP authentication tag" and "SRTCP aut= hentication tag" instead of just "authentication tag". - [s9.2] In the paragraph below Figure 2, shoudn't "cipher" be "ciphertext"= . - [s9] Figure 2,4,5 does not show AEAD input as SRT(C)P MKI and SRT(C)P aut= hentication tag are appended after encryption (and removed before decryptio= n). As the packet processing from RFC3711 is not changed (nor should it be)= the packet will never look like Figure 2,4,5 during the processing.=20 I would suggest changing the pictures to show: "Format of an AEAD SRTP packet" "Format of an AEAD SRTCP packet when encryption flag =3D 1" "Format of an AEAD SRTCP packet when encryption flag =3D 0" which would then include the new "AEAD authentication tag". - [s9.3] "Additional Authenticated Data (AAD)" Is it not best to just use A= ssociated Data (AD) consistently in the whole document? - [s9.2, s10.2, s10.3] The SRT(C)P MKI and the SRT(C)P authentication tag b= oth have variable lengths (i.e. not 32 bit).=20 - [Figure 4,5] sender info, report block 1, report block 2, ..., SDES items= , ..., SRTCP MKI all have variable lengths (i.e. use ":" not "|").=20 - [Figure 4,5] The figures replaces the text "PT=3DSDES=3D202" with the gen= eral "Packet Type" but still keeps "SDES items". - [s13] In the tables, shouldn't "Default key lifetime" be "Maximum key lif= etime" - [s13] In the tables, "Cipher (for SRTP and SRTCP)" includes tag length bu= t not key length. Should include both or none. - [s14.1] As all the bullets contain "MUST", they are maybe more requiremen= ts than recommendations - [s14.1] "Each time a rekey occurs, the initial values of the SRTCP index = and the values of all the SEQ counters MUST be saved." Save initial SEQ value? Do you mean something like: "the current values of the SRTCP index and the SRTP index MUST be not be ch= anged" - [s14.1] "Packet Counter" this is called "SRTP index" or "packet index" in= RFC3711. I suggest using one of these terms (and as SEQ starts on a random= value, it is not really a counter either). - [s14.1] I would suggest "Processing MUST cease if" -> "Processing MUST ce= ase before" to avoid ambiguity of what to do with the last packet. - [s14.2] " The goal of an authentication tag is to minimize the probabilit= y" As this is not minimize in the mathematical way, I suggest to use some s= ynonym like "reduce", or reformulate. - [s14.2] Strictly, prob_success <=3D expected number of successes (equal = for N_tries =3D 0,1). - [s14.2] I suggest to mention that: if expected number of successes << 1=20 then prob_success approx. expected number of successes Otherwise it is hard to understand that the table contains approximate and = quite exact values and not only maximum bounds for the probabilities. - [s14.2] "2^-N_tries" is correct for tags in general, but isn't the correc= t value for GCM "ceiling(len(Ciphertext + AD) / 16) * 2^-N_tries"? (c.f. Ap= pendix B of 800-38D). - [s15.1] "In order to allow SDP to signal". As RFC4567 could also be used,= I suggest changing "SDP" to "Security Descriptions" or "SDP Security Descr= iptions"=20 - [s15.1] I think the correct registry is "Session Description Protocol (SD= P) Security Descriptions". - [s15.3] As the "AEAD authentication tag length" is general and may be use= d for future AEAD algorithms, the Possible values should be "depends on cip= her used" - [s15.3] If there is a default key length, there should also be a default = "AEAD authentication tag length" (8 octets). - [s16] I suggest changing "AEAD" to "AEAD_AES" or "AES-GCM and AES-CCM" as= Section 12 is not that general. Editorial Comments on draft-ietf-avtcore-srtp-aes-gcm-10 ------------------------------------------------------------------------- - Some of the section headings miss to capitalize all the first letters. - [p1] "each AEAD will" -> "each AEAD algorithm will" - [p4] " number(SEQ)" -> " number (SEQ)" - [p5] "Cipher Context" -> "Crypto Context" - [p6] "Octets long" -> "octets long" - [p7] "9.1 and 10.1)with" -> "9.1 and 10.1) with" - [s9.1] "4-octer" -> "4-octet" - [9.1, 10.1] "12 octet" -> "12-octet" - Figure 1 and 3 uses different approaches to enumerate the bytes.=20 - [s9.2] "see figure 2" -> "see Figure 2" - [Figure 4] "SRTCP MKI (optional) index" -> "SRTCP MKI (OPTIONAL)" - [s13] Caption is above Table 1 and 8 but below all other tables. - [s13.2] "CBC MAC" -> "CBC-MAC" - [s15.3] Delete "lists maintained under "MIKEY Security Protocol Parameter= s"." - [s16] "length )" -> "length)" =09 - [s16] "the key length of the Key Derivation Function" -> "the input key length of the Key Derivation Function" - [Table 16] remove space before 16: "AEAD_AES_128_GCM_12 | AES-GCM | 16 octets | 12 octets |" -> "AEAD_AES_128_GCM_12 | AES-GCM | 16 octets | 12 octets |" - [s17] If you would like to thank my Ericsson colleagues, their names are = "Westerlund" and "Ohlsson" (BTW the pdf version of the document has strange page breaks...) ---------------------------------------------------------------------------= --------- JOHN MATTSSON MSc Engineering Physics, MSc Business Administration and Economics=20 Senior Researcher, Security=20 Ericsson AB Security Research F=E4r=F6gatan 6 SE-164 80 Stockholm, Sweden Phone +46 10 71 43 501 SMS/MMS +46 76 11 53 501 john.mattsson@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 From csp@csperkins.org Tue Oct 15 10:08:35 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559A511E81D5 for ; Tue, 15 Oct 2013 10:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0j77c7XwmWl for ; Tue, 15 Oct 2013 10:08:31 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB1911E81E2 for ; Tue, 15 Oct 2013 10:08:21 -0700 (PDT) Received: from [130.209.247.112] (port=51808 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VW86R-0003GT-54; Tue, 15 Oct 2013 18:08:15 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: Date: Tue, 15 Oct 2013 18:08:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <570820FC-C6A6-4969-B8FE-4EA8F06B5A78@csperkins.org> References: To: John Mattsson X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "avt@ietf.org" Subject: Re: [AVTCORE] draft-ietf-avt-srtp-not-mandatory-13 review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:08:35 -0000 Hi, Thanks for the comments. I'm about to submit the -14 version to address = these. Colin On 11 Oct 2013, at 10:51, John Mattsson = wrote: > Hi, >=20 > I reviewed draft-ietf-avt-srtp-not-mandatory-13. Sorry for missing = WGLC. >=20 > I think it looks very good and I only have a few minor editorial = comments: >=20 > - Choose either:=20 > "RTP Control Protocol" or "RTP control protocol" > "RTP Payload Format" or "RTP payload format" > "RTP Profiles" or "RTP profiles" >=20 > - [p2] "Source-specific multicast (SSM)" and "multipoint conference = unit (MCU)" > First letters should probably be capitalized in all or none of the = abbreviations c.f. "Real-time Transport Protocol (RTP)" and "Secure RTP = (SRTP)" >=20 > - [p2] semicolon at the end of first bullet (telephony;), but not at = the end of any other bullet. >=20 > - [p2] "Any Source Multicast video (ASM) conferencing" -> "Any Source = Multicast (ASM) video conferencing" >=20 > - [p6] "and it's associated" -> "and its associated" >=20 > - [p6] "that are can be independent" -> "are" or "can be" >=20 > /John >=20 > ---------------------------------------------------------------------- > JOHN MATTSSON > MSc Engineering Physics, MSc Business Administration and Economics=20 > Senior Researcher, Security=20 >=20 > Ericsson AB > Security Research > F=E4r=F6gatan 6 > SE-164 80 Stockholm, Sweden > Phone +46 10 71 43 501 > SMS/MMS +46 76 11 53 501 > john.mattsson@ericsson.com > www.ericsson.com >=20 >=20 >=20 >=20 > This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Tue Oct 15 10:23:49 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF8011E818D; Tue, 15 Oct 2013 10:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeqEs4oh39Zm; Tue, 15 Oct 2013 10:23:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F0D11E813F; Tue, 15 Oct 2013 10:23:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015172348.2118.92269.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 10:23:48 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avt-srtp-not-mandatory-14.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:23:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Securing the RTP Protocol Framework: Why RTP Does Not Ma= ndate a Single Media Security Solution Author(s) : Colin Perkins Magnus Westerlund Filename : draft-ietf-avt-srtp-not-mandatory-14.txt Pages : 9 Date : 2013-10-15 Abstract: This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP), and the associated RTP Control Protocol (RTCP), do not mandate a single media security mechanism. Guidelines for designers and reviewers of future RTP extensions are provided, to ensure that appropriate security mechanisms are mandated, and that any such mechanisms are specified in a manner that conforms with the RTP architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-srtp-not-mandatory-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From john.mattsson@ericsson.com Sat Oct 19 15:44:58 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007D321F9FD7 for ; Sat, 19 Oct 2013 15:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.541 X-Spam-Level: X-Spam-Status: No, score=-7.541 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lW4683crhzK4 for ; Sat, 19 Oct 2013 15:44:50 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2C42611E82CD for ; Sat, 19 Oct 2013 15:44:47 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-a0-52630b5e8f42 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E4.19.03802.E5B03625; Sun, 20 Oct 2013 00:44:46 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.88]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Sun, 20 Oct 2013 00:44:45 +0200 From: John Mattsson To: John Mattsson , "avt@ietf.org" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" Thread-Topic: draft-ietf-avtcore-srtp-aes-gcm-10 review Thread-Index: Ac7I3KoMq4YJWcF+RZ2qUP93gMGt0AEPlzGg Date: Sat, 19 Oct 2013 22:44:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+JvjW4cd3KQwetfIhYve1ayW6w9kujA 5LFkyU8mjy+XP7MFMEVx2aSk5mSWpRbp2yVwZXxr2slY8LyuYsUaqQbGq6ldjBwcEgImErOW iXYxcgKZYhIX7q1n62Lk4hASOMwoMa/pFzNIQkhgMaPEtGsBIDabgIHE3D0NYEUiAlsYJa4v /MwOkhAWMJPo/7qKGWSoiIC5xLbt/iBhEQEjieWNn9hAbBYBVYntC9+BzeQV8Jbo2rCIEaRc CMi+d0cTJMwp4CPxd+VssBJGoHu+n1rDBGIzC4hL3HoynwniTgGJJXvOM0PYohIvH/9jhbCV JNYe3s4CUa8ncWPqFDYIW1ti2cLXUGsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWM7LmJ mTnp5UabGIExcHDLb9UdjHfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMH JzDAQw7Vs5++9uDs+ov1v/uzM125PQ2vaLPvjPBNaTx8/BDjEbtjF1eyJfMFdd+91H2x5Nrs ksKlM6ViIvRXZotMrM3adNTz4hPG//kPnMWnLJtltS3rIvOllsAPzDO5+dvDp1/y8qp/uzws YdXcraF7plps3SnS29hVuHBlqxjzFr+fFUeVpeofK7EUZyQaajEXFScCAPb6CIVPAgAA Subject: Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-10 review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 22:44:58 -0000 Hi, With the NIST servers back online, I could read the NIST material regarding= GCM, which reminded me of the fact that in GCM, a small number of repeated= IVs for different messages do not only void the confidentiality of these m= essages, it also leaks the GCM authentication key H. With H, an adversary c= an calculate the AEAD authentication tag for any chosen Ciphertext and Asso= ciated Data. This is not a problem when GCM is used in e.g. TLS or IPsec, but with SRTP = where group keys are common, SSRC collisions may occur, and the IV is calcu= lated from information given from the RTP application, repeated IVs may act= ually happen. I think the consequences should be made clear to application developers usi= ng AES-GCM (this is currently missing), and the needed deviations from RFC3= 711 should be more explicitly stated. (I do not like just pointing out problems, I reviewed this draft because I = really like GCM and CCM, and think they will (and should) be used a lot. In= fact, I think the introduction could advertise the benefits even more, bot= h GCM and CCM combine outstanding performance with provable security. What = more can you hope for.) /John Four more comments, all related to repeated IVs: - [Section 6] "With any counter mode, if the same (IV, encryption_key) pair is used twice= , precisely the same keystream is formed. As explained in section 9.1 of RF= C 3711, this is a cryptographic disaster." While this is true, Section 9.1 of [RFC3711] only discusses two-time pad an= d the consequences of repeated IV with GCM are even worse. I would suggest = writing: "With any counter mode, if the same (IV, encryption_key) pair is used twice= , precisely the same keystream is formed. As explained in section 9.1 of R= FC 3711, this is a cryptographic disaster. For GCM the consequences are eve= n worse as also the integrity is compromised, and not only temporary, but f= or all future use of encryption_key." And maybe better to move the text to Section 9.4 or the Security Considerat= ions section. - [Section 9.4] "In order to prevent IV reuse, we must ensure that the (ROC,SEQ,SSRC) tripl= e is never used twice with the same master key. There are two phases to thi= s issue. Counter Management: A rekey MUST be performed to establish a new master key= before the (ROC,SEQ) pair cycles back to its original value." This assumes that the RTP application is totally trusted. With the transfor= ms in [RFC3711] this is not important as a malicious RTP application can on= ly compromise the confidentiality of information it already had knowledge a= bout. For GCM, this is no longer the case as a malicious RTP application ca= n make the SRTP implementation leak the authentication key just by using th= e same SEQ twice, something RFC3711 do not require the SRTP implementation = to check: Section 4.1.1 of [RFC3711]: "It is RECOMMENDED that, if a dedicated securit= y module is present, the RTP sequence numbers and SSRC either be generated = or checked by that module (i.e., sequence-number and SSRC processing in an = SRTP system needs to be protected as well as the key)." For GCM, I think this has to be changed to MUST. I therefore suggest adding= something along the lines of: "For GCM, the SEQ and SSRC values used MUST either be generated or checked = by the SRTP implementation, or by a module (e.g. the RTP application) that = can be considered equally trusted as the SRTP implementation. While [RFC371= 1] allows detecting SSRC collisions after they happen, SRTP using GCM with = shared master keys MUST prevent SSRC collision from happening even once." - [Section 9.4, Section 10.4] "before the (ROC,SEQ) pair cycles back to its original value." "Ideally, a rekey performed should be performed and a new master key put in= place well before the SRTCP index overflows." Due to previous re-keying, the need for a new master key may or may not coi= ncide with overflow of the indices.=20 - [Section 9.4] In the bullet "SSRC Management" I think something like the following is nee= ded: "The identity of the entity giving out SSRC values MUST be verified, and th= e SSRC signaling MUST be integrity protected." -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of John = Mattsson Sent: den 14 oktober 2013 15:10 To: avt@ietf.org; draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org Subject: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-10 review Hi, I reviewed draft-ietf-avtcore-srtp-aes-gcm-10. Sorry for commenting after t= he publication request. I support the publication, but I have some comments that should probably be= addressed before proceeding to the IESG review: /John Comments and suggestions on draft-ietf-avtcore-srtp-aes-gcm-10 ------------------------------------------------------------------------- - [s6] The values for the maximum keystream/plaintext length do not seem to= agree with the P_MAX values in [RFC5116]. Section 6 states: "up to (2^28)-16 octets for AES-CCM and up to (2^36)-32 octets for AES-GCM.= " [RFC5116] states: "P_MAX is 2^36 - 31 octets" for GCM and "P_MAX is 2^24 - 1 octets" for CCM.= =20 While lowering the value for GCM with 1 octet would be ok, increasing the v= alues with a factor of 16 for CCM would require some motivation. Might this= this actually be a typo in [RFC5116]?=20 Why were the values from [RFC5116] not followed directly? I assume it was d= one to match an integer number of blocks. I suggest adding a short motivati= on. - [s11] The values for C_MAX in Section 11 do not agree with the values for= keystream/plaintext length in Section 6. Section 11 states: "C_MAX maximum ciphertext GCM: MUST be <=3D 2^36-16 octets. length per invocation CCM: MUST be <=3D 2^28-16 octets." As the minimum AEAD tag length is 8 octets this would mean that the maximum= keystream length is 2^28-24. Assuming the values in Section 6 is correct, = the correct value should probably be: "CCM: MUST be <=3D 2^28 octets." - [s14.1] The text describing the handling of the block counters do not see= m correct. Section 14.1 states: " At the start of each packet, the block counter MUST be reset (to 0 for CC= M, to 1 for GCM). The block counter is incremented after each block key has= been produced, but it MUST NOT be allowed to exceed 2^32 for GCM and 2^24 = for CCM."=20 1. While the number of blocks could exceed 2^32 for GCM and 2^24 for CCM, t= he block counter can never exceed 2^32-1 for GCM and 2^24-1 for CCM. 2. Even with a block counter value of 2^24-1, CCM would have exceeded maxim= um keystream length of (2^28)-16 octets specified in Section 6. Assuming that the keystream limits in Section 6 are correct, I think the co= rrect values should be: "The block counter is incremented after each block key has been produced, b= ut it MUST NOT be allowed to exceed (2^32) - 2 for GCM and (2^24) - 2 for C= CM. - The values for the maximum Ciphertext length for GCM_8 do not seem to agr= ee with the constraints in Appendix C of 800-38D: "For any implementation t= hat supports 32-bit or 64-bit tags, one of the rows in Table 1 or Table 2, = respectively, shall be enforced." This seems to be missing in RFC5285 as we= ll.=20 - The values for the maximum number on invocations (2^48 and 2^31) for GCM_= 8 do not seem to agree with the constraints in Appendix C of 800-38D. This = seems to be missing in RFC5285 as well. I have not had time to read the actual papers behind Appendix B and C in 80= 0-38D, but if Appendix C for some reason do not apply to draft-ietf-avtcore= -srtp-aes-gcm-10 (and RFC5285), this should be mentioned and motivated. Oth= erwise, would there be any additional constraints on Ciphertext length and = maximum number on invocations for GCM_12? - The document decreases the session salt length from the RFC3711 default o= f 112 to 96. Whether it is to follow the recommendations in RFC5116 or allo= wing longer keystreams, it should be motivated. And even if the negative se= curity implications against pre-computation and TMTO attacks are theoretica= l (2^96 keys in use instead of 2^112) the negative security implications co= mpared to RFC3711 should be discussed (shortly). - The document decreases the session salt length from the RFC3711 default o= f 112 to 96, but it does not mention weather the default length of the mast= er salt is also changed to 96 or if it is still 112. - There is a lot of "optional", "must" and "not recommended" etc. written w= ith lower case. Both in text and figures. Should all be CAPITAL I think.=20 - [s3] As this section gives an overview of the security architecture in th= e draft rather than general SRTP I would suggest: "SRTP/SRTCP security" -> "SRTP/SRTCP AEAD security" - [p4] "A Key Derivation Function is applied to the shared master key value= to form separate encryption keys, authentication keys and salting keys for= SRTP and for SRTCP (a total of six keys). This process is described in se= ctions 4.3.1 and 4.3.3 of [RFC3711]." Key derivation for SRTCP is described in section 4.3.2. Maybe best to write= "This process is described in section 4.3 of [RFC3711]." - [s4] The defined terms are barely used at all: "Crypto Context" is not used at all in the text. "Instantiation" is used exactly 1 time after the definition. "Invocation" is used only 3 times.=20 Should be fixed in one way or another. - [s5.2] 5.2.1 specifies the encrypt input for Associated data and Plaintex= t as "Bit string", while 5.2.2 defines them defines them as "Octet string".= I assume both should be "Octet string".=20 - [s5.2.1] "cannot", should this maybe be "MUST NOT" or "SHOULD NOT" instea= d? - [s6] As the output of GCM_keystream and CCM_keystream is key_stream and n= ot Ciphertext, the input should probably be len(Plaintext) instead of Plain= text. - [s8.2] Should probably use ""NOT RECOMMENDED". - [s8.2] Maybe give VBR codecs as an example. - [s9.2] Marker (M) and Payload Type (PT) is missing from the list of Assoc= iated Data fields. - [Figure 2] While PT means "Packet Type" in RTCP it means "Payload Type" i= n RTP. - [Figure 2,4,5] I suggest writing "SRTP authentication tag" and "SRTCP aut= hentication tag" instead of just "authentication tag". - [s9.2] In the paragraph below Figure 2, shoudn't "cipher" be "ciphertext"= . - [s9] Figure 2,4,5 does not show AEAD input as SRT(C)P MKI and SRT(C)P aut= hentication tag are appended after encryption (and removed before decryptio= n). As the packet processing from RFC3711 is not changed (nor should it be)= the packet will never look like Figure 2,4,5 during the processing.=20 I would suggest changing the pictures to show: "Format of an AEAD SRTP packet" "Format of an AEAD SRTCP packet when encryption flag =3D 1" "Format of an AEAD SRTCP packet when encryption flag =3D 0" which would then include the new "AEAD authentication tag". - [s9.3] "Additional Authenticated Data (AAD)" Is it not best to just use A= ssociated Data (AD) consistently in the whole document? - [s9.2, s10.2, s10.3] The SRT(C)P MKI and the SRT(C)P authentication tag b= oth have variable lengths (i.e. not 32 bit).=20 - [Figure 4,5] sender info, report block 1, report block 2, ..., SDES items= , ..., SRTCP MKI all have variable lengths (i.e. use ":" not "|").=20 - [Figure 4,5] The figures replaces the text "PT=3DSDES=3D202" with the gen= eral "Packet Type" but still keeps "SDES items". - [s13] In the tables, shouldn't "Default key lifetime" be "Maximum key lif= etime" - [s13] In the tables, "Cipher (for SRTP and SRTCP)" includes tag length bu= t not key length. Should include both or none. - [s14.1] As all the bullets contain "MUST", they are maybe more requiremen= ts than recommendations - [s14.1] "Each time a rekey occurs, the initial values of the SRTCP index = and the values of all the SEQ counters MUST be saved." Save initial SEQ value? Do you mean something like: "the current values of the SRTCP index and the SRTP index MUST be not be ch= anged" - [s14.1] "Packet Counter" this is called "SRTP index" or "packet index" in= RFC3711. I suggest using one of these terms (and as SEQ starts on a random= value, it is not really a counter either). - [s14.1] I would suggest "Processing MUST cease if" -> "Processing MUST ce= ase before" to avoid ambiguity of what to do with the last packet. - [s14.2] " The goal of an authentication tag is to minimize the probabilit= y" As this is not minimize in the mathematical way, I suggest to use some s= ynonym like "reduce", or reformulate. - [s14.2] Strictly, prob_success <=3D expected number of successes (equal = for N_tries =3D 0,1). - [s14.2] I suggest to mention that: if expected number of successes << 1=20 then prob_success approx. expected number of successes Otherwise it is h= ard to understand that the table contains approximate and quite exact value= s and not only maximum bounds for the probabilities. - [s14.2] "2^-N_tries" is correct for tags in general, but isn't the correc= t value for GCM "ceiling(len(Ciphertext + AD) / 16) * 2^-N_tries"? (c.f. Ap= pendix B of 800-38D). - [s15.1] "In order to allow SDP to signal". As RFC4567 could also be used,= I suggest changing "SDP" to "Security Descriptions" or "SDP Security Descr= iptions"=20 - [s15.1] I think the correct registry is "Session Description Protocol (SD= P) Security Descriptions". - [s15.3] As the "AEAD authentication tag length" is general and may be use= d for future AEAD algorithms, the Possible values should be "depends on cip= her used" - [s15.3] If there is a default key length, there should also be a default = "AEAD authentication tag length" (8 octets). - [s16] I suggest changing "AEAD" to "AEAD_AES" or "AES-GCM and AES-CCM" as= Section 12 is not that general. Editorial Comments on draft-ietf-avtcore-srtp-aes-gcm-10 ------------------------------------------------------------------------- - Some of the section headings miss to capitalize all the first letters. - [p1] "each AEAD will" -> "each AEAD algorithm will" - [p4] " number(SEQ)" -> " number (SEQ)" - [p5] "Cipher Context" -> "Crypto Context" - [p6] "Octets long" -> "octets long" - [p7] "9.1 and 10.1)with" -> "9.1 and 10.1) with" - [s9.1] "4-octer" -> "4-octet" - [9.1, 10.1] "12 octet" -> "12-octet" - Figure 1 and 3 uses different approaches to enumerate the bytes.=20 - [s9.2] "see figure 2" -> "see Figure 2" - [Figure 4] "SRTCP MKI (optional) index" -> "SRTCP MKI (OPTIONAL)" - [s13] Caption is above Table 1 and 8 but below all other tables. - [s13.2] "CBC MAC" -> "CBC-MAC" - [s15.3] Delete "lists maintained under "MIKEY Security Protocol Parameter= s"." - [s16] "length )" -> "length)" =09 - [s16] "the key length of the Key Derivation Function" -> "the input key length of the Key Derivation Function" - [Table 16] remove space before 16: "AEAD_AES_128_GCM_12 | AES-GCM | 16 octets | 12 octets |" -> "AEAD_AES_128_GCM_12 | AES-GCM | 16 octets | 12 octets |" - [s17] If you would like to thank my Ericsson colleagues, their names are = "Westerlund" and "Ohlsson" (BTW the pdf version of the document has strange page breaks...) ---------------------------------------------------------------------------= --------- JOHN MATTSSON MSc Engineering Physics, MSc Business Administration and Economics Senior R= esearcher, Security=20 Ericsson AB Security Research F=E4r=F6gatan 6 SE-164 80 Stockholm, Sweden Phone +46 10 71 43 501 SMS/MMS +46 76 11 53 501 john.mattsson@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From internet-drafts@ietf.org Mon Oct 21 08:27:23 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559F511E85C8; Mon, 21 Oct 2013 08:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtFwugXedkwW; Mon, 21 Oct 2013 08:27:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 582AF11E85A5; Mon, 21 Oct 2013 08:27:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021152718.29469.8767.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 08:27:18 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 15:27:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Options for Securing RTP Sessions Author(s) : Magnus Westerlund Colin Perkins Filename : draft-ietf-avtcore-rtp-security-options-08.txt Pages : 34 Date : 2013-10-21 Abstract: The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity and source authentication of RTP/RTCP packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP, and gives guidance for developers on how to choose the appropriate security mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-security-options-= 08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From csp@csperkins.org Mon Oct 21 08:31:39 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B8311E85F7 for ; Mon, 21 Oct 2013 08:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.799 X-Spam-Level: X-Spam-Status: No, score=-104.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_48=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szMS6GzFxtcj for ; Mon, 21 Oct 2013 08:31:32 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B7011E83FB for ; Mon, 21 Oct 2013 08:31:06 -0700 (PDT) Received: from [130.209.247.112] (port=55931 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VYHRa-0004rC-57; Mon, 21 Oct 2013 16:30:59 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Colin Perkins In-Reply-To: Date: Mon, 21 Oct 2013 16:30:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1C9FC9AE-5404-4B0D-9B6E-0F1E4FBA9372@csperkins.org> References: To: John Mattsson X-Mailer: Apple Mail (2.1510) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Cc: "avt@ietf.org" Subject: Re: [AVTCORE] draft-ietf-avtcore-rtp-security-options-07 review X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 15:31:41 -0000 Hi, After some offline discussion we've just submitted an updated version of = this draft, that hopefully addresses these comments. Cheers, Colin On 11 Oct 2013, at 15:04, John Mattsson = wrote: > Hi, >=20 > I reviewed draft-ietf-avtcore-rtp-security-options-07. Sorry for = missing the WGLC deadline. >=20 > Generally the draft is excellent! Just the kind of document I wish had = been available when I read up on RTP security many years ago. I have = some comments though: >=20 > /John >=20 >=20 > Comments on draft-ietf-avtcore-rtp-security-options-07 > = ------------------------------------------------------------------------- >=20 > - [s2] While the section provides an excellent review of topologies on = the RTP user plane, it lacks description of different topologies and = trust relationships in the control plane, which very often do not = involve the same nodes as the user plane and is equally (or even more) = important for the key management. Some information is provided in = section 4, but structuring it as in section 2 would be good. >=20 > - I suggest slightly refining the sentences about groups with shared = security contexts: > [p5] "trusted device that is part of the security context" > [p6] "without needing to be in the security context" > [p6] "needs to be a trusted part of the application security context" > [p7] "that is part of the security context" > [p7] "participants in the group security context" > [p7] "individual sources within the security context" > [p16] "do not include the media server in the security context" >=20 > At least for SRTP, the identities of the participants are not part of = the security context (except maybe for the receiver=B4s own IP which may = be used to identify the context). General suggestions: > "has access/knowledge of the security context" > "is part of/participates in the group sharing the security context" > "needs to be trusted with the security context" >=20 > - I would remove the uses of the word symmetric that does not refer to = symmetric crypto > [p7] "Thus use of any symmetric security functions fails ..." > [p8] "and a non-symmetrical verification of who sent" >=20 > I suggest:=20 > "Thus use of any group security context fails ..." > "and an individual verification of who sent" >=20 > - [p8] The feedback targets FT1 and FT2 in Figure 6 are not mentioned = in the text? Why are there exactly 2 and why do they receive traffic = from the distribution source? >=20 > - [s3.1] The difference between SRTP transforms, SRTP crypto suites, = and SRTP protection profiles needs to be explained. > Suggestion: > "SRTP and MIKEY works with transforms where any combination of = encryption algorithm, authentication algorithm, and PRF can be used and = the authentication tag length can be set to any value. This gives = flexibility but requires more security knowledge by the application = developer. To simplify things, Security Descriptions and DTLS-SRTP uses = SRTP crypto suites and SRTP protection profiles that bundles together = transforms and other parameters. This gives less flexibility but it = easier to use." >=20 > I would recommend that the document first discusses SRTP transforms, = and then SRTP crypto suites and SRTP protection profiles. >=20 > - [p9] "The following transforms are defined..." but then the defined = crypto suites are listed... >=20 > - [p9] "AES Counter Mode encryption with 128 bits keys combined with = 128 bits keyed HMAC-SHA-1 using 80- or 32-bits authentication tags. This = is the default cryptographic transform that needs to be supported. = Defined in SRTP [RFC3711]." >=20 > 1. HMAC-SHA-1 uses 160 bit keys so "combined with 160 bits keyed = HMAC-SHA-1". > 2. 32-bit authentication tags are not default and not mandatory to = support. > 3. While the mentioned transforms are defined in [RFC3711], the crypto = suites were defined in [RFC4568] and the protection profiles in = [RFC5764].=20 >=20 > - [p9] "AES-f8 and HMAC-SHA-1: AES f8 mode encryption with 128-bits = keys combined with keyed HMAC-SHA-1 using 80- or 32-bit authentication. = Defined in SRTP [RFC3711]." >=20 > While the mentioned transforms are defined in [RFC3711], the crypto = suite F8_128_HMAC_SHA1_80 is defined in [RFC4568]. There is no = F8_128_HMAC_SHA1_32 crypto suite, and no f8 protection profiles. >=20 > - [p9] "The TESLA transform for SRTP is defined in [RFC4383]". > Yes, but if the list is for crypto suites, there are no crypto suites = for TESLA (nor protection profile), i.e. you can only use TESLA with = MIKEY (or some proprietary protocol). As TESLA is not an ordinary SRTP = authentication transforms (it introduces new fields and may be used = together with an ordinary SRTP authentication transform), it might be = better to describe it in the same part as RFC4771. >=20 > - [p9,10] In the bullets on SEED and ARIA. "It has three modes" and = "It has also three modes. I know that RFC5669 states that: "We define = three modes of running SEED: (1) SEED in counter mode, (2) SEED in = counter mode with CBC-MAC" But the word "mode" is a really poor choice = (as mode is used to describe blockcipher mode, even it that same = sentence) better to use "options", "variants", or "crypto suites". >=20 > - [p10] "AES-192 and AES-256: cryptographic transforms for SRTP based = on AES-192 and AES-256 counter mode encryption and 160-bit keyed = HMAC-SHA-1 with 80- and 32-bit authentication tags. Thus providing 192 = and 256 bits encryption keys. Defined in [RFC6188]." >=20 > AES-192 and AES-256 are the block ciphers, the transforms would be = AES_192_CM and AES_256_CM. Debatable if AES_192_CM and AES_256_CM are = different SRTP transforms from AES CM. MIKEY sees them as the AES CM = transform with different key lengths. The transforms were defined = already in [RFCR3711]. [RFC6188] better describes the use of AES-192, = AES-256, provides test data and define the crypto suites. Maybe "Defined = in [RFC3711], [RFC6188]" >=20 > - [p10] "AES-GCM: Galois Counter Mode and AES-CCM (Counter with CBC)" > The colon should be moved to include AES-CCM "AES-GCM and AES-CCM:" or = "AES-GCM (Galois Counter Mode) and AES-CCM (Counter with CBC-MAC):" > Note that CCM is abbreviation of Counter with CBC-MAC. >=20 > - [s3.1] The NULL transforms defined in [RFC3711] should be mentioned = somehow. >=20 > - [s3.1] The MKI mechanism for rekeying defined in [RFC3711] should be = mentioned somehow. >=20 > - After "is the most common used" I would suggest adding:=20 > "AES-GCM, AES_192_CM, and AES_256_CM are expected to gain usage in the = future, especially due to the AES- and GCM-specific instructions on new = CPUs. >=20 > - [s3.1.1, s5.1] I think the texts regarding DTLS-SRTP is a little bit = too optimistic, and fails to mention the weaknesses. If used with PKI = (or some other trusted third party solution), the security may of course = be great, but in practice it is used with self-signed certificates. And = while DTLS-SRTP with self-signed certificates might be close to optimal = for point-to-point SIP over Internet or WebRTC, it was not chosen = because of the perfect security, it was chosen because it offers fair = security while not requiring complicated setup or trust in a third = party. The normal usage of DTLS-SRTP with self-signed certificates still = relies on trust in the signaling or the assumption that nobody was = spying during the first call, and for a call over the Internet, you = cannot normally make either of these assumptions... >=20 > - [p11] "It is mandatory to support in WebRTC" > -> "to use" or "to support and use" >=20 > - [p12] MIKEY might establish a TEK directly without any TGK. Maybe = better to just write "cryptographic method used to establish the session = keys actually used by the security protocol, like SRTP" Then also change = "TGK" to "session key" in the following bullets. >=20 > - [p12] Maybe write a little bit more about TICKET. Suggestion: > "TICKET: [RFC6043] is a MIKEY extension using a trusted centralized = key management service (KMS). The Initiator and the Responder do not = share any credentials; instead, they trust a third party, the KMS, with = which they both have or can establish shared credentials." >=20 > - [p13] In the paragraph "MIKEY messages have several ..." > Should mention the application/mikey MIME media type. Suggestion: > "[RFC3830] defines the application/mikey MIME media type allowing = MIKEY to be used in e.g. emails and HTTP." >=20 > - [p13] In the paragraph "MIKEY with pre-shared ...", it would be good = to add: > "IMS media security [T3GPP.33.328] specifies use of the TICKET mode = transported over SIP and HTTP." >=20 > - [s3.1.3] I suggest adding: "Security Descriptions are used for = access protection in IMS Media Security [T3GPP.33.328]." >=20 > - [s3.5] I suggest stating that as DTLS build upon TLS, they are = almost equivalent from a security perspective (and many other aspects), = and then ONLY mention any differences from DTLS. >=20 > - [s5] I think IMS media security using Security Descriptions for e2ae = security (specified in 3GPP TS 33.328) should be one of examples. The = trust and architecture is quite different from SIP over Internet. (If = you want I can write the example text). >=20 > - [s5.2] Maybe a little bit too detailed; At least the text cannot = recommend use of new self-signed certificates each session without = discussing the negative security consequences of doing so, i.e. no = continuity of authentication. Maybe better to move all privacy = discussions to section 4.1.5. >=20 > - [s5.3] I would suggest the word "copied" instead of "captured" >=20 >=20 >=20 > Editorial comments on draft-ietf-avtcore-rtp-security-options-07 > = ------------------------------------------------------------------------- >=20 > - Varying capitalization/spelling of several terms: > [p4] "Point to point" vs. "point-to-point"=20 > [p6] "Any source Multicast" -> "Any Source Multicast" > [p7] "Source-Specific Multicast" vs. "Source Specific Multicast"=20 > [p9] "128 bits keys" vs. "128-bits keys" >=20 > - Some figure texts capitalizes first letters in words while others do = not. >=20 > - [p7] "needs to be trusted device" -> "needs to be a trusted device" = or "needs to be trusted" >=20 > - [p8] "The goal is to help applications designer by giving reviewing = the types of solution that are available." > Something is wrong with this sentence. >=20 > - [p9] "membership by not sources" -> "membership but not sources" >=20 > - [p13] "It's features" -> "Its features" >=20 > - [s5.3] "ISMA Crypt 2.0" -> "ISMACryp 2.0" >=20 > - [p28] "[ISMACrypt2]" -> "[ISMACryp2]" And maybe refer to Open IPTV = Forum as they are keeping the old ISMA/MPEGIF documents >=20 >=20 > = --------------------------------------------------------------------------= ---------- > JOHN MATTSSON > MSc Engineering Physics, MSc Business Administration and Economics=20 > Senior Researcher, Security=20 >=20 > Ericsson AB > Security Research > F=E4r=F6gatan 6 > SE-164 80 Stockholm, Sweden > Phone +46 10 71 43 501 > SMS/MMS +46 76 11 53 501 > john.mattsson at ericsson.com > www.ericsson.com >=20 >=20 >=20 >=20 > This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Mon Oct 21 14:40:31 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37FE11E8610; Mon, 21 Oct 2013 14:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKuW1m1fDqcN; Mon, 21 Oct 2013 14:40:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7198F11E8712; Mon, 21 Oct 2013 14:40:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021213939.32455.90581.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 14:39:39 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-ekt-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 21:40:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Encrypted Key Transport for Secure RTP Author(s) : David A. McGrew Dan Wing Filename : draft-ietf-avtcore-srtp-ekt-01.txt Pages : 51 Date : 2013-10-21 Abstract: Encrypted Key Transport (EKT) is an extension to Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, Rollover Counters, and other information, within SRTP or SRTCP. This facility enables SRTP to work for decentralized conferences with minimal control. This note defines EKT, and also describes how to use it with SDP Security Descriptions, DTLS-SRTP, and MIKEY. These other key management protocols provide an EKT key to everyone in a session, and EKT coordinates the keys within the session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-ekt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-srtp-ekt-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-ekt-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 21 15:44:35 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A3511E87BD; Mon, 21 Oct 2013 15:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J17ruOCN6Nl2; Mon, 21 Oct 2013 15:44:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AA011E87B3; Mon, 21 Oct 2013 15:44:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021224434.32482.19379.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:44:34 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-topologies-update-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:44:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP Topologies Author(s) : Magnus Westerlund Stephan Wenger Filename : draft-ietf-avtcore-rtp-topologies-update-01.txt Pages : 41 Date : 2013-10-21 Abstract: This document discusses point to point and multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document is updated with additional topologies and is intended to replace RFC 5117. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-rtp-topologies-update= -01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ron.even.tlv@gmail.com Tue Oct 22 14:58:42 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4385611E8244; Tue, 22 Oct 2013 14:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FORGED_OUTLOOK_TAGS=0.001, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB4CvLxQZC9D; Tue, 22 Oct 2013 14:58:41 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 27F9111E822C; Tue, 22 Oct 2013 14:58:40 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id r16so4608357ead.31 for ; Tue, 22 Oct 2013 14:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=GNpBhlAb8EaKgrbb7TxEENV2Vgzdropj5w8sNLtvhl0=; b=EMvwT+b8mmqlfZkznvcYTwHkqLMc0rteUSeJVMSA16BtJv6y2W18+6MyWQCOKgp974 x1umo6DEr6WaI5H/VkPbrT3EwA3DBRzQ/3byNlXEH5EIPlqyWxyvpqmZf+Wu4u62jGy/ WXOpmLDyeITPSBjVNThoYBxyQ91UkLvIrDzV/Kj/WrVcM1UlQz1QVqvO1dGRqHaJXEDw spGb3k32SBwpTDm+Y7ZeuaEw9zYyPfbtpgfN9fPw7ULsmMWzgIAt2WRm4J12zrL71a1P uXMa1/CY9Mr9/cKqfSL37d+N04oiyyM8vAQud1Mi1xGTtL46bJuX9LYLd7Jh86wNwv8b K9mw== X-Received: by 10.15.77.132 with SMTP id p4mr1484149eey.95.1382479118254; Tue, 22 Oct 2013 14:58:38 -0700 (PDT) Received: from RoniE (bzq-79-181-191-27.red.bezeqint.net. [79.181.191.27]) by mx.google.com with ESMTPSA id b42sm61756477eem.9.2013.10.22.14.58.35 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Oct 2013 14:58:37 -0700 (PDT) From: "Roni Even" To: Date: Wed, 23 Oct 2013 00:55:26 +0300 Message-ID: <090501cecf71$6d634740$4829d5c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0906_01CECF8A.92B0F470" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7PcRoF2W2BSJUEQ0itKDuVz8sR2w== Content-Language: en-us Cc: Magnus Westerlund , payload@ietf.org Subject: [AVTCORE] AVTcore agenda for IETF88 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 21:58:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0906_01CECF8A.92B0F470 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0907_01CECF8A.92B0F470" ------=_NextPart_001_0907_01CECF8A.92B0F470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The proposed agenda for the AVTcore session in Vancouver is uploaded. We allocated some time for Payload WG. Please send any comments to the chairs Roni Even AVTcore co-chair ------=_NextPart_001_0907_01CECF8A.92B0F470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The proposed = agenda for the AVTcore session in Vancouver is uploaded. We allocated = some time for Payload WG.

Please send = any comments to the chairs

Roni = Even

AVTcore = co-chair

------=_NextPart_001_0907_01CECF8A.92B0F470-- ------=_NextPart_000_0906_01CECF8A.92B0F470 Content-Type: text/html; name="agenda.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="agenda.html" Audio/Video Transport Core Maintenance (AVTCore) Working Group = Agenda

Audio/Video Transport Core Maintenance = (AVTCore) Working Group Agenda

Chairs: Magnus Westerlund , Roni = Even

Thursday, 7 November 2013 at 15:20-17:20 (Regency C)

15:20 AVTCore Status UpdateChairs
15:35 Sending Multiple Media Streams in a Single RTP = SessionMagnus
= draft-ietf-avtcore-rtp-multi-stream-01
15:45 Grouping RTCP Reception Statistics and Other = FeedbackMagnus=20
draft-ietf-avtcore-rtp-multi-stream-optimisation-00
15:55 Circuit Breakers for Unicast SessionsZaheduzzaman Sarker=20
draft-ietf-avtcore-rtp-circuit-breakers-03
16:25 Payload Status UpdateChairs
16:35 RTP Payload Format for Opus Speech and Audio CodecJM Valin
draft-ie= tf-payload-rtp-opus-01
16:50 End
------=_NextPart_000_0906_01CECF8A.92B0F470 Content-Type: text/plain; name="a1311.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="a1311.txt" Audio/Video Transport Core Maintenance (AVTCore) Working Group =============================================================== CHAIRS: Magnus Westerlund Roni Even AGENDA Thursday, 7 November 2013 at 15:20-17:20 (Regency C) ---------------------------------------------------- 15:20 AVTCore Status Update (Chairs, 15) 15:35 Sending Multiple Media Streams in a Single RTP Session(Magnus, 10) draft-ietf-avtcore-rtp-multi-stream-01 15:45 Grouping RTCP Reception Statistics and Other Feedback(Magnus , 10) draft-ietf-avtcore-rtp-multi-stream-optimisation-00 15:55 Circuit Breakers for Unicast Sessions (Zaheduzzaman Sarker , 30) draft-ietf-avtcore-rtp-circuit-breakers-03 16:25 Payload Status Update (Chairs, 10) 16:35 RTP Payload Format for Opus Speech and Audio Codec(JM Valin, 15) draft-ietf-payload-rtp-opus-01 16:50 End ------=_NextPart_000_0906_01CECF8A.92B0F470-- From magnus.westerlund@ericsson.com Thu Oct 24 00:04:44 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F16411E82F1 for ; Thu, 24 Oct 2013 00:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.302 X-Spam-Level: X-Spam-Status: No, score=-105.302 tagged_above=-999 required=5 tests=[AWL=0.947, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOU5gJm5UHk2 for ; Thu, 24 Oct 2013 00:04:39 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8711E82EC for ; Thu, 24 Oct 2013 00:04:37 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-e2-5268c68437ed Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4D.CA.16099.486C8625; Thu, 24 Oct 2013 09:04:37 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.328.9; Thu, 24 Oct 2013 09:04:36 +0200 Message-ID: <5268C6AA.8060804@ericsson.com> Date: Thu, 24 Oct 2013 09:05:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: IETF AVTCore WG References: <20131021224434.32482.19379.idtracker@ietfa.amsl.com> In-Reply-To: <20131021224434.32482.19379.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+JvjW7rsYwgg3d/2C1e9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtHDF1gLjohVLD//laWBsV+oi5GTQ0LARGLH4UOsELaYxIV7 69m6GLk4hAQOM0qsXrycFcJZzijxsnUdM0gVr4C2xOnPWxhBbBYBVYn3B5aB2WwCFhI3fzSy gdiiAsESN5YdYoOoF5Q4OfMJC4gtIqAksWPSNrA5wgIeEh+ndDCB2EICjhI3j60GinNwcAo4 SVw+JwxiSgiIS/Q0BoFUMAvoSUy52sIIYctLNG+dzQzRqS3R0NTBOoFRcBaSZbOQtMxC0rKA kXkVI3tuYmZOernhJkZg8B3c8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwKjz0DHkm/j9by/fsvh4VV33+DbFg21H1YWy0o+/OffqrZ648I0j+9vK3Fl9 swqePRDu+5Ip87pgobu0tpxZYN2Nxq574tZb+x174pf0WDrlaYjfOD9TqFuiSzL8rqxux9KK W9+vSYR+Z5L489krSPWPy8Jy8Tqfgzv9b79kfDo5IuVd1Q9bPiWW4oxEQy3mouJEAL2kdioM AgAA Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-topologies-update-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 07:04:44 -0000 WG, Stephan and I have updated this draft. Likely the most impacting change is the renaming of the Source Projection Middlebox to Selective Forwarding Middlebox and De-composite Endpoint to Split Component Endpoint. There is also quite a bit of new text in the topologies description expanding on some behaviors. A large number of editorial changes has also happened. The Topologies properties section is not yet updated with all the topologies. Something for the next version. So please review and provide feedback. Cheers Magnus On 2013-10-22 00:44, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : RTP Topologies > Author(s) : Magnus Westerlund > Stephan Wenger > Filename : draft-ietf-avtcore-rtp-topologies-update-01.txt > Pages : 41 > Date : 2013-10-21 > > Abstract: > This document discusses point to point and multi-endpoint topologies > used in Real-time Transport Protocol (RTP)-based environments. In > particular, centralized topologies commonly employed in the video > conferencing industry are mapped to the RTP terminology. > > This document is updated with additional topologies and is intended > to replace RFC 5117. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-topologies-update-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Oct 24 00:07:11 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FE811E8160 for ; Thu, 24 Oct 2013 00:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.515 X-Spam-Level: X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KIgzCm6koPw for ; Thu, 24 Oct 2013 00:07:06 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 38D1A11E82EC for ; Thu, 24 Oct 2013 00:07:03 -0700 (PDT) X-AuditID: c1b4fb38-b7f178e00000233b-67-5268c716a876 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id DB.74.09019.617C8625; Thu, 24 Oct 2013 09:07:02 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.2.328.9; Thu, 24 Oct 2013 09:07:01 +0200 Message-ID: <5268C73C.40605@ericsson.com> Date: Thu, 24 Oct 2013 09:07:40 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: IETF AVTCore WG References: <20131021152718.29469.8767.idtracker@ietfa.amsl.com> In-Reply-To: <20131021152718.29469.8767.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvja7Y8Ywgg3mzhS1e9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsLfT9gLlohVdC7byd7A+F6wi5GDQ0LAROL9pdouRk4gU0zi wr31bF2MXBxCAkcZJa48msMI4SxnlLjRsYIRpIFXQFPi/QRXkAYWAVWJZ2dnsoPYbAIWEjd/ NLKB2KICwRI3lh0Cs3kFBCVOznzCAmKLCChJ7Ji0jRnEFhZwl2ic+QKsV0jAQaLl4A+wek4B R4nzjw6wQ9wmLtHTGAQSZhbQk5hytYURwpaXaN46mxmiVVuioamDdQKj4Cwk22YhaZmFpGUB I/MqRo7i1OKk3HQjg02MwOA7uOW3xQ7Gy39tDjFKc7AoifN+fOscJCSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoGRefP/m63n0w/V+d861Cl2Rk39g6dHn6zQZ37f70/1Zpz483wpa9EOgyWr z/xSt//y04H3JWPUfYvHrZ823ZlbP3npxj+lKYstmI553A1+eYJpS4Zc+97KRuan5T+ehWnn c6vZaio+91nl2/AiTC/zgManB07zfphe+VC6rffEQ5nFNvu5+hjzlFiKMxINtZiLihMByTVk pgwCAAA= Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-security-options-08.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 07:07:11 -0000 WG, Speaking as a co-author. This version was seen some significant changes due to John Mattsson's comments. So please review these changes and indicate if you are okay with them or provide comments. Cheers Magnus On 2013-10-21 17:27, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Options for Securing RTP Sessions > Author(s) : Magnus Westerlund > Colin Perkins > Filename : draft-ietf-avtcore-rtp-security-options-08.txt > Pages : 34 > Date : 2013-10-21 > > Abstract: > The Real-time Transport Protocol (RTP) is used in a large number of > different application domains and environments. This heterogeneity > implies that different security mechanisms are needed to provide > services such as confidentiality, integrity and source authentication > of RTP/RTCP packets suitable for the various environments. The range > of solutions makes it difficult for RTP-based application developers > to pick the most suitable mechanism. This document provides an > overview of a number of security solutions for RTP, and gives > guidance for developers on how to choose the appropriate security > mechanism. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-security-options-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-security-options-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Oct 24 00:20:29 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363A311E816F for ; Thu, 24 Oct 2013 00:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.305 X-Spam-Level: X-Spam-Status: No, score=-105.305 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCY1HeHWaO77 for ; Thu, 24 Oct 2013 00:20:24 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A62E611E80F9 for ; Thu, 24 Oct 2013 00:20:23 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-42-5268ca366934 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 51.8D.16099.63AC8625; Thu, 24 Oct 2013 09:20:22 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Thu, 24 Oct 2013 09:20:22 +0200 Message-ID: <5268CA5C.3010402@ericsson.com> Date: Thu, 24 Oct 2013 09:21:00 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIJMWRmVeSWpSXmKPExsUyM+Jvja7ZqYwggxWfDCxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo7Wn6wFy/gqzjTsYWlgbOPpYuTkkBAwkTjz9B4jhC0mceHe ejYQW0jgMKPE7V0qXYxcQPZyRom+68fYQRK8AtoS1x8fBmtgEVCVmHvyPiuIzSZgIXHzRyNY s6hAsMSNZYfYIOoFJU7OfMICYosIKEnsmLSNGcQWFjCQWPT8LtAcDqDF4hI9jUEgYWYBPYkp V1sYIWx5ieats5kh7tGWaGjqYJ3AyD8LydRZSFpmIWlZwMi8ipE9NzEzJ73ccBMjMJgObvmt u4Px1DmRQ4zSHCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBkqnCwvBdS8HNa xiTp12tMC+NemlwXUtjXL7/d4aH7kSLnzP0f/3y5+P+0gNbEudfZ/aaF9/3ZxHD699VAiS/L Y10rl5RuOxeaFczu95TlyTSexrnJnH+5xUqc7GxfG1lYlT5bI+rtfC/iyrkzQZXtsv5bXkpf YNF5qT7ts7bmebf8XduWK7MosRRnJBpqMRcVJwIAFPIgw/QBAAA= Subject: [AVTCORE] RTP Simulcast proposal has been updated X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 07:20:29 -0000 WG, My co-authors and I have updated the proposal for how to do Simulcast in RTP so that it supports Unified Plan for SDP. Thus we can support single media source per media description with multiple simulcast encodings. It also support multiple sources per media description for broadcast/simulcast as well as "legacy" usages where the simulcast encoding versions are distributed across different media descriptions in SDP. Thus simulcast within one as well as using multiple RTP sessions (and thus transports) are supported. This update also focuses the SRCNAME SDES item proposal to the need of simulcast. SRCNAME is used to identify the relationship between an SSRC and the media source and particular encoding carried. To speed up acquisition we are proposing an generic SDES item RTP Header extension to enable inclusion of the SRCNAME item in RTP headers at startup. The proposal consists of three I-Ds and we will discuss the general signalling and setup/negotiation in MMUSIC and the SRCNAME and the header extension is requested to be presented in AVTEXT WG. https://datatracker.ietf.org/doc/draft-westerlund-avtcore-transport-multiplexing/ https://datatracker.ietf.org/doc/draft-westerlund-avtext-sdes-hdr-ext/ https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtcp-sdes-srcname/ Feedback much appreciated Cheers Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bill.wu@huawei.com Thu Oct 24 21:00:21 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD9A11E821E for ; Thu, 24 Oct 2013 21:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.144 X-Spam-Level: X-Spam-Status: No, score=-6.144 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeVRQaTp2SfH for ; Thu, 24 Oct 2013 21:00:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ABFCF11E81EA for ; Thu, 24 Oct 2013 21:00:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZL23759; Fri, 25 Oct 2013 04:00:14 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 05:00:06 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 05:00:11 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.141]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0146.000; Fri, 25 Oct 2013 12:00:02 +0800 From: Qin Wu To: "avt@ietf.org" Thread-Topic: I-D Action: draft-wu-avtcore-dynamic-pt-usage-02.txt Thread-Index: AQHOzkNpG0zmgLYpiEO8yjE9N/VRfpoEzrvw Date: Fri, 25 Oct 2013 04:00:01 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [AVTCORE] FW: I-D Action: draft-wu-avtcore-dynamic-pt-usage-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 04:00:21 -0000 Hi,folks: We have made a minor update to draft-wu-avtcore-dyanmic-pt-usage Based on comments we received so far. The diff is: http://www.ietf.org/rfcdiff?url2=3Ddraft-wu-avtcore-dynamic-pt-usage-02 The reasons to have such document are two: a. We need a document to clarify how to update IANA registry for Dynamic pa= yload type number allocation to reflect RFC5761. b. We need a document to provide additional guidelines for Dynamic payload = type usage as follows: (1) New payload formats(e.g.,H.264,VP8) MUST use dynamic payload type numbe= r assignment.=20 Each new payload format MUST be named as "encoding name" by a registered me= dia subtype defined in the "RTP Payload Format media types" registry.=20 The "encoding name" in the RTP payload type registry is also registered as = a media subtype under the media type "audio" or "video" in the "RTP Payload= Format media types" registry. (2) Provide order for dynamic payload type number allocation I. first use values in the range [96-127]for dynamic payload types II. Then use codes below 96 O Unassigned payload type numbers [35-63]=20 O Followed by [20-24], 27,[29-30]. O Use the reserved values 1,2,19 (see [RFC3551]for reserved values) O And 64, 65 (see [RFC5761]for reserved value)if H.261 FIR or H.261 NACK is= not used in the WebRTC context Warning: potentially cause collisions with legacy use O Override the static types[0, 3-18,25,26,28,31-34] and map encodings to th= ese defined static payload type Warning: cause problems for applications that ignore the mapping in the = signaling and assume a specific payload format based on the Payload Type (3) In the case when multiplexing RTP and RTCP are not used, the range [66-= 95] is used Caution: better to use the pt numbers that are not conflicting with the cur= rently assigned RTCP values Let us know if you think these reasons make sense. Regards! -Qin -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, October 21, 2013 5:53 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-wu-avtcore-dynamic-pt-usage-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Guideline for dynamic payload type number usage policy Author(s) : Qin Wu Roni Even Rachel Huang Filename : draft-wu-avtcore-dynamic-pt-usage-02.txt Pages : 8 Date : 2013-10-21 Abstract: The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document provides guidelines for payload type number usage policy when dynamic payload type allocation is used. Also this document updates closed IANA registry "RTP Payload types (PT) for standard audio and video encodings". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-avtcore-dynamic-pt-usage There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-avtcore-dynamic-pt-usage-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-wu-avtcore-dynamic-pt-usage-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From magnus.westerlund@ericsson.com Fri Oct 25 02:54:29 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE2E11E83B7 for ; Fri, 25 Oct 2013 02:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.284 X-Spam-Level: X-Spam-Status: No, score=-105.284 tagged_above=-999 required=5 tests=[AWL=0.965, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuYYa6VIqBdM for ; Fri, 25 Oct 2013 02:54:24 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2729E11E83B6 for ; Fri, 25 Oct 2013 02:54:22 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-9b-526a3fcd7c54 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FB.87.16099.DCF3A625; Fri, 25 Oct 2013 11:54:22 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Fri, 25 Oct 2013 11:54:21 +0200 Message-ID: <526A3FF9.1060607@ericsson.com> Date: Fri, 25 Oct 2013 11:55:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+Jvje45+6wgg/5N3BYve1ayW5zsfMPk wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGWsnrSVseAra8Wpi5+ZGhi/s3QxcnJICJhI zLpziBHCFpO4cG89WxcjF4eQwGFGiWlz1zGBJIQEljNK/OvxBbF5BbQl1m9czgpiswioSixc /BKsmU3AQuLmj0Y2EFtUIFjixrJDbBD1ghInZz4BWyYioCSxY9I2ZhCbWcBAYnn7TrD5wkC9 N27uYe9i5AA6QlyipzEIokRPYsrVFkYIW16ieetsZohztCUamjpYJzAKzEKyYRaSlllIWhYw Mq9iZM9NzMxJLzfcxAgMvINbfuvuYDx1TuQQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGKctSn/4XvRCx+TNQp95L8t1+0t5T/z08V/Knf9ibf9ND16/tzDIImTzjppH a2seqxwtVVu9MjiIe7FO9M67J9Vs7uf+dNjYZHJk6+XnKx3Ym0KU/RwWd1hemKDHanEm34Wr 80FdbLvSq/7Ol4fmVVnIdF20P9W1JO/f5uNylnKXTU4vnVt7tESJpTgj0VCLuag4EQDM/t2Q CgIAAA== Cc: draft-ietf-avtcore-srtp-ekt@tools.ietf.org Subject: [AVTCORE] WG last call for draft-ietf-avtcore-srtp-ekt-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:54:29 -0000 WG, This starts a 3-week (due to the IETF meeting) WG last call of Encrypted Key Transport for Secure RTP with intended status Proposed Standard. Please provide any feedback by the 15th of November. The draft https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-ekt/ Cheers Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Oct 25 03:50:35 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94B021F9F9D for ; Fri, 25 Oct 2013 03:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.316 X-Spam-Level: X-Spam-Status: No, score=-105.316 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AFKtVxo+OLf for ; Fri, 25 Oct 2013 03:50:30 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DDF3A11E8303 for ; Fri, 25 Oct 2013 03:50:24 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-77-526a4cee0b89 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BF.4A.03802.EEC4A625; Fri, 25 Oct 2013 12:50:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.2.328.9; Fri, 25 Oct 2013 12:50:22 +0200 Message-ID: <526A4D1B.20401@ericsson.com> Date: Fri, 25 Oct 2013 12:51:07 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: References: <20131001160737.21382.20160.idtracker@ietfa.amsl.com> In-Reply-To: <20131001160737.21382.20160.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvje57n6wgg/5ObouXPSvZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMeG3e8FbwYqLU40aGLv4uhg5OSQETCT+njnFDmGLSVy4t56t i5GLQ0jgMKPEyk/vGCGc5YwSj5s+MoNU8QpoSmx61sUEYrMIqEqcnHWJEcRmE7CQuPmjkQ3E FhUIlrix7BAbRL2gxMmZT1hAbBEBIYnp/RPAeoUFPCRm/j4AViMk4CjR0vuaFcTmFHCS+Dhh HVA9B9BF4hI9jUEgYWYBPYkpV1sYIWx5ieats5khWrUlGpo6WCcwCs5Csm0WkpZZSFoWMDKv YmTPTczMSS832sQIDL2DW36r7mC8c07kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanF hxiZODilGhjlHTVUGi/t78xPYVEuXnHyRq3HfcuHZ0OOqx1L1f7o23zhYts1/Q2t65UcFPhn 8YtOfbu1z0jk6TzvOMsSXgFGTUGb9XGOjl/2GB1vDTjPohht62U1aYrG5AbZzfmPdqsvtt3p LciqurXh039HptbNRn3/N2x1unf9t8T9T0Zd9/lTFm46x6rEUpyRaKjFXFScCAAvCkBXCwIA AA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-leap-second-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 10:50:36 -0000 WG, We did WG last call the -03. Some feedback was provided. There has been updates to the draft. I will now perform the write-up, and the WG gets some few more days to consider the changes before I will request publication. Cheers Magnus On 2013-10-01 18:07, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : RTP and Leap Seconds > Author(s) : Kevin Gross > Ray van Brandenburg > Filename : draft-ietf-avtcore-leap-second-05.txt > Pages : 8 > Date : 2013-10-01 > > Abstract: > This document discusses issues that arise when RTP sessions span > Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 > to describe how RTP senders and receivers should behave in the > presence of leap seconds. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-leap-second-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-leap-second-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Oct 25 07:17:38 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5AA11E83E0 for ; Fri, 25 Oct 2013 07:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.345 X-Spam-Level: X-Spam-Status: No, score=-105.345 tagged_above=-999 required=5 tests=[AWL=0.904, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTIwTdF7M6cL for ; Fri, 25 Oct 2013 07:17:33 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9B08611E8313 for ; Fri, 25 Oct 2013 07:17:31 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-e9-526a7d7a2b56 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C7.C9.03802.A7D7A625; Fri, 25 Oct 2013 16:17:30 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.2.328.9; Fri, 25 Oct 2013 16:17:27 +0200 Message-ID: <526A7DA5.5080600@ericsson.com> Date: Fri, 25 Oct 2013 16:18:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: References: <20130925062945.29986.54998.idtracker@ietfa.amsl.com> In-Reply-To: <20130925062945.29986.54998.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+JvjW5VbVaQwcojShYve1ayWyx/eYLR 4uK1h0wW+xefZ3Zg8ZjyeyOrx7T799k8liz5yeTR9uwOewBLFJdNSmpOZllqkb5dAlfGz+MH 2AvuiFSs/P6NrYGxSaCLkZNDQsBE4urrDiYIW0ziwr31bF2MXBxCAocZJebv6WWHcJYzSuz9 uIQVpIpXQFti0+aVLCA2i4CqRPe7vWA2m4CFxM0fjWwgtqhAsMSNZYfYIOoFJU7OfAJWIyIg JDG9fwLYNmaBTIm9P86A2cICNhKbp+4Ds4UEHCWWbz/CDGJzCjhJXPo9mbGLkQPoOnGJnsYg iFY9iSlXWxghbHmJ5q2zmSFatSUamjpYJzAKzUKyeRaSlllIWhYwMq9iZM9NzMxJLzfaxAgM 6YNbfqvuYLxzTuQQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGBNm2OTu j3r+8u0Ndcd7OVKzFzztOLzwh0Cj+sK7RecOnNUWe3f7c/ny9TuiL98Un36EVdlLvqXyA7NL KuN95Wkscy6/7mHtfrDimKruLDHXpeHa8vsF8td8L5W2W/Typ1BG4yuhg9lpJqu3RGjukUmf cOPg/xunnH9EyPypC6q3/PZnu8SVd65KLMUZiYZazEXFiQD7UHqCNwIAAA== Cc: Jonathan Lennox , Colin Perkins , Dan Wing Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 14:17:39 -0000 Hi, By now I assume everyone is happy with how this draft resolved the WG last call comments. I will start preparing the publication request. Cheers Magnus On 2013-09-25 08:29, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP) > Author(s) : Woo-Hwan Kim > Jungkeun Lee > Dong-Chan Kim > Je-Hong Park > Daesung Kwon > Filename : draft-ietf-avtcore-aria-srtp-05.txt > Pages : 33 > Date : 2013-09-24 > > Abstract: > This document describes the use of the ARIA block cipher algorithm > within the Secure Real-time Transport Protocol (SRTP) for providing > confidentiality for the Real-time Transport Protocol (RTP) traffic > and for the control traffic for RTP, the RTP Control Protocol (RTCP). > It details three modes of operation (CTR, CCM, GCM) and a SRTP Key > Derivation Function for ARIA. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-aria-srtp-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-aria-srtp-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From vsingh.ietf@gmail.com Sun Oct 27 03:57:35 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B66511E8162; Sun, 27 Oct 2013 03:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDG+d24J07X4; Sun, 27 Oct 2013 03:57:34 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCAB11E8144; Sun, 27 Oct 2013 03:57:34 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id u16so9158984iet.4 for ; Sun, 27 Oct 2013 03:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=mymBHQPqvBP7FJmEqZ+rUEcI3Mc1FnVw+ZxkAaruUBg=; b=esd2rUZmHNV84VUnnZXB0b00Yh8JcvzG5PmnUYzm0fo3/Xxz/0l3HVMhuXmN/W54g7 MsRyxGz1HTYfOpEWluRJL8b3+80N6qCmeqpgI1VM2PDvbJYeSxA0VELGvfl5i07Ck77y q2o3F4xD5enTbVkJcApDXV/PEK5poAuHAXAQ87KaIrlC40RRF7N+8qL5yEAWYJZKnDCd WLipNbDQ2Vgyh4AiKiaPv9Y3RgoXWtk9QRbTXXfofUGsRVnHrIiF6+Fg21W1x2fob2Ma DiMJBXqeg48qQ3uDe69MAhWXlHVGMpK0y+9utUUHKFDDVDBE1QEnjJTUpDfoNbzwZnDS kTjA== X-Received: by 10.50.77.72 with SMTP id q8mr4891071igw.14.1382871453857; Sun, 27 Oct 2013 03:57:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Sun, 27 Oct 2013 03:57:13 -0700 (PDT) From: Varun Singh Date: Sun, 27 Oct 2013 12:57:13 +0200 Message-ID: To: "rtcweb@ietf.org" , "avt@ietf.org" , rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Cc: "Eggert, Lars" , Mirja Kuehlewind , Colin Perkins Subject: [AVTCORE] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 10:57:35 -0000 Hi all, In RMCAT WG there has been discussion surrounding the use of a media traffic generator and to facilitate discussion, RMCAT is hosting a side meeting on Sunday, 03 November at 1300-1500. I suppose the room details will be announced shortly. Below is a list of questions that will help design or choose an appropriate traffic generator for Interactive multimedia traffic. The list is an initial set and mainly to foster discussion both on the mailing list and at the meeting. Mirja and Lars are not available that day, hence on their behalf, the meeting is hosted by Colin and I . Cheers, Varun --- Traffic generator: to model the intrinsic variability of video: - what target bit rates can be achieved? (max?, min?) - how much variability in media bit rate for a given target bit rate - how to model motion? capturing high motion leads to bursty video (higher than target bit rate), but by how much? can this even be done? Traffic generator: on responsiveness to a new target bitrate: - how quickly can the codec generate a lower bit rate? - immediately? does this depend on the new or requested bit rate? - what is immediately? is it next frame or a few frames later, until then does it generates at the current rate? - if not immediately, what bitrates (and duration) will it generate before meeting the target bitrate. - how quickly can the codec generate a higher bit rate? - immediately in the next frame? does this also depend on the new or requested bit rate? - not immediately but in steps of intermediate bitrates, i.e., intermediate bitrate for a short duration then an increase in step, repeating until reaching the target bit rate. - If the target bit rate is achieved in steps, can they be announced to the congestion controller, i.e., the congestion controller knows the ramp up curve to meet the target bit rate. - If the media bit rate has not yet reached the requested target bit rate and the congestion control requests a new target bit rate, how does the codec respond? Application design related: - should the congestion control be able to change the frame rate (video) or packetization time (audio) or is this something that the application controls. - should the congestion control be able to change video resolution? - should error-repair: NACKs, FEC be considered part of congestion control or outside it, i.e., it is something that the application does and not congestion control - If FEC is controlled by the congestion control, how quickly can the sending rate be adapted by reducing/adding redundancy (FEC)? is something link this done? Does this makes sense at all? - Apart from loss and RTT, what other congestion cues are currently used by congestion control algorithms? e.g., Decoding rate/goodput, application decode error rate, ECN, PCN, etc. - If the codec is data limited, i.e., producing a sending rate smaller than the one calculated by the congestion control, can the congestion control probe the bandwidth by sending additional data packets in a certain pattern (e.g., PathChirp)? would somehting link this help? - application input on prioritization: audio vs video (vs data) -- http://www.netlab.tkk.fi/~varun/ From ietf-secretariat-reply@ietf.org Wed Oct 30 01:40:46 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B483811E8265 for ; Wed, 30 Oct 2013 01:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx8Aed1wTNJQ for ; Wed, 30 Oct 2013 01:40:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 435A111E833C for ; Wed, 30 Oct 2013 01:40:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131030084017.6951.67450.idtracker@ietfa.amsl.com> Date: Wed, 30 Oct 2013 01:40:17 -0700 From: IETF Secretariat Subject: [AVTCORE] Milestones changed for avtcore WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 08:40:46 -0000 Changed milestone "Submit SRTP Cryptographic Transforms for AES Galois/Counter Mode (AES-GCM) and AES Counter with Cipher Block Chaining-Message Authentication Code (AES-CCM) and corresponding key-management profiles for Security Descriptions, MIKEY and DTLS-SRTP for publication as proposed standard", resolved as "Done". URL: http://datatracker.ietf.org/wg/avtcore/charter/ From ietf-secretariat-reply@ietf.org Wed Oct 30 05:15:06 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04D111E816F for ; Wed, 30 Oct 2013 05:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSMm70Gqgc2m for ; Wed, 30 Oct 2013 05:15:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 406BB11E8167 for ; Wed, 30 Oct 2013 05:15:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131030121503.6987.23946.idtracker@ietfa.amsl.com> Date: Wed, 30 Oct 2013 05:15:03 -0700 From: IETF Secretariat Subject: [AVTCORE] Milestones changed for avtcore WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 12:15:06 -0000 URL: http://datatracker.ietf.org/wg/avtcore/charter/ From magnus.westerlund@ericsson.com Wed Oct 30 05:22:27 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5F211E81E8 for ; Wed, 30 Oct 2013 05:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.398 X-Spam-Level: X-Spam-Status: No, score=-105.398 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxrXCC81tm6u for ; Wed, 30 Oct 2013 05:22:22 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9932811E8147 for ; Wed, 30 Oct 2013 05:22:22 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-dd-5270f9fd2f50 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 14.35.03802.DF9F0725; Wed, 30 Oct 2013 13:22:21 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.2.328.9; Wed, 30 Oct 2013 13:22:21 +0100 Message-ID: <5270FA37.6090107@ericsson.com> Date: Wed, 30 Oct 2013 13:23:19 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: References: <20131030121503.6987.23946.idtracker@ietfa.amsl.com> In-Reply-To: <20131030121503.6987.23946.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvje7fnwVBBnt79Sxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrulTcwFCzgqjkx/xdzA+Jati5GTQ0LARGL1i5eMELaYxIV7 64HiXBxCAocYJd73HWWGcJYzSixYuJAFpIpXQFvi241zYN0sAqoSCx58AIuzCVhI3PzRCBYX FQiWuLHsEBtEvaDEyZlPwGpEBIQkpvdPYAKxhYHqzzYfBYsLCThIXL2zACzOKeAo0XPhKXsX IwfQReISPY1BIGFmAT2JKVdbGCFseYnmrbOZIVq1JRqaOlgnMArOQrJtFpKWWUhaFjAyr2Jk z03MzEkvN9rECAy/g1t+q+5gvHNO5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoYVwpp23MGFGgFeWwSau0Q/r7BIOzinlnL5SUuc0uW1gTN8830/3Ly6PZSk+iAxZwT F0y4mGKgq/liU0XqR47GB9P/vVF3Dr0wf0H//wjGb1/5//RdkzaVuyHTV3tz6axriv8n9z45 +yhOI+/E3i2Lm1dofqnjvaLz88uJ5z4Nh5acV7/vvT24TomlOCPRUIu5qDgRAEIgZ3UNAgAA Subject: Re: [AVTCORE] Milestones changed for avtcore WG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 12:22:28 -0000 Hi, I don't know if this is a bug or not. However, what triggered this was that we chairs have submitted a request for two Milestones for the following drafts: draft-ietf-avtcore-rtp-multi-stream-01 draft-ietf-avtcore-rtp-multi-stream-optimisation-00 They await AD approval Cheers Magnus On 2013-10-30 13:15, IETF Secretariat wrote: > > > URL: http://datatracker.ietf.org/wg/avtcore/charter/ > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From vsingh.ietf@gmail.com Wed Oct 30 06:49:56 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8DE11E8167; Wed, 30 Oct 2013 06:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hghbUF61OJsO; Wed, 30 Oct 2013 06:49:54 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 092AD11E8174; Wed, 30 Oct 2013 06:49:53 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id e14so2252811iej.22 for ; Wed, 30 Oct 2013 06:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3wDQGBZXwBfou3hv2wsrPfdt81Bq5W/6wzhuIiqh0HA=; b=WsMNyZokkQJgTRQfcapxVwWUXPOZQcnOugCBsYsNo8Gktunxgx2jEw9CDnkQNF+a7F ND8olXhALot9piOGjJWdQN67zuNqjFceMwBqqU5EvKmwK/Z4dS/5ALSO/TNikh0T2ru4 joQpw5fwescwLx5j2erpLg/lZK/APbk9uIoAHg38sbX/Oy4FRY6CQ//UiqAyQsBiKSYn 8x2s3LonK3aS/l3Ybl8+LdNQEAD3ubynltuZsruj/3QoE/8s2S18msA5YhyWXDi2xRM/ q0djlqhMrRvgkGvtKRjAP9crH+kTI+GnE5iZUP8DHJwSucaNu0eQXMk9QoiQ2lDwsNMD zXPg== X-Received: by 10.50.77.72 with SMTP id q8mr2534284igw.14.1383140993330; Wed, 30 Oct 2013 06:49:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.102.8 with HTTP; Wed, 30 Oct 2013 06:49:33 -0700 (PDT) In-Reply-To: References: From: Varun Singh Date: Wed, 30 Oct 2013 15:49:33 +0200 Message-ID: To: "rtcweb@ietf.org" , "avt@ietf.org" , rmcat WG Content-Type: text/plain; charset=ISO-8859-1 Cc: "Eggert, Lars" , Mirja Kuehlewind , Colin Perkins Subject: Re: [AVTCORE] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 13:49:56 -0000 Hi all, Practical details for the meeting on **RMCAT Traffic models** Date: 03.11. 2013 Time: 12:30 to 14:30. Assigned Room: Regency A Cheers, Varun On Sun, Oct 27, 2013 at 12:57 PM, Varun Singh wrote: > Hi all, > > In RMCAT WG there has been discussion surrounding the use > of a media traffic generator and to facilitate discussion, > RMCAT is hosting a side meeting on Sunday, 03 November > at 1300-1500. I suppose the room details will be announced > shortly. > > Below is a list of questions that will help design or choose > an appropriate traffic generator for Interactive multimedia traffic. > The list is an initial set and mainly to foster discussion both > on the mailing list and at the meeting. > > Mirja and Lars are not available that day, hence on their behalf, > the meeting is hosted by Colin and I . > > Cheers, > Varun > --- > > Traffic generator: to model the intrinsic variability of video: > > - what target bit rates can be achieved? (max?, min?) > - how much variability in media bit rate for a given target bit rate > - how to model motion? capturing high motion leads to bursty video > (higher than target bit rate), but by how much? can this even be done? > > Traffic generator: on responsiveness to a new target bitrate: > > - how quickly can the codec generate a lower bit rate? > - immediately? does this depend on the new or requested bit rate? > - what is immediately? is it next frame or a few frames later, until then > does it generates at the current rate? > - if not immediately, what bitrates (and duration) will it generate before > meeting the target bitrate. > > > - how quickly can the codec generate a higher bit rate? > - immediately in the next frame? does this also depend on the new > or requested bit rate? > - not immediately but in steps of intermediate bitrates, i.e., intermediate > bitrate for a short duration then an increase in step, repeating until > reaching the target bit rate. > > - If the target bit rate is achieved in steps, can they be announced to the > congestion controller, i.e., the congestion controller knows the ramp up > curve to meet the target bit rate. > > - If the media bit rate has not yet reached the requested target bit rate and > the congestion control requests a new target bit rate, how does the codec > respond? > > Application design related: > - should the congestion control be able to change the frame rate (video) or > packetization time (audio) or is this something that the application controls. > - should the congestion control be able to change video resolution? > - should error-repair: NACKs, FEC be considered part of congestion control or > outside it, i.e., it is something that the application does and not > congestion control > - If FEC is controlled by the congestion control, how quickly can the sending > rate be adapted by reducing/adding redundancy (FEC)? is something link this > done? Does this makes sense at all? > - Apart from loss and RTT, what other congestion cues are currently used by > congestion control algorithms? e.g., Decoding rate/goodput, application > decode error rate, ECN, PCN, etc. > - If the codec is data limited, i.e., producing a sending rate smaller than the > one calculated by the congestion control, can the congestion control probe > the bandwidth by sending additional data packets in a certain pattern (e.g., > PathChirp)? would somehting link this help? > - application input on prioritization: audio vs video (vs data) > > > > > > -- > http://www.netlab.tkk.fi/~varun/ -- http://www.netlab.tkk.fi/~varun/ From magnus.westerlund@ericsson.com Wed Oct 30 09:01:10 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF6121E811D for ; Wed, 30 Oct 2013 09:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.422 X-Spam-Level: X-Spam-Status: No, score=-105.422 tagged_above=-999 required=5 tests=[AWL=0.827, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qjh1GDfcL0-y for ; Wed, 30 Oct 2013 09:01:03 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CABEA21E8115 for ; Wed, 30 Oct 2013 09:00:50 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-a7-52712d31c93f Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A5.86.03802.13D21725; Wed, 30 Oct 2013 17:00:49 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.2.328.9; Wed, 30 Oct 2013 17:00:46 +0100 Message-ID: <52712D69.4050303@ericsson.com> Date: Wed, 30 Oct 2013 17:01:45 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyM+Jvja6hbmGQwdd9+hYve1ayW+z8v5/N gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4Mo4smQKW8Fe4Yqt100bGFv4uxg5OSQETCTe 7m1ghrDFJC7cW8/WxcjFISRwiFGiae9dZghnOaPEp/d/WUCqeAW0JZounQSzWQRUJU5MXA/W zSZgIXHzRyMbiC0qECxxY9khNoh6QYmTM5+A1YsIGEssXHIHrJ5ZQEli7tLXYLawQITE5Jut QDUcQFeIS/Q0BkGU6ElMudrCCGHLSzRvnQ1WLgR0QkNTB+sERoFZSDbMQtIyC0nLAkbmVYzs uYmZOenlRpsYgYF3cMtv1R2Md86JHGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAj EwenVANjQUNBwa63Dlv3lf97ma0i1Oi99cH9FTZCdTZ8OfFTjn5PW/mbKWZ9+gwXnvWCexLj DFfe7Hv9J4UrJU7DtmnT0YdOpnbmXAu/WrMb2sRJ25xMubPmDAcTy6KW2Vc8Hp3w/MxscdEo 5JddpfYPpZ+r3RN5RT0VRLbOdqm/bqO15qzfGvF7Le+VWIozEg21mIuKEwF+1LSlCgIAAA== Cc: IETF AVTCore WG Subject: [AVTCORE] Comments coming out of the Shepherds writeup: draft-ietf-avtcore-leap-second-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 16:01:10 -0000 Hi Kevin and Ray, I have some few things I like to fix before requesting publication. Sorry for not doing my writeup earlier and spotting this earlier. 1. Section 9.2 The following references are a bit thin on information. [9] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", July 2008. [10] Global Positioning Systems Directorate, "Navstar GPS Space Segment/Navigation User Segment Interfaces", September 2011. [11] BIPM, "Circular T", May 2012. For example 9 is not stating that this is 1588. Both 10 and 11 could benefit from a link. [11] should have BIPM expanded. Circular T appears to be a monthly publication of correction/correlation data. What is the intention with this reference? To use the appropriate or the latest? Or was May 2012 the right one? Is this an issue of getting the XML to include what is included in reference? 2. Section 5: Note that a working communication channel includes a protocol means of notifying clocks of an impending leap second such as the Leap Indicator in the NTP header [8] but also a means for top-tier clocks to receive leap- second schedule information published by the International Earth Rotation and Reference Systems Service. I think there should be a informative reference to "International Earth Rotation and Reference Systems Service" with an URL, or at least include the URL in the text. 3. Section 5: RTP implementation using a wall-clock reference is simplified by using a clock with a timescale which does not include leap seconds. IEEE 1588,[9] GPS [10] and other TAI [11] references do not include leap seconds. Is really [11] a good informative reference what TAI is? Can you please prepare an update of these issues and submit when the ID submission opens on Monday so that I can request publication? Cheers Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Thu Oct 31 06:52:51 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FD221F8411 for ; Thu, 31 Oct 2013 06:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uqNWZB4cxUd for ; Thu, 31 Oct 2013 06:52:51 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 99AED11E8146 for ; Thu, 31 Oct 2013 06:52:49 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id cb5so7837241wib.0 for ; Thu, 31 Oct 2013 06:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=HhHlR49yOjunEWSvpenQM8D3/zI8/inSO4gi2lJtKGM=; b=KCNHqwIE56PaLvw2cKxbGTnh00IvUnxN8D2t8yISSPH/qZFJeVQJ/HUMkSQ1sftOLB tqpsBzmfVGhbml/8RaujxXFvuS1/pCzULAtlzUd8dyTfhY/GpeIm1ownG/8qTDJe1G1D M/TlFhn9I+NM1uPvNRuFwvLJUy1EcjwkMDK/0K4lTM6TZ2j0BdOIZ7KThiTw3BSUaCHA oq+RpQYJYOX3eA8Hx6dkvoCz5Jj5uQJHeEH/KH/i/UzaY6VFuyHhpybn0+he0iLWn/NW UivbRhF0w4pnHU8ZIzbVNNFBhj2ShgDjIRqoDMkCGH/PGseMM9P/NQ0NjxZc7kDgN766 f+aA== X-Received: by 10.180.149.234 with SMTP id ud10mr2797167wib.25.1383227568743; Thu, 31 Oct 2013 06:52:48 -0700 (PDT) Received: from RoniE ([109.67.11.64]) by mx.google.com with ESMTPSA id w10sm7031988wia.4.2013.10.31.06.52.46 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Oct 2013 06:52:47 -0700 (PDT) From: "Roni Even" To: Date: Thu, 31 Oct 2013 15:49:31 +0200 Message-ID: <00a101ced640$099e1890$1cda49b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01CED650.CD275DC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7WP8GZh37oHbXVTEG3xcWJzwXePA== Content-Language: en-us Subject: [AVTCORE] Second WGLC on draft-ietf-avtcore-clksrc-07 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 13:52:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A2_01CED650.CD275DC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I would like to start a second WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-07 , RTP Clock Source Signalling. We had a last call on the 03 version and SDP directorate review. There were changes and the current version addresses the comments received so far. The WGLC will end on November 15th , 2013 Please review the draft and send comments to the list. If no comments we will send the document to publication Thanks Roni Even AVTcore co-chair ------=_NextPart_000_00A2_01CED650.CD275DC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would =
like to start a second  WGLC on http://t=
ools.ietf.org/html/draft-ietf-avtcore-clksrc-07  , RTP Clock =
Source Signalling.
We had a =
last call on the 03 version and SDP directorate =
review.
There were =
changes and the current version addresses the comments received so far. =

 =

The WGLC will = end on November  15th  , = 2013

 

Please review the draft and send comments to the = list.

If no comments we will send the = document to publication

 

Thanks

 

Roni = Even

AVTcore =  co-chair

 

 

 

------=_NextPart_000_00A2_01CED650.CD275DC0-- From magnus.westerlund@ericsson.com Thu Oct 31 07:54:32 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C4B11E8149 for ; Thu, 31 Oct 2013 07:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.422 X-Spam-Level: X-Spam-Status: No, score=-105.422 tagged_above=-999 required=5 tests=[AWL=0.827, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXJ0dA3IAgFZ for ; Thu, 31 Oct 2013 07:54:26 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 06E2C21F9DAF for ; Thu, 31 Oct 2013 07:54:25 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-9f-52726f2056ca Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F6.C1.23787.02F62725; Thu, 31 Oct 2013 15:54:24 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.328.9; Thu, 31 Oct 2013 15:54:24 +0100 Message-ID: <52726F60.9060207@ericsson.com> Date: Thu, 31 Oct 2013 15:55:28 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: , IETF AVTCore WG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJJMWRmVeSWpSXmKPExsUyM+Jvja5CflGQwdsGXYuXPSvZLSZPFnBg 8liy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4MnofPmcr6FKrmLJ+CVsD4wK5LkZODgkBE4mH i1+wQ9hiEhfurWfrYuTiEBI4xCjxsHsBO4SznFHi6ayZrF2MHBy8AtoS92ZHgDSwCKhK/L7/ mxXEZhOwkLj5o5ENxBYVCJa4sewQmM0rIChxcuYTFpBWEaD43m2FIGFhARuJH6ufg4UlBMQl ehqDQMLMAnoSU662MELY8hLNW2czg9hCQEsbmjpYJzDyz0IydBaSlllIWhYwMq9iZM9NzMxJ LzfcxAgMroNbfuvuYDx1TuQQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GBMUN+/6VqKkybDKOdJO+f//lRZBJ0qDbrjKy6Z8cI9S/lbm76agfKCU722GWTzj0fPXmV+3 ebtFbvwmtvnyresW3a9aksXyzFmWb+f1vlJwQ9y04c12iR2bO5e9PbS57FTKdXaPSXPDGQ2u hN2aed+Hc+8Bvv+iLzdJholGnvgudCFB+6cbuxJLcUaioRZzUXEiAL6ygR78AQAA Subject: [AVTCORE] Writeup comments on draft-ietf-avtcore-aria-srtp-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:54:32 -0000 Authors, WG. These are my comments on the ARIA draft found during my Write-up review. These needs to be addressed prior to publication request can happen. 1. Section 6.2: [I-D.ietf-avtcore-srtp-aes-gcm] McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp- aes-gcm-10 (work in progress), September 2013. Based on the formulations in the draft, this is a normative reference. Please move it to the right section. 2. Section 5.2: "IANA is requested to add the below crypto suite to the ..." Replace "crypto suite" with "protection profiles" 3. Section 5.2: "Note that these SRTP Protection Profiles do not specify an auth_function, auth_key_length, or auth_tag_length because all of these profiles use AEAD algorithms, and thus do not use a separate auth_function, auth_key, or auth_tag." Not all of the above SRTP Protection Profiles are AEDA ones, thus I suggest changing the above sentence to: Note that the majority of the SRTP Protection Profiles do not specify an auth_function, auth_key_length, or auth_tag_length because all of these profiles use AEAD algorithms, and thus do not use a separate auth_function, auth_key, or auth_tag. 4. Section 5.3: "In order to allow the use of the algorithms defined in this document in MIKEY, IANA is requested to add the below crypto suites to the "MIKEY Security Protocol Parameters SRTP Type 0 (Encryption algorithm)" and to add the below PRF to the "MIKEY Security Protocol Parameters SRTP Type 5 (Pseudo Random Function)" created by [RFC3830], at time of writing located on the following IANA page: http://www.iana.org/assignments/mikey-payloads/mikey- payloads.xml#mikey-payloads-26 [3]." There is an issue with using "crypto suites" in the MIKEY context. What you are registering are parameters for the ARIA SRTP transform, and then you provide a mapping between the crypto suits to the transform parameter's values. Can we find another formulation here? Perhaps: "In order to allow the use of the algorithms defined in this document in MIKEY, IANA is requested to add three encryption algorithms to the "MIKEY Security Protocol Parameters SRTP Type 0 (Encryption algorithm)" and to add the below PRF to the "MIKEY Security Protocol Parameters SRTP Type 5 (Pseudo Random Function)" created by [RFC3830], at time of writing located on the following IANA page: http://www.iana.org/assignments/mikey-payloads/mikey- payloads.xml#mikey-payloads-26 [3]." To further clarify the purpose of Figure 1 and 2 maybe one should modify this text: MIKEY specifies the algorithm family separately from the key length (which is specified by the Session Encryption key length) and the authentication tag length. To something like: MIKEY specifies the algorithm family separately from the key length (which is specified by the Session Encryption key length) and the authentication tag length. The SDP Security Descriptions [RFC4568] crypto suits and corresponding DTLS-SRTP [RFC5764] protection profiles are mapped to MIKEY parameter sets as shown below. 5. Abstract: This document describes the use of the ARIA block cipher algorithm I would change "describes" to "defines" 6. Section 2.2, and Section 2.3: While Seciton 2.1 addresses Jonathan Lennox comments regarding defining encryption key stream for Header Extensions the GCM and and CCM fails to do this. Although AES-GCM document do defines this in Section 9.3, I don't think it is clear enough which cipher shall be used with ARIA. Thus add an explicit definition also in these sections for how it is generated. 7. Section 2.1: ARIA counter modes are defined in the same manner except that each invocation of AES is replaced by that of ARIA, and are denoted by ARIA_128_CTR, ARIA_192_CTR and ARIA_256_CTR respectively, according to the key lengths. I am missing the normative reference to ARIA in the above sentence, is this: RFC5794? IF it is please include it here and the other places for the other modes when you define the crypto as follows: this procedure but replace AES with ARIA [RFC5794] Then also RFC5794 needs to be moved to the normative list. Cheers Magnus Westerlund ---------------------------------------------------------------------- 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: magnus.westerlund@ericsson.com ----------------------------------------------------------------------