From mamontor@posgrado.upv.es Mon Dec 3 07:29:25 2012 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 1243921F85B1 for ; Mon, 3 Dec 2012 07:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_20=-0.74, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoMU4XuteDDN for ; Mon, 3 Dec 2012 07:29:24 -0800 (PST) Received: from marfik.cc.upv.es (smtpsal1.cc.upv.es [158.42.249.61]) by ietfa.amsl.com (Postfix) with ESMTP id 474D521F845B for ; Mon, 3 Dec 2012 07:29:22 -0800 (PST) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id qB3FTJ2E028401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 16:29:19 +0100 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id qB3FTJKQ015854; Mon, 3 Dec 2012 16:29:19 +0100 Received: from localhost (wmr.cc.upv.es [158.42.249.58]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id qB3FTI4Y001026; Mon, 3 Dec 2012 16:29:18 +0100 Received: from gnd2g71-74.wi-fi.upv.es (gnd2g71-74.wi-fi.upv.es [158.42.71.74]) by webmail.upv.es (Horde Framework) with HTTP; Mon, 03 Dec 2012 16:29:18 +0100 Message-ID: <20121203162918.18323qluhl1kxp3i@webmail.upv.es> Date: Mon, 03 Dec 2012 16:29:18 +0100 From: Mario Montagud Climent To: Magnus Westerlund References: <20121105132002.50214lz37taa88he@webmail.upv.es> <50AA3401.6020102@ericsson.com> In-Reply-To: <50AA3401.6020102@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-Mailman-Approved-At: Mon, 03 Dec 2012 08:24:49 -0800 Cc: avt@ietf.org Subject: Re: [AVTCORE] Question about the minimum RTCP report interval 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, 03 Dec 2012 15:29:25 -0000 Hi Magnus, all, Thank you for your response! And sorry for our late reply! See our comments inline. Magnus Westerlund escribió: > On 2012-11-05 13:20, Mario Montagud Climent wrote: >> >> Hi all, >> >> I would appreciate it very much if you could clarify me a doubt about >> the minimum RTCP reporting interval. >> >> According to RFC 3550, the RTCP report interval is dynamically computed >> based on the allocated session bandwidth, the average size of all >> (received and sent) RTCP packets, the number of participants in the >> session and their role (senders or receivers), or their proportion, and >> the unicast or multicast nature of the session (Section 6.2 of RFC 3550). >> >> Nevertheless, it is also specified that this deterministically computed >> RTCP report interval should have a lower bound to avoid having bursts >> (cumpling) of RTCP packets when the number of participants is small and >> the law of large numbers is not helping to smooth out the traffic >> overhead. This would also help to avoid excessive frequent reports >> during transient outages like a network partition. The recommended value >> in RFC 3550 for that fixed RTCP minimum interval is 5 seconds. >> >> The RFC 3550 also specifies that in some cases (e.g., if the data rate >> is high and the application demands more timely feedback reports) an >> implementation may scale the minimum RTCP interval to a smaller value >> given by 360 divided by the session bandwidth (in kbps). Consequently, >> this yields to an interval smaller than 5 seconds for bandwidths greater >> than 72 kbps. In multicast sessions, only active senders may use that >> reduced minimum interval, whilst in unicast sessions it also may be used >> by receivers. In the above cases, however, the RTCP minimum interval >> must be still taken into account during the membership accounting >> procedure in order to not prematurely time out participants (who can >> indeed be using it) because of inactivity. >> >> However, RFC 4585 defines an extension to the RTP Audio-Visual Profile >> (AVP) that enables receivers to provide, statistically, more immediate >> feedback messages to the senders and thus allows for short-term >> adaptation and efficient feedback-based repair mechanisms to be >> implemented, while maintaining the bandwidth constraints for RTCP and >> preserving scalability to large groups. In RFC 4585, the RTCP >> transmission interval specified in RFC 3550 is denoted as Regular RTCP >> interval. In addition, RFC 4585 specifies that feedback messages can be >> reported earlier than the next scheduled Regular RTCP transmission time >> if a receiver detects the need to inform about events of interest in the >> media stream (e.g., picture or slice loss) close to their occurrence. >> Otherwise, the Regular RTCP transmission mode is employed, but the >> minimum RTCP report interval of 5 seconds recommended in RFC 3550 is >> dropped. >> >> So, my questions about this are: >> >> - When using the Regular RTCP reporting rules (RFC 3550) in multicast >> scenarios, which option should we select for the minimum RTCP reporting >> interval (for a media sender)? Can we use any of the two options for >> selection the minimum thresholds (i.e., 5 sec or 360/bw_session_kbps)? >> > > To my understanding you can use any of them. This is actually a > potential interoperability issue. OK. Thanks for the clarification! > >> - Likewise, should the sentence "the minimum RTCP report interval of 5 >> seconds recommended in RFC 3550 is dropped" from RFC 4585 be applied in >> all cases (i.e. not only when using the early RTCP reporting rules)? > > It applies also for regular reporting and instead the trr-int mechanism > is introduced. We didn?t know about the existence of the trr-int attribute. As we understand now, the following steps must be followed to compute the Regular RTCP Report Interval (T_rtcp): - USING RTP/AVP (RFC 3550) 1. T_rtcp_avp_det_1 = (members * avg_rtcp_size * 8)/rtcp_bw_portion The values of 'members' and 'rtcp_bw_portion' parameters depend on the proportion of participants and their role (sender or receivers), as specified in RFC 3550, as well as on the value of the RTCP bandwidth modifiers (if available), as specified in RFC 3556. 2. Also, a recommended minimal fixed RTCP Report interval, T_rtcp_min, must be taken into account. Three options for selecting T_rtcp_min: 2a. T_rtcp_min_a = 2.5 sec (if the participant has not sent any RTCP packet yet) 2b. T_rtcp_min_b = 5 sec 2c. T_rtcp_min_c = 360/session_bw(kbps), but only allowed for senders in multicast scenarios. This reduced minimal interval, T_rtcp_min_c, drops below 5 seconds when the session bandwidth is greater than 72 kbps. 3. Select the maximum value between (1) and the selected option in (2): T_rtcp_avp_det_2= max(T_rtcp_avp_det_1, T_rtcp_min) 4. Apply randomization: T_rtcp_avp_rnd = T_rtcp_avp_det_2*(0.5+rnd()) 5. Apply compensation for the reconsideration algorithm: T_rtcp_avp_final = T_rtcp_avp_rnd/(e - 3/2) = T_rtcp_avp_rnd/1.21828 * Note that most of the variables used for the RTCP period interval calculation are estimated at each participant. Therefore, their local values may differ at any given point in time. - USING RTP/AVPF (RFC 4585) When using the RTP/AVPF (RFC 4585), the interval between regular RTCP reports is only derived from the average RTCP packet size and the RTCP bandwidth share available to the RTP/RTCP entity. Here, the 5-second minimum interval between RTCP reports is dropped. However, an OPTIONAL attribute, called trr-int, is defined to specify the minimum period interval (in milliseconds) between two Regular (full compound) RTCP packets. Therefore, the RTCP report interval is computed as: // Please, check if the following formula is correct!! T_rtcp_real_avpf = (0.5+rnd())(trr-int + T_rtcp_avp_det_1/1.21828) The use of the trr-int parameter can minimize an excessive RTCP bandwidth consumption, while keeping compatibility with AVP end-points. If the trr-int is not specified, a default value of 0 is assumed. If trr-int == 0, then this variable has no impact on the overall operation of the RTCP feedback algorithm, other than the minimum value for the report interval is dropped. If trr-int != 0, this variable does not affect the transmission scheduling of Early RTCP packets. Note that providing trr-int as an independent variable is meant to minimize Regular RTCP feedback (and thus bandwidth consumption) while additionally allowing the use of more frequent Early RTCP packets to provide timely feedback. This goal could not be achieved by reducing the overall RTCP bandwidth, because an RTCP bandwidth reduction would also have an impact over the frequency of the Early RTCP feedback messages. > > I would however strongly recommend that one uses 5 seconds in the > formula when timing out sources to avoid spurious timing out of sources > that uses the 5 seconds if oneself are uses the scaled value. > To our understanding, if trr-int != 0, then the timeout calculation for RTP/AVPF entities MUST be modified to use the larger value between trr-int (or the RTCP report interval using RTP/AVPF) and the selected option for T_rtcp_min (5 sec, or 360/session_bw) using RTP/AVP, to avoid premature timeout of RTP entities. RFC 4585 species that the trr-int parameter ?SHOULD NOT be larger than five seconds? for avoiding accidental timeouts in combined AVP-AVPF sessions. RFC 4585 also recommends that in those cases involving RTP/AVP entities in which the dynamically calculated T_rtcp is sufficiently small (e.g., less than one second), the value of trr-int parameter SHOULD be set (close?) to 5 seconds. Thus, a recommended value of 4 seconds for the trr-int seems a good option to allow interworking between RTP/AVPF and RTP/AVP end-points, unless they explicitly need this parameter to be lower. So, if the above consideration are correct, we have some question. If we want an RTP/AVP and RTP/AVPF compliant scenario: 1) In RTP/AVPF devices, should the trr-int parameter only be applied to media receivers? Or contrarily, should this parameter be applied to both media receivers and senders? My doubt is because the trr-int is also called "Minimal RECEIVER report interval" in the RFC 4585. 2) If the trr-int parameter applies to both senders and receivers, which is the recommended value for each case? 3) As the trr-int is specified as an OPTIONAL attribute, could the trr-int be set to zero in a compliant RTP/AVPF scenario? For example, if we want Sync Clients in an IDMS-enabled session to send frequent IDMS reports to the MSAS (this would allow a more fine-grained IDMS control), but still adhering to the maximum 5 % RTCP traffic bounds, can we set the trr-int parameter to zero in the calculation of the RTCP report interval in either Sync Clients or the MSAS? Sorry for the length of the mail! Best Regards, Fernando & Mario > 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 woohwankim@gmail.com Mon Dec 3 20:31:54 2012 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 C4A8C1F0C6E for ; Mon, 3 Dec 2012 20:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-pqKQ1mINVI for ; Mon, 3 Dec 2012 20:31:53 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B51A21F0C61 for ; Mon, 3 Dec 2012 20:31:53 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so5876858ieb.31 for ; Mon, 03 Dec 2012 20:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=F3EWKmCYOMTwGyxJwJ1IUHfThhTTT6EkW++AfEFjDX4=; b=Ud22zbpBDJIcs5NV2CTdZWSOtvQydXrTPCeOA5MCC77C/RV8tATJEsUEACKB1SM4Wv yjoQv3zpDcSYWRLBlG3zVDOu+uxVXaYNzE5+O83hPlToEgJGA6xKW1wW3cnH+7sukA2r WvTsEaNaaFQ6kCy2V2R6Yk5nAOkeBCdqQuSbf99K4NN+Ruy7vfbjcngA+reFbBwtDLPW R3wzI19tfSvYize5qW2qFXDGPmP3JL1DhtTQ9fY7GuaRgSfbSTRdKSJ4ewW3Wz789CIa 16RLPXZEEkhMjxg5K/1Qbn92mvPJZ97snW195g4R2zro20WoWpP1yyiBxmev8g6YjNEL 6LoA== MIME-Version: 1.0 Received: by 10.50.222.231 with SMTP id qp7mr1310194igc.74.1354595513376; Mon, 03 Dec 2012 20:31:53 -0800 (PST) Sender: woohwankim@gmail.com Received: by 10.64.47.163 with HTTP; Mon, 3 Dec 2012 20:31:53 -0800 (PST) Date: Tue, 4 Dec 2012 13:31:53 +0900 X-Google-Sender-Auth: z8SEvQYpdTkEqr4PJwXpvaJ6Vzg Message-ID: From: Woo-Hwan Kim To: avt@ietf.org, Magnus Westerlund , draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org Content-Type: multipart/alternative; boundary=14dae934089f639e6c04cfff58dd Cc: Daesung Kwon , Je Hong Park Subject: [AVTCORE] Re: Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03 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, 04 Dec 2012 04:31:54 -0000 --14dae934089f639e6c04cfff58dd Content-Type: text/plain; charset=ISO-8859-1 Hi. Here are some comments on draft-ietf-avtcore-srtp-aes-gcm-03 1. Typos Sec. 5.3 - Validation Error flag raised => Validity_Flag is to be FALSE Sec. 6 - the plaintext to form cipher => the plaintext to form ciphertext - this apllication => this application - A (first_key_block, keystream) pair => A (first_key_block, key_stream) pair - These keystream generation processes allows for => These keystream generation processes allow for - up to (2^24)-16 octets for AES-CCM and => up to (2^28)-16 octets for AES-CCM and Sec. 7 - AEAD_AEC => AEAD_AES Sec. 8.1 - the older authentication methods redundant => the older authentication mechanisms redundant - Some applications use the SRTP/SRTCP Authentication Tag as => Some applications use the SRTP/SRTCP authentication tag field as Sec. 8.2 - Neither AES-GCM not AES-CCM => Neither AES-GCM nor AES-CCM - RECOMENDED => RECOMMENDED Sec. 9.1 - used by both AES-GCM and AES-CCM SRTP is => used by both AES-GCM and AES-CCM in SRTP is - and the two octet sequence number SEQ. => and the 2-octet sequence number SEQ. Sec. 9.2 & 10.2 - AEAD cipher, ~containing the cipher, the resulting cipher => AEAD ciphertext, ~containing the ciphertext, the resulting ciphertext Sec. 9.2, 10.2 & 10.3 (similar meaning, different writing) - The data fields within the SRTP packets are broken into Associated Data, Plaintext and Raw Data as follows (see figure 2): - the SRTCP packet is broken into plaintext, associated data, and raw (untouched) data as listed below (see figure 4): - the SRTCP compound packet is broken into plaintext, associated data, and raw (untouched) data as follows (see figure 5): Sec. 10.3 - returns a cipher field which ~, This cipher ~, the Encryption flag => a ciphertext which ~, This ciphertext ~, the encryption flag Sec. 11.1 - GCM: MUST be at most 2^36-16 octets CCM: MUST be at most 2^24+16 octets => GCM: MUST be at most 2^36-32 octets CCM: MUST be at most 2^28-16 octets Sec. 11.2 & 11.3 - Any implementation of AES-GCM(AES-CCM) SRTP SHOULD ~ => Any implementation of AES-GCM(AES-CCM) in SRTP SHOULD ~ Sec. 11.3 - in counter node encryptionn, AES-CCM authentications also useus => ~ in counter mode encryption, AES-CCM authentications also uses ~ Sec. 12 - AEAD_AES_128(256)_CCM(GCM) algorithms => AEAD_AES_128(256)_CCM(GCM) Sec. 13.1 - after each block key has => after each encryption key has 2. Editing Sec. 1 3rd and 4th paragraphs - In 3rd paragraph, 2nd sentence 'Two families of ~ based upon AES.' is repeated in 4th paragraph. So it may be better to remove this sentence, and to modify the last sentence as follows: 'This specification uses GCM and CCM with AES, which we call AES-GCM and AES-CCM respectively)' Sec. 8.1 1st and 2nd sentences When an AEAD algorithm is used for SRTP/SRTCP, the AEAD message authentication mechanism MUST be the primary message authentication mechanism. 3. Length vs Size It may be good to unify the words 'length' and 'size' 4. CCM authentication tag length Though the CCM specification adapted by NIST and IETF uses the tag length to format the message, basically there is no difference between CCM and GCM to deal with authentication tag length. As GCM, CCMs with different tag length (ex. CCM_8, CCM_12) should be considered separately. AEAD Parameters managed by IANA also show it. In addition, it is not necessary to consider the capability of handling variable-length authentication tags because this draft restricts the length of authenticated tag to be 8, 12, or 16. And tag length should be shared by key manage process based on SDES, DTLS or MIKEY. Though MIKEY explicitly supports authentication tag length parameter as specified in Section 14.3, SDES and DTLS do not. Instead, the choice of cipher suite (or protection profile) implies the authentication tag length directly. So I think that cipher suites for SDES should be corresponded to protection profiles for DTLS, and that is the reason why I recommend to add cipher suites of CCM with authentication tag length 8 and 12. Because the authentication tag length is shared during key and parameters negotiation, I think that Encrypt/Decrypt mode described in Section 5.2 does not need to use the term 'Tag_Size_Flag' explicitly. The above also holds for the Decrypt Mode in 5.2.2. Thanks. Best Regards, Woo-Hwan Kim > Date: Tue, 27 Nov 2012 15:20:46 +0100 > From: Magnus Westerlund > To: IETF AVTCore WG > Subject: [AVTCORE] Working group last call on > draft-ietf-avtcore-srtp-aes-gcm-03 > Message-ID: <50B4CC3E.6070705@ericsson.com> > Content-Type: text/plain; charset="ISO-8859-1" > > WG, > > This announces the WG last call on AES-GCM and AES-CCM Authenticated > Encryption in Secure RTP (SRTP) > https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ > > Please provide any comments no later than the 12th of December. Also > comments of the nature of "I have read it and have no comments and think > it should be published" are highly valuable. > > 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 > ---------------------------------------------------------------------- --14dae934089f639e6c04cfff58dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi.

Here are some comments on draft-ietf-avtc= ore-srtp-aes-gcm-03


1. Typos
<= div>
Sec. 5.3
- Validation Error flag raised =3D>= ; =A0Validity_Flag is to be FALSE

Sec. 6
- the plaintext to form cipher =3D>= the plaintext to form ciphertext
- this apllication =3D> this= application
- A (first_key_block, keystream) pair =3D> A (fir= st_key_block, key_stream) pair
- These keystream generation processes allows for =3D> These keystr= eam generation processes allow for
- up to (2^24)-16 octets for A= ES-CCM and =3D> up to (2^28)-16 octets for AES-CCM and=A0

=
Sec. 7
- AEAD_AEC =3D> AEAD_AES

= Sec. 8.1
- the older authentication methods redundant =3D> the= older authentication mechanisms redundant
- Some applications us= e the SRTP/SRTCP Authentication Tag as =3D> Some applications use the SR= TP/SRTCP authentication tag field as

Sec. 8.2=A0
- Neither AES-GCM not AES-CCM =3D= > Neither AES-GCM nor AES-CCM
- RECOMENDED =3D> RECOMMENDED=

Sec. 9.1
- used by both AES-GCM and AES= -CCM SRTP is =3D> used by both AES-GCM and AES-CCM in SRTP is
- and the two octet sequence number SEQ. =3D> and the 2-octet seque= nce number SEQ.

Sec. 9.2 & 10.2
- AE= AD cipher, ~containing the cipher, the resulting cipher =3D> AEAD cipher= text, ~containing the ciphertext, the resulting ciphertext

Sec. 9.2, 10.2 & 10.3 (similar meaning, different w= riting)
- The data fields within the SRTP packets are broken into= Associated Data, Plaintext and Raw Data as follows (see figure 2):
- the SRTCP packet is broken into plaintext, associated data, and raw = (untouched) data as listed below (see figure 4):
- the SRTCP comp= ound packet is broken into plaintext, associated data, and raw (untouched) = data as follows (see figure 5):

Sec. 10.3
- returns a cipher field which ~, T= his cipher ~, the Encryption flag =3D> a ciphertext which ~, This cipher= text ~, the encryption flag

Sec. 11.1
- GCM: MUST be at most 2^36-16 octets CCM: MUST be at most 2^24+16 octets = =3D> GCM: MUST be at most 2^36-32 octets CCM: MUST be at most 2^28-16 oc= tets

Sec. 11.2 & 11.3=A0
- Any imple= mentation of AES-GCM(AES-CCM) SRTP SHOULD ~ =3D> Any implementation of A= ES-GCM(AES-CCM) in SRTP SHOULD ~

Sec. 11.3
- in counter node encryptionn, AES-= CCM authentications also useus =3D> ~ in counter mode encryption, AES-CC= M authentications also uses ~

Sec. 12
- AEAD_AES_128(256)_CCM(GCM) algorithms =3D> AEAD_AES_128(256)_CCM(GCM)<= /div>

Sec. 13.1
- after each block key has =3D= > after each encryption key has


2. Editing
Sec. 1 3rd and 4th paragraphs

- In 3rd paragraph, 2nd sentence 'Two families of ~ based upon AES.= 9; is repeated in 4th paragraph.=A0
So it may be better to remove= this sentence, and to modify the last sentence as follows:=A0
'This specification uses GCM and CCM with AES, which we call AES-G= CM and AES-CCM respectively)'

Sec. 8.1 1st and= 2nd sentences

When an AEAD algorithm is used for = SRTP/SRTCP, the AEAD message authentication mechanism MUST be the primary m= essage authentication mechanism.=A0


3. Length vs Size

It may be good to unify the words 'length' and 'size'


4. CCM authentication tag length

Though the CCM specification adapted by NIST and IETF u= ses the tag length to format the message,=A0
basically there is n= o difference between CCM and GCM to deal with authentication tag length.=A0=
As GCM, CCMs with different tag length (ex. CCM_8, CCM_12) should be c= onsidered separately.=A0
AEAD Parameters managed by IANA also sho= w it.=A0

In addition, it is not necessary to consi= der the capability of handling variable-length authentication tags=A0
because this draft restricts the length of authenticated tag to be 8, = 12, or 16.=A0
And tag length should be shared by key manage proce= ss based on SDES, DTLS or MIKEY.=A0
Though MIKEY explicitly suppo= rts authentication tag length parameter as specified in Section 14.3,=A0
SDES and DTLS do not.=A0
Instead, the choice of cipher suite= (or protection profile) implies the authentication tag length directly.=A0=
So I think that cipher suites for SDES should be corresponded to= protection profiles for DTLS,=A0
and that is the reason why I recommend to add cipher suites of CCM wit= h authentication tag length 8 and 12.

Because the = authentication tag length is shared during key and parameters negotiation,= =A0
I think that Encrypt/Decrypt mode described in Section 5.2 does not ne= ed to use the term 'Tag_Size_Flag' explicitly.=A0
The abo= ve also holds for the Decrypt Mode in 5.2.2.


Thanks.

Best Regards,=A0

=
Woo-Hwan Kim

> Date: Tue, 27 Nov 201= 2 15:20:46 +0100
> From: Magnus Westerlund <magnus.westerlund@ericsson.com>
> To: IETF AVTCore WG <avt@ietf.= org>
> Subject: [AVTCORE] Working group last call on
> draft-ietf-avtcore-srtp-aes-gcm-03
> Content-Type: text/plain; charset=3D"ISO-8859-1"
<= div>>
> WG,
>
> This announces th= e WG last call on AES-GCM and AES-CCM Authenticated
> Encrypti= on in Secure RTP (SRTP)
>
> Please provide any comments no later = than the 12th of December. Also
> comments of the nature of "I have read it and have no commen= ts and think
> it should be published" are highly valuabl= e.
>
> Cheers
>
> Magnu= s Westerlund
>
> --------------------------------------------------= --------------------
> Multimedia Technologies, Ericsson Resea= rch EAB/TVM
> ------------------------------------------------= ----------------------
> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148= 287
> F?r?gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 = 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> -----------------------------------------------------------------= -----
--14dae934089f639e6c04cfff58dd-- From internet-drafts@ietf.org Mon Dec 3 20:39:06 2012 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 AED8021E803D; Mon, 3 Dec 2012 20:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGVpINGLQsep; Mon, 3 Dec 2012 20:39:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7DA21E8037; Mon, 3 Dec 2012 20:39:06 -0800 (PST) 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.36 Message-ID: <20121204043906.16199.43596.idtracker@ietfa.amsl.com> Date: Mon, 03 Dec 2012 20:39:06 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-aria-srtp-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: Tue, 04 Dec 2012 04:39: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 : 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-01.txt Pages : 10 Date : 2012-12-03 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 Real-time Transport 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-aria-srtp-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cris.pascual.gonzalez@gmail.com Tue Dec 4 01:26:25 2012 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 BAA3E21F85F5 for ; Tue, 4 Dec 2012 01:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.129 X-Spam-Level: X-Spam-Status: No, score=-3.129 tagged_above=-999 required=5 tests=[AWL=-1.130, BAYES_50=0.001, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2r4HbWpm6DV for ; Tue, 4 Dec 2012 01:26:25 -0800 (PST) Received: from marfik.cc.upv.es (smtpsal1.cc.upv.es [158.42.249.61]) by ietfa.amsl.com (Postfix) with ESMTP id 177D821F85EA for ; Tue, 4 Dec 2012 01:26:24 -0800 (PST) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id qB49QNil030558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Dec 2012 10:26:23 +0100 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id qB49QNSv007630 for ; Tue, 4 Dec 2012 10:26:24 +0100 Received: from JLLORET (pptp243-106.vpns.upv.es [158.42.243.106]) by smtp.upv.es (8.13.6/8.13.6) with SMTP id qB49QM47031117 for ; Tue, 4 Dec 2012 10:26:22 +0100 Date: Tue, 4 Dec 2012 10:26:22 +0100 Message-Id: <201212040926.qB49QM47031117@smtp.upv.es> From: Cristina Pascual To: avt@ietf.org CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 04 Dec 2012 08:28:18 -0800 Subject: [AVTCORE] Last Mile | ICDT 2013 || April 22 - 26, 2013 - Venice, Italy 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, 04 Dec 2012 09:26:25 -0000 INVITATION: ================= Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results to ICDT 2013. The submission deadline is December 15, 2012. Authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== ICDT 2013 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS ICDT 2013, The Eighth International Conference on Digital Telecommunications April 22 - 26, 2013 - Venice, Italy General page: http://www.iaria.org/conferences2013/ICDT13.html Call for Papers: http://www.iaria.org/conferences2013/CfPICDT13.html - regular papers - short papers (work in progress) - posters Submission page: http://www.iaria.org/conferences2013/SubmitICDT13.html Submission deadline: December 15, 2012 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Print proceedings will be available via Curran Associates, Inc.: http://www.proceedings.com/9769.html Articles will be archived in the free access ThinkMind Digital Library: http://www.thinkmind.org Please note the Poster and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and conform with the Editorial rules: http://www.iaria.org/editorialrules.html ICDT 2013 Topics (topics and submission details: see CfP on the site) SIGNAL: Signal processing in telecommunications Signal processing theory and practice; Image and multidimensional signal processing; Signal filter design and structures; Multirate filtering, filter banks, and adaptive filters; Fast signal processing algorithms; Nonlinear signals and systems; Nonuniform transformation; 2D nonuniform DFT; Fast algorithm of NDFT; Advanced image/video coding; Advanced prediction techniques; Signal detection and reconstruction; Spectral estimation and time-frequency analysis; Higher order spectrum analysis; Parameter estimation; Array signal processing; Statistical signal analysis; Signal and system modeling; Cyclostationary signal analysis; Active noise control, active noise reduction and echo cancellation; Psychoacoustics and room acoustics; Signal processing for music; Binaural systems and multidimensional signal systems; Geophysical and seismic signal processing; Nonlinear interpolation/resampling; Extensions to wavelet based coding (x-lets); Low complexity image/video compression; Multiple resolution signal processing; New approach to digital signal processing; Compression of random data; Recompression of compressed data; 2D projection of 3D data; Stereo data matching; Emerging applications requiring new compression tools; Unified compression and recognition; H.264 and latest video coding standards; Latest audio coding standards DATA: Data processing Data transmission and reception mechanisms and techniques; Enhanced tools for video data integrity; Data mining, filtering, and reporting; Secure data transmission; Transmission media and data encoding; Text reading devices (super-pen, pen-elite, reading-pen); Scanned and generated lossy (progressive) multi-page text; (Visually) lossless mechanisms; Pricing data transmission; Differential data transmission systems; Data transmission equipments and transmission rates; Delay-constrained data transmission; Undersea and satellite data transmission techniques; Performance evaluation of data transmission; Multicast data transmission; High speed data transmission; Data transmission control; Integrity and privacy in data transmission; Data transmission standards AUDIO: Audio transmission and reception systems Audio transmission and reception systems and devices; Digital audio transmission signal processing; Audio transmission over Internet; Audio Multiplexing Transmission Systems; Stereo audio transmission signal; Digital infrared audio transmission; Multi-stream and multi-path audio transmission; Wireless-compressed digital audio transmission; Perceptual coding for audio transmission and storage; Laser audio transmission; Synchronizing video and audio transmission; Wide-band audio transmission; Index-frame audio transmission; Digital audio transmission rights; Noise in wireless audio transmission; Audio tools and products; Standards VOICE: Voice over packet networks Planning and implementing voice networks and systems; Voice transmission systems; Voice transmission performance; Quality real-time voice transmission; Metrics for quality of voice transmission; Stereophonic voice transmission systems; Header Compression for VoIP over WLAN; Voice over IP solution for mobile radio interoperability; VoIP over cable TV networks; VoIP over Wi-Max VIDEO: Video, conferencing, telephony Digital video; Video coding formats (ITU-T, SMPTE 421M, AVS-China); Video coders and decoders; Profiles, latency, intermediate formats; Video surveillance and privacy; Video feature requirements; Network video recorders; Graceful degradation of archive video; Video data integrity (error detection, tamper resistance); Alarm events for voice content (motion detection, object tracking, face recognitions); Coding efficiency and distributed video coding; Compression and scrambling; Enhanced tools for video data integrity; Multiple reference pictures; Intra-layer and inter-layer prediction; Fading prediction and loop filter; Video with compression errors; Viewing distance and perceptual quality; Video quality models; Omnidirectional video; 3D video; Video standardization encoding; Texture synthesizer IMAGE: Image producing, sending, and mining Model-based progressive image transmission; Wireless image transmission; Computer generated images; Image security, scrambling, and regions of interest; Timing requirements for image transmission; Transmission of still and moving images; Protocols for low bit rate; Error-prone image transmission; Energy efficient image transmission; Multi-technology image formation; Devices for image capturing and processing (cams, web-cams, etc.); Scanning and sampling, quantization and halftoning, color reproduction; Image representation and rendering, display and printing systems; Image quality assessment; Image search and sorting, video indexing and editing; Integration of images and video with other media; Image authentication and watermarking; Image storage, retrieval and multimedia; Image and video databases; Generic coding of moving pictures; Media stream packetization; Modes for archival playback; Image-based applications; Standard for image processing; Image analysis and segmentation; Image filtering, restoration and enhancement; Image representation and modeling; Pattern recognition SPEECH: Speech producing and processing Tooling, Architectures, Components and Standards; Voice modulation, frequencies; Linguistics, Phonology and Phonetics; Discourse and Dialogue; Speech analysis, synthesis, coding, and recognition; Speech enhancement and noise reduction; Speech features, production, and perception; Speech Coding and Transmission; Speech Signal Processing; Spoken Language Generation and Synthesis; Speech QoS Enhancement; Speaker Characterization and Recognition; Spoken Language; Resources and Annotation; Spoken/Multi-modal Dialogue Technology and Systems; Spoken Language Information Extraction/Retrieval; Speech Transmission Technology for the Aged and Disabled; Audio-Visual Speech Processing; Biomedical Applications of Speech Analysis; Spoken document retrieval; Speech Processing in a Packet; Network Environment; Automatic Speech Recognition in the Context of Mobile Communications; Human Factors in Speech and Communication Systems; Automatic speech recognition and understanding technology; Speech to text systems; Spoken dialog systems; Multilingual language processing; New Applications of Spoken Language Technology and Systems IPTV: IP/Mobile TV IPTV applications and middleware; On-demand television; Interactive TV; Broadcast TV data; Broadcast content formats; Stereo and 3D TV; TVoDSL; Television archiving; IPTV broadcasting; IPTV-aware devices; IPTV regulatory issues and copyrights; IPTV network infrastructure; IPTV monitoring and management; I[P]TV usage fees; IPTV Personalization and QoS Implications MULTI: Multicast/Broadcast Triple-Quadruple-play Scalable video/audio coding; Multiplexing video/audio/data; Multimedia terminals; Multimedia systems and protocols; PSTN modems and interfaces; Facsimile terminals; Direct broadcast satellite; Terrestrial broadcast television; Cable modems; Universal media access; Format compatibility; Media support platforms; VoIP Quality for Triple Play; Testing triple-play services; Triple-play data encryption; Triple-play services CONTENT: Production, distribution Content injection, cashing, storage, and distribution; Producing and transmitting streaming content; Content localization services; Content and customers profiles; Documenting and content authoring; Authorizing topic-based content; Content customization and metadata; On-demand content; Content retrieval from archives (alarm-based, time stamp-based); Content management solutions and systems; Unstructured content environment; Multi-channel content delivery/publishing strategies; Content reuse HXSIP: H-series towards SIP SIP and H-xxx architectures and logical components; Instant messages and presence; Management of QoS in SIP and H-xxx environments; Basic SIP building blocks; Security and firewalls with SIP and H-xxx series; Service creation and telephony services with SIP and H-xxx; Multimedia conferencing with SIP and H-xxx; SIP application scenarios; SIP (auto)configuration; SIP and H-xxx beyond VoIP; Leveraging SIP for Global Enterprise Roaming; SIP, H-xxx and 3GPP; Emergency Calling in SIP and H-xxx; Advanced SIP and H-xxx applications and services; SIP and H-xxx on Cable Networks; SIP and H-xxx devices; SIP and h-xxx deployment experience; End-to-end SIP and H-xxx communications; SIP/H.323 Interworking Function for real time communications MULTE: Multimedia Telecommunications Frameworks, architectures, systems for delivering voices, audio, and data; Methodologies, technologies, procedures and mechanisms; IMT-2000 concepts; IMS concepts (IP Multimedia Systems); Bluetooth and WLAN coexistence on handsets; Packet-based multimedia communication systems; Converging technology for voice and data networks; Accessibility features for unpaired users; Confidentiality for audiovisual services; Multimedia transmission performance; Multiplexing and synchronization; Directory services for multimedia; Computation complexity and costs (multiple simultaneous decoders); Coding efficiency (embedded, bit-plane, arithmetic); Compatibility between Analog/DVD and networks; IP4/IP6 transition and NAT; QoS/SLA, perceptual QoS, and formal visual tests; Temporal and spatial scalability; Pre-processing and predictive coding; Coding with regions-of-interest; Secure transcoding; Computation power and resolution; Transform and quantization; Entropy coding; Lossless and lossy compression; Transmission in noisy environments; Voice/video/data in 4G; Specialized medical applications; Medical imaging and communications networks; MPEG for endoscopy, microscopy, radiology, surgery; Medical archiving systems; Digital devices for image capturing (microscope, stethoscope); Digital equipments and digital cinema; Digital signature protection MOBILE: Mobile technologies 3G+: UMTS, HSPA, HSUPA, HSDPA, HSOPA, WiMAX, UWB. LTE, All-IP LTE 4G and beyond; Seamless handover engineering; Cognitive radio; Mobile video surveillance; Pervasive/ubiquitous/mobile systems; Security and privacy issues for mobile and wireless systems; Mobile ad hoc networks MEDMAN: Control and management of multimedia telecommunication Video codec-aware of packets; Monitoring via guard on patrol, central station, forensic analysis; Managing single domestic licensing and granted patent pool for compressions; End-to-end quality monitoring/management; Perceived/offered quality: video-only, audio-only, audio-video; In-service monitoring of voice/video/data services; Real-time distributed imagery management systems; Performance in voice/video/data systems; Distributed multimedia service management; Mobile multimedia network management; Multi-point, multicast services management; Deployment of multimedia services; Network management models and architectures; Billing and security for multimedia services; Network measurement/monitoring for multimedia services SARP: Software architecture research and practice Distributed software architecture; Architectural styles and patterns; Architecture refinement and transformation; Software architecture and pervasive systems; Software architecture analysis & testing; Architectural description languages (ADLs); Component-based software architecture; Dynamic software architecture; Self-repairing software architecture; Adaptive software architecture; Aspect-oriented software architecture; Service-oriented architecture [SOA]; Domain specific software architecture [DSSA]; Tools/Environments for software architects; Product-line software architecture; Industrial case studies and reports STREAM: Data stream processing Fundamentals on data stream processing; Data stream processing and event stream processing; Continuous query languages; Time management in data stream systems; Aggregated queries support; Query processing with multiple, continuous, rapid, time-varying data streams; Processing frequent itemset discovery queries; Real-time stream data processing; Network-aware operator placement for stream-processing systems; Integrating database queries and Web searches; Scalable Distributed Stream Processing; Optimization of data stream processing; Performance and overhead in data stream processing; QoS adaptation in data stream systems; Adaptive query processing in data stream; Interactive distributed data stream processing and mining; Data stream management systems; Control theory on stream processing; Processing high-speed data streams; Stream processing in production-to-business software; Multi-site cooperative data stream analysis; Grid-based data stream processing; Hyperdatabases for P2P data stream processing; Sensor data stream processing in health monitoring; Processing and sharing data streams in Grid-based P2P infrastructures TRACK: Tracking computing technologies Airport security communications technologies; Hazards detection- automatic real-time material/object recognition; Intelligent IP-based sensor networking for homeland security; Real-time intelligence data validation and verification mechanisms; Efficient data integration and mining techniques for NATO countries; Secure distributed storage and data pinning; SATCOM for HLS; Critical aerospace communications systems; HLS for air, land and sea operational environments; Airborne real-time spatial tracking techniques; Bio- authentication sensors and tools; Cyber and physical security of key infrastructure and operations; Protection of Real-time resilient communications network infrastructures; International standards for data schema and data sharing between USA and other countries; Emergency response tools; Prediction of Intent; Standards for Passenger Data Integration; Sharing Addressing and Service Discovery in Auto-configuring MANETs; Exploiting localization and network information (GPS, INS, GIS, terrain features, ToA, AoA, SNR, QoS) for improved ad-hoc networking in complex terrain; Advanced indoor and outdoor location-based applications: real-time tracking, multimedia, bidirectional, proactive applications; Location based services based on integrated cellular, ad hoc, RFID, and sensor networks; New positioning techniques in support of location based servcies (indoor, cellular, satellite, hybrid); Geographic Information Systems for supporting location based services; Quality of location data; Integration of Hierarchical Location-Based Routing (HLBR) with Delay- and Disruption-Tolerant Neworks (DTNs); Narrow-band control channels for HLBR; Location-aware (GPS-aware) Internet Browsers for Location-based services -------------------------- Committee: http://www.iaria.org/conferences2013/ComICDT13.html ================================================ From magnus.westerlund@ericsson.com Mon Dec 10 05:25:44 2012 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 8430A21F8C1A for ; Mon, 10 Dec 2012 05:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIHLcVoSRrGN for ; Mon, 10 Dec 2012 05:25:43 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0930721F8C14 for ; Mon, 10 Dec 2012 05:25:42 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-72-50c5e2d599b3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 75.DE.10459.5D2E5C05; Mon, 10 Dec 2012 14:25:41 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 10 Dec 2012 14:25:40 +0100 Message-ID: <50C5E2D3.5040205@ericsson.com> Date: Mon, 10 Dec 2012 14:25:39 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , EKR References: <50B4CC3E.6070705@ericsson.com> In-Reply-To: <50B4CC3E.6070705@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvje7VR0cDDKZNMrJ42bOS3WLtkUSL Fa/PsTsweyxZ8pPJY/LjNmaPL5c/swUwR3HZpKTmZJalFunbJXBlHHl/jKngiVvF2m9VDYzT jboYOTkkBEwketZ0MELYYhIX7q1n62Lk4hASOMkosWxOHxOEs5xRonXpShaQKl4BbYnZDY/Y QGwWAVWJF+/bWEFsNgELiZs/GsHiogK+ErP2/GKCqBeUODnzCViviEC1xMqm/WD1zAJKEnOX vmYGsYUFQiROts9nB7GFgOb39mwA6+UU0JE4ducD1HWSEoumdbJA9OpJTLnawghhy0s0b53N DNPb0NTBOoFRaBaS1bOQtMxC0rKAkXkVI3tuYmZOernhJkZg8B7c8lt3B+OpcyKHGKU5WJTE ebmS9vsLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYKz6z/de1NqKeSffE7XVsawV/w1/79gT urjxyf6E+bcWtsQnP19soBA+ZbZhknyd4VGDL2lKWTfXZD7SmeGU2DBfkeU0xx23d9O+vbeY oRTVI7cs/28wz9cab+mJEdWCVZGBrQsVrz2bE+ey0jq0aIrow8/cT1ijmDb9eNf3dbbq7kYz hZLF1kosxRmJhlrMRcWJADDUHxQsAgAA Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Working group last call on draft-ietf-avtcore-srtp-aes-gcm-03 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, 10 Dec 2012 13:25:44 -0000 WG, Authors EKR, please look at issue 8 and 16 below. On 2012-11-27 15:20, Magnus Westerlund wrote: > WG, > > This announces the WG last call on AES-GCM and AES-CCM Authenticated > Encryption in Secure RTP (SRTP) > https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ > I have made a personal review of this document. My comments are the following. I have not checked for overlap with already made comments. 1) In the front page header: "Intended Status: Informational" Please change this to standards track. 2) Section 1: The first mentioning of SRTP, RTP etc should have references, that also applies to AES and the AES-GCM, AES-CCM. 3) Section 4) Instantiation In AEAD, an instantiation is an (Encryption_key, salt) pair together with all of the data structures (for example, counters) needed for it to function properly. In SRTP/SRTCP, each endpoint will need two instantiations of the AEAD algorithm for each master key in its possession, one for SRTP and one for SRTCP. When reading this I got hang up on this. I realized why when getting further one. First of all I had forgotten about the fact that the SSRC is provided at invocation time through the IV, rather than at Instantiation. So I don't think this text is wrong, I think the issue might be in Section 3, that needs an bullet 4 that maps down to invocation level by making clear that a particular packet is processed by forming the IV for that packet using SSRC, Roll-over counter and SSRC combined with selecting the instantiation that is relevant for this packet. 4) Section 6. In both GCM and CCM, each outbound packet uses a 12-octet IV and an encryption key to form two outputs, a 16-octet first_key_block which is used informing the authentication tag and keystream of octets which is XORed to the plaintext to form cipher. I guess "informing" should be "in forming"? Is a "the" needed before "keystream"? 5) Section 6: When GCM is used, the concatenation of a 12-octet IV, with a 4-octet block counter forms the input to AES. This is used to build a key_stream as follows: Please add a forward pointer to where the IV is defined. 6) Section 6, page 7: The example code, is clearly not full code, but does it allow usage of some commonly available code? If so I think the authors needs to consider if they can offer this code as "Code component" following the IPR license from the trust for Code Components. Please see: http://trustee.ietf.org/license-info/ 7. Section 6, These keystream generation processes allows for a keystream of length of up to (2^24)-16 octets for AES-CCM and up to (2^36)-32 octets for AES-GCM. I wonder if the decimal values should be included in the above sentence to ease for humans. 8. Section 8.1. SRTP/SRTCP Authentication Field I think this section is attempting the wrong approach to this issue. First of all as the algorithms include authentication I think they fulfill the mandates from SRTP on requiring authentication on RTCP. Secondly, I think the right approach to deal with the issue that you have no data is to have the algorithms define there usage of the authentication tag to be zero length. All the defined algorithm identifiers includes both key lengths and auth tag lengths. Thus writing this as "SHOULD NOT" is very strange, as all the other CIPHERS include the encryption + authentication with one ID. This one is no different. This would then have implications on Section 9.2, 10.3, etc which mentions this field. 9. Section 9.2 and 9.3: please consider to use some separator between the defined term and the definition, like: Counter Management: A rekey MUST be performed to establish a new master key before the (ROC,SEQ) pair cycles back to its original value. 10. Section 9.3: SSRC Management The set of all SSRC values must be partitioned into disjoint pools, one pool for each endpoint using the master key to originate outbound data. Each such endpoint MUST only issue SSRC values from the pool it has been assigned. Further, each endpoint MUST maintain a history of outbound SSRC identifiers that it has issued within the lifetime of the current master key, and when a new synchronization source requests an SSRC identifier it MUST NOT be given an identifier that has been previously issued. A rekey MUST be performed before its pool of SSRC values is exhausted. I wonder if one should specifically discuss the cases where each end-point has its own master key and thus can use any SSRC value from a crypto perspective. This clearly apply to Security Description and DTLS-SRTP. 11. Section 10.1: 0 1 2 3 4 5 6 7 8 9 10 11 +--+--+--+--+--+--+--+--+--+--+--+--+ |00|00| SSRC |00|00|0+SRTCP Idx|---+ +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | Encryption Salt |->(+) +--+--+--+--+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+--+--+--+--+ | | Initialization Vector |<--+ +--+--+--+--+--+--+--+--+--+--+--+--+ Please clarify in this figure and text above that the Salt is the one derived for the SRTCP. 12. Section 10.1: Using the terminology of section 8.2.1. of [GCM], the first eight octets of the IV are the fixed field and the last four octets are the invocation field. As I haven't look at the ref, this might be correct. But compared to the definition of Invocation in Section 3: Invocation SRTP/SRTCP data streams are broken into packets. Each packet is processed by a single invocation of the appropriate instantiation of the AEAD algorithm. This can't be correct. As an end-point can use multiple SSRC simultaneously, it looks like the SSRC should be considered an Invocation field, or? 13. Section 11.1: The lower bound on C_MAX is obtained by subtracting away a 20-octet IP header, 8-octet UDP header, and 12-octet RTP header from the maximum transmission unit (MTU) of 2272. Who's MTU is 2272? Considering SRTP I don't think there is any definition of "THE MTU" as stated in the above sentence. 14. Section 11.3 In addition to the flag octet used in counter node encryptionn, AES-CCM authentications also useus a flag octet that conveys information about the length of the authentication tag, length of the block counter, and presence of additional authenticated data (see section 2.2 of [RFC 3610]). "counter node encryption" I guess this should be "mode" 15. Section 14.2: AEAD_AES_128_CCM_8 cipher: AES_128_CCM cipher_key_length: 128 bits cipher_salt_length: 96 bits maximum lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets Shouldn't this read for cipher: AES_128_CCM_8? Same errors exist for all the shorter tag lengths. 16. AEAD_AES_128_CCM cipher: AES_128_CCM cipher_key_length: 128 bits cipher_salt_length: 96 bits maximum lifetime: at most 2^31 SRTCP packets and at most 2^48 SRTP packets Shouldn't these definition include the following values also: auth_function: NULL auth_key_length: 0 auth_tag_length: 0 Thus completing the definitions that you are not using the regular authentication tag length? That was all. I think there is some few issues that absolutely must be sorted out before publishing this document. But I think it is in fairly good shape. I would expect a second WG last call on the changes before we proceed. But lets start with discussing the changes. 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 Wed Dec 12 02:28:01 2012 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 44AB821F899E for ; Wed, 12 Dec 2012 02:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKKRy4mtQjZP for ; Wed, 12 Dec 2012 02:28:00 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A36621F8953 for ; Wed, 12 Dec 2012 02:28:00 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so171268eaa.31 for ; Wed, 12 Dec 2012 02:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=nuC6rh54N9VYFt3BqMgzIUSWUKEa5nK/vyJesNkzFr8=; b=ij6ISOAce8mV+M1k5z5lroqJwoUKq83JQgbU0cG5xu7NklTKgPMEPcQUo1KxI/XMD+ M+TK7NlTxEc3DUxRkKl00Kbl8OI6rNFnuQ7HFrkDx5G6uQQCwRvwjLN1r7xieb0/YleW UqWJb0V7GcmdvVvpiSZ3wR2KEhJ1k2RTcCYE1difQULCiMQLIZbhLeYFnKU3NSUWL73N 3ui+PYnRWPHSVZQ4wnE2XQx9z38OHvFdhjm75hhUE6pangMArXkJBfolBB4az5Bg47r9 pIE2f4PuLEmZBURMGXIR6So/BJi/4+9WB0ri/xh3g+hlQXiuIXuNfGJefFOoeZ6KdGr3 eBJQ== Received: by 10.14.216.70 with SMTP id f46mr1591850eep.12.1355308079571; Wed, 12 Dec 2012 02:27:59 -0800 (PST) Received: from RoniE (bzq-79-176-185-176.red.bezeqint.net. [79.176.185.176]) by mx.google.com with ESMTPS id l3sm36896973eem.14.2012.12.12.02.27.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 02:27:58 -0800 (PST) From: "Roni Even" To: References: In-Reply-To: Date: Wed, 12 Dec 2012 12:25:12 +0200 Message-ID: <05ff01cdd852$fdb15e70$f9141b50$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0600_01CDD863.C13ACAB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3NMr6FWNMq2fV1TbiWYfaPrC+jfQLH7LfQ Content-Language: en-us Subject: Re: [AVTCORE] confirmation of adoption of draft-terriberry-avp-codecs-00 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, 12 Dec 2012 10:28:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0600_01CDD863.C13ACAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Since there were no objection we will accept the work. Can the authors submit it as draft-ietf-avtcore-avp-codecs-00 Thanks Roni Even AVTcore co-chair From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 28 November, 2012 8:38 AM To: avt@ietf.org Subject: confirmation of adoption of draft-terriberry-avp-codecs-00 WG, At the IETF 85th meeting's second AVTCORE session we took a hum for adopting Update to Recommended Codecs for the AVP RTP Profile (draft-terriberry-avp-codecs-00) as a WG item with the intention to update RFC3551. I would like to confirm this call for adoption also on the WG mailing list. So people that didn't provided input into this in the meeting please provide your support or objections no later than December 10th. Thanks Roni ------=_NextPart_000_0600_01CDD863.C13ACAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Since there were no = objection we will accept the work.

Can the authors submit = it as draft-ietf-avtcore-avp-codecs-00

Thanks

Roni = Even

AVTcore co-chair

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 28 November, = 2012 8:38 AM
To: avt@ietf.org
Subject: confirmation = of adoption of = draft-terriberry-avp-codecs-00

 

WG,

 

At the =
IETF 85th meeting's second AVTCORE session we took a hum for adopting =
Update to =
Recommended Codecs for the AVP RTP Profile

(draft-terriberry-avp-codecs-00) as a WG item with = the intention to update  RFC3551.

 

I = would like to confirm this call for adoption also on the WG mailing = list. So people that didn't provided input into this in the meeting = please provide your support or objections no later than December = 10th.

 

Thanks

Roni

------=_NextPart_000_0600_01CDD863.C13ACAB0-- From christian.correll@siemens-enterprise.com Wed Dec 12 04:59:57 2012 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 3A95721F89EA for ; Wed, 12 Dec 2012 04:59:57 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64WUhK0J1s6W for ; Wed, 12 Dec 2012 04:59:56 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9430521F89E1 for ; Wed, 12 Dec 2012 04:59:54 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 446491EB8D08 for ; Wed, 12 Dec 2012 13:59:53 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.13]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0318.001; Wed, 12 Dec 2012 13:59:53 +0100 From: "Correll, Christian" To: "avt@ietf.org" Thread-Topic: Review of draft-ietf-avtcore-rtp-security-options-01 Thread-Index: Ac3YaJM+kKvjxfmqSLeB4fsIpj/CiA== Date: Wed, 12 Dec 2012 12:59:47 +0000 Message-ID: <0EA3AE418270B64C930B97CECB6E78180126883D@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_0EA3AE418270B64C930B97CECB6E78180126883DMCHP04MSXglobal_" MIME-Version: 1.0 Subject: [AVTCORE] Review of draft-ietf-avtcore-rtp-security-options-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: Wed, 12 Dec 2012 12:59:57 -0000 --_000_0EA3AE418270B64C930B97CECB6E78180126883DMCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I reviewed the RTP security options document and I have following comments. 1) Section 3.1. Secure RTP The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly used mechanisms to provide confidentiality, integrity protection and source authentication for RTP. Another security property that is explicitly mentioned in RFC 3711 is repla= y protection. 2) Section 3.1.1. Key Management for SRTP: DTLS-SRTP A Datagram Transport Layer Security extension exists for establishing SRTP keys [RFC5763][RFC5764]. This extension provides secure key- exchange between two peers, including perfect forward secrecy and enabling binding strong identity verification to an end-point. I wonder if the security properties of DTLS-SRTP actually depend on the cip= hersuite the endpoints negotiate during the DTLS handshake. For example, wh= en client and server agree on the ciphersuite TLS_DHE_RSA_WITH_AES_128_CBC_= SHA they perform a Diffie-Hellman key agreement; in this case DTLS-SRTP pro= vides PFS. Whereas when they agree on TLS_RSA_WITH_AES_128_CBC_SHA the clie= nt encrypts a shared secret with the server's public key; and in that case = PFS is not provided. To meet the security goals, the ciphersuites that the = client can offer and the server can accept need carefully be selected. 3) Section 3.1.2. Key Management for SRTP: MIKEY Pre-Shared Key mode: This system is the most efficient from the perspective of having small messages and processing demands. The downside is scalability. Usually, the effort for the provisioning of pr= e-shared keys is only manageable, if the number of endpoints is small. IBAKE mode: If provides both perfect forward and backwards secrecy. I think the term perfect backward secrecy needs more clarification. In what= exactly is it different from forward secrecy? For example, RFC 4949 gives = a definition of perfect forward secrecy and briefly discusses issues where = experts disagree about it. Backward secrecy is mentioned in that context as= one of the disputed issues (it seems to be a synonym for forward secrecy),= but not precisely defined. I am not aware of a clear definition of this te= rm. SAKKE mode: Requires additional infrastructure. A key management service (KMS) must cre= ate the secret keys associated with the identities (resp. public keys). 4) Section 3.1.3. Key Management for SRTP: Security Descriptions Since keys are transported in plain text in SDP, they can easily be intercepted unless the SDP carrying protocol provides strong end-to- end confidentiality and authentication guarantees. This is not the common use of security descriptions with SIP, where instead hop by hop security is provided between signalling nodes using TLS. This still leaves the keying material sensitive to capture by the traversed signalling nodes. Thus in most cases the security properties of security description are weak. I agree. The usage of security descriptions usually requires additional sec= urity measures, e.g. the signalling nodes be trusted and protected by stric= t access control. An example where these conditions are often given is an e= nterprise environment. Usage of security descriptions requires careful desi= gn in order to ensure that the security goals can be met. 5) Section 3.1.4. Key Management for SRTP: EKT Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP extension that enables group keying despite using a keying mechanism that can't support group keys, like DTLS-SRTP. A second use case also described in the EKT draft is interoperability betwe= en different key management systems. 6) Section 4.1.3. Source Authentication Binding the Source: For example, consider a point to point communication system that use DTLS-SRTP using self-signed certificates for key-management, and SIP for signalling. In such a system the end-points for the DTLS-SRTP handshake have securely established keys that are not visible to the signalling nodes. However, as the certificates used by DTLS is not bound to any PKI they can't be verified. Instead, hashes over the certificate are sent over the signalling path. If the signalling can be trusted not to collaborate on performaning a man in the middle attack by modifying the hashes, then the end-points can verify that they have reached the peer they are doing signalling with. A second example is a key management method that transports the key exchang= e data in the signalling plane, e.g. MIKEY or security descriptions. Such a= method ties the key exchange directly to the signalling. There are no addi= tinal steps required to ensure that the "signalling peer" is the same as th= e "key exchange peer". 7) Section 4.1.4. Identity ..., having an identity provider system can benefit the applications by enabling them to do strong assertion between identity and the actual media source. I wonder if the draft should briefly address how identity verification can = be achieved. The draft states several times that source authentication is p= ossible using verifiable identities. I think, giving examples for the most = widely used systems for asserting and verifying an identity makes reading e= asier. Regards Christian Correll --_000_0EA3AE418270B64C930B97CECB6E78180126883DMCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I reviewed the RTP security options do= cument and I have following comments.
 
 
1) Section 3.1.  Secure RTP
 
   The Secure RTP (SRTP) pro= tocol [RFC3711] is one of the most commonly
   used mechanisms to provide confidentiality, integrity protecti= on and
   source authentication for RTP.
 
Another security property that is expl= icitly mentioned in RFC 3711 is replay protection.
 

2) Section 3.1.1.  Key Management for = SRTP: DTLS-SRTP
 
   A Datagram Transport Laye= r Security extension exists for establishing
   SRTP keys [RFC5763][RFC5764].  This extension provides se= cure key-
   exchange between two peers, including perfect forward secrecy = and
   enabling binding strong identity verification to an end-point.=
 
I wonder if the security properties of= DTLS-SRTP actually depend on the ciphersuite the endpoints negotiate durin= g the DTLS handshake. For example, when client and server agree on the ciphersuite TLS_DHE= _RSA_WITH_AES_128_CBC_SHA they perform a Diffie-Hellman key agreement; in t= his case DTLS-SRTP provides PFS. Whereas when they agree on TLS_RSA_WITH_AES_128_CBC_SHA the client e= ncrypts a shared secret with the server's public key; and in that case PFS = is not provided. To meet the security goals, the ciphersuites that the client can off= er and the server can accept need carefully be selected.
 

3) Section 3.1.2.  Key Management for = SRTP: MIKEY
 
Pre-Shared Key mode:
 
   This system is the most e= fficient from the perspective of having
   small messages and processing demands.
 
The downside is scalability. Usually, = the effort for the provisioning of pre-shared keys is only manageable, if t= he number of endpoints is small.
 

IBAKE mode:
 
   If provides both perfect = forward and backwards secrecy.
 
I think the term perfect backward secr= ecy needs more clarification. In what exactly is it different from forward = secrecy? For example, RFC 4949 gives a definition of perfect forward secrecy = and briefly discusses issues where experts disagree about it. Backward secrecy is mentioned in that context as one of the disputed= issues (it seems to be a synonym for forward secrecy), but not precisely d= efined. I am not aware of a clear definition of this term.
 

SAKKE mode:
 
Requires additional infrastructure. A = key management service (KMS) must create the secret keys associated with th= e identities (resp. public keys).
 

4) Section 3.1.3.  Key Management for = SRTP: Security Descriptions
 
   Since keys are transporte= d in plain text in SDP, they can easily be
   intercepted unless the SDP carrying protocol provides strong e= nd-to-
   end confidentiality and authentication guarantees.  This = is not the
   common use of security descriptions with SIP, where instead ho= p by
   hop security is provided between signalling nodes using TLS.&n= bsp; This
   still leaves the keying material sensitive to capture by the    traversed signalling nodes.  Thus in most cases the secur= ity
   properties of security description are weak.
 
I agree. The usage of security descrip= tions usually requires additional security measures, e.g. the signalling no= des be trusted and protected by strict access control. An example where the= se conditions are often given is an enterprise environment. Usage of= security descriptions requires careful design in order to ensure that the = security goals can be met.
 

5) Section 3.1.4.  Key Management for = SRTP: EKT
 
   Encrypted Key Transport (= EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP
   extension that enables group keying despite using a keying mec= hanism
   that can't support group keys, like DTLS-SRTP.
 
A second use case also described in th= e EKT draft is interoperability between different key management systems.
 

6) Section 4.1.3.  Source Authenticati= on
 
Binding the Source:
 
      For exa= mple, consider a point to point communication system that
      use DTLS-SRTP using self-signed certificates= for key-management,
      and SIP for signalling.  In such a syst= em the end-points for the
      DTLS-SRTP handshake have securely establishe= d keys that are not
      visible to the signalling nodes.  Howev= er, as the certificates
      used by DTLS is not bound to any PKI they ca= n't be verified.
      Instead, hashes over the certificate are sen= t over the signalling
      path.  If the signalling can be trusted= not to collaborate on
      performaning a man in the middle attack by m= odifying the hashes,
      then the end-points can verify that they hav= e reached the peer
      they are doing signalling with.
 
A second example is a key management m= ethod that transports the key exchange data in the signalling plane, e.g. M= IKEY or security descriptions. Such a method ties the key exchange directly to the signalling. = ;There are no additinal steps req= uired to ensure that the "signalling peer" is the same as the &qu= ot;key exchange peer".
 

7) Section 4.1.4.  Identity
 
   ..., having an identity p= rovider system can benefit the applications
   by enabling them to do strong assertion between identity and t= he
   actual media source.
 
I wonder if the draft should briefly a= ddress how identity verification can be achieved. The draft states several times that source authentication is possibl= e using verifiable identities. I think, giving examples for the most widely used systems for assert= ing and verifying an identity makes reading easier.
 

Regards
 
Christian Correll
 
 
--_000_0EA3AE418270B64C930B97CECB6E78180126883DMCHP04MSXglobal_-- From magnus.westerlund@ericsson.com Wed Dec 12 23:48:16 2012 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 53AFC21F8890 for ; Wed, 12 Dec 2012 23:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.206 X-Spam-Level: X-Spam-Status: No, score=-106.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYzyhGjjv2qd for ; Wed, 12 Dec 2012 23:48:15 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DA7F621F85EA for ; Wed, 12 Dec 2012 23:48:14 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-f6-50c9883d40e3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 18.9E.10459.D3889C05; Thu, 13 Dec 2012 08:48:13 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 13 Dec 2012 08:48:13 +0100 Message-ID: <50C9883C.4030806@ericsson.com> Date: Thu, 13 Dec 2012 08:48:12 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: avt@ietf.org References: <50B4D747.4090005@ericsson.com> In-Reply-To: <50B4D747.4090005@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+Jvja5tx8kAg6vr5Sxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvylHxkLNvNXPDn2ha2B8TBPFyMnh4SAicT6Q40sELaYxIV7 69m6GLk4hAROMkqcu72fGcJZziix++gNsCpeAW2Jd73vWUFsFgFViXkHnzOD2GwCFhI3fzSy gdiiAr4Ss/b8YoKoF5Q4OfMJWK+IgIDEiu1/wWxhgRCJlXcmgdUIAc2c/a4frJdTQEfiVl8X E8RFkhKLpnWC1TML6ElMudrCCGHLSzRvnc0M09vQ1ME6gVFwFpJ1s5C0zELSsoCReRUje25i Zk56ueEmRmAAHtzyW3cH46lzIocYpTlYlMR5uZL2+wsJpCeWpGanphakFsUXleakFh9iZOLg lGpg9H2p/bWtfcp15l2Tz+bfP2C9XvSgZ/r8r0e2s7ZPq/n9vMykkvXjPLOvU/nKD22RF6vk dDZ/k1AoaWvhx37j2+4d1QYiT8uWmvMYz6nbI37W0cm5cm+fdH7t/rryCIlt+mtlLFR82QSF tCY9+5RYdbOA67XlpxUi9/92ygYfjfvuu73dXMJCiaU4I9FQi7moOBEAq/TyZQ4CAAA= Subject: Re: [AVTCORE] Confirmation of adoption of draft-rescorla-avtcore-6222bis-00 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, 13 Dec 2012 07:48:16 -0000 WG, My judgment is that there exist a strong consensus to adopt an update of RFC 6222 to include a random and privacy protecting CNAME allocation algorithm as a WG item. I will now request a Milestone and AD approval for this. Cheers Magnus Westerlund (As WG chair) On 2012-11-27 16:07, Magnus Westerlund wrote: > WG, > > At the IETF 85th meeting's first AVTCORE session we took a hum for > adopting Guidelines for Choosing RTP Control Protocol (RTCP) Canonical > Names (CNAMEs) (draft-rescorla-avtcore-6222bis-00) as a WG item with the > intention to have it replace RFC 6222. > > I would like to confirm this call for adoption also on the WG mailing > list. So people that didn't provided input into this in the meeting > please provide your support or objections no later than the 6th of December. > > 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 > ---------------------------------------------------------------------- > > _______________________________________________ > 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 ietf-ipr@ietf.org Wed Dec 12 09:36:01 2012 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 B066721E80F7; Wed, 12 Dec 2012 09:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AffRnFub5NRx; Wed, 12 Dec 2012 09:36:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06B021F89B5; Wed, 12 Dec 2012 09:35:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: rjesup@wgate.com, tom.kristensen@tandberg.com, yekuiwang@huawei.com, ron.even.tlv@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121212173559.26173.51592.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 09:35:59 -0800 X-Mailman-Approved-At: Thu, 13 Dec 2012 15:52:09 -0800 Cc: avt@ietf.org, ipr-announce@ietf.org Subject: [AVTCORE] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6184 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, 12 Dec 2012 17:36:02 -0000 Dear Randell Jesup, Tom Kristensen, Yekui Wang, Roni Even: An IPR disclosure that pertains to your RFC entitled "RTP Payload Format f= or H.264 Video" (RFC6184) was submitted to the IETF Secretariat on 2012-12-10 = and has been posted on the "IETF Page of Intellectual Property Rights Disclosur= es" (https://datatracker.ietf.org/ipr/1936/). The title of the IPR disclosure is "Microsoft Corporation's Statement about IPR related to RFC 6184.""); The IETF Secretariat From adam@nostrum.com Thu Dec 13 16:00:21 2012 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 5149C21F88DA for ; Thu, 13 Dec 2012 16:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.204 X-Spam-Level: X-Spam-Status: No, score=-101.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlgNUu3lKWer for ; Thu, 13 Dec 2012 16:00:16 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C6A6521F87F5 for ; Thu, 13 Dec 2012 16:00:16 -0800 (PST) Received: from [192.168.2.2] (mb35636d0.tmodns.net [208.54.86.179]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBE00DCF013647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 18:00:15 -0600 (CST) (envelope-from adam@nostrum.com) References: <20121212173559.26173.51592.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20121212173559.26173.51592.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6FDA18D2-7A13-425E-BC64-6A6F9E00F5F8@nostrum.com> X-Mailer: iPad Mail (10A403) From: Adam Roach Date: Thu, 13 Dec 2012 18:02:32 -0600 To: IETF Secretariat Received-SPF: pass (nostrum.com: 208.54.86.179 is authenticated by a trusted mechanism) Cc: "tom.kristensen@tandberg.com" , "rjesup@wgate.com" , "avt@ietf.org" , "yekuiwang@huawei.com" , "ipr-announce@ietf.org" Subject: Re: [AVTCORE] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6184 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, 14 Dec 2012 00:00:21 -0000 I'm confused. This does not appear to disclose anything at all. The only inf= ormation filled in for that form is an RFC number and contact information. S= urely this form was submitted in error, before being filled out completely.=20= /a On Dec 12, 2012, at 11:35, IETF Secretariat wrote: >=20 > Dear Randell Jesup, Tom Kristensen, Yekui Wang, Roni Even: >=20 > An IPR disclosure that pertains to your RFC entitled "RTP Payload Format f= or > H.264 Video" (RFC6184) was submitted to the IETF Secretariat on 2012-12-10= and > has been posted on the "IETF Page of Intellectual Property Rights Disclosu= res" > (https://datatracker.ietf.org/ipr/1936/). The title of the IPR disclosure i= s > "Microsoft Corporation's Statement about IPR related to RFC 6184.""); >=20 > The IETF Secretariat >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From mizquierdo@extron.com Thu Dec 13 16:22:39 2012 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 5EBB221F8BF6; Thu, 13 Dec 2012 16:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCI+NPuxQo43; Thu, 13 Dec 2012 16:22:33 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7403B21F8BF2; Thu, 13 Dec 2012 16:22:32 -0800 (PST) Received: from mail62-am1-R.bigfish.com (10.3.201.234) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Dec 2012 00:22:31 +0000 Received: from mail62-am1 (localhost [127.0.0.1]) by mail62-am1-R.bigfish.com (Postfix) with ESMTP id 38A7F160108; Fri, 14 Dec 2012 00:22:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:207.141.218.78; KIP:(null); UIP:(null); IPV:NLI; H:USA-EX-HUB1.extron.com; RD:host76.extron.com; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz98dI9371I936eI1432Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033ILz2fh2a8h668h839h944ha12hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h14ddh1504h1537h153bh162dh1631h1758h122ck1155h) Received-SPF: pass (mail62-am1: domain of extron.com designates 207.141.218.78 as permitted sender) client-ip=207.141.218.78; envelope-from=mizquierdo@extron.com; helo=USA-EX-HUB1.extron.com ; 1.extron.com ; Received: from mail62-am1 (localhost.localdomain [127.0.0.1]) by mail62-am1 (MessageSwitch) id 1355444549302971_10281; Fri, 14 Dec 2012 00:22:29 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.231]) by mail62-am1.bigfish.com (Postfix) with ESMTP id 46A8F120067; Fri, 14 Dec 2012 00:22:29 +0000 (UTC) Received: from USA-EX-HUB1.extron.com (207.141.218.78) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Dec 2012 00:22:27 +0000 From: Mike Izquierdo To: Adam Roach Thread-Topic: [AVTCORE] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6184 Thread-Index: AQHN2Y4aXBlXfIQrRk6nHEf2Bdjre5gXbxEA Date: Fri, 14 Dec 2012 00:22:24 +0000 Message-ID: References: <20121212173559.26173.51592.idtracker@ietfa.amsl.com>, <6FDA18D2-7A13-425E-BC64-6A6F9E00F5F8@nostrum.com> In-Reply-To: <6FDA18D2-7A13-425E-BC64-6A6F9E00F5F8@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: extron.com Cc: "tom.kristensen@tandberg.com" , "rjesup@wgate.com" , "avt@ietf.org" , "yekuiwang@huawei.com" , IETF Secretariat , "ipr-announce@ietf.org" Subject: Re: [AVTCORE] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6184 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, 14 Dec 2012 00:22:39 -0000 I'm confused as well. It doesn't reference a patent number or the name of t= he patent that is infringed. I'm not sure the value of an IPR if it doesn't= have this information. What does this mean? Mike On Dec 13, 2012, at 7:01 PM, "Adam Roach" wrote: > I'm confused. This does not appear to disclose anything at all. The only = information filled in for that form is an RFC number and contact informatio= n. Surely this form was submitted in error, before being filled out complet= ely. > > /a > > On Dec 12, 2012, at 11:35, IETF Secretariat wrote: > >> >> Dear Randell Jesup, Tom Kristensen, Yekui Wang, Roni Even: >> >> An IPR disclosure that pertains to your RFC entitled "RTP Payload Format= for >> H.264 Video" (RFC6184) was submitted to the IETF Secretariat on 2012-12-= 10 and >> has been posted on the "IETF Page of Intellectual Property Rights Disclo= sures" >> (https://datatracker.ietf.org/ipr/1936/). The title of the IPR disclosur= e is >> "Microsoft Corporation's Statement about IPR related to RFC 6184.""); >> >> The IETF Secretariat >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > ________________________________ Statement Of Confidentiality: This electronic message transmission, and all attachments, contains informa= tion from Extron Electronics which is confidential and privileged. The info= rmation is for the exclusive viewing or use of the intended recipient. If y= ou are not the intended recipient, be aware that any disclosure, copying, d= istribution or use of the contents of this information is prohibited. If yo= u have received this electronic transmission in error, please notify the se= nder immediately by a "reply to sender only" message and destroy all electr= onic and hard copies of the communication, including attachments. From tom.taylor.stds@gmail.com Fri Dec 14 17:34:59 2012 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 0FD8121F8AE2 for ; Fri, 14 Dec 2012 17:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTONyy7utRSw for ; Fri, 14 Dec 2012 17:34:58 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4A621F8AD5 for ; Fri, 14 Dec 2012 17:34:58 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so6929230ieb.31 for ; Fri, 14 Dec 2012 17:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-antivirus:x-antivirus-status; bh=y2ZUSz3WtORffbWpA7rfN9uxFEbR1aMxqBKxN87QT+E=; b=P/PwX4ZvXZyWG8JhWJxrg9vBl8HAKXEaiOAQt8rWikdP2zCoqCqsII6wbsnIm8m1lJ oTeMhGxxVh6qI41V2kOhyANw97bFI4W5eLSpfCED6qXMwWPDg4p/4kfnWV7Hal4RM5pH 4PnZmvW8CKsNaekCzNJpHdCFvCPQd26UzMpdfRjEz8m8PE18D2aNppitOWJW6DUlZoTt SH9rgSuv82PBwXNb8UJKN0zubLHRKVWOFMQZ2txpH3v62UUz2thQXvsOias0zZ897n0j UW6/ixXwSOH7KTice8owpiC3MqwqPaHAVHhgZ3XrMWUxtviQeg3BbpVMoK1ToylU0irv fFlA== Received: by 10.50.161.232 with SMTP id xv8mr3527646igb.22.1355535298047; Fri, 14 Dec 2012 17:34:58 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-82-108.tor.primus.ca. [173.206.82.108]) by mx.google.com with ESMTPS id eu3sm114750igc.7.2012.12.14.17.34.56 (version=SSLv3 cipher=OTHER); Fri, 14 Dec 2012 17:34:57 -0800 (PST) Message-ID: <50CBD3BF.2010501@gmail.com> Date: Fri, 14 Dec 2012 20:34:55 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: avt@ietf.org References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------080401090405090508030903" X-Antivirus: avast! (VPS 121214-0, 14/12/2012), Outbound message X-Antivirus-Status: Clean Cc: Raul Villafani Subject: [AVTCORE] Fwd: Normas o Estandares de Auditoria sobre NGN 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, 15 Dec 2012 01:34:59 -0000 This is a multi-part message in MIME format. --------------080401090405090508030903 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit My Spanish isn't good enough to know what "Auditoria" means but it sounds like something relevant to this group. Tom Taylor -------- Original Message -------- Subject: Normas o Estandares de Auditoria sobre NGN Date: Wed, 12 Dec 2012 20:49:28 -0500 From: Raul Villafani To: ipv6@ietf.org Saludos, Si alguien tuviese conocimiento sobre Normas o Estandares de Auditoria que se apliquen a las Infraestructura de Redes de Nueva Generacion, Infraestructura de Telecomunicaciones, Redes de Nuevas Tecnologia, IP Multimedia Subsystem, Insfraestructura de Operadores de Telefonica Fija u Operadores de Moviles. Pueda copiarla a la Lista o mi email. Gracias Exitos y Feliz Navidad !!! raul.villafani@gmail.com --------------080401090405090508030903 Content-Type: text/plain; charset=windows-1252; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --------------080401090405090508030903-- From mary.ietf.barnes@gmail.com Fri Dec 14 17:38:30 2012 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 9AF9D21F85E6 for ; Fri, 14 Dec 2012 17:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.551 X-Spam-Level: X-Spam-Status: No, score=-103.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1AtuK4f-pBy for ; Fri, 14 Dec 2012 17:38:30 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB52121F85D8 for ; Fri, 14 Dec 2012 17:38:29 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so3278805lah.31 for ; Fri, 14 Dec 2012 17:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l6fCJl6i61LQtwXb0lLcy0i8qinnpP5+A9THdti++TI=; b=Ri0XV1ljUWInGh+1Bps4FFOx7k6a9C8x4eZqJ3+gLW+J4OA4FpOU8Sy9oAM7C9h2TN vtRe7W9wr2gN0KmcZHzd9zJND8KrpLvQXQ45wUlohftatEYz8CnUcqQA1AL5Uibukndx 3evCH6KwZ7eo2e3xRids98FXa5RKf6UG6bFrO5jFxS8XaU7fIFnTC8qnlIcYMxUwaGtR NF7QobCmu72udNu7HL5kHkcw2mxzLpgpwGfZBWaHWILAWgKyKWQryuDRzVnfrgAPedzn 9AHn0gQf1/vXOKXEr+c/gCsfV97JBMZKexzHi8lfId3jRUzHuk1Z7LT66bG78TVTNVYt /Opg== MIME-Version: 1.0 Received: by 10.112.28.9 with SMTP id x9mr3043837lbg.27.1355535508604; Fri, 14 Dec 2012 17:38:28 -0800 (PST) Received: by 10.114.20.41 with HTTP; Fri, 14 Dec 2012 17:38:28 -0800 (PST) In-Reply-To: <50CBD3BF.2010501@gmail.com> References: <50CBD3BF.2010501@gmail.com> Date: Fri, 14 Dec 2012 19:38:28 -0600 Message-ID: From: Mary Barnes To: Tom Taylor Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , Raul Villafani Subject: Re: [AVTCORE] Fwd: Normas o Estandares de Auditoria sobre NGN 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, 15 Dec 2012 01:38:30 -0000 I don't think it's relevant to this mailing list unless of course by "audit" he's asking for something like RTCP. Here's the translation from Google: " If someone had knowledge of rules or standards of audit apply to the infrastructure of next generation networks, Telecommunications Infrastructure, New Tech Network, IP Multimedia Subsystem, insfraestructura of fixed telephone operators or Mobile operators. Can copy it to the list or my email." 2012/12/14 Tom Taylor : > My Spanish isn't good enough to know what "Auditoria" means but it sounds > like something relevant to this group. > > Tom Taylor > > > -------- Original Message -------- > Subject: Normas o Estandares de Auditoria sobre NGN > Date: Wed, 12 Dec 2012 20:49:28 -0500 > From: Raul Villafani > To: ipv6@ietf.org > > Saludos, > Si alguien tuviese conocimiento sobre Normas o Estandares de Auditoria que > se apliquen a las Infraestructura de Redes de Nueva Generacion, > Infraestructura de Telecomunicaciones, Redes de Nuevas Tecnologia, IP > Multimedia Subsystem, Insfraestructura de Operadores de Telefonica Fija u > Operadores de Moviles. Pueda copiarla a la Lista o mi email. Gracias > Exitos y Feliz Navidad !!! > raul.villafani@gmail.com > > > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From csp@csperkins.org Sat Dec 15 08:21:32 2012 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 4377121F86AB for ; Sat, 15 Dec 2012 08:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlglWgXCNnEv for ; Sat, 15 Dec 2012 08:21:31 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id A522F21F85D4 for ; Sat, 15 Dec 2012 08:21:31 -0800 (PST) Received: from [80.176.158.71] (helo=[192.168.0.11]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TjuUH-0007Pz-CM for avt@ietf.org; Sat, 15 Dec 2012 16:21:17 +0000 From: Colin Perkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Dec 2012 16:21:16 +0000 Message-Id: To: IETF AVTCore WG Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BlackCat-Spam-Score: -13 X-Mythic-Debug: Threshold = On = Subject: [AVTCORE] It was 20 years ago today... 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, 15 Dec 2012 16:21:32 -0000 AVT Working Group, Today is an anniversary of sorts. The first working group draft of the = RTP specification, draft-ietf-avt-rtp-00.txt, on "A Transport Protocol = for Real-Time Applications" is dated 15 December 1992 -- 20 years ago = today. The draft is online at http://tools.ietf.org/html/draft-ietf-avt-rtp-00 = and was discussed at the 25th IETF meeting. The minutes of that meeting = can be found at http://www.ietf.org/proceedings/25.pdf (AVT minutes are = pages 441-447), and make interesting reading.=20 Colin From casner@acm.org Sat Dec 15 11:09:36 2012 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 3F67121F8542 for ; Sat, 15 Dec 2012 11:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gx0HbZGqPVr8 for ; Sat, 15 Dec 2012 11:09:35 -0800 (PST) Received: from mailman.packetdesign.com (firewall-gw-dirty-u.packetdesign.com [65.192.41.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A76921F84CD for ; Sat, 15 Dec 2012 11:09:35 -0800 (PST) Received: from packetdesign.com (vpn2-int.packetdesign.com [192.168.0.181]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id qBFJ9SFa000660; Sat, 15 Dec 2012 11:09:28 -0800 Date: Sat, 15 Dec 2012 11:09:28 -0800 (PST) From: Stephen Casner To: Colin Perkins In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IETF AVTCore WG Subject: Re: [AVTCORE] It was 20 years ago today... 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, 15 Dec 2012 19:09:36 -0000 Colin, Thanks for the notice. I guess we missed citing another 20th anniversary earlier this year, that of the first AVT meeting on March 17, 1992 at the 23rd IETF in San Diego. That meeting was included in the first IETF "audiocast" using IP multicast and NVP-II that was one of the inputs to the RTP design process. (There was actually an impromptu BOF to assess interest in forming a working group for AVT in November 1991 at the 22nd IETF in Santa Fe as an outgrowth of the Teleconferencing BOF at that meeting.) The notion that sending audio and video over the Internet should be constrained to experimental activities was valid then, and words to that effect remained when RFC 1889 was published. Those words were removed in the revision for full standard RFC 3550, and I think we can safely say this was an experiment with a successful outcome. -- Steve On Sat, 15 Dec 2012, Colin Perkins wrote: > AVT Working Group, > > Today is an anniversary of sorts. The first working group draft of > the RTP specification, draft-ietf-avt-rtp-00.txt, on "A Transport > Protocol for Real-Time Applications" is dated 15 December 1992 -- 20 > years ago today. > > The draft is online at > http://tools.ietf.org/html/draft-ietf-avt-rtp-00 and was discussed > at the 25th IETF meeting. The minutes of that meeting can be found > at http://www.ietf.org/proceedings/25.pdf (AVT minutes are pages > 441-447), and make interesting reading. > > Colin > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From ron.even.tlv@gmail.com Sun Dec 16 14:14:01 2012 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 A939121F8578 for ; Sun, 16 Dec 2012 14:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICs2mQU5dzRV for ; Sun, 16 Dec 2012 14:14:00 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C13D621F8573 for ; Sun, 16 Dec 2012 14:13:59 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so2939043eek.31 for ; Sun, 16 Dec 2012 14:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=UonYOXDoM56k+qoOFUX6hHXdBuZGqG4s/adUYbQAgtU=; b=s2Jf8YeVtphXHaiTDIIccugBnQWQmdXyTxVnuOQhlBFT4toKR3JVUzZIGXgEoL9NJC SeVRDVkDt1qEo+zYcIL+Ue05Tsyve+asVfRnAbOIGE/2Fbv5zaizftUsaVJpl/WmihrU 6iy2uZmCg1QKjZ1NilYNLKhmNYyuGmLJYSAieKdFjdz4v21PQfmaYERIdsgixfDWlwJQ 8/BZAz3IDDnQ+Agd1SKn63ziB1yc/c5K4LgPfqQdG97BaIPVaaqyQnyTA8GS8BiJkJj5 c+NWem5QKUdo1+7cGtK950KZI6py83OcfXMTD4VHZG9NYohtglAU1csVxz3mpR6lk88e CcjA== Received: by 10.14.221.9 with SMTP id q9mr35657593eep.3.1355696038899; Sun, 16 Dec 2012 14:13:58 -0800 (PST) Received: from RoniE (bzq-79-176-185-176.red.bezeqint.net. [79.176.185.176]) by mx.google.com with ESMTPS id l3sm25124653eem.14.2012.12.16.14.13.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Dec 2012 14:13:57 -0800 (PST) From: "Roni Even" To: References: In-Reply-To: Date: Mon, 17 Dec 2012 00:11:10 +0200 Message-ID: <026801cddbda$432a46d0$c97ed470$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0269_01CDDBEB.06B49D70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3bZ8Inu3L669YmS0CCrs3cFTI/3gAcnERA Content-Language: en-us Subject: [AVTCORE] FW: request for publication of draft-ietf-avtcore-srtp-encrypted-header-ext-03 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, 16 Dec 2012 22:14:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0269_01CDDBEB.06B49D70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 16 December, 2012 10:32 AM To: 'Robert Sparks' Cc: 'iesg-secretary@ietf.org'; 'avtcore@ietf.org'; Magnus Westerlund (magnus.westerlund@ericsson.com) Subject: request for publication of draft-ietf-avtcore-srtp-encrypted-header-ext-03 Hi Robert, I'd like to request that draft-ietf-avtcore-srtp-encrypted-header-ext-03, Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP), be published as Standard Track RFC. I've reviewed the draft in detail, and the AVTCore working group was given the opportunity to comment. The draft is documented in sufficient detail to meet the registration requirements, and doesn't conflict with other work in AVTCore. Accordingly, please consider it for publication. Thanks, Roni Even (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This is a standard track RFC updating RFC3711 adding a procedure that allows to encrypt part of the RTP header. The title page header indicates it. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: The Secure Real-Time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-Time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. This document updates RFC 3711, the Secure Real-Time Transport Protocol specification, to require that all SRTP encryption transforms specify how RTP header extensions are to be encrypted. Working Group Summary: This document went through two working group last call. As a result of the first one there were proposals to add some technical changes that were consented in the second working group last call. Document Quality: The document got good reviews from AVTcore members including SRTP and security experts. Personnel: Roni Even is the Document Shepherd and the Responsible Area Director is Robert Sparks. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd reviewed the document very carefully in version -03 (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document got a good review by key people from AVTcore including SRTP experts. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No need for any such review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes, the shepherd has confirmed with all authors. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was a strong consensus that header extension encryption is needed and this document is already referenced by new RTP header extensions in RFC6464 and RFC6465. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No ID nits in this document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable (13) Have all references within this document been identified as either normative or informative? yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? no (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. no (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document updates RFC3711 and it appears in the title page header, listed in the abstract and discussed in the introduction section. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document defines a new extension URI to the RTP Compact Header Extensions sub-registry of the Real-Time Transport Protocol (RTP) Parameters registry. The registration was reviewed by the document shepherd and it follows the registration requirements. No new IANA registries are defined. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new IANA registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No formal language. ------=_NextPart_000_0269_01CDDBEB.06B49D70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI

 

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 16 December, = 2012 10:32 AM
To: 'Robert Sparks'
Cc: = 'iesg-secretary@ietf.org'; 'avtcore@ietf.org'; Magnus Westerlund = (magnus.westerlund@ericsson.com)
Subject: request for = publication of = draft-ietf-avtcore-srtp-encrypted-header-ext-03

 

Hi Robert,

I'd like = to request that draft-ietf-avtcore-srtp-encrypted-header-ext-03, = Encryption of Header Extensions in the Secure Real-Time Transport = Protocol (SRTP), be published as Standard Track RFC.

 =

I've reviewed the draft in detail, = and the AVTCore working group was given the opportunity to comment. The = draft is documented in sufficient detail to meet the registration = requirements, and doesn't conflict with other work in AVTCore. = Accordingly, please consider it for publication.

 

Thanks,

Roni = Even

 

 

(1) What type of RFC is = being requested (BCP, Proposed Standard, Internet Standard, = Informational, Experimental, or Historic)? Why is this the proper type = of RFC? Is this type of RFC indicated in the title page header? =

This is a standard track RFC updating RFC3711 = adding a procedure that allows to encrypt part of the RTP = header.

The title page header indicates = it.

(2) The IESG approval = announcement includes a Document Announcement Write-Up. Please provide = such a Document Announcement Write-Up. Recent examples can be found in = the "Action" announcements for approved documents. The = approval announcement contains the following sections:

Technical = Summary:

The Secure = Real-Time Transport Protocol (SRTP) provides authentication, but not = encryption, of the headers of Real-Time Transport Protocol (RTP) = packets.  However, RTP header extensions may carry sensitive = information for which participants in multimedia sessions want = confidentiality.  This document provides a mechanism, extending the = mechanisms of SRTP, to selectively encrypt RTP header extensions in = SRTP.

This = document updates RFC 3711, the Secure Real-Time Transport Protocol = specification, to require that all SRTP encryption transforms specify = how RTP header extensions are to be encrypted.

 

Working Group Summary:

This document went through = two working group last call. As a result of the first one there were = proposals to add some technical changes that were consented in the = second working group last call.

Document = Quality:

The document got good reviews from AVTcore members = including SRTP and security experts.

Personnel:

Roni Even is the Document Shepherd and the Responsible Area Director = is Robert Sparks.

(3) Briefly describe the review of this document = that was performed by the Document Shepherd. If this version of the = document is not ready for publication, please explain why the document = is being forwarded to the IESG.

The shepherd reviewed the document very carefully in version = -03

(4) Does the document = Shepherd have any concerns about the depth or breadth of the reviews = that have been performed?

This document got a good = review by key people from AVTcore including SRTP = experts.

(5) Do portions of the document need review from a = particular or from broader perspective, e.g., security, operational = complexity, AAA, DNS, DHCP, XML, or internationalization? If so, = describe the review that took place.

No need for any such = review.

(6) Describe any specific concerns or issues that = the Document Shepherd has with this document that the Responsible Area = Director and/or the IESG should be aware of? For example, perhaps he or = she is uncomfortable with certain parts of the document, or has concerns = whether there really is a need for it. In any event, if the WG has = discussed those issues and has indicated that it still wishes to advance = the document, detail those concerns here.

No = concerns

(7) Has each author confirmed that any and all = appropriate IPR disclosures required for full conformance with the = provisions of BCP 78 and BCP 79 have already been filed. If not, explain = why?

Yes, the shepherd has confirmed with all authors.

(8) Has an IPR disclosure been filed that = references this document? If so, summarize any WG discussion and = conclusion regarding the IPR disclosures.

No IPR = disclosure

(9) How solid is the WG consensus behind this = document? Does it represent the strong concurrence of a few individuals, = with others being silent, or does the WG as a whole understand and agree = with it?

There was a strong consensus that header extension = encryption is needed and this document is already referenced by new RTP = header extensions in RFC6464 and RFC6465.

(10) Has anyone threatened = an appeal or otherwise indicated extreme discontent? If so, please = summarise the areas of conflict in separate email messages to the = Responsible Area Director. (It should be in a separate email because = this questionnaire is publicly available.)

No

(11) Identify any ID nits = the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idni= ts/ and the Internet-Drafts Checklist). Boilerplate checks are not = enough; this check needs to be thorough.

No ID nits in this = document.

(12) Describe how the document meets any required = formal review criteria, such as the MIB Doctor, media type, and URI type = reviews.

Not applicable

(13) Have all references = within this document been identified as either normative or informative? =

yes

(14) Are there normative = references to documents that are not ready for advancement or are = otherwise in an unclear state? If such normative references exist, what = is the plan for their completion?

no

(15) Are there downward = normative references (see RFC 3967)? If so, list these downward = references to support the Area Director in the Last Call procedure. =

no

(16) Will publication of this document change the = status of any existing RFCs? Are those RFCs listed on the title page = header, listed in the abstract, and discussed in the introduction? If = the RFCs are not listed in the Abstract and Introduction, explain why, = and point to the part of the document where the relationship of this = document to the other RFCs is discussed. If this information is not in = the document, explain why the WG considers it unnecessary. =

This document updates RFC3711 and it appears in the title page = header, listed in the abstract and discussed in the introduction = section.

(17) Describe the Document = Shepherd's review of the IANA considerations section, especially with = regard to its consistency with the body of the document. Confirm that = all protocol extensions that the document makes are associated with the = appropriate reservations in IANA registries. Confirm that any referenced = IANA registries have been clearly identified. Confirm that newly created = IANA registries include a detailed specification of the initial contents = for the registry, that allocations procedures for future registrations = are defined, and a reasonable name for the new registry has been = suggested (see RFC 5226).

This = document defines a new extension URI to the RTP Compact Header = Extensions sub-registry of the Real-Time Transport Protocol = (RTP)   Parameters registry. The registration was reviewed by = the document shepherd and it follows the registration requirements. =

 

No new IANA registries are = defined.

 

(18) List any new IANA = registries that require Expert Review for future allocations. Provide = any public guidance that the IESG would find useful in selecting the = IANA Experts for these new registries.

No new IANA = registries.

(19) Describe reviews and automated checks = performed by the Document Shepherd to validate sections of the document = written in a formal language, such as XML code, BNF rules, MIB = definitions, etc.

No formal = language.

 

------=_NextPart_000_0269_01CDDBEB.06B49D70-- From internet-drafts@ietf.org Tue Dec 18 14:29:46 2012 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 EC02E21F86FF; Tue, 18 Dec 2012 14:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltmXfDn78YXC; Tue, 18 Dec 2012 14:29:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3867521F86EA; Tue, 18 Dec 2012 14:29:46 -0800 (PST) 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.37 Message-ID: <20121218222946.30732.78155.idtracker@ietfa.amsl.com> Date: Tue, 18 Dec 2012 14:29:46 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-00.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: Tue, 18 Dec 2012 22:29:47 -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 : Guidelines for Choosing RTP Control Protocol (RTCP) Cano= nical Names (CNAMEs) Author(s) : Eric Rescorla Ali Begen Filename : draft-ietf-avtcore-6222bis-00.txt Pages : 10 Date : 2012-12-18 Abstract: The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tavares@fe.up.pt Wed Dec 19 08:57:27 2012 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 4E51321F87DE for ; Wed, 19 Dec 2012 08:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDFMXlOREoXp for ; Wed, 19 Dec 2012 08:57:27 -0800 (PST) Received: from smtp.fe.up.pt (smtp.fe.up.pt [193.136.28.30]) by ietfa.amsl.com (Postfix) with ESMTP id 399BB21F87C6 for ; Wed, 19 Dec 2012 08:57:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.fe.up.pt (Postfix) with ESMTP id 1B0DC603E for ; Wed, 19 Dec 2012 16:57:25 +0000 (WET) Received: from smtp.fe.up.pt ([127.0.0.1]) by localhost (smtp2.fe.up.pt [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIghUBL354YM for ; Wed, 19 Dec 2012 16:57:25 +0000 (WET) Received: from Blur (blur.fe.up.pt [192.168.131.51]) by smtp.fe.up.pt (Postfix) with ESMTPA id C7BB45FB5 for ; Wed, 19 Dec 2012 16:57:24 +0000 (WET) From: "=?iso-8859-1?B?Sm/jbyBNYW51ZWwgUi4gUy4gVGF2YXJlcw==?=" To: "avt" Message-ID: <3df09a28e5d58a43ae5f7b973633e6cb@Blur> Date: Wed, 19 Dec 2012 16:46:52 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_1A5B5389.775E9643" X-Priority: 3 X-Mailer: Microsoft Office Outlook 12.0 X-Mailman-Approved-At: Thu, 20 Dec 2012 09:40:44 -0800 Subject: [AVTCORE] IV ECCOMAS Thematic Conference VipIMAGE 2013: FIRST ANNOUNCEMENT & CALL FOR CONTRIBUTIONS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tavares@fe.up.pt List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 16:57:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_1A5B5389.775E9643 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Colleague,=0D=0A =0D=0AWe are pleased to announce the Internation= al Conference VipIMAGE 2013 - IV ECCOMAS THEMATIC CONFERENCE = ON COMPUTATIONAL VISION AND MEDICAL IMAGE PROCESSING (www.fe.up.pt/~vi= pimage) to be held October 14-16, 2013, in Melia Madeira Mare = Hotel, Madeira Island, Funchal, Portugal.=0D=0A =0D=0A =0D=0APossible = Topics (not limited to)=0D=0A =0D=0A. Signal and Image Processing =0D=0A= =2E Computational Vision =0D=0A. Medical Imaging =0D=0A. Physics = of Medical Imaging =0D=0A. Tracking and Analysis of Movement =0D=0A. = Simulation and Modeling=0D=0A. Image Acquisition =0D=0A. Industrial = Applications =0D=0A. Shape Reconstruction =0D=0A. Objects Segmentation= , Matching, Simulation =0D=0A. Data Interpolation, Registration, = Acquisition and Compression =0D=0A. 3D Vision =0D=0A. Virtual = Reality =0D=0A. Visual Inspection =0D=0A. Software Development = for Image Processing and Analysis =0D=0A. Computer Aided Diagnosis, = Surgery, Therapy, and Treatment =0D=0A. Computational Bioimaging = and Visualization =0D=0A. Telemedicine Systems and their Applications=0D= =0A =0D=0AInvited Lecturers=0D=0A =0D=0A. Daniel Rueckert - = Imperial College London, UK=0D=0A. Dimitris N. Metaxas - Rutgers = University, USA=0D=0A. Durval C. Costa - Champalimaud Foundation, = Portugal=0D=0A. James S Duncan - Yale School of Medicine, USA=0D=0A. = Milan Sonka - The University of Iowa, USA=0D=0A. Richard Bowden = - University of Surrey, UK=0D=0A =0D=0AThematic Sessions=0D=0A =0D=0AP= roposals to organize Thematic Session under the auspicious of = VipIMAGE 2013 are welcome.=0D=0AThe organizers of the selected = thematic sessions will be included in the conference scientific = committee and will have a reduced registration fee. Additionally, = they will be responsible for the dissemination of their thematic = session, may invite expertise researchers to have invited keynotes = during their session and will participate in the review process = of the submitted contributions.=0D=0AProposal for Thematic Sessions = should be submitted by email to the conference co-chairs (tavares@fe.u= p.pt, rnatal@fe.up.pt) until March 1, 2013.=0D=0A =0D=0APublications=0D= =0A =0D=0AProceedings: The proceedings book will be published = by the Taylor & Francis Group (www.balkema.nl/instructions.asp) = and indexed by Thomson Reuters Conference Proceedings Citation = Index, IET Inspect and Elsevier Scopus.=0D=0ASpringer Book: = A book with 20 invited works from the ones presented in the = conference will be published by Springer under the book series = "Lecture Notes in Computational Vision and Biomechanics" (www.springer= =2Ecom/series/8910).=0D=0AJournal Publication: A dedicated special = issue of the Taylor & Francis International Journal "Computer = Methods in Biomechanics and Biomedical Engineering: Imaging = & Visualization" (www.tandfonline.com/tciv) will be published = with extended versions of the best works presented in the conference.=0D= =0A =0D=0AImportant dates=0D=0A =0D=0A. Deadline for Thematic = Session Proposals: March 1, 2013=0D=0A. Deadline for Extended = Abstracts: April 15, 2013=0D=0A. Authors Notification: May 1, = 2013=0D=0A. Deadline for Lectures and Papers: July 1, 2013=0D=0A =0D=0A= =0D=0AWe are looking forward to see you in Funchal next October.=0D=0A= =0D=0AKind regards,=0D=0A =0D=0AJo=E3o Manuel R. S. Tavares=0D=0ARena= to Natal Jorge=0D=0A(conference co-chairs)=0D=0A =0D=0APS. For = further details please have a look in the conference website = at: www.fe.up.pt/~vipimage, or the Facebook page at: www.facebook.com/= pages/Vipimage/237980719665456=0D=0A=0D=0A---------------------------=0D= =0ATO UNSUBSCRIBE FROM OUR LIST AND STOP RECEIVING EMAILS FROM = US, please send an email to tavares@fe.up.pt with REMOVE.=0D=0AThank = you. ------=_NextPart_000_0001_1A5B5389.775E9643 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A= =0D=0A= =0D=0A=0D=0A

= Dear Colleague,=0D=0A

 

=0D=0A

We are pleased to announce = the International Conference VipIMAGE 2013 - IV ECCOMAS THEMATIC CONFERENCE ON COMPUTATIONAL = VISION AND MEDICAL IMAGE PROCESSING (<= /SPAN>www.fe.up.pt= /~vipimage) to be held October 14-16, 2013, in Melia Madeira = Mare Hotel, Madeira Island, Funchal, Portugal.

=0D=0A

 

=0D=0A

 <= /o:p>

=0D=0A

Possible Topics = (not limited to)

=0D=0A

 <= /o:p>

=0D=0A

. = Signal and Image Processing

=0D=0A

. Computational Vision

=0D=0A

. Medical = Imaging

=0D=0A=

<= SPAN style=3D"mso-bookmark: OLE_LINK23">. = Physics of Medical Imaging

=0D=0A

. Tracking and Analysis of Movement

=0D=0A

. = Simulation and Modeling<= /SPAN>

=0D=0A

. Image Acquisition

=0D=0A

= . Industrial Applications =

=0D=0A

. = Shape Reconstruction

=0D=0A

. Objects Segmentation, Matching, Simulation =

=0D=0A

. = Data Interpolation, Registration, Acquisition and Compression =

=0D=0A

. = 3D Vision

=0D= =0A

. Virtual Reality =

=0D=0A

. Visual Inspection

=0D=0A

= . Software Development = for Image Processing and Analysis

=0D=0A

. Computer Aided Diagnosis, = Surgery, Therapy, and Treatment

=0D=0A

. Computational Bioimaging and Visualization =

=0D=0A

. = Telemedicine Systems and their Applications

=0D=0A

 

=0D=0A

Invited Lecturers

=0D=0A

 

=0D=0A=

<= SPAN style=3D"mso-bookmark: OLE_LINK23">. = Daniel Rueckert - Imperial College = London, UK=

=0D=0A

. Dimitris = N. Metaxas - Rutgers University, USA

=0D=0A

. Durval C. Costa - Champalimaud Foundation, = Portugal=0D=0A

. James S Duncan - = Yale School of Medicine, USA

=0D=0A

. Milan Sonka - The University of Iowa, USA

=0D=0A

. = Richard Bowden - University of = Surrey, UK=

=0D=0A

 =

=0D=0A

Thematic Sessions

=0D=0A

 <= /B>

=0D=0A

Proposals to organize Thematic Session under the auspicious = of VipIMAGE 2013 are welcome.

=0D=0A

The organizers of the = selected thematic sessions will be included in the conference = scientific committee and will have a reduced registration fee. = Additionally, they will be responsible for the dissemination = of their thematic session, may invite expertise researchers = to have invited keynotes during their session and will participate = in the review process of the submitted contributions.

=0D=0A

Proposal for Thematic Sessions should be submitted by email = to the conference co-chairs (tavares@fe.up.pt<= /SPAN>, rnatal@fe.up= =2Ept) until March 1, 2013.=

=0D=0A

 =

=0D=0A

Publications<= /SPAN>

=0D=0A

 

=0D=0A=

<= SPAN style=3D"mso-bookmark: OLE_LINK23">Proceedings: The proceedings book will be published by the = Taylor & Francis Group (= www.balkema.nl= /instructions.asp= ) and indexed by Thomson Reuters Conference = Proceedings Citation Index, IET Inspect and Elsevier Scopus.

=0D=0A

Springer Book: A book with 20 invited works from the ones = presented in the conference will be published by Springer under = the book series "Lecture Notes in Computational Vision and Biomechanic= s" (www.springer.com/series/8910<= /SPAN>).

=0D=0A

Journal Publication: A dedicated special issue of the Taylor = & Francis International Journal "Computer Methods in Biomechanics = and Biomedical Engineering: Imaging & Visualization" (www.tandfonl= ine.com/tciv= ) will be published with extended versions = of the best works presented in the conference.

=0D=0A

 

=0D=0A

Important dates

=0D=0A

 =

=0D=0A

. Deadline = for Thematic Session Proposals: March 1, 2013=

=0D=0A

. Deadline = for Extended Abstracts: April 15, 2013=

=0D=0A

. Authors Notification: = May 1, 2013

=0D= =0A

. Deadline for Lectures and Papers: July 1, 2013

=0D=0A

 <= /o:p>

=0D=0A

 <= /o:p>

=0D=0A

We = are looking forward to see you in Funchal next October.

=0D=0A

 <= /o:p>

= =0D=0A

Kind regards,=

=0D=0A

&nbs= p;

=0D=0A

Jo=E3o Manuel R. S. Tavares

=0D=0A

Renato Natal Jorge

=0D=0A

(conference co-chairs)

=0D=0A

 =

=0D=0A

PS. = For further details please have a look in the conference website = at: www.fe.up.pt/~vipimage, or the Facebook page = at: www.facebook.com/pages/Vipimage/237980719665456=

=0D=0A

=0D=0A

 

=0D=0A

= ---------------------------
TO UNSUBSCRIBE FROM OUR LIST = AND STOP RECEIVING EMAILS FROM US, please send an email to tavares@fe.up.pt with REMOVE.
= Thank you.

=0D=0A

------=_NextPart_000_0001_1A5B5389.775E9643-- From kevin.gross@avanw.com Thu Dec 20 17:14:51 2012 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 9C63121E8034 for ; Thu, 20 Dec 2012 17:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTt7atD5jqTL for ; Thu, 20 Dec 2012 17:14:50 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id C41D121E802E for ; Thu, 20 Dec 2012 17:14:50 -0800 (PST) Received: (qmail 14898 invoked by uid 0); 21 Dec 2012 01:14:29 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy11.bluehost.com with SMTP; 21 Dec 2012 01:14:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=wDUDaJePw+TjwdqRCzq/KEvhKWvYl6H78sQPwkv+XRI=; b=h16W6x1BGHiAFNyGkbLYuW9aaRukcigiMppPNFI7aJsajAxMtlRfqPsJr7dmjU2DIGPNH5bXidSrr+GWR4SpLV+P8qHbrMEwQTiozt1Vy+OgN4ayXWfBFe2lKNh0OvlI; Received: from [209.85.223.179] (port=38564 helo=mail-ie0-f179.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1TlrC1-0003LJ-Bd for avt@ietf.org; Thu, 20 Dec 2012 18:14:29 -0700 Received: by mail-ie0-f179.google.com with SMTP id k14so5512789iea.24 for ; Thu, 20 Dec 2012 17:14:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.151.241 with SMTP id ut17mr7013591igb.107.1356052468607; Thu, 20 Dec 2012 17:14:28 -0800 (PST) Received: by 10.50.151.135 with HTTP; Thu, 20 Dec 2012 17:14:28 -0800 (PST) In-Reply-To: <04b701cdcd32$e18c2750$a4a475f0$@gmail.com> References: <04b701cdcd32$e18c2750$a4a475f0$@gmail.com> Date: Thu, 20 Dec 2012 18:14:28 -0700 Message-ID: From: Kevin Gross To: Roni Even Content-Type: multipart/alternative; boundary=e89a8f3b9ea5b02c5804d15291bb X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.223.179 authed with kevin.gross@avanw.com} Cc: avt@ietf.org Subject: Re: [AVTCORE] confirmation of adoption of draft-terriberry-avp-codecs-00 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, 21 Dec 2012 01:14:51 -0000 --e89a8f3b9ea5b02c5804d15291bb Content-Type: text/plain; charset=ISO-8859-1 I support this housekeeping project. Kevin Gross On Tue, Nov 27, 2012 at 11:37 PM, Roni Even wrote: > WG,**** > > ** ** > > At the IETF 85th meeting's second AVTCORE session we took a hum for adopting Update to Recommended Codecs for the AVP RTP Profile**** > > (draft-terriberry-avp-codecs-00) as a WG item with the intention to update > RFC3551.**** > > ** ** > > I would like to confirm this call for adoption also on the WG mailing > list. So people that didn't provided input into this in the meeting please > provide your support or objections no later than December 10th.**** > > ** ** > > Thanks**** > > Roni**** > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > --e89a8f3b9ea5b02c5804d15291bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support this housekeeping project.

Kevin Gross=


On Tue, = Nov 27, 2012 at 11:37 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

WG,

=A0

At the IETF 85th meeting's second AVTCORE session we took a hum for =
adopting Update to Recommended Codecs for t=
he AVP RTP Profile

(draft-terriberry-avp-codecs-00) as a WG item with the intention to upd= ate =A0RFC3551.

=A0

I would like to= confirm this call for adoption also on the WG mailing list. So people that= didn't provided input into this in the meeting please provide your sup= port or objections no later than December 10th.

=A0

Thanks

Ron= i


_____________________________________________= __
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt


--e89a8f3b9ea5b02c5804d15291bb-- From abegen@cisco.com Sat Dec 29 13:49:06 2012 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 0A4A721F87B3 for ; Sat, 29 Dec 2012 13:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.43 X-Spam-Level: X-Spam-Status: No, score=-9.43 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-NT6FL3mprC for ; Sat, 29 Dec 2012 13:49:05 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5667A21F87B1 for ; Sat, 29 Dec 2012 13:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1704; q=dns/txt; s=iport; t=1356817745; x=1358027345; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CH12pNlP4qg5ihZxIsCpb/waToHyijR88BlobP2j0aQ=; b=j6QETRAnQreJg8GYDb2kCOrxD1ID43n39MTFWq2Z3w8pF1O7CiKPWq/e G6sd7YNVD7F5aK/yX+9fIORi+RloZZDRWIjNJpeyj0QqClAeXcOFlbdsp IgLwhm88xd/xL1arN5/aK2WEoQNAUc7OnkexD9xieQvda7Qk2GLhVh6L3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAFk31CtJV2c/2dsb2JhbABFgmyDTrY2dBZzgh4BAQEENEMCDAYBCBEDAQIFBiIEMBwBCAIEDgUIiAsBiz+abQaQWYEcizuDKjhhA6ZUgnSCJg X-IronPort-AV: E=Sophos;i="4.84,379,1355097600"; d="scan'208";a="157416881" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 29 Dec 2012 21:48:54 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBTLms53001796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Dec 2012 21:48:54 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Sat, 29 Dec 2012 15:48:54 -0600 From: "Ali C. Begen (abegen)" To: Kevin Gross Thread-Topic: [AVTCORE] FW: New Version Notification for draft-rescorla-avtcore-6222bis-00.txt Thread-Index: AQHNqbPzDESOY6uX60uCchMrTLBMoZe47vUAgCNpJYCAAB0HAIBUZM6A Date: Sat, 29 Dec 2012 21:48:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.245.254] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] FW: New Version Notification for draft-rescorla-avtcore-6222bis-00.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: Sat, 29 Dec 2012 21:49:06 -0000 S2V2aW4sDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiQWxpIEMuIEJlZ2Vu IiA8YWJlZ2VuQGNpc2NvLmNvbT4NCkRhdGU6IE1vbmRheSwgTm92ZW1iZXIgNSwgMjAxMiA3OjAy IFBNDQpUbzogS2V2aW4gR3Jvc3MgPGtldmluLmdyb3NzQGF2YW53LmNvbT4NCkNjOiAiYXZ0QGll dGYub3JnIiA8YXZ0QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBGVzogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvcg0KZHJhZnQtcmVzY29ybGEtYXZ0Y29yZS02MjIyYmlzLTAw LnR4dA0KDQo+PlNlY29uZCBidWxsZXQgcG9pbnQgaW4gc2VjdGlvbiA0LjIgSXRlbSAoYik6IFBy b3Bvc2VzIHRydW5jYXRpbmcgb3VyIG5pY2UNCj4+OTYtYml0IHJhbmRvbSBDTkFNRSB0byA0OCBi aXRzLiBJIHRoaW5rIHdlIGhhdmUgYW4gdW5hY2NlcHRhYmxlDQo+Pm9wcG9ydHVuaXR5IGZvciBk dXBsaWNhdGlvbiB3aXRoIHRoaXMgYXBwcm9hY2guIFRoaXMgQ05BTUUgc2hvdWxkDQo+PnByb2Jh Ymx5IHVzZSBSRkMgNDY0OCBpbiB3aGljaCBjYXNlIHRoZXNlIENOQU1Fcw0KPj50YWtlIHRoZSBz YW1lIGZvcm0gYXMgdGhlIHBlci1zZXNzaW9uIENOQU1FUyBidXQgZGlmZmVyIGluIHRoZQ0KPj5y ZXF1aXJlbWVudCB0byBjcmVhdGUgb25jZSBhdCBzb2Z0d2FyZSBpbml0aWFsaXphdGlvbi4gSXMg aXQgbmVjZXNzYXJ5DQo+PmZvciB0aGUgZGlmZmVyZW50IHR5cGVzIG9mIENOQU1FcyB0byBoYXZl IGRpZmZlcmVudCBhcHBlYXJhbmNlPw0KPg0KPkkgZG9uqfZ0IHRoaW5rIHRoZXJlIGlzIHN1Y2gg YSByZXF1aXJlbWVudCBhbmQgeW91ciBzdWdnZXN0aW9uIG1ha2VzIHNlbnNlLg0KDQpUaGlua2lu ZyBtb3JlIGFib3V0IHRoaXMsIEkgdGhpbmsgdGhlIGN1cnJlbnQgdGV4dCBpcyBnb29kLiBJdGVt IChhKSB1c2VzDQo0OC1iaXQgTUFDIGFkZHJlc3Nlcy4gU28sIGV2ZW4gaWYgd2UgdXNlIHRydW5j YXRpbmcgaW4gaXRlbSAoYiksIGl0cw0KY29sbGlzaW9uIHByb2JhYmlsaXR5IHdpbGwgbm90IGJl IGFueSB3b3JzZSB0aGFuIGl0ZW0gKGEpJ3MuIE5vdGUgdGhhdA0KYm90aCBpdGVtIChhKSBhbmQg KGIpIHVzZSAxNy1vY3RldCBzdHJpbmcgcmVwcmVzZW50YXRpb24gd2hlcmVhcyB0aGUNCnBlci1z ZXNzaW9uIENOQU1FIHVzZXMgMTYtb2N0ZXQgc3RyaW5nIHJlcHJlc2VudGF0aW9uLg0KDQpMZXQg bWUga25vdyBpZiB5b3UgdGhpbmsgb3RoZXJ3aXNlLg0KDQotYWNiZWdlbg0KDQo=