From Jerome.Lacan@isae.fr Wed Jan 5 00:04:26 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62BDB3A6A2C for ; Wed, 5 Jan 2011 00:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.326 X-Spam-Level: X-Spam-Status: No, score=-0.326 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+0ICouBFU9V for ; Wed, 5 Jan 2011 00:04:24 -0800 (PST) Received: from smtpext.isae.fr (smtpext.isae.fr [193.54.120.4]) by core3.amsl.com (Postfix) with SMTP id 5500F3A6B83 for ; Wed, 5 Jan 2011 00:04:24 -0800 (PST) Received: from catalpa (unknown [10.4.1.11]) by smtpext.isae.fr (Postfix) with SMTP id AB2FE22E2AA for ; Wed, 5 Jan 2011 09:06:27 +0100 (CET) Received: from smtp-secu (smtp-secu.isae.fr [193.54.120.15]) by catalpa (Postfix) with SMTP id 2C1BEB7D7B for ; Wed, 5 Jan 2011 09:06:30 +0100 (CET) Received: from jeromelacanPC (unknown [10.33.1.87]) by smtp-secu (Postfix) with ESMTP id 1A3383FF38 for ; Wed, 5 Jan 2011 09:06:30 +0100 (CET) From: =?iso-8859-1?Q?J=E9r=F4me_Lacan?= To: Date: Wed, 5 Jan 2011 09:06:35 +0100 Message-ID: <01ed01cbacaf$79038840$6b0a98c0$@lacan@isae.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acusr3jLRaPi/KL5TDWlVRQX5UFo2g== Content-Language: fr Subject: Re: [Fecframe] Adopt ? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 08:04:26 -0000 Hello, As a co-author of the draft draft-roca-fecframe-ldpc-01 and researcher in the domain of coding theory, I fully support the adoption of this draft by the FECFRAME WG. Indeed, even though a huge quantity of different LDPC codes were proposed for the erasure channel in the coding community, the ldpc-staircase presented in this draft are the only one to have the sufficient maturity to be adopted by FECFRAME. Since their first presentation in June 2005 at the RMT WG and their adoption as RFC 5170 in 2008, both academics and industrials has evaluated them and validated the excellent performance in terms of correction capability and processing speed with the proposed implementations. For these reasons, these codes appear to be a excellent complement of the Raptor and (probably) the Reed-Solomon in the set of codes adapted by the FECFRAME WG. Regards, Jerome Lacan Professor, ISAE/LAAS-CNRS, Toulouse, France > Date: Tue, 21 Dec 2010 17:05:56 +0100 > From: Vincent Roca > Subject: Re: [Fecframe] Adopt? > To: fecframe@ietf.org > > Hello Greg, David and everybody, > > Yes, let us follow the charter since this latter is explicit on how to > proceed. > > 1/ Concerning the two Reed-Solomon I-Ds, there are so many use-cases > relying on those codes, including for the "erasure channel", both for > real-time and non real-time flow protection, that it does *not* make > sense to solicit any external review. > Additionally they are used in the most simplest manner in the proposed > schemes IMHO. Tell me if you disagree... > > > 2/ Concerning our LDPC-Staircase I-D, the situation is different, so > let's apply the rules. Two elements: > > - LDPC-Staircase codes are already well known by the IETF > community, they are not brand new codes. See RFC 5170. > > - their applicability to certain FECFRAME use-cases has been > studied, and the results published. See: > > K. Matsuzono, J. Detchart, M. Cunche, V. Roca, H. Asaeda, > "Performance Analysis of a High-Performance Real-Time > Application with Several AL-FEC Schemes", > 35th Annual IEEE Conference on Local Computer Networks > 2010 (LCN 2010), October 2010. > > http://planete.inrialpes.fr/people/roca/doc/lcn10_dvts_fecframe_2010ju > l > 25_hal.pdf > > This is the paper that I quickly introduced at Beijing during > the meeting. > > Anyway I'll solicit external opinions as you suggested. > Regards, > > Vincent > > -- > Vincent Roca, INRIA research institute, France > http://planete.inrialpes.fr/people/roca/ > > > On 11/12/10 08:06, Greg Shepherd wrote: > > Yes, you are just being a pain in the butt. Adoption as a working > group item is not the same acceptance. > > > > Greg > > > > Sent from my iPhone > > > > On Dec 11, 2010, at 8:30, "David Harrington" > wrote: > > > >> Hi, > >> > >> Not to be a pain in the butt, but to be a pain in the butt ... ;-) > >> > >> Your charter is explicit: > >> "the acceptance of any FEC scheme will require multiple, prior, > >> detailed reviews of the FEC code by independent experts from both > >> the IETF > and > >> the broader community, since it is likely that the IETF working > group > >> will not include a large enough number of suitable experts in its > >> working set. If these reviews are positive, then Working Group > >> acceptance of an FEC scheme work item still needs the approval of > the > >> responsible Area Director." > >> > >> We need more than just approval/disapproval from the WG > participants. > >> We need multiple, prior, detailed reviews of the FEC code by > >> independent experts from both the IETF and the broader community. > >> > >> Please provide detailed reviews of the FEC code, and solicit > detailed > >> reviews from others in the broader community. Then we can talk > >> about adopting new WG drafts. > >> > >> David Harrington > >> Director, IETF Transport Area > >> ietfdbh@comcast.net (preferred for ietf) > >> dbharrington@huaweisymantec.com > >> +1 603 828 1401 (cell) > >> > >>> -----Original Message----- > >>> From: fecframe-bounces@ietf.org > >>> [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd > >>> Sent: Thursday, December 09, 2010 12:50 PM > >>> To: fecframe@ietf.org > >>> Subject: [Fecframe] Adopt? > >>> > >>> *, > >>> > >>> As per the discussion at the last WG meeting, can you each respond > >>> with your comments (approval/ disapproval) for the group to adopt > >> the > >>> following drafts: > >>> > >>> - draft-roca-fecframe-simple-rs-01 > >>> - draft-galanos-fecframe-rtp-reedsolomon-02 > >>> - draft-roca-fecframe-ldpc-01 > >>> > >>> Thanks, > >>> Greg > >>> _______________________________________________ > >>> Fecframe mailing list > >>> Fecframe@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fecframe > > > ------------------------------ > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > > End of Fecframe Digest, Vol 59, Issue 21 > **************************************** From gjshep@gmail.com Wed Jan 5 04:40:53 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8F963A6CAA for ; Wed, 5 Jan 2011 04:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.328 X-Spam-Level: X-Spam-Status: No, score=-103.328 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b2tqyFlBkdp for ; Wed, 5 Jan 2011 04:40:53 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id D0F663A6B92 for ; Wed, 5 Jan 2011 04:40:52 -0800 (PST) Received: by bwz12 with SMTP id 12so15300829bwz.31 for ; Wed, 05 Jan 2011 04:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type; bh=6J2ArLC8ICOZ5GJPkcZNw6q05BEM6FRMhgrrAjsbXMk=; b=Nghm1UX4EApfO7ifzZq/qwHAdoRtY3JRKUJnmaDbsgvcLQ8ljRFOrPeVPiQK4Pd5zo lvIY5yx0MP4PGuYyQZbJZjMf6khwzmTaAQunLaqTVijtMTj+8z8mqwBhjUi/Aqtxrgda qlNnp9zYFXQbIJ14kEUCJ2XXUcfJSz/jQwNq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=sOvu4eUHpEEFsyeqEm2DOwCmNJOTErsb1Dck6ySrDALzGlH9ZgNqs5/Zx7Tobkjd3M fAzZu1ugN/Tl9WDc1rI0ykzXcyqjA6VUhOMdsLk2beBNPvosRfZg4nwz21nX6K/9QgVn v7+fy01sWuoedxNxIqVUzAfsRfe4kJg34DaKU= MIME-Version: 1.0 Received: by 10.204.33.74 with SMTP id g10mr4521400bkd.131.1294231378969; Wed, 05 Jan 2011 04:42:58 -0800 (PST) Received: by 10.204.80.6 with HTTP; Wed, 5 Jan 2011 04:42:58 -0800 (PST) In-Reply-To: References: Date: Wed, 5 Jan 2011 04:42:58 -0800 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Fecframe] Adopt? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 12:40:53 -0000 Thanks to all of you who responded. With overall approval the FECFrame WG will adopt these three drafts as Working Group documents. Cheers, Greg On Thu, Dec 9, 2010 at 9:50 AM, Greg Shepherd wrote: > *, > > As per the discussion at the last WG meeting, can you each respond > with your comments (approval/ disapproval) for the group to adopt the > following drafts: > > - draft-roca-fecframe-simple-rs-01 > - draft-galanos-fecframe-rtp-reedsolomon-02 > - draft-roca-fecframe-ldpc-01 > > Thanks, > Greg > From gjshep@gmail.com Mon Jan 10 10:20:08 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E283A6B12 for ; Mon, 10 Jan 2011 10:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.347 X-Spam-Level: X-Spam-Status: No, score=-103.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk4Oqo9m3vM4 for ; Mon, 10 Jan 2011 10:20:07 -0800 (PST) Received: from mail-bw0-f66.google.com (mail-bw0-f66.google.com [209.85.214.66]) by core3.amsl.com (Postfix) with ESMTP id BE06C3A69CB for ; Mon, 10 Jan 2011 10:20:06 -0800 (PST) Received: by bwz7 with SMTP id 7so7253490bwz.1 for ; Mon, 10 Jan 2011 10:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=k57wyqC4i9jfU5oA1SOB5tKNxg5CCcGhXF7YE03JKhs=; b=UlFl8wpcfFDAQY1xzPQOQ+QL3ecgNIJdqf9kvL0Kx68qNOBPbYbCE6Ghy1T7gv74OY zWNAazZwyXD2ttI0cMszORoZLKGPJRtezvvOF6onJfxnC3N49++WKJ0LFstn5qP5bqql xDFQLErS+oUVsXUWHYq0MXsfzS/qePhTm/qO0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=f4hFDLzUQrxyoFyB3P9cCy8jJd03TpS20Exs9m8C9+MORD9jjiRQWHhOYiejHvgWag xEgysVBb89TkFLEPZ/1gHQ08Gpq4pfm2tHMQGC/vODVXlaNAYW+lho2kZ14oyvrsTe3J yyjU/3E7QWHOPNLoCcHvvl4RrWziDoIslQlTw= MIME-Version: 1.0 Received: by 10.204.51.65 with SMTP id c1mr20905396bkg.185.1294683738396; Mon, 10 Jan 2011 10:22:18 -0800 (PST) Received: by 10.204.80.6 with HTTP; Mon, 10 Jan 2011 10:22:17 -0800 (PST) In-Reply-To: <4D089F54.7000304@inrialpes.fr> References: <4D089F54.7000304@inrialpes.fr> Date: Mon, 10 Jan 2011 10:22:17 -0800 Message-ID: From: Greg Shepherd To: Vincent Roca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Proposed changes to the framework draft - part 2(security) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 18:20:09 -0000 I believe the concerns David had are well addressed here in this thread. If we can all agree on the new security section then let's get the edits made and the document updated and shipped. Thanks, Greg On Wed, Dec 15, 2010 at 2:58 AM, Vincent Roca w= rote: > Mike and everybody, > > I think we now agree, it's more a matter presenting things correctly. So > let's try once again (sorry for this long email). There are several > dimensions > to consider and this is probably what makes the discussion complex: > > Dimension 1, the way FECFRAME is used: > U1- FECFRAME is used end-to-end, and is included in the final end-device > U2- FECFRAME is used in middle-boxes, e.g. to protect several source flow= s > globally, > =A0 coming from several content servers, and destinated to the same remot= e > middle box. > > Dimension 2, the threat model: > T1- threats on the end device when FECFRAME is run on the end-device (cas= e > U1 above): > =A0 the attacker is either the end-user (who may want to access protected > content) or > =A0 somebody else. In all cases the attacker has access to the end device= , but > not > =A0 necessarily a full control of the end-device since a secure domain ca= n > exist. > T2- threats on the FECFRAME middle-box when FECFRAME is run on a differen= t > server > =A0 (case U2 above). An attacker has access to this box. > T3- threats during the end-to-end transport (e.g. Internet). The attacker > can do > =A0 =A0many different things on the FEC source and repair packets (e.g. d= elay, > drop, > =A0 =A0add forged packets, replay). > > Dimension 3, the desired security features W.R.T. the use of FECFRAME: > F1- content integrity / source authentication > F2- content confidentiality > F3- DoS mitigation > F4- anti-replay protection > > Dimension 4, the security tools: > S1- the various DRM systems, defined out of the context of IETF, some of > them > =A0 =A0being proprietary and/or subject to IPRs. > S2- SRTP (and SRTCP). > S3- IPsec/ESP. > > > We agree we only need to focus on topics related to the use of FECFRAME. > Here is a list of such topics: > > **Topic 1** Should encryption be applied after or before FEC protection? > Proposed text already discusses this, depending on the way FECFRAME is > used (U1 or U2) and threat model (T1, T2, T3). It is often preferable > to encrypt first, then do FEC processing. > > (NB: the proposed text should be sufficient) > > > **Topic 2** Is SRTP a solution and how should SRTP be used along with > FECFRAME? > This is a solution in some situations, but FECFRAME impacts the way it > is used: > - When SRTP is used to encrypt the content, we have the same discussion > =A0as Topic 1- above. > - When SRTP is used only to provide authentication/integrity, we can > =A0probably use SRTP either above FECFRAME, or below FECFRAME. Using it > =A0below FECFRAME, on both FEC Source packets and FEC Repair packets has > =A0the advantage of fulfilling the desired features F1 and F3 (fake > =A0FEC source/repair packets are filtered). > =A0BUT this requires (1) we deal with RTP source flows, and (2) FEC Sourc= e > =A0and Repair packets are RTP packets. There are therefore restrictions. > > (NB: we need to update the current I-D to add this discussion too) > > > **Topic 3** Is IPsec a solution and how should it be used along with > FECFRAME? > Being applied below FECFRAME it secures the whole traffic (FEC Source and > Repair traffic). With the threat model T3 (end2end transport), it's > appropriate > and provides the desirable features F1 F3 F4 (that are FECFRAME related) > along > with F2 (but this is independent of FECFRAME). > It can therefore be a "mandatory to implement" security solution IMHO. > The potential issue I see is that it may seem too much of a burden to > require > mobile terminals to include IPsec, even if not used. > > (NB: we need to improve the current I-D) > > > **Topic 4** What about attacks on the FECFRAME component itself (T1 and T= 2)? > This is what Mike means if I understand correctly by: > =A0 =A0 =A0 "BTW, a third axis is the security in the servers that are ad= ding > =A0 =A0 =A0 =A0FECFRAME formatting to the outgoing packets, and perhaps t= his should > =A0 =A0 =A0 =A0be addressed as well (e.g., the process of adding FEC repa= ir packets > =A0 =A0 =A0 =A0to the stream might be vulnerable to an attack, and thus i= t is better > =A0 =A0 =A0 =A0if this process doesn't have access to the plaintext conte= nt, etc.)" > If F2 is required, it's clear that encryption must have occurred before, > while > data was still in the secure domain. In fact I don't know if we can do > anything > else in this case. > > > **Topic 5** What about attacks on the session description? > David said: > =A0"I don't see a mandatory to implement protocol for protecting the > =A0 session description." > The FECFRAME session description generates new opportunities for attacks, > it's obvious. But I don't see how we can mandate a security solution for > something that is sent OOB, using a mechanism that is not defined by our > I-D. If SDP is used, then it's preferable to refer to SDP's Security > Consideration sections (even if this latter fails to mandate a security > solution!). > > (NB: we need to improve the current I-D) > > > Is there anything else? Feel free to suggest new topics if needed or > correct me if I made mistakes. > > Regards, > > =A0Vincent > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From abegen@cisco.com Mon Jan 10 11:33:39 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7C2328C10D for ; Mon, 10 Jan 2011 11:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5EjraA7tBCP for ; Mon, 10 Jan 2011 11:33:37 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8457828C0EF for ; Mon, 10 Jan 2011 11:33:37 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4HAPftKk2rR7Hu/2dsb2JhbACECJ9qVQJzoxCKU41khFh0BIsKgyaCcA Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 10 Jan 2011 19:35:51 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p0AJZoqN023582; Mon, 10 Jan 2011 19:35:51 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 Jan 2011 11:35:51 -0800 Received: from 72.163.62.137 ([72.163.62.137]) by xmb-sjc-215.amer.cisco.com ([171.70.151.169]) with Microsoft Exchange Server HTTP-DAV ; Mon, 10 Jan 2011 19:35:50 +0000 References: <4D089F54.7000304@inrialpes.fr> Content-Transfer-Encoding: 7bit From: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary="Apple-Mail-22-700844710"; charset="iso-8859-1" Thread-Topic: [Fecframe] Proposed changes to the framework draft - part2(security) Thread-Index: Acuw/ZYicYoCtaR8SheCqbcpAFDDhA== In-Reply-To: Message-ID: Date: Mon, 10 Jan 2011 20:35:38 +0100 To: MIME-Version: 1.0 (iPhone Mail 8C148) X-OriginalArrivalTime: 10 Jan 2011 19:35:51.0583 (UTC) FILETIME=[96F1BAF0:01CBB0FD] Cc: fecframe@ietf.org Subject: Re: [Fecframe] Proposed changes to the framework draft - part2(security) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:33:39 -0000 --Apple-Mail-22-700844710 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes the discusses around the sec issues should be resolved with the revision= but I am still expecting to hear from the AD about the other discuss relate= d to the ops and management. He is yet to respond to the responses made to h= is email about the proposed text.=20 I certainly hope the framework draft can be done before the next meeting.=20= -acbegen On Jan 10, 2011, at 7:22 PM, "Greg Shepherd" wrote: > I believe the concerns David had are well addressed here in this > thread. If we can all agree on the new security section then let's get > the edits made and the document updated and shipped. >=20 > Thanks, > Greg >=20 > On Wed, Dec 15, 2010 at 2:58 AM, Vincent Roca w= rote: > > Mike and everybody, > > > > I think we now agree, it's more a matter presenting things correctly. So= > > let's try once again (sorry for this long email). There are several > > dimensions > > to consider and this is probably what makes the discussion complex: > > > > Dimension 1, the way FECFRAME is used: > > U1- FECFRAME is used end-to-end, and is included in the final end-device= > > U2- FECFRAME is used in middle-boxes, e.g. to protect several source flo= ws > > globally, > > coming from several content servers, and destinated to the same remote= > > middle box. > > > > Dimension 2, the threat model: > > T1- threats on the end device when FECFRAME is run on the end-device (ca= se > > U1 above): > > the attacker is either the end-user (who may want to access protected > > content) or > > somebody else. In all cases the attacker has access to the end device,= but > > not > > necessarily a full control of the end-device since a secure domain can= > > exist. > > T2- threats on the FECFRAME middle-box when FECFRAME is run on a differe= nt > > server > > (case U2 above). An attacker has access to this box. > > T3- threats during the end-to-end transport (e.g. Internet). The attacke= r > > can do > > many different things on the FEC source and repair packets (e.g. dela= y, > > drop, > > add forged packets, replay). > > > > Dimension 3, the desired security features W.R.T. the use of FECFRAME: > > F1- content integrity / source authentication > > F2- content confidentiality > > F3- DoS mitigation > > F4- anti-replay protection > > > > Dimension 4, the security tools: > > S1- the various DRM systems, defined out of the context of IETF, some of= > > them > > being proprietary and/or subject to IPRs. > > S2- SRTP (and SRTCP). > > S3- IPsec/ESP. > > > > > > We agree we only need to focus on topics related to the use of FECFRAME.= > > Here is a list of such topics: > > > > **Topic 1** Should encryption be applied after or before FEC protection?= > > Proposed text already discusses this, depending on the way FECFRAME is > > used (U1 or U2) and threat model (T1, T2, T3). It is often preferable > > to encrypt first, then do FEC processing. > > > > (NB: the proposed text should be sufficient) > > > > > > **Topic 2** Is SRTP a solution and how should SRTP be used along with > > FECFRAME? > > This is a solution in some situations, but FECFRAME impacts the way it > > is used: > > - When SRTP is used to encrypt the content, we have the same discussion > > as Topic 1- above. > > - When SRTP is used only to provide authentication/integrity, we can > > probably use SRTP either above FECFRAME, or below FECFRAME. Using it > > below FECFRAME, on both FEC Source packets and FEC Repair packets has > > the advantage of fulfilling the desired features F1 and F3 (fake > > FEC source/repair packets are filtered). > > BUT this requires (1) we deal with RTP source flows, and (2) FEC Source= > > and Repair packets are RTP packets. There are therefore restrictions. > > > > (NB: we need to update the current I-D to add this discussion too) > > > > > > **Topic 3** Is IPsec a solution and how should it be used along with > > FECFRAME? > > Being applied below FECFRAME it secures the whole traffic (FEC Source an= d > > Repair traffic). With the threat model T3 (end2end transport), it's > > appropriate > > and provides the desirable features F1 F3 F4 (that are FECFRAME related)= > > along > > with F2 (but this is independent of FECFRAME). > > It can therefore be a "mandatory to implement" security solution IMHO. > > The potential issue I see is that it may seem too much of a burden to > > require > > mobile terminals to include IPsec, even if not used. > > > > (NB: we need to improve the current I-D) > > > > > > **Topic 4** What about attacks on the FECFRAME component itself (T1 and T= 2)? > > This is what Mike means if I understand correctly by: > > "BTW, a third axis is the security in the servers that are adding > > FECFRAME formatting to the outgoing packets, and perhaps this sho= uld > > be addressed as well (e.g., the process of adding FEC repair pack= ets > > to the stream might be vulnerable to an attack, and thus it is be= tter > > if this process doesn't have access to the plaintext content, etc= .)" > > If F2 is required, it's clear that encryption must have occurred before,= > > while > > data was still in the secure domain. In fact I don't know if we can do > > anything > > else in this case. > > > > > > **Topic 5** What about attacks on the session description? > > David said: > > "I don't see a mandatory to implement protocol for protecting the > > session description." > > The FECFRAME session description generates new opportunities for attacks= , > > it's obvious. But I don't see how we can mandate a security solution for= > > something that is sent OOB, using a mechanism that is not defined by our= > > I-D. If SDP is used, then it's preferable to refer to SDP's Security > > Consideration sections (even if this latter fails to mandate a security > > solution!). > > > > (NB: we need to improve the current I-D) > > > > > > Is there anything else? Feel free to suggest new topics if needed or > > correct me if I made mistakes. > > > > Regards, > > > > Vincent > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --Apple-Mail-22-700844710 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Yes the discusses around the sec issues should be resolved with the revision but I am still expecting to hear from the AD about the other discuss related to the ops and management. He is yet to respond to the responses made to his email about the proposed text. 

I certainly hope the framework draft can be done before the next meeting. 

-acbegen

On Jan 10, 2011, at 7:22 PM, "Greg Shepherd" <gjshep@gmail.com> wrote:

I believe the concerns David had are well addressed here in this
thread. If we can all agree on the new security section then let's get
the edits made and the document updated and shipped.

Thanks,
Greg

On Wed, Dec 15, 2010 at 2:58 AM, Vincent Roca <vincent.roca@inrialpes.fr> wrote:
> Mike and everybody,
>
> I think we now agree, it's more a matter presenting things correctly. So
> let's try once again (sorry for this long email). There are several
> dimensions
> to consider and this is probably what makes the discussion complex:
>
> Dimension 1, the way FECFRAME is used:
> U1- FECFRAME is used end-to-end, and is included in the final end-device
> U2- FECFRAME is used in middle-boxes, e.g. to protect several source flows
> globally,
>   coming from several content servers, and destinated to the same remote
> middle box.
>
> Dimension 2, the threat model:
> T1- threats on the end device when FECFRAME is run on the end-device (case
> U1 above):
>   the attacker is either the end-user (who may want to access protected
> content) or
>   somebody else. In all cases the attacker has access to the end device, but
> not
>   necessarily a full control of the end-device since a secure domain can
> exist.
> T2- threats on the FECFRAME middle-box when FECFRAME is run on a different
> server
>   (case U2 above). An attacker has access to this box.
> T3- threats during the end-to-end transport (e.g. Internet). The attacker
> can do
>    many different things on the FEC source and repair packets (e.g. delay,
> drop,
>    add forged packets, replay).
>
> Dimension 3, the desired security features W.R.T. the use of FECFRAME:
> F1- content integrity / source authentication
> F2- content confidentiality
> F3- DoS mitigation
> F4- anti-replay protection
>
> Dimension 4, the security tools:
> S1- the various DRM systems, defined out of the context of IETF, some of
> them
>    being proprietary and/or subject to IPRs.
> S2- SRTP (and SRTCP).
> S3- IPsec/ESP.
>
>
> We agree we only need to focus on topics related to the use of FECFRAME.
> Here is a list of such topics:
>
> **Topic 1** Should encryption be applied after or before FEC protection?
> Proposed text already discusses this, depending on the way FECFRAME is
> used (U1 or U2) and threat model (T1, T2, T3). It is often preferable
> to encrypt first, then do FEC processing.
>
> (NB: the proposed text should be sufficient)
>
>
> **Topic 2** Is SRTP a solution and how should SRTP be used along with
> FECFRAME?
> This is a solution in some situations, but FECFRAME impacts the way it
> is used:
> - When SRTP is used to encrypt the content, we have the same discussion
>  as Topic 1- above.
> - When SRTP is used only to provide authentication/integrity, we can
>  probably use SRTP either above FECFRAME, or below FECFRAME. Using it
>  below FECFRAME, on both FEC Source packets and FEC Repair packets has
>  the advantage of fulfilling the desired features F1 and F3 (fake
>  FEC source/repair packets are filtered).
>  BUT this requires (1) we deal with RTP source flows, and (2) FEC Source
>  and Repair packets are RTP packets. There are therefore restrictions.
>
> (NB: we need to update the current I-D to add this discussion too)
>
>
> **Topic 3** Is IPsec a solution and how should it be used along with
> FECFRAME?
> Being applied below FECFRAME it secures the whole traffic (FEC Source and
> Repair traffic). With the threat model T3 (end2end transport), it's
> appropriate
> and provides the desirable features F1 F3 F4 (that are FECFRAME related)
> along
> with F2 (but this is independent of FECFRAME).
> It can therefore be a "mandatory to implement" security solution IMHO.
> The potential issue I see is that it may seem too much of a burden to
> require
> mobile terminals to include IPsec, even if not used.
>
> (NB: we need to improve the current I-D)
>
>
> **Topic 4** What about attacks on the FECFRAME component itself (T1 and T2)?
> This is what Mike means if I understand correctly by:
>       "BTW, a third axis is the security in the servers that are adding
>        FECFRAME formatting to the outgoing packets, and perhaps this should
>        be addressed as well (e.g., the process of adding FEC repair packets
>        to the stream might be vulnerable to an attack, and thus it is better
>        if this process doesn't have access to the plaintext content, etc.)"
> If F2 is required, it's clear that encryption must have occurred before,
> while
> data was still in the secure domain. In fact I don't know if we can do
> anything
> else in this case.
>
>
> **Topic 5** What about attacks on the session description?
> David said:
>  "I don't see a mandatory to implement protocol for protecting the
>   session description."
> The FECFRAME session description generates new opportunities for attacks,
> it's obvious. But I don't see how we can mandate a security solution for
> something that is sent OOB, using a mechanism that is not defined by our
> I-D. If SDP is used, then it's preferable to refer to SDP's Security
> Consideration sections (even if this latter fails to mandate a security
> solution!).
>
> (NB: we need to improve the current I-D)
>
>
> Is there anything else? Feel free to suggest new topics if needed or
> correct me if I made mistakes.
>
> Regards,
>
>  Vincent
>
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe
>
_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecframe

--Apple-Mail-22-700844710-- From Internet-Drafts@ietf.org Tue Jan 11 12:30:03 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642BA28C2F3; Tue, 11 Jan 2011 12:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4vrpxeIZ1bO; Tue, 11 Jan 2011 12:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C957D28C2CD; Tue, 11 Jan 2011 12:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111203001.28682.22931.idtracker@localhost> Date: Tue, 11 Jan 2011 12:30:01 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-config-signaling-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 20:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Methods to convey FEC Framework Configuration Information Author(s) : R. Asati Filename : draft-ietf-fecframe-config-signaling-04.txt Pages : 17 Date : 2011-01-11 FEC Framework document [FECARCH] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes how to use existing signaling protocols to determine and dynamically communicate the Configuration information between sender(s) and receiver(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-config-signaling-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-config-signaling-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11121651.I-D@ietf.org> --NextPart-- From vincent.roca@inrialpes.fr Tue Jan 11 23:41:39 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD9BD3A6B08 for ; Tue, 11 Jan 2011 23:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OHSD6rkg81P for ; Tue, 11 Jan 2011 23:41:32 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 518403A6B02 for ; Tue, 11 Jan 2011 23:41:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,312,1291590000"; d="scan'208,217";a="84867607" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 12 Jan 2011 08:43:47 +0100 Message-ID: <4D2D5BB3.8030507@inrialpes.fr> Date: Wed, 12 Jan 2011 08:43:47 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: fecframe@ietf.org References: <4E3DAC27-ED71-4B28-BDEA-4F241242C842@gmail.com> <4D10D064.7090004@inrialpes.fr> In-Reply-To: <4D10D064.7090004@inrialpes.fr> Content-Type: multipart/alternative; boundary="------------010801080404060904080601" Cc: SAVIN Valentin 209363 Subject: Re: [Fecframe] Adopt? X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 07:41:39 -0000 This is a multi-part message in MIME format. --------------010801080404060904080601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hello Everybody, Even if the draft-roca-fecframe-ldpc-01 draft has already been accepted, please find below another opinion why these codes make sense in the context of FECFRAME. Thank you, Valentin! Cheers, Vincent NB: Valentin has many theoretical and practical contributions on FEC codes in general, and binary or non binary LDPC codes in particular, including for the erasure channel use-cases. -------- Message original -------- Sujet: LDPC-staircase FEC scheme for FECFRAME - review Date : Mon, 10 Jan 2011 15:19:30 +0100 De : SAVIN Valentin 209363 Pour : Vincent Roca Hello Vincent, Can you please forward to the FECFRAME list the text below that explains why I strongly support the LDPC-Staircase AL-FEC scheme proposal. Thanks! ---------------------------------------------------------------- /The following review refers to the LDPC-staircase FEC scheme for FECFRAME, proposed in the [draft-roca-fecframe-ldpc-01] document/. In the context of content distribution applications, Low Density Parity Check (LDPC) codes constitute a very broad class of FEC codes, distinguished by the fact that they are defined by sparse parity-check matrices, and can be iteratively decoded in linear time with respect to their block-length. Since their invention in early 60's by Gallager, a large body of knowledge has been acquired (analysis, optimization, construction); LDPC codes are known to be capacity approaching codes for a large class of channels, and became synonymous with modern coding. The LDPC-staircase codes proposed in the abovementioned draft belong to the broad class of LDPC codes. They are defined by parity-check matrices verifying the two following properties: (1) the columns corresponding to source symbols are of constant weight, specified by the parameter N1, and (2) the columns corresponding to repair symbols form a "staircase" (double-diagonal) matrix. These codes can thereby be fully specified in a very simple way and their encoder and decoder allow very simple implementations. Indeed, as for the encoder, each new repair symbol is immediately generated as the sum (bitwise xor) of the previous repair symbol and some of the source symbols. The decoder can implement either the iterative (IT) decoding, which consists of a simple technique of solving a linear system by iteratively searching for equations with only one single unknown variable left, or the Maximum-Likelihood (ML) decoding, which relies on the more complex Gaussian elimination method. The N1 parameter allows for fine-tuning the FEC scheme with respect to the decoding performance, measured in terms of inefficiency or overhead, and complexity, measured in terms of throughput. Very high throughputs (e.g. several Gbps) can be reached by using the IT decoding, which achieves good performance (low overheads) for small values of N1 (generally 3, 4). To improve the decoding performance, one can trade IT for ML decoding. For instance, LDPC-staircase codes with N1 = 5 or 7 have almost ideal performance under the ML decoding (overhead < 1%), at the expense of lower throughput (which however remains above 1 Gbps most of the time). Moreover, the performance of the ML decoding can be further improved by increasing the N1 parameter above 7 if needed. The usability, combined with reliable performance, make LDPC-staircase highly attractive for practical FEC schemes for the erasure channel. I therefore strongly recommend them for adoption by the FECFRAME working group. Dr. Valentin Savin CEA-LETI, MINATEC Information Theory Specialist ---------------------------------------------------------------- **/Dr. Valentin Savin/** //CEA-LETI, MINATEC// //DSIS/LCS - Communications sans fil et Sécurité// //17, rue des Martyrs,38054 Grenoble, FRANCE// //Bât BOC(51C), Pièce C452// //Tél. +33.(0)4.38.78.07.11// //Fax. +33.(0)4.38.78.65.86// //http://www-leti.cea.fr//, //http://www.minatec.com// --------------010801080404060904080601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Everybody,

Even if the draft-roca-fecframe-ldpc-01 draft has already been accepted, please
find below another opinion why these codes make sense in the context of FECFRAME.
Thank you, Valentin!

Cheers,

   Vincent


NB: Valentin has many theoretical and practical contributions on FEC codes
in general, and binary or non binary LDPC codes in particular, including for the
erasure channel use-cases.


-------- Message original --------
Sujet: LDPC-staircase FEC scheme for FECFRAME - review
Date : Mon, 10 Jan 2011 15:19:30 +0100
De : SAVIN Valentin 209363 <valentin.savin@cea.fr>
Pour : Vincent Roca <vincent.roca@inrialpes.fr>


Hello Vincent,

Can you please forward to the FECFRAME list the text below that explains why I strongly support the LDPC-Staircase AL-FEC scheme proposal.
Thanks!
----------------------------------------------------------------
 
The following review refers to the LDPC-staircase FEC scheme for FECFRAME, proposed in the [draft-roca-fecframe-ldpc-01] document.
 
In the context of content distribution applications, Low Density Parity Check (LDPC) codes constitute a very broad class of FEC codes, distinguished by the fact that they are defined by sparse parity-check matrices, and can be iteratively decoded in linear time with respect to their block-length. Since their invention in early 60’s by Gallager, a large body of knowledge has been acquired (analysis, optimization, construction); LDPC codes are known to be capacity approaching codes for a large class of channels, and became synonymous with modern coding.
 
The LDPC-staircase codes proposed in the abovementioned draft belong to the broad class of LDPC codes. They are defined by parity-check matrices verifying the two following properties: (1) the columns corresponding to source symbols are of constant weight, specified by the parameter N1, and (2) the columns corresponding to repair symbols form a “staircase” (double-diagonal) matrix. These codes can thereby be fully specified in a very simple way and their encoder and decoder allow very simple implementations.
Indeed, as for the encoder, each new repair symbol is immediately generated as the sum (bitwise xor) of the previous repair symbol and some of the source symbols. The decoder can implement either the iterative (IT) decoding, which consists of a simple technique of solving a linear system by iteratively searching for equations with only one single unknown variable left, or the Maximum-Likelihood (ML) decoding, which relies on the more complex Gaussian elimination method.  

The N1 parameter allows for fine-tuning the FEC scheme with respect to the decoding performance, measured in terms of inefficiency or overhead, and complexity, measured in terms of throughput. Very high throughputs (e.g. several Gbps) can be reached by using the IT decoding, which achieves good performance (low overheads) for small values of N1 (generally 3, 4). To improve the decoding performance, one can trade IT for ML decoding. For instance, LDPC-staircase codes with N1 = 5 or 7 have almost ideal performance under the ML decoding (overhead < 1%), at the expense of lower throughput (which however remains above 1 Gbps most of the time). Moreover, the performance of the ML decoding can be further improved by increasing the N1 parameter above 7 if needed.
 
The usability, combined with reliable performance, make LDPC-staircase highly attractive for practical FEC schemes for the erasure channel. I therefore strongly recommend them for adoption by the FECFRAME working group.
 
 
Dr. Valentin Savin
CEA-LETI, MINATEC
Information Theory Specialist
 
 
----------------------------------------------------------------
Dr. Valentin Savin
CEA-LETI, MINATEC
DSIS/LCS - Communications sans fil et Sécurité
17, rue des Martyrs,38054 Grenoble, FRANCE
Bât BOC(51C), Pièce C452
Tél.  +33.(0)4.38.78.07.11
Fax. +33.(0)4.38.78.65.86
http://www-leti.cea.fr, http://www.minatec.com   --------------010801080404060904080601-- From ietfdbh@comcast.net Sat Jan 15 09:58:20 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7608C3A6DD6 for ; Sat, 15 Jan 2011 09:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.906 X-Spam-Level: X-Spam-Status: No, score=-102.906 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnMMbbnpC47I for ; Sat, 15 Jan 2011 09:58:18 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id EEFD83A6DD5 for ; Sat, 15 Jan 2011 09:58:17 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id vu0a1f0041vXlb853u0n4f; Sat, 15 Jan 2011 18:00:47 +0000 Received: from davidPC ([67.189.235.106]) by omta17.westchester.pa.mail.comcast.net with comcast id vu0m1f00X2JQnJT3du0nQr; Sat, 15 Jan 2011 18:00:47 +0000 From: "David Harrington" To: "'Ali C. Begen \(abegen\)'" , References: <4D089F54.7000304@inrialpes.fr> In-Reply-To: Date: Sat, 15 Jan 2011 13:00:35 -0500 Message-ID: <529A0E8A963F401E8A3C86E05404A2EE@davidPC> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_034E_01CBB4B4.338A84A0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: Acuw/ZYicYoCtaR8SheCqbcpAFDDhAC/4qMw Cc: fecframe@ietf.org Subject: Re: [Fecframe] Proposed changes to the framework draft -part2(security) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 17:58:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_034E_01CBB4B4.338A84A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Since this is a framework document, it is likely to be the first document an operator will read regarding the deployment of fec in their existing environment. Please add a section to the document: operational considerations. (this is really deployment considerations) In this section please discuss what an operator should know about deploying fec. This should include the expected impact to traffic loads, what infrastructure must exist to support fec (e.g DNS) , and so on. Please add a section to the document: management considerations. In this section, please discuss how an operator/NOC/NMS is expected to communicate with the devices on which fec is deployed. Mostly this should deal with how does one configure fec, and how does one monitor fec? It should include a discussion of configuration issues, the asynchronous reporting of fec error conditions, and the querying of operational state and statistics. >From a framework perspective ... dbh _____ From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Monday, January 10, 2011 2:36 PM To: gjshep@gmail.com Cc: fecframe@ietf.org Subject: Re: [Fecframe] Proposed changes to the framework draft -part2(security) Yes the discusses around the sec issues should be resolved with the revision but I am still expecting to hear from the AD about the other discuss related to the ops and management. He is yet to respond to the responses made to his email about the proposed text. I certainly hope the framework draft can be done before the next meeting. -acbegen On Jan 10, 2011, at 7:22 PM, "Greg Shepherd" wrote: I believe the concerns David had are well addressed here in this thread. If we can all agree on the new security section then let's get the edits made and the document updated and shipped. Thanks, Greg On Wed, Dec 15, 2010 at 2:58 AM, Vincent Roca wrote: > Mike and everybody, > > I think we now agree, it's more a matter presenting things correctly. So > let's try once again (sorry for this long email). There are several > dimensions > to consider and this is probably what makes the discussion complex: > > Dimension 1, the way FECFRAME is used: > U1- FECFRAME is used end-to-end, and is included in the final end-device > U2- FECFRAME is used in middle-boxes, e.g. to protect several source flows > globally, > coming from several content servers, and destinated to the same remote > middle box. > > Dimension 2, the threat model: > T1- threats on the end device when FECFRAME is run on the end-device (case > U1 above): > the attacker is either the end-user (who may want to access protected > content) or > somebody else. In all cases the attacker has access to the end device, but > not > necessarily a full control of the end-device since a secure domain can > exist. > T2- threats on the FECFRAME middle-box when FECFRAME is run on a different > server > (case U2 above). An attacker has access to this box. > T3- threats during the end-to-end transport (e.g. Internet). The attacker > can do > many different things on the FEC source and repair packets (e.g. delay, > drop, > add forged packets, replay). > > Dimension 3, the desired security features W.R.T. the use of FECFRAME: > F1- content integrity / source authentication > F2- content confidentiality > F3- DoS mitigation > F4- anti-replay protection > > Dimension 4, the security tools: > S1- the various DRM systems, defined out of the context of IETF, some of > them > being proprietary and/or subject to IPRs. > S2- SRTP (and SRTCP). > S3- IPsec/ESP. > > > We agree we only need to focus on topics related to the use of FECFRAME. > Here is a list of such topics: > > **Topic 1** Should encryption be applied after or before FEC protection? > Proposed text already discusses this, depending on the way FECFRAME is > used (U1 or U2) and threat model (T1, T2, T3). It is often preferable > to encrypt first, then do FEC processing. > > (NB: the proposed text should be sufficient) > > > **Topic 2** Is SRTP a solution and how should SRTP be used along with > FECFRAME? > This is a solution in some situations, but FECFRAME impacts the way it > is used: > - When SRTP is used to encrypt the content, we have the same discussion > as Topic 1- above. > - When SRTP is used only to provide authentication/integrity, we can > probably use SRTP either above FECFRAME, or below FECFRAME. Using it > below FECFRAME, on both FEC Source packets and FEC Repair packets has > the advantage of fulfilling the desired features F1 and F3 (fake > FEC source/repair packets are filtered). > BUT this requires (1) we deal with RTP source flows, and (2) FEC Source > and Repair packets are RTP packets. There are therefore restrictions. > > (NB: we need to update the current I-D to add this discussion too) > > > **Topic 3** Is IPsec a solution and how should it be used along with > FECFRAME? > Being applied below FECFRAME it secures the whole traffic (FEC Source and > Repair traffic). With the threat model T3 (end2end transport), it's > appropriate > and provides the desirable features F1 F3 F4 (that are FECFRAME related) > along > with F2 (but this is independent of FECFRAME). > It can therefore be a "mandatory to implement" security solution IMHO. > The potential issue I see is that it may seem too much of a burden to > require > mobile terminals to include IPsec, even if not used. > > (NB: we need to improve the current I-D) > > > **Topic 4** What about attacks on the FECFRAME component itself (T1 and T2)? > This is what Mike means if I understand correctly by: > "BTW, a third axis is the security in the servers that are adding > FECFRAME formatting to the outgoing packets, and perhaps this should > be addressed as well (e.g., the process of adding FEC repair packets > to the stream might be vulnerable to an attack, and thus it is better > if this process doesn't have access to the plaintext content, etc.)" > If F2 is required, it's clear that encryption must have occurred before, > while > data was still in the secure domain. In fact I don't know if we can do > anything > else in this case. > > > **Topic 5** What about attacks on the session description? > David said: > "I don't see a mandatory to implement protocol for protecting the > session description." > The FECFRAME session description generates new opportunities for attacks, > it's obvious. But I don't see how we can mandate a security solution for > something that is sent OOB, using a mechanism that is not defined by our > I-D. If SDP is used, then it's preferable to refer to SDP's Security > Consideration sections (even if this latter fails to mandate a security > solution!). > > (NB: we need to improve the current I-D) > > > Is there anything else? Feel free to suggest new topics if needed or > correct me if I made mistakes. > > Regards, > > Vincent > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe ------=_NextPart_000_034E_01CBB4B4.338A84A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Since this is a framework document, it is likely = to be the=20 first document an operator will read regarding the deployment of fec in = their=20 existing environment.
 
Please add a section to the document: operational=20 considerations.
(this is really deployment = considerations)
In this section please discuss what an operator = should know=20 about deploying fec.
This should include the expected impact to traffic = loads, what=20 infrastructure must exist to support fec (e.g DNS) , and so=20 on.
 
Please add a section to the document: management=20 considerations.
In this = section, please=20 discuss how an operator/NOC/NMS is expected to communicate with the = devices on=20 which fec is deployed.
Mostly this = should deal=20 with how does one configure fec, and how does one monitor = fec?
It should = include a=20 discussion of configuration issues, the asynchronous reporting of = fec error=20 conditions, and the querying of operational state and = statistics.
From a = framework=20 perspective ...
 
dbh
 

From: fecframe-bounces@ietf.org=20 [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen=20 (abegen)
Sent: Monday, January 10, 2011 2:36 = PM
To:=20 gjshep@gmail.com
Cc: fecframe@ietf.org
Subject: = Re:=20 [Fecframe] Proposed changes to the framework draft=20 -part2(security)

Yes the discusses around the sec issues should be resolved with = the=20 revision but I am still expecting to hear from the AD about the other = discuss=20 related to the ops and management. He is yet to respond to the = responses made=20 to his email about the proposed text. 

I certainly hope the framework draft can be done before the next=20 meeting. 

-acbegen

On Jan 10, 2011, at 7:22 PM, "Greg Shepherd" <gjshep@gmail.com> = wrote:

I believe the concerns David had are well = addressed here in=20 this
thread. If we can all agree on the new security section then = let's=20 get
the edits made and the document updated and=20 shipped.

Thanks,
Greg

On Wed, Dec 15, 2010 at 2:58 = AM,=20 Vincent Roca <vincent.roca@inrialpes.fr&g= t;=20 wrote:
> Mike and everybody,
>
> I think we now = agree,=20 it's more a matter presenting things correctly. So
> let's try = once=20 again (sorry for this long email). There are several
>=20 dimensions
> to consider and this is probably what makes the=20 discussion complex:
>
> Dimension 1, the way FECFRAME is = used:
> U1- FECFRAME is used end-to-end, and is included in = the final=20 end-device
> U2- FECFRAME is used in middle-boxes, e.g. to = protect=20 several source flows
> globally,
>   coming from = several=20 content servers, and destinated to the same remote
> middle=20 box.
>
> Dimension 2, the threat model:
> T1- = threats on=20 the end device when FECFRAME is run on the end-device (case
> = U1=20 above):
>   the attacker is either the end-user (who may = want to=20 access protected
> content) or
>   somebody else. = In all=20 cases the attacker has access to the end device, but
> = not
>=20   necessarily a full control of the end-device since a secure = domain=20 can
> exist.
> T2- threats on the FECFRAME middle-box = when=20 FECFRAME is run on a different
> server
>   (case = U2=20 above). An attacker has access to this box.
> T3- threats = during the=20 end-to-end transport (e.g. Internet). The attacker
> can = do
>=20    many different things on the FEC source and repair = packets=20 (e.g. delay,
> drop,
>    add forged packets,=20 replay).
>
> Dimension 3, the desired security features = W.R.T.=20 the use of FECFRAME:
> F1- content integrity / source=20 authentication
> F2- content confidentiality
> F3- DoS=20 mitigation
> F4- anti-replay protection
>
> = Dimension 4,=20 the security tools:
> S1- the various DRM systems, defined out = of the=20 context of IETF, some of
> them
>    being = proprietary=20 and/or subject to IPRs.
> S2- SRTP (and SRTCP).
> S3-=20 IPsec/ESP.
>
>
> We agree we only need to focus on = topics=20 related to the use of FECFRAME.
> Here is a list of such=20 topics:
>
> **Topic 1** Should encryption be applied = after or=20 before FEC protection?
> Proposed text already discusses this, = depending on the way FECFRAME is
> used (U1 or U2) and threat = model=20 (T1, T2, T3). It is often preferable
> to encrypt first, then = do FEC=20 processing.
>
> (NB: the proposed text should be=20 sufficient)
>
>
> **Topic 2** Is SRTP a solution = and how=20 should SRTP be used along with
> FECFRAME?
> This is a = solution=20 in some situations, but FECFRAME impacts the way it
> is = used:
>=20 - When SRTP is used to encrypt the content, we have the same=20 discussion
>  as Topic 1- above.
> - When SRTP is = used only=20 to provide authentication/integrity, we can
>  probably = use SRTP=20 either above FECFRAME, or below FECFRAME. Using it
> =  below=20 FECFRAME, on both FEC Source packets and FEC Repair packets = has
>=20  the advantage of fulfilling the desired features F1 and F3=20 (fake
>  FEC source/repair packets are filtered).
> =  BUT this requires (1) we deal with RTP source flows, and (2) = FEC=20 Source
>  and Repair packets are RTP packets. There are = therefore=20 restrictions.
>
> (NB: we need to update the current I-D = to add=20 this discussion too)
>
>
> **Topic 3** Is IPsec a = solution=20 and how should it be used along with
> FECFRAME?
> Being = applied=20 below FECFRAME it secures the whole traffic (FEC Source and
> = Repair=20 traffic). With the threat model T3 (end2end transport), it's
> = appropriate
> and provides the desirable features F1 F3 F4 = (that are=20 FECFRAME related)
> along
> with F2 (but this is = independent of=20 FECFRAME).
> It can therefore be a "mandatory to implement" = security=20 solution IMHO.
> The potential issue I see is that it may seem = too=20 much of a burden to
> require
> mobile terminals to = include=20 IPsec, even if not used.
>
> (NB: we need to improve the = current=20 I-D)
>
>
> **Topic 4** What about attacks on the = FECFRAME=20 component itself (T1 and T2)?
> This is what Mike means if I=20 understand correctly by:
>       "BTW, a third = axis is=20 the security in the servers that are adding
>     =  =20  FECFRAME formatting to the outgoing packets, and perhaps this=20 should
>        be addressed as well = (e.g., the=20 process of adding FEC repair packets
>       =  to=20 the stream might be vulnerable to an attack, and thus it is = better
>=20        if this process doesn't have access to = the=20 plaintext content, etc.)"
> If F2 is required, it's clear that = encryption must have occurred before,
> while
> data was = still=20 in the secure domain. In fact I don't know if we can do
>=20 anything
> else in this case.
>
>
> **Topic = 5** What=20 about attacks on the session description?
> David = said:
>=20  "I don't see a mandatory to implement protocol for protecting=20 the
>   session description."
> The FECFRAME = session=20 description generates new opportunities for attacks,
> it's = obvious.=20 But I don't see how we can mandate a security solution for
> = something=20 that is sent OOB, using a mechanism that is not defined by = our
> I-D.=20 If SDP is used, then it's preferable to refer to SDP's = Security
>=20 Consideration sections (even if this latter fails to mandate a=20 security
> solution!).
>
> (NB: we need to improve = the=20 current I-D)
>
>
> Is there anything else? Feel = free to=20 suggest new topics if needed or
> correct me if I made=20 mistakes.
>
> Regards,
>
>=20  Vincent
>
>=20 _______________________________________________
> Fecframe = mailing=20 list
> Fecframe@ietf.org
> = https://www.ietf.= org/mailman/listinfo/fecframe
>
________________________= _______________________
Fecframe=20 mailing list
Fecframe@ietf.org
https://www.ietf.= org/mailman/listinfo/fecframe

------=_NextPart_000_034E_01CBB4B4.338A84A0-- From gjshep@gmail.com Sat Jan 15 17:16:37 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609543A6BEE for ; Sat, 15 Jan 2011 17:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.364 X-Spam-Level: X-Spam-Status: No, score=-103.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-G7D7+ZkXxb for ; Sat, 15 Jan 2011 17:16:36 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id A43893A6BA7 for ; Sat, 15 Jan 2011 17:16:35 -0800 (PST) Received: by fxm9 with SMTP id 9so4832072fxm.31 for ; Sat, 15 Jan 2011 17:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2PLM5x/+szExntTHiMZEX4RBtfkbaKH/ZReCfSYUqiE=; b=QR6TyM7YrnqdoqTdC9fKxXGNInPxD1XNREAWOhQxaaB+t5981cLBqugwokihT8s99l jsTp9nqVpIA9m7kig/TWOcKQe1rzSVwuP2CSQmjxSUJtt3xgpTPWmYFhZUzQ9LwBpPwo Yq/cAAVWz66LYTx4pLeXlaGYJbocOMyKEmQRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=VVuqpPF5tr0VsXw3lIOHv+1s35dlGMGihLvKePdPVxO0jQj8Mba/hJVPq7XdQn19w0 cE1q/baEPsqNRQO9k1UQ/KuNXlWZ8qK2K4xG1Z/IouyqPvnV7iFR8I60k5nYy/vP6hRn IeVoExNg+xTRYUIbUVQGMG0f6wFw1VVcwfbcs= MIME-Version: 1.0 Received: by 10.204.33.74 with SMTP id g10mr1399762bkd.131.1295140744617; Sat, 15 Jan 2011 17:19:04 -0800 (PST) Received: by 10.204.80.6 with HTTP; Sat, 15 Jan 2011 17:19:04 -0800 (PST) In-Reply-To: <529A0E8A963F401E8A3C86E05404A2EE@davidPC> References: <4D089F54.7000304@inrialpes.fr> <529A0E8A963F401E8A3C86E05404A2EE@davidPC> Date: Sat, 15 Jan 2011 17:19:04 -0800 Message-ID: From: Greg Shepherd To: David Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: Re: [Fecframe] Proposed changes to the framework draft -part2(security) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jan 2011 01:16:37 -0000 Dave, Can you please read and comment on the other feedback on this thread before adding more requirements? Thanks, Greg On Sat, Jan 15, 2011 at 10:00 AM, David Harrington wr= ote: > Hi, > > Since this is a framework document, it is likely to be the first document= an > operator will read regarding the deployment of fec in their existing > environment. > > Please add a section to the document: operational considerations. > (this is really deployment considerations) > In this section please discuss what an operator should know about=A0deplo= ying > fec. > This should include the expected impact to traffic loads, what > infrastructure must exist to support fec (e.g DNS) , and so on. > > Please add a section to the document: management considerations. > In this section, please discuss how an operator/NOC/NMS is expected to > communicate with the devices on which fec is deployed. > Mostly this should deal with how does one configure fec, and how does one > monitor fec? > It should include a discussion of configuration issues, the asynchronous > reporting of fec=A0error conditions, and the querying of operational stat= e and > statistics. > From a framework perspective ... > > dbh > > > ________________________________ > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Beh= alf > Of Ali C. Begen (abegen) > Sent: Monday, January 10, 2011 2:36 PM > To: gjshep@gmail.com > Cc: fecframe@ietf.org > Subject: Re: [Fecframe] Proposed changes to the framework draft > -part2(security) > > Yes the discusses around the sec issues should be resolved with the revis= ion > but I am still expecting to hear from the AD about the other discuss rela= ted > to the ops and management. He is yet to respond to the responses made to = his > email about the proposed text. > I certainly hope the framework draft can be done before the next meeting. > > -acbegen > On Jan 10, 2011, at 7:22 PM, "Greg Shepherd" wrote: > > I believe the concerns David had are well addressed here in this > thread. If we can all agree on the new security section then let's get > the edits made and the document updated and shipped. > > Thanks, > Greg > > On Wed, Dec 15, 2010 at 2:58 AM, Vincent Roca > wrote: >> Mike and everybody, >> >> I think we now agree, it's more a matter presenting things correctly. So >> let's try once again (sorry for this long email). There are several >> dimensions >> to consider and this is probably what makes the discussion complex: >> >> Dimension 1, the way FECFRAME is used: >> U1- FECFRAME is used end-to-end, and is included in the final end-device >> U2- FECFRAME is used in middle-boxes, e.g. to protect several source flo= ws >> globally, >> =A0 coming from several content servers, and destinated to the same remo= te >> middle box. >> >> Dimension 2, the threat model: >> T1- threats on the end device when FECFRAME is run on the end-device (ca= se >> U1 above): >> =A0 the attacker is either the end-user (who may want to access protecte= d >> content) or >> =A0 somebody else. In all cases the attacker has access to the end devic= e, >> but >> not >> =A0 necessarily a full control of the end-device since a secure domain c= an >> exist. >> T2- threats on the FECFRAME middle-box when FECFRAME is run on a differe= nt >> server >> =A0 (case U2 above). An attacker has access to this box. >> T3- threats during the end-to-end transport (e.g. Internet). The attacke= r >> can do >> =A0 =A0many different things on the FEC source and repair packets (e.g. = delay, >> drop, >> =A0 =A0add forged packets, replay). >> >> Dimension 3, the desired security features W.R.T. the use of FECFRAME: >> F1- content integrity / source authentication >> F2- content confidentiality >> F3- DoS mitigation >> F4- anti-replay protection >> >> Dimension 4, the security tools: >> S1- the various DRM systems, defined out of the context of IETF, some of >> them >> =A0 =A0being proprietary and/or subject to IPRs. >> S2- SRTP (and SRTCP). >> S3- IPsec/ESP. >> >> >> We agree we only need to focus on topics related to the use of FECFRAME. >> Here is a list of such topics: >> >> **Topic 1** Should encryption be applied after or before FEC protection? >> Proposed text already discusses this, depending on the way FECFRAME is >> used (U1 or U2) and threat model (T1, T2, T3). It is often preferable >> to encrypt first, then do FEC processing. >> >> (NB: the proposed text should be sufficient) >> >> >> **Topic 2** Is SRTP a solution and how should SRTP be used along with >> FECFRAME? >> This is a solution in some situations, but FECFRAME impacts the way it >> is used: >> - When SRTP is used to encrypt the content, we have the same discussion >> =A0as Topic 1- above. >> - When SRTP is used only to provide authentication/integrity, we can >> =A0probably use SRTP either above FECFRAME, or below FECFRAME. Using it >> =A0below FECFRAME, on both FEC Source packets and FEC Repair packets has >> =A0the advantage of fulfilling the desired features F1 and F3 (fake >> =A0FEC source/repair packets are filtered). >> =A0BUT this requires (1) we deal with RTP source flows, and (2) FEC Sour= ce >> =A0and Repair packets are RTP packets. There are therefore restrictions. >> >> (NB: we need to update the current I-D to add this discussion too) >> >> >> **Topic 3** Is IPsec a solution and how should it be used along with >> FECFRAME? >> Being applied below FECFRAME it secures the whole traffic (FEC Source an= d >> Repair traffic). With the threat model T3 (end2end transport), it's >> appropriate >> and provides the desirable features F1 F3 F4 (that are FECFRAME related) >> along >> with F2 (but this is independent of FECFRAME). >> It can therefore be a "mandatory to implement" security solution IMHO. >> The potential issue I see is that it may seem too much of a burden to >> require >> mobile terminals to include IPsec, even if not used. >> >> (NB: we need to improve the current I-D) >> >> >> **Topic 4** What about attacks on the FECFRAME component itself (T1 and >> T2)? >> This is what Mike means if I understand correctly by: >> =A0 =A0 =A0 "BTW, a third axis is the security in the servers that are a= dding >> =A0 =A0 =A0 =A0FECFRAME formatting to the outgoing packets, and perhaps = this >> should >> =A0 =A0 =A0 =A0be addressed as well (e.g., the process of adding FEC rep= air >> packets >> =A0 =A0 =A0 =A0to the stream might be vulnerable to an attack, and thus = it is >> better >> =A0 =A0 =A0 =A0if this process doesn't have access to the plaintext cont= ent, >> etc.)" >> If F2 is required, it's clear that encryption must have occurred before, >> while >> data was still in the secure domain. In fact I don't know if we can do >> anything >> else in this case. >> >> >> **Topic 5** What about attacks on the session description? >> David said: >> =A0"I don't see a mandatory to implement protocol for protecting the >> =A0 session description." >> The FECFRAME session description generates new opportunities for attacks= , >> it's obvious. But I don't see how we can mandate a security solution for >> something that is sent OOB, using a mechanism that is not defined by our >> I-D. If SDP is used, then it's preferable to refer to SDP's Security >> Consideration sections (even if this latter fails to mandate a security >> solution!). >> >> (NB: we need to improve the current I-D) >> >> >> Is there anything else? Feel free to suggest new topics if needed or >> correct me if I made mistakes. >> >> Regards, >> >> =A0Vincent >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >> > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From ietfdbh@comcast.net Mon Jan 17 12:49:24 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048D428C0D7 for ; Mon, 17 Jan 2011 12:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.821 X-Spam-Level: X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zuF2ygRUXXc for ; Mon, 17 Jan 2011 12:49:21 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 7DED528C128 for ; Mon, 17 Jan 2011 12:49:20 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta07.westchester.pa.mail.comcast.net with comcast id wkZP1f0061c6gX857krwjr; Mon, 17 Jan 2011 20:51:56 +0000 Received: from davidPC ([67.189.235.106]) by omta23.westchester.pa.mail.comcast.net with comcast id wkrv1f01j2JQnJT3jkrwuj; Mon, 17 Jan 2011 20:51:56 +0000 From: "David Harrington" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> <04CAD96D4C5A3D48B1919248A8FE0D540DE2DDF1@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DE2DDF1@xmb-sjc-215.amer.cisco.com> Date: Mon, 17 Jan 2011 15:51:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAnWz4wAEBdh1AHPzL3kA== Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 20:49:24 -0000 Hi Ali, I am not a fan of introducing what appear to be additional requirements late in the process, and I strongly support the idea that a charter should make sure all aspects will be addressed adequately. Unfortunately the charter as written does not do a good job of identifying operations and management considerations as a requirement. That does not mean the WG, and the IETF in general, and the IESG in particular, should allow specifications to advance that ignore important requirements. The IESG DISCUSS criteria http://www.ietf.org/iesg/statement/discuss-criteria.html include specific points to be considered when evaluating whether a document should be advanced. In my opinion, this document and the rest of the WG document set fails to meet the following criteria: .It is unlikely that multiple implementations of the specification would interoperate, usually due to vagueness or incomplete specification .It would present serious operational issues in widespread deployment, by for example neglecting network management or configuration entirely. As you know, I am not the only IESG member that thinks this document fails to meet that criteria. It has been suggested you consult RFC5706 for guidance. I think RFC5706 is fairly heavyweight for guidance. I have made some suggestions of things to consider (so you can document those considerations) that I believe would help satisfy the DISCUSS criteria. Saying consideration of operations and management is out of scope is simply unacceptable, and the document is likely to never be approved as long as that is the attitude presented to the IESG. The IESG accepts that no one protocol will be right for all fec schemes and all environments, but the purpose of standards is interoperability, so the IESG would consider it perfectly reasonable if the configuration and management support was fec scheme specific. In that case, the framework should state that each fec scheme compliant with this framework MUST identify a mandatory-to-implement protocol and data model to ensure a minimum level of interoperability between implementations of that fec scheme from different sources. dbh > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Saturday, December 11, 2010 2:26 PM > To: David Harrington; fecframe@ietf.org > Subject: RE: [Fecframe] Operations and Management > Considerations (text for theframework) > > Hi David, All, > > This was not an attempt for a punt or refusal. This was > simply a summary of what has been discussed in the WG and > design team in the past three years. I might have done a poor > job in summarizing it but your email is not concerned about it. > > I offered the text based on my knowledge and past meetings, > and asked the WG to provide input on it. There were no > objections. And from what we saw, I can tell that those of us > who actually run FEC systems were happy with the points or > arguments summarized in this section. I agree there is not > much detailed information but the section offers why it is so. > > The list you provided below involves many things that were > never discussed in this WG (at least to my knowledge), > largely because they were left outside the scope since the > beginning. I was still at school when fecframe was formed and > chartered but the current charter does not have much > (actually anything at all) related to the list below. If > these things indeed needed a specification, the charter > should have said so and they should have been worked on when > the framework draft was still developing and during the time > when we had a larger participation in the WG. > > I am happy with what the WG decides to do. As one of the > current editors, I am willing to contribute but this is a > daunting task, which will certainly require more than one > person. However, first I would like to see what everybody > thinks: are we missing essential information that we would > need in the field for fecframe apps? > > -acbegen > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Friday, December 10, 2010 8:31 AM > > To: Ali C. Begen (abegen); fecframe@ietf.org > > Subject: RE: [Fecframe] Operations and Management > Considerations (text for theframework) > > > > Hi, > > > > This is not adequate to address IESG concerns. > > > > You need to talk about what needs to be managed, and how it can be > > managed in an interoperable manner. > > > > Excerpts from the IETF Mission statement: > > The mission of the IETF is to make the Internet work better by > > producing high quality, relevant technical documents that influence > > the way people design, use, and manage the Internet... when the IETF > > takes ownership of a protocol or function, it accepts the > > responsibility for all aspects of the protocol. > > > > This is an excerpt from another conversation that is > happening in the > > IESG, and the statement has IESG and IAB consensus: > > "IETF [...] has negative experience with two standards in the same > > general area. When one vendor implements one standard and another > > vendor implements the other standard, there is no interoperability. > > The result is two disjoint communities, which is considered > a failure > > in the IETF." > > > > Some IESG responses to your proposed text: > > > > - This is worse than a punt. This is an explicit refusal to consider > > the issues of operation or management, plus the addition of > text that > > states "we will not do this in this draft". > > > > - As holder of the DISCUSS I would not clear the DISCUSS > based on the > > proposed text. > > > Defining tools for the operation and management of these hosts is > > not within the scope of this specification. > > Sure - it's a framework document. Yet discussion of the > operations and > > management interoperability is IMO within scope as it is part of the > > interoperable framework. > > > > I strongly support these IESG positions. > > > > So, going forward, what we need to produce, as a starter, is > > discussion of > > 1) what are the critical errors in FEC processing, and how should > > operators and applications respond to these errors? > > 2) How should critical errors get reported to operators and network > > management applications? > > 3) How are the critical errors reported in a vendor-neutral manner? > > 4) what is the ***standard*** for configuring FEC parameters, so we > > have a minimum level of interoperability across vendors? If there is > > no need for such a standard, then it is questionable whether this is > > IETF work because the IETF works to develop vendor-neutral standards > > for interoperability across vendors. > > 5) A standard set of functionality can be supplemented with > > proprietary methods if desired, but there should be ONE method that > > all compliant implementations support. > > 6) What statistics should be maintained by senders and recievers of > > FEC-protected content? Faults? performance measures? connections? > > 7) What is the range of the statistics? What happens to the > statistics > > when a device reboots? or a session restarts? > > 8) I recommend you expand section 6 to standardize this feedback > > information model in more detail. > > - see RFC3444 about information models, > > - see the BRIDGE-MIB for some guidelines about limiting the > > information model to necessary infromation > > - for those that participate in IEEE 802.1, you might want to > > look at how they separate the information model form the data model > > - how does pre- and post-encryption affect those statistics? > > Should the use of pre-, -post-, or both encryption be reported so an > > operator can tell whether FEC configuration is properly aligned with > > domains of trust? > > 9) How are the statistics reported to an operator or NM application, > > especially NM applications from another vendor? > > 10) How are the statistics reported between receiver and sender? is > > there in-line OAM functionality? What happens if there is a proxy? > > > > One of things that happens, when you refuse to properly consider > > security and/or operations and management, is that you tend to get a > > bigger pushback in response. I think you are seriously beyond the > > point of being able to say "how security is handled and how > operations > > and manageent are handled is up to the operator." > > > > when the IETF takes ownership of a protocol or function, it accepts > > the responsibility for all aspects of the protocol. > > > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > > > -----Original Message----- > > > From: fecframe-bounces@ietf.org > > > [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen > > (abegen) > > > Sent: Thursday, December 09, 2010 12:30 PM > > > To: fecframe@ietf.org > > > Subject: [Fecframe] Operations and Management Considerations > > > (text for theframework) > > > > > > This is the text that will be incorporated into the framework > > > draft (following up on the earlier discussion in the list). > > > If there are any final comments, please send them to the list. > > > > > > Otherwise, we are waiting for the AD to give us a green light > > > to move ahead with a submission to address the IESG comments. > > > > > > Thanks, > > > -acbegen > > > > > > > > > 10. Operations and Management Considerations > > > > > > The FEC Framework is concerned about the FEC encoding and > > decoding > > > operations, and the configuration information that is essential > > to > > > control the hosts running these operations. Defining tools for > > the > > > operation and management of these hosts is not within the scope > > of > > > this specification. > > > > > > Some applications using the CDPs compatible with the FEC > > Framework > > > are one-way meaning that they do not have a way to gather > > > any kind of > > > feedback from receivers (e.g., broadcast), while some > of them may > > > collect detailed feedback (in case it is a one-to-one > > > application) or > > > occasional feedback (in case it is a multicast > application). All > > > these applications have naturally different management aspects. > > If > > > any, they also have different requirements or features for > > > collecting > > > feedback, processing it and acting on it. The data structures > > for > > > carrying the feedback also vary. > > > > > > On the operations side, it is not advisable for the FEC > > > Framework to > > > explicitly list what the hosts (sender or receiver or even > > > a middle- > > > box) could do upon observing something in particular > or receiving > > a > > > specific feedback. The CDPs and the FEC schemes > > > compatible with the > > > FEC Framework SHOULD make use of existing tools as much as > > possible > > > and to the extent possible. For example, for repair flows > > > using RTP > > > transport, benefiting from all the features of RTCP > mechanisms is > > > strongly RECOMMENDED since RTCP has already solved > many of these > > > issues in an agnostic way of the data carried with RTP. > > > > > > Overall, the CDPs and FEC schemes compatible with the FEC > > Framework > > > widely differ in their capabilities, application and deployment > > > scenarios such that a common operation and management tool > > > that works > > > well for all of them does not exist. Thus, as a design choice, > > the > > > FEC Framework does not dictate the use of any particular > > technology > > > or protocol for transporting FEC data, managing the hosts, > > > signaling > > > the configuration information or encoding the configuration > > > information. This provides flexibility and was one of the > > > main goals > > > of the FEC Framework. > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe > > > > From ietfdbh@comcast.net Mon Jan 17 13:04:25 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4EE3A6EDB for ; Mon, 17 Jan 2011 13:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po6syTooGyyn for ; Mon, 17 Jan 2011 13:04:24 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id B64033A6DBA for ; Mon, 17 Jan 2011 13:04:23 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id wkeB1f0041vXlb851l6zoQ; Mon, 17 Jan 2011 21:06:59 +0000 Received: from davidPC ([67.189.235.106]) by omta17.westchester.pa.mail.comcast.net with comcast id wl6z1f00F2JQnJT3dl6zLA; Mon, 17 Jan 2011 21:06:59 +0000 From: "David Harrington" To: "'David R Oran'" , "'Ali C. Begen \(abegen\)'" References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> <04CAD96D4C5A3D48B1919248A8FE0D540DE2DDF1@xmb-sjc-215.amer.cisco.com> <65B2271C-42CB-4357-A79A-85908A9EC661@cisco.com> In-Reply-To: <65B2271C-42CB-4357-A79A-85908A9EC661@cisco.com> Date: Mon, 17 Jan 2011 16:06:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: AcuZcaugNNZzpVnMQ2KJCXeNlCzgCwdFse2w Cc: fecframe@ietf.org Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 21:04:25 -0000 Hi, I agree that it may make more sense to focus on the interoperability of specific fec schemes and features. The framework ops+mgmt considerations should SAY that, and should set the requirement that framework-compliant components MUST specify mandatory-to-implement protocols for config and monitoring, so independently developed implementations have at least one protocol available for operators to deploy to provide interoperable operations and interoperable management for each chosen fec scheme. Of course, if each scheme chooses a different mandatory-to-implement protocol, then an entity that supports multiple fec schemes might end up with a panoply of mandatory-to-implement protocols for config and monitoring, so it might make more sense to have at least one mandatory-to-implement protocol at the framework level, to ensure a minimum level of interoperability for config and monitoring. The approach so far taken by this WG seems to be "let's just declare it out of scope" - i.e., have no standard mechanisms for configuring or monitoring FEC operations or specific FEC schemes. As far as I can see, that means that if vendor A's server wants to use fec protection for something it is sending to a client from vendor B, and vendor A chooses one protocol for config, such as SDP, and vendor B chooses not to support the same protocol, then the two endpoints cannot communicate to agree on a configuration. That would be a pretty sad situation for an IETF standard. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Saturday, December 11, 2010 3:26 PM > To: Ali C. Begen (abegen) > Cc: David Harrington; fecframe@ietf.org > Subject: Re: [Fecframe] Operations and Management > Considerations (text for theframework) > > It seems to me that since this is a framework draft, what it > needs is a framework for how the FEC parts of a bigger system > affect the overall operations and management of that system. > While the current text may be view by the IESG as inadequate, > there is frankly not a whole lot other than motherhood to say > here. The framework is not a protocol with specific > mechanisms and state machines that need configuration and/or > fail in particular ways that need to be managed. Therefore, > while I think some of the cited requirements on enhancing the > draft make a certain amount of sense, the level of > specificity that is possible is quite low, so the "pain-gain" > ratio strikes at least this WG participant as not warranting > a whole lot of work. > > The kind of drafts where the O&M considerations become > concrete are documents like > > http://datatracker.ietf.org/doc/draft-ietf-fecframe-config-signaling/ > > and > > http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/ > > I think there's more bang-for-the-buck in focusing the > limited energies of the FEC community there. > > DaveO. > > > On Dec 11, 2010, at 2:26 PM, Ali C. Begen (abegen) wrote: > > > Hi David, All, > > > > This was not an attempt for a punt or refusal. This was > simply a summary of what has been discussed in the WG and > design team in the past three years. I might have done a poor > job in summarizing it but your email is not concerned about it. > > > > I offered the text based on my knowledge and past meetings, > and asked the WG to provide input on it. There were no > objections. And from what we saw, I can tell that those of us > who actually run FEC systems were happy with the points or > arguments summarized in this section. I agree there is not > much detailed information but the section offers why it is so. > > > > The list you provided below involves many things that were > never discussed in this WG (at least to my knowledge), > largely because they were left outside the scope since the > beginning. I was still at school when fecframe was formed and > chartered but the current charter does not have much > (actually anything at all) related to the list below. If > these things indeed needed a specification, the charter > should have said so and they should have been worked on when > the framework draft was still developing and during the time > when we had a larger participation in the WG. > > > > I am happy with what the WG decides to do. As one of the > current editors, I am willing to contribute but this is a > daunting task, which will certainly require more than one > person. However, first I would like to see what everybody > thinks: are we missing essential information that we would > need in the field for fecframe apps? > > > > -acbegen > > > >> -----Original Message----- > >> From: David Harrington [mailto:ietfdbh@comcast.net] > >> Sent: Friday, December 10, 2010 8:31 AM > >> To: Ali C. Begen (abegen); fecframe@ietf.org > >> Subject: RE: [Fecframe] Operations and Management > Considerations (text for theframework) > >> > >> Hi, > >> > >> This is not adequate to address IESG concerns. > >> > >> You need to talk about what needs to be managed, and how it can be > >> managed in an interoperable manner. > >> > >> Excerpts from the IETF Mission statement: > >> The mission of the IETF is to make the Internet work better by > >> producing high quality, relevant technical documents that influence > >> the way people design, use, and manage the Internet... > when the IETF > >> takes ownership of a protocol or function, it accepts the > >> responsibility for all aspects of the protocol. > >> > >> This is an excerpt from another conversation that is > happening in the > >> IESG, and the statement has IESG and IAB consensus: > >> "IETF [...] has negative experience with two standards in the same > >> general area. When one vendor implements one standard and another > >> vendor implements the other standard, there is no interoperability. > >> The result is two disjoint communities, which is > considered a failure > >> in the IETF." > >> > >> Some IESG responses to your proposed text: > >> > >> - This is worse than a punt. This is an explicit refusal > to consider > >> the issues of operation or management, plus the addition > of text that > >> states "we will not do this in this draft". > >> > >> - As holder of the DISCUSS I would not clear the DISCUSS > based on the > >> proposed text. > >>> Defining tools for the operation and management of these hosts is > >> not within the scope of this specification. > >> Sure - it's a framework document. Yet discussion of the > operations and > >> management interoperability is IMO within scope as it is > part of the > >> interoperable framework. > >> > >> I strongly support these IESG positions. > >> > >> So, going forward, what we need to produce, as a starter, is > >> discussion of > >> 1) what are the critical errors in FEC processing, and how should > >> operators and applications respond to these errors? > >> 2) How should critical errors get reported to operators and network > >> management applications? > >> 3) How are the critical errors reported in a vendor-neutral manner? > >> 4) what is the ***standard*** for configuring FEC parameters, so we > >> have a minimum level of interoperability across vendors? > If there is > >> no need for such a standard, then it is questionable > whether this is > >> IETF work because the IETF works to develop vendor-neutral > standards > >> for interoperability across vendors. > >> 5) A standard set of functionality can be supplemented with > >> proprietary methods if desired, but there should be ONE method that > >> all compliant implementations support. > >> 6) What statistics should be maintained by senders and recievers of > >> FEC-protected content? Faults? performance measures? connections? > >> 7) What is the range of the statistics? What happens to > the statistics > >> when a device reboots? or a session restarts? > >> 8) I recommend you expand section 6 to standardize this feedback > >> information model in more detail. > >> - see RFC3444 about information models, > >> - see the BRIDGE-MIB for some guidelines about limiting the > >> information model to necessary infromation > >> - for those that participate in IEEE 802.1, you might want to > >> look at how they separate the information model form the data model > >> - how does pre- and post-encryption affect those statistics? > >> Should the use of pre-, -post-, or both encryption be > reported so an > >> operator can tell whether FEC configuration is properly > aligned with > >> domains of trust? > >> 9) How are the statistics reported to an operator or NM > application, > >> especially NM applications from another vendor? > >> 10) How are the statistics reported between receiver and sender? is > >> there in-line OAM functionality? What happens if there is a proxy? > >> > >> One of things that happens, when you refuse to properly consider > >> security and/or operations and management, is that you > tend to get a > >> bigger pushback in response. I think you are seriously beyond the > >> point of being able to say "how security is handled and > how operations > >> and manageent are handled is up to the operator." > >> > >> when the IETF takes ownership of a protocol or function, it accepts > >> the responsibility for all aspects of the protocol. > >> > >> David Harrington > >> Director, IETF Transport Area > >> ietfdbh@comcast.net (preferred for ietf) > >> dbharrington@huaweisymantec.com > >> +1 603 828 1401 (cell) > >> > >>> -----Original Message----- > >>> From: fecframe-bounces@ietf.org > >>> [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen > >> (abegen) > >>> Sent: Thursday, December 09, 2010 12:30 PM > >>> To: fecframe@ietf.org > >>> Subject: [Fecframe] Operations and Management Considerations > >>> (text for theframework) > >>> > >>> This is the text that will be incorporated into the framework > >>> draft (following up on the earlier discussion in the list). > >>> If there are any final comments, please send them to the list. > >>> > >>> Otherwise, we are waiting for the AD to give us a green light > >>> to move ahead with a submission to address the IESG comments. > >>> > >>> Thanks, > >>> -acbegen > >>> > >>> > >>> 10. Operations and Management Considerations > >>> > >>> The FEC Framework is concerned about the FEC encoding and > >> decoding > >>> operations, and the configuration information that is essential > >> to > >>> control the hosts running these operations. Defining tools for > >> the > >>> operation and management of these hosts is not within the scope > >> of > >>> this specification. > >>> > >>> Some applications using the CDPs compatible with the FEC > >> Framework > >>> are one-way meaning that they do not have a way to gather > >>> any kind of > >>> feedback from receivers (e.g., broadcast), while some > of them may > >>> collect detailed feedback (in case it is a one-to-one > >>> application) or > >>> occasional feedback (in case it is a multicast > application). All > >>> these applications have naturally different management aspects. > >> If > >>> any, they also have different requirements or features for > >>> collecting > >>> feedback, processing it and acting on it. The data structures > >> for > >>> carrying the feedback also vary. > >>> > >>> On the operations side, it is not advisable for the FEC > >>> Framework to > >>> explicitly list what the hosts (sender or receiver or even > >>> a middle- > >>> box) could do upon observing something in particular or > receiving > >> a > >>> specific feedback. The CDPs and the FEC schemes > >>> compatible with the > >>> FEC Framework SHOULD make use of existing tools as much as > >> possible > >>> and to the extent possible. For example, for repair flows > >>> using RTP > >>> transport, benefiting from all the features of RTCP > mechanisms is > >>> strongly RECOMMENDED since RTCP has already solved many of these > >>> issues in an agnostic way of the data carried with RTP. > >>> > >>> Overall, the CDPs and FEC schemes compatible with the FEC > >> Framework > >>> widely differ in their capabilities, application and deployment > >>> scenarios such that a common operation and management tool > >>> that works > >>> well for all of them does not exist. Thus, as a design choice, > >> the > >>> FEC Framework does not dictate the use of any particular > >> technology > >>> or protocol for transporting FEC data, managing the hosts, > >>> signaling > >>> the configuration information or encoding the configuration > >>> information. This provides flexibility and was one of the > >>> main goals > >>> of the FEC Framework. > >>> _______________________________________________ > >>> Fecframe mailing list > >>> Fecframe@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fecframe > >>> > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > From oran@cisco.com Mon Jan 17 13:31:45 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096E23A6E3A for ; Mon, 17 Jan 2011 13:31:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.905 X-Spam-Level: X-Spam-Status: No, score=-108.905 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lkAfT8LOkpV for ; Mon, 17 Jan 2011 13:31:43 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0E2103A6F5C for ; Mon, 17 Jan 2011 13:31:43 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 17 Jan 2011 21:34:18 +0000 Received: from [10.32.245.151] (stealth-10-32-245-151.cisco.com [10.32.245.151]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0HLYHn8002239; Mon, 17 Jan 2011 21:34:17 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: David R Oran In-Reply-To: Date: Mon, 17 Jan 2011 16:34:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6E57A7F4-41B8-474B-A140-A0566B9EB481@cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> <04CAD96D4C5A3D48B1919248A8FE0D540DE2DDF1@xmb-sjc-215.amer.cisco.com> <65B2271C-42CB-4357-A79A-85908A9EC661@cisco.com> To: "David Harrington" X-Mailer: Apple Mail (2.1082) Cc: fecframe@ietf.org Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 21:31:45 -0000 Thanks for getting back to me on this. I think we're converging = (somewhat), or at least talking about the same things. On Jan 17, 2011, at 4:06 PM, David Harrington wrote: > Hi, >=20 > I agree that it may make more sense to focus on the interoperability > of specific fec schemes and features. >=20 > The framework ops+mgmt considerations should SAY that, and should set > the requirement that framework-compliant components MUST specify > mandatory-to-implement protocols for config and monitoring, so > independently developed implementations have at least one protocol > available for operators to deploy to provide interoperable operations > and interoperable management for each chosen fec scheme. >=20 This seems a reasonable principle to follow. The devil is in the = details, especially in how the config and management for the overall = system(s) interact with the FEC-specific pieces. See below for more. > Of course, if each scheme chooses a different mandatory-to-implement > protocol, then an entity that supports multiple fec schemes might end > up with a panoply of mandatory-to-implement protocols for config and > monitoring, so it might make more sense to have at least one > mandatory-to-implement protocol at the framework level, to ensure a > minimum level of interoperability for config and monitoring. >=20 If FEC schemes were "top-of-the-foodchain" kinds of protocol, like TCP, = or RTP, or SIP, then following this rule would in fact help a lot in = ensuring system-level interoperability for the operations and management = components of making the protocol work and instrumenting it. = Unfortunately (or perhaps in my view fortunately), that's not the case = here. FEC schemes are pretty much without exception *embedded* in a = "top-of-the-food-chain" protocol like RTP, or reliable multicast file = transfer. That means one REALLY wants the operations and management = protocols and instrumentation framework to be dictated by the embedding = and not by the FEC scheme. In fact, I would consider it undesirable if = we picked and mandatory-to-implement config/management protocol (e.g. = SDP) for an FEC scheme, and then embedded it in a different = "top-of-the-food-chain" system that has no need of SDP for anything. = This is not entirely theoretical; we already have FEC schemes in use by = other SDOs that use multicast file transfer and XML to describe and = manage the protocols with which which the FEC scheme is based. It makes = much more sense to ensure that the necessary configuration and = instrumentation information is present in those protocols, than to = declare the implementation non-compliant in the IETF because the = implementer didn't (uselessly) put SDP in the system. Therefore, I still maintain that: - There isn't a lot to say in the framework draft, and find your = suggestion to limit language in that draft to saying that the operations = and management of FEC is "scheme specific" and that the scheme RFCs MUST = address O&M with the appropriate O&M considerations section. - if you at all buy my logic above, then it is not appropriate to = require "mandatory to implement" protocols in the scheme drafts; rather, = the requirement is for enough specific information about configuration = and instrumentation to give implementors guidance about what = changes/enhancements may be needed to the protocols used in the = "enclosing" protocol environment. > The approach so far taken by this WG seems to be "let's just declare > it out of scope" - i.e., have no standard mechanisms for configuring > or monitoring FEC operations or specific FEC schemes. That's a correct assessment of the WG's general approach, but I do not = view that criticism as necessarily all that serious given the nature of = the work. > As far as I can > see, that means that if vendor A's server wants to use fec protection > for something it is sending to a client from vendor B, and vendor A > chooses one protocol for config, such as SDP, and vendor B chooses not > to support the same protocol, then the two endpoints cannot > communicate to agree on a configuration. That would be a pretty sad > situation for an IETF standard. >=20 Not as sad as having an FEC scheme used with both RTP and with Reliable = file transfer being forced to add a lot of useless complexity and = introduce new interoperability problems for the system they are embedded = in because the two systems for good reason use different configuration = and management protocols. I'm of course encouraged by the discussion, which has shed some light on = the underlying issues. I think that at least at this point we are not in = agreement about the right way forward, but hopefully this has helped = make some progress. DaveO. > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 >> -----Original Message----- >> From: David R Oran [mailto:oran@cisco.com]=20 >> Sent: Saturday, December 11, 2010 3:26 PM >> To: Ali C. Begen (abegen) >> Cc: David Harrington; fecframe@ietf.org >> Subject: Re: [Fecframe] Operations and Management=20 >> Considerations (text for theframework) >>=20 >> It seems to me that since this is a framework draft, what it=20 >> needs is a framework for how the FEC parts of a bigger system=20 >> affect the overall operations and management of that system.=20 >> While the current text may be view by the IESG as inadequate,=20 >> there is frankly not a whole lot other than motherhood to say=20 >> here. The framework is not a protocol with specific=20 >> mechanisms and state machines that need configuration and/or=20 >> fail in particular ways that need to be managed. Therefore,=20 >> while I think some of the cited requirements on enhancing the=20 >> draft make a certain amount of sense, the level of=20 >> specificity that is possible is quite low, so the "pain-gain"=20 >> ratio strikes at least this WG participant as not warranting=20 >> a whole lot of work. >>=20 >> The kind of drafts where the O&M considerations become=20 >> concrete are documents like=20 >>=20 >>=20 > http://datatracker.ietf.org/doc/draft-ietf-fecframe-config-signaling/ >>=20 >> and >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/ >>=20 >> I think there's more bang-for-the-buck in focusing the=20 >> limited energies of the FEC community there. >>=20 >> DaveO. >>=20 >>=20 >> On Dec 11, 2010, at 2:26 PM, Ali C. Begen (abegen) wrote: >>=20 >>> Hi David, All, >>>=20 >>> This was not an attempt for a punt or refusal. This was=20 >> simply a summary of what has been discussed in the WG and=20 >> design team in the past three years. I might have done a poor=20 >> job in summarizing it but your email is not concerned about it. >>>=20 >>> I offered the text based on my knowledge and past meetings,=20 >> and asked the WG to provide input on it. There were no=20 >> objections. And from what we saw, I can tell that those of us=20 >> who actually run FEC systems were happy with the points or=20 >> arguments summarized in this section. I agree there is not=20 >> much detailed information but the section offers why it is so. >>>=20 >>> The list you provided below involves many things that were=20 >> never discussed in this WG (at least to my knowledge),=20 >> largely because they were left outside the scope since the=20 >> beginning. I was still at school when fecframe was formed and=20 >> chartered but the current charter does not have much=20 >> (actually anything at all) related to the list below. If=20 >> these things indeed needed a specification, the charter=20 >> should have said so and they should have been worked on when=20 >> the framework draft was still developing and during the time=20 >> when we had a larger participation in the WG.=20 >>>=20 >>> I am happy with what the WG decides to do. As one of the=20 >> current editors, I am willing to contribute but this is a=20 >> daunting task, which will certainly require more than one=20 >> person. However, first I would like to see what everybody=20 >> thinks: are we missing essential information that we would=20 >> need in the field for fecframe apps? >>>=20 >>> -acbegen >>>=20 >>>> -----Original Message----- >>>> From: David Harrington [mailto:ietfdbh@comcast.net] >>>> Sent: Friday, December 10, 2010 8:31 AM >>>> To: Ali C. Begen (abegen); fecframe@ietf.org >>>> Subject: RE: [Fecframe] Operations and Management=20 >> Considerations (text for theframework) >>>>=20 >>>> Hi, >>>>=20 >>>> This is not adequate to address IESG concerns. >>>>=20 >>>> You need to talk about what needs to be managed, and how it can > be >>>> managed in an interoperable manner. >>>>=20 >>>> Excerpts from the IETF Mission statement: >>>> The mission of the IETF is to make the Internet work better by >>>> producing high quality, relevant technical documents that > influence >>>> the way people design, use, and manage the Internet...=20 >> when the IETF >>>> takes ownership of a protocol or function, it accepts the >>>> responsibility for all aspects of the protocol. >>>>=20 >>>> This is an excerpt from another conversation that is=20 >> happening in the >>>> IESG, and the statement has IESG and IAB consensus: >>>> "IETF [...] has negative experience with two standards in the > same >>>> general area. When one vendor implements one standard and > another >>>> vendor implements the other standard, there is no > interoperability. >>>> The result is two disjoint communities, which is=20 >> considered a failure >>>> in the IETF." >>>>=20 >>>> Some IESG responses to your proposed text: >>>>=20 >>>> - This is worse than a punt. This is an explicit refusal=20 >> to consider >>>> the issues of operation or management, plus the addition=20 >> of text that >>>> states "we will not do this in this draft". >>>>=20 >>>> - As holder of the DISCUSS I would not clear the DISCUSS=20 >> based on the >>>> proposed text. >>>>> Defining tools for the operation and management of these hosts > is >>>> not within the scope of this specification. >>>> Sure - it's a framework document. Yet discussion of the=20 >> operations and >>>> management interoperability is IMO within scope as it is=20 >> part of the >>>> interoperable framework. >>>>=20 >>>> I strongly support these IESG positions. >>>>=20 >>>> So, going forward, what we need to produce, as a starter, is >>>> discussion of >>>> 1) what are the critical errors in FEC processing, and how should >>>> operators and applications respond to these errors? >>>> 2) How should critical errors get reported to operators and > network >>>> management applications? >>>> 3) How are the critical errors reported in a vendor-neutral > manner? >>>> 4) what is the ***standard*** for configuring FEC parameters, so > we >>>> have a minimum level of interoperability across vendors?=20 >> If there is >>>> no need for such a standard, then it is questionable=20 >> whether this is >>>> IETF work because the IETF works to develop vendor-neutral=20 >> standards >>>> for interoperability across vendors. >>>> 5) A standard set of functionality can be supplemented with >>>> proprietary methods if desired, but there should be ONE method > that >>>> all compliant implementations support. >>>> 6) What statistics should be maintained by senders and recievers > of >>>> FEC-protected content? Faults? performance measures? connections? >>>> 7) What is the range of the statistics? What happens to=20 >> the statistics >>>> when a device reboots? or a session restarts? >>>> 8) I recommend you expand section 6 to standardize this feedback >>>> information model in more detail. >>>> - see RFC3444 about information models, >>>> - see the BRIDGE-MIB for some guidelines about limiting the >>>> information model to necessary infromation >>>> - for those that participate in IEEE 802.1, you might want to >>>> look at how they separate the information model form the data > model >>>> - how does pre- and post-encryption affect those statistics? >>>> Should the use of pre-, -post-, or both encryption be=20 >> reported so an >>>> operator can tell whether FEC configuration is properly=20 >> aligned with >>>> domains of trust? >>>> 9) How are the statistics reported to an operator or NM=20 >> application, >>>> especially NM applications from another vendor? >>>> 10) How are the statistics reported between receiver and sender? > is >>>> there in-line OAM functionality? What happens if there is a > proxy? >>>>=20 >>>> One of things that happens, when you refuse to properly consider >>>> security and/or operations and management, is that you=20 >> tend to get a >>>> bigger pushback in response. I think you are seriously beyond the >>>> point of being able to say "how security is handled and=20 >> how operations >>>> and manageent are handled is up to the operator." >>>>=20 >>>> when the IETF takes ownership of a protocol or function, it > accepts >>>> the responsibility for all aspects of the protocol. >>>>=20 >>>> David Harrington >>>> Director, IETF Transport Area >>>> ietfdbh@comcast.net (preferred for ietf) >>>> dbharrington@huaweisymantec.com >>>> +1 603 828 1401 (cell) >>>>=20 >>>>> -----Original Message----- >>>>> From: fecframe-bounces@ietf.org >>>>> [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen >>>> (abegen) >>>>> Sent: Thursday, December 09, 2010 12:30 PM >>>>> To: fecframe@ietf.org >>>>> Subject: [Fecframe] Operations and Management Considerations >>>>> (text for theframework) >>>>>=20 >>>>> This is the text that will be incorporated into the framework >>>>> draft (following up on the earlier discussion in the list). >>>>> If there are any final comments, please send them to the list. >>>>>=20 >>>>> Otherwise, we are waiting for the AD to give us a green light >>>>> to move ahead with a submission to address the IESG comments. >>>>>=20 >>>>> Thanks, >>>>> -acbegen >>>>>=20 >>>>>=20 >>>>> 10. Operations and Management Considerations >>>>>=20 >>>>> The FEC Framework is concerned about the FEC encoding and >>>> decoding >>>>> operations, and the configuration information that is > essential >>>> to >>>>> control the hosts running these operations. Defining tools > for >>>> the >>>>> operation and management of these hosts is not within the > scope >>>> of >>>>> this specification. >>>>>=20 >>>>> Some applications using the CDPs compatible with the FEC >>>> Framework >>>>> are one-way meaning that they do not have a way to gather >>>>> any kind of >>>>> feedback from receivers (e.g., broadcast), while some=20 >> of them may >>>>> collect detailed feedback (in case it is a one-to-one >>>>> application) or >>>>> occasional feedback (in case it is a multicast=20 >> application). All >>>>> these applications have naturally different management > aspects. >>>> If >>>>> any, they also have different requirements or features for >>>>> collecting >>>>> feedback, processing it and acting on it. The data structures >>>> for >>>>> carrying the feedback also vary. >>>>>=20 >>>>> On the operations side, it is not advisable for the FEC >>>>> Framework to >>>>> explicitly list what the hosts (sender or receiver or even >>>>> a middle- >>>>> box) could do upon observing something in particular or=20 >> receiving >>>> a >>>>> specific feedback. The CDPs and the FEC schemes >>>>> compatible with the >>>>> FEC Framework SHOULD make use of existing tools as much as >>>> possible >>>>> and to the extent possible. For example, for repair flows >>>>> using RTP >>>>> transport, benefiting from all the features of RTCP=20 >> mechanisms is >>>>> strongly RECOMMENDED since RTCP has already solved many of > these >>>>> issues in an agnostic way of the data carried with RTP. >>>>>=20 >>>>> Overall, the CDPs and FEC schemes compatible with the FEC >>>> Framework >>>>> widely differ in their capabilities, application and > deployment >>>>> scenarios such that a common operation and management tool >>>>> that works >>>>> well for all of them does not exist. Thus, as a design > choice, >>>> the >>>>> FEC Framework does not dictate the use of any particular >>>> technology >>>>> or protocol for transporting FEC data, managing the hosts, >>>>> signaling >>>>> the configuration information or encoding the configuration >>>>> information. This provides flexibility and was one of the >>>>> main goals >>>>> of the FEC Framework. >>>>> _______________________________________________ >>>>> Fecframe mailing list >>>>> Fecframe@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/fecframe >>>>>=20 >>>=20 >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>=20 >>=20 >=20 From ietfdbh@comcast.net Mon Jan 17 14:38:55 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18613A6E0A for ; Mon, 17 Jan 2011 14:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.784 X-Spam-Level: X-Spam-Status: No, score=-102.784 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXWSlCeIcurG for ; Mon, 17 Jan 2011 14:38:52 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id CAAE63A6DB6 for ; Mon, 17 Jan 2011 14:38:51 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta01.westchester.pa.mail.comcast.net with comcast id wmNL1f00A1wpRvQ51mhUEw; Mon, 17 Jan 2011 22:41:28 +0000 Received: from davidPC ([67.189.235.106]) by omta18.westchester.pa.mail.comcast.net with comcast id wmcU1f00E2JQnJT3emcU3y; Mon, 17 Jan 2011 22:36:28 +0000 From: "David Harrington" To: "'Luby, Michael'" , "'Ali C. Begen \(abegen\)'" , References: <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> In-Reply-To: Date: Mon, 17 Jan 2011 17:36:15 -0500 Message-ID: <6ADE359AAAF849669355FADD50F17053@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAnWz4wAEZTJucHQ9QboA== Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 22:38:55 -0000 Hi Mike, Sure, I'll take a whack! The fecframe charter says "A primary objective of this framework is to support FEC for real-time media applications using RTP over UDP, such as on demand streaming and audio/video broadcast." The RTP MIB (RFC2959) is an example of the AVT approach to standardizing operations and management support. While RTP can support a variety of payloads, just as the FEC framework can support multiple fec schemes, there are certain properties that exist regardless of payload (and correspondingly, regardless of fec scheme). The RTP MIB document discusses operational issues and how the MIB can be applied to detect/monitor/address those issues. For example, the RTP MIB allows an operator to 1) monitor what RTP sessions exist, 2) monitor what senders are active in the sessions, 3) monitor what receivers are active in the senders, 4) monitor statistics and operational state about the sessions, and 5) create and configure new sessions. So the RTP MIB, and FEC-specific extensions to the RTP MIB, could be a likely candidate for how to manage FEC sessions. A MIB module is a data model, that provides a concrete expression of an information model (see RFC3444). If you'd like to write a MIB module, feel free. But the IESG is not demanding a MIB module. There are multiple protocols and data modeling languages that have been standardized since the RTP MIB was written, that might provide the necessary functionality, including syslog/SDE, netconf/YANG, ipfix/IE, and SDP. Other protocols might be more suitable to the environments where FEC may be applied. The IESG is asking for a discussion of operational and management issues related to forward error correction, at the framework level, and a discussion of how independent implementations will be interoperable for operations and management: "[a framework] document is expected to include information about operational impact and manageability of devices and networks that will compy to the framework, also indication about what kind of operations and manageability information future specifications of protocols that comply to the framwork would include. This document includes no such information." My recommendation is to add a section that discusses operational impact, such as the expected increase in traffic load caused by deploying FEC. It would probabyl be good to require each FEC scheme to discuss the expected impact of that scheme, and the effect of certain configuration settings. I recommend adding another section that addresses cross-vendor-interoperable manageability of entities complying with the framework, including interoperable configuration mechanisms, and interoperable mechanisms for reporting asynchronous errors, and interoperable mechanisms for reporting operational state and statistics. At some level, there should be mandatory-to-implement protocols and/or data models to ensure a minimum level of interoperability across implementations. The framework should identify which level in the framework MUST require that interoperability. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Saturday, December 11, 2010 4:40 PM > To: David Harrington; Ali C. Begen (abegen); fecframe@ietf.org > Subject: Re: [Fecframe] Operations and Management > Considerations (text for theframework) > > Hi Dave, > Perhaps you could provide the equivalent text from the AVT > working group > that addresses this issue as a starting point for what the > corresponding > text could be in FECFRAME? The reason I suggest this is that > the AVT is > somewhat similar to FECFRAME, as in AVT there is the > standardization of > delivering different video codec formats to receivers, and > FECFRAME is about > delivering FEC data that protects those deliveries, so in this sense > FECFRAME is an adjunct to AVT and should be able to leverage > the general > framework specifications that AVT has that describes how to > manage video > delivery in an interoperable way. I'm sure there must be an > AVT standard > that addresses all the issues you raise below, and it sure > would be use that > as a starting point. > Mike > > > On 12/10/10 5:31 AM, "David Harrington" wrote: > > > Hi, > > > > This is not adequate to address IESG concerns. > > > > You need to talk about what needs to be managed, and how it can be > > managed in an interoperable manner. > > > > Excerpts from the IETF Mission statement: > > The mission of the IETF is to make the Internet work better by > > producing high quality, relevant technical documents that influence > > the way people design, use, and manage the Internet... when the IETF > > takes ownership of a protocol or function, it accepts the > > responsibility for all aspects of the protocol. > > > > This is an excerpt from another conversation that is > happening in the > > IESG, and the statement has IESG and IAB consensus: > > "IETF [...] has negative experience with two standards in the same > > general area. When one vendor implements one standard and another > > vendor implements the other standard, there is no interoperability. > > The result is two disjoint communities, which is considered > a failure > > in the IETF." > > > > Some IESG responses to your proposed text: > > > > - This is worse than a punt. This is an explicit refusal to consider > > the issues of operation or management, plus the addition of > text that > > states "we will not do this in this draft". > > > > - As holder of the DISCUSS I would not clear the DISCUSS > based on the > > proposed text. > >> Defining tools for the operation and management of these hosts is > > not within the scope of this specification. > > Sure - it's a framework document. Yet discussion of the > operations and > > management interoperability is IMO within scope as it is part of the > > interoperable framework. > > > > I strongly support these IESG positions. > > > > So, going forward, what we need to produce, as a starter, is > > discussion of > > 1) what are the critical errors in FEC processing, and how should > > operators and applications respond to these errors? > > 2) How should critical errors get reported to operators and network > > management applications? > > 3) How are the critical errors reported in a vendor-neutral manner? > > 4) what is the ***standard*** for configuring FEC parameters, so we > > have a minimum level of interoperability across vendors? If there is > > no need for such a standard, then it is questionable whether this is > > IETF work because the IETF works to develop vendor-neutral standards > > for interoperability across vendors. > > 5) A standard set of functionality can be supplemented with > > proprietary methods if desired, but there should be ONE method that > > all compliant implementations support. > > 6) What statistics should be maintained by senders and recievers of > > FEC-protected content? Faults? performance measures? connections? > > 7) What is the range of the statistics? What happens to the > statistics > > when a device reboots? or a session restarts? > > 8) I recommend you expand section 6 to standardize this feedback > > information model in more detail. > > - see RFC3444 about information models, > > - see the BRIDGE-MIB for some guidelines about limiting the > > information model to necessary infromation > > - for those that participate in IEEE 802.1, you might want to > > look at how they separate the information model form the data model > > - how does pre- and post-encryption affect those statistics? > > Should the use of pre-, -post-, or both encryption be reported so an > > operator can tell whether FEC configuration is properly aligned with > > domains of trust? > > 9) How are the statistics reported to an operator or NM application, > > especially NM applications from another vendor? > > 10) How are the statistics reported between receiver and sender? is > > there in-line OAM functionality? What happens if there is a proxy? > > > > One of things that happens, when you refuse to properly consider > > security and/or operations and management, is that you tend to get a > > bigger pushback in response. I think you are seriously beyond the > > point of being able to say "how security is handled and how > operations > > and manageent are handled is up to the operator." > > > > when the IETF takes ownership of a protocol or function, it accepts > > the responsibility for all aspects of the protocol. > > > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > >> -----Original Message----- > >> From: fecframe-bounces@ietf.org > >> [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen > > (abegen) > >> Sent: Thursday, December 09, 2010 12:30 PM > >> To: fecframe@ietf.org > >> Subject: [Fecframe] Operations and Management Considerations > >> (text for theframework) > >> > >> This is the text that will be incorporated into the framework > >> draft (following up on the earlier discussion in the list). > >> If there are any final comments, please send them to the list. > >> > >> Otherwise, we are waiting for the AD to give us a green light > >> to move ahead with a submission to address the IESG comments. > >> > >> Thanks, > >> -acbegen > >> > >> > >> 10. Operations and Management Considerations > >> > >> The FEC Framework is concerned about the FEC encoding and > > decoding > >> operations, and the configuration information that is essential > > to > >> control the hosts running these operations. Defining tools for > > the > >> operation and management of these hosts is not within the scope > > of > >> this specification. > >> > >> Some applications using the CDPs compatible with the FEC > > Framework > >> are one-way meaning that they do not have a way to gather > >> any kind of > >> feedback from receivers (e.g., broadcast), while some > of them may > >> collect detailed feedback (in case it is a one-to-one > >> application) or > >> occasional feedback (in case it is a multicast > application). All > >> these applications have naturally different management aspects. > > If > >> any, they also have different requirements or features for > >> collecting > >> feedback, processing it and acting on it. The data structures > > for > >> carrying the feedback also vary. > >> > >> On the operations side, it is not advisable for the FEC > >> Framework to > >> explicitly list what the hosts (sender or receiver or even > >> a middle- > >> box) could do upon observing something in particular or > receiving > > a > >> specific feedback. The CDPs and the FEC schemes > >> compatible with the > >> FEC Framework SHOULD make use of existing tools as much as > > possible > >> and to the extent possible. For example, for repair flows > >> using RTP > >> transport, benefiting from all the features of RTCP > mechanisms is > >> strongly RECOMMENDED since RTCP has already solved many of these > >> issues in an agnostic way of the data carried with RTP. > >> > >> Overall, the CDPs and FEC schemes compatible with the FEC > > Framework > >> widely differ in their capabilities, application and deployment > >> scenarios such that a common operation and management tool > >> that works > >> well for all of them does not exist. Thus, as a design choice, > > the > >> FEC Framework does not dictate the use of any particular > > technology > >> or protocol for transporting FEC data, managing the hosts, > >> signaling > >> the configuration information or encoding the configuration > >> information. This provides flexibility and was one of the > >> main goals > >> of the FEC Framework. > >> _______________________________________________ > >> Fecframe mailing list > >> Fecframe@ietf.org > >> https://www.ietf.org/mailman/listinfo/fecframe > >> > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > From abegen@cisco.com Mon Jan 17 14:49:48 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA0D3A6F70 for ; Mon, 17 Jan 2011 14:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.451 X-Spam-Level: X-Spam-Status: No, score=-10.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1QcQhscSqzF for ; Mon, 17 Jan 2011 14:49:47 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1EA253A6F73 for ; Mon, 17 Jan 2011 14:49:47 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFdXNE2rRN+J/2dsb2JhbACkVXOoKpk4gngagj4EhG+JWQ Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 17 Jan 2011 22:52:20 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p0HMqKQJ005352; Mon, 17 Jan 2011 22:52:20 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 14:52:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 14:51:15 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCF5@xmb-sjc-215.amer.cisco.com> In-Reply-To: <6ADE359AAAF849669355FADD50F17053@davidPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Operations and Management Considerations (text for theframework) Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAnWz4wAEZTJucHQ9QboAADT1QQ References: <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> <6ADE359AAAF849669355FADD50F17053@davidPC> From: "Ali C. Begen (abegen)" To: "David Harrington" , "Luby, Michael" , X-OriginalArrivalTime: 17 Jan 2011 22:52:20.0364 (UTC) FILETIME=[327F34C0:01CBB699] Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 22:49:48 -0000 FWIW, none of the RTP deployments I am aware of (and I know several) = support RTP MIB. So, do different RTP implementations fail to = interoperate? Absolutely not. -acbegen > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Monday, January 17, 2011 5:36 PM > To: 'Luby, Michael'; Ali C. Begen (abegen); fecframe@ietf.org > Subject: RE: [Fecframe] Operations and Management Considerations (text = for theframework) >=20 > Hi Mike, >=20 > Sure, I'll take a whack! >=20 > The fecframe charter says "A primary objective of this framework is to > support FEC for real-time > media applications using RTP over UDP, such as on demand streaming and >=20 > audio/video broadcast." >=20 > The RTP MIB (RFC2959) is an example of the AVT approach to > standardizing operations and management support. > While RTP can support a variety of payloads, just as the FEC framework > can support multiple fec schemes, there are certain properties that > exist regardless of payload (and correspondingly, regardless of fec > scheme). > The RTP MIB document discusses operational issues and how the MIB can > be applied to detect/monitor/address those issues. > For example, the RTP MIB allows an operator to > 1) monitor what RTP sessions exist, > 2) monitor what senders are active in the sessions, > 3) monitor what receivers are active in the senders, > 4) monitor statistics and operational state about the sessions, and > 5) create and configure new sessions. >=20 > So the RTP MIB, and FEC-specific extensions to the RTP MIB, could be a > likely candidate for how to manage FEC sessions. > A MIB module is a data model, that provides a concrete expression of > an information model (see RFC3444). >=20 > If you'd like to write a MIB module, feel free. > But the IESG is not demanding a MIB module. There are multiple > protocols and data modeling languages that have been standardized > since the RTP MIB was written, that might provide the necessary > functionality, including syslog/SDE, netconf/YANG, ipfix/IE, and SDP. > Other protocols might be more suitable to the environments where FEC > may be applied. >=20 > The IESG is asking for a discussion of operational and management > issues related to forward error correction, at the framework level, > and a discussion of how independent implementations will be > interoperable for operations and management: > "[a framework] document is expected to include information about > operational impact and manageability of > devices and networks that will compy to the framework, also indication > about > what kind of operations and manageability information future > specifications of > protocols that comply to the framwork would include. This document > includes no > such information." >=20 > My recommendation is to add a section that discusses operational > impact, such as the expected increase in traffic load caused by > deploying FEC. It would probabyl be good to require each FEC scheme to > discuss the expected impact of that scheme, and the effect of certain > configuration settings. > I recommend adding another section that addresses > cross-vendor-interoperable manageability of entities complying with > the framework, including interoperable configuration mechanisms, and > interoperable mechanisms for reporting asynchronous errors, and > interoperable mechanisms for reporting operational state and > statistics. At some level, there should be mandatory-to-implement > protocols and/or data models to ensure a minimum level of > interoperability across implementations. The framework should identify > which level in the framework MUST require that interoperability. >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 > > -----Original Message----- > > From: Luby, Michael [mailto:luby@qualcomm.com] > > Sent: Saturday, December 11, 2010 4:40 PM > > To: David Harrington; Ali C. Begen (abegen); fecframe@ietf.org > > Subject: Re: [Fecframe] Operations and Management > > Considerations (text for theframework) > > > > Hi Dave, > > Perhaps you could provide the equivalent text from the AVT > > working group > > that addresses this issue as a starting point for what the > > corresponding > > text could be in FECFRAME? The reason I suggest this is that > > the AVT is > > somewhat similar to FECFRAME, as in AVT there is the > > standardization of > > delivering different video codec formats to receivers, and > > FECFRAME is about > > delivering FEC data that protects those deliveries, so in this sense > > FECFRAME is an adjunct to AVT and should be able to leverage > > the general > > framework specifications that AVT has that describes how to > > manage video > > delivery in an interoperable way. I'm sure there must be an > > AVT standard > > that addresses all the issues you raise below, and it sure > > would be use that > > as a starting point. > > Mike > > > > > > On 12/10/10 5:31 AM, "David Harrington" wrote: > > > > > Hi, > > > > > > This is not adequate to address IESG concerns. > > > > > > You need to talk about what needs to be managed, and how it can be > > > managed in an interoperable manner. > > > > > > Excerpts from the IETF Mission statement: > > > The mission of the IETF is to make the Internet work better by > > > producing high quality, relevant technical documents that > influence > > > the way people design, use, and manage the Internet... when the > IETF > > > takes ownership of a protocol or function, it accepts the > > > responsibility for all aspects of the protocol. > > > > > > This is an excerpt from another conversation that is > > happening in the > > > IESG, and the statement has IESG and IAB consensus: > > > "IETF [...] has negative experience with two standards in the same > > > general area. When one vendor implements one standard and another > > > vendor implements the other standard, there is no > interoperability. > > > The result is two disjoint communities, which is considered > > a failure > > > in the IETF." > > > > > > Some IESG responses to your proposed text: > > > > > > - This is worse than a punt. This is an explicit refusal to > consider > > > the issues of operation or management, plus the addition of > > text that > > > states "we will not do this in this draft". > > > > > > - As holder of the DISCUSS I would not clear the DISCUSS > > based on the > > > proposed text. > > >> Defining tools for the operation and management of these hosts is > > > not within the scope of this specification. > > > Sure - it's a framework document. Yet discussion of the > > operations and > > > management interoperability is IMO within scope as it is part of > the > > > interoperable framework. > > > > > > I strongly support these IESG positions. > > > > > > So, going forward, what we need to produce, as a starter, is > > > discussion of > > > 1) what are the critical errors in FEC processing, and how should > > > operators and applications respond to these errors? > > > 2) How should critical errors get reported to operators and > network > > > management applications? > > > 3) How are the critical errors reported in a vendor-neutral > manner? > > > 4) what is the ***standard*** for configuring FEC parameters, so > we > > > have a minimum level of interoperability across vendors? If there > is > > > no need for such a standard, then it is questionable whether this > is > > > IETF work because the IETF works to develop vendor-neutral > standards > > > for interoperability across vendors. > > > 5) A standard set of functionality can be supplemented with > > > proprietary methods if desired, but there should be ONE method > that > > > all compliant implementations support. > > > 6) What statistics should be maintained by senders and recievers > of > > > FEC-protected content? Faults? performance measures? connections? > > > 7) What is the range of the statistics? What happens to the > > statistics > > > when a device reboots? or a session restarts? > > > 8) I recommend you expand section 6 to standardize this feedback > > > information model in more detail. > > > - see RFC3444 about information models, > > > - see the BRIDGE-MIB for some guidelines about limiting the > > > information model to necessary infromation > > > - for those that participate in IEEE 802.1, you might want to > > > look at how they separate the information model form the data > model > > > - how does pre- and post-encryption affect those statistics? > > > Should the use of pre-, -post-, or both encryption be reported so > an > > > operator can tell whether FEC configuration is properly aligned > with > > > domains of trust? > > > 9) How are the statistics reported to an operator or NM > application, > > > especially NM applications from another vendor? > > > 10) How are the statistics reported between receiver and sender? > is > > > there in-line OAM functionality? What happens if there is a proxy? > > > > > > One of things that happens, when you refuse to properly consider > > > security and/or operations and management, is that you tend to get > a > > > bigger pushback in response. I think you are seriously beyond the > > > point of being able to say "how security is handled and how > > operations > > > and manageent are handled is up to the operator." > > > > > > when the IETF takes ownership of a protocol or function, it > accepts > > > the responsibility for all aspects of the protocol. > > > > > > David Harrington > > > Director, IETF Transport Area > > > ietfdbh@comcast.net (preferred for ietf) > > > dbharrington@huaweisymantec.com > > > +1 603 828 1401 (cell) > > > > > >> -----Original Message----- > > >> From: fecframe-bounces@ietf.org > > >> [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen > > > (abegen) > > >> Sent: Thursday, December 09, 2010 12:30 PM > > >> To: fecframe@ietf.org > > >> Subject: [Fecframe] Operations and Management Considerations > > >> (text for theframework) > > >> > > >> This is the text that will be incorporated into the framework > > >> draft (following up on the earlier discussion in the list). > > >> If there are any final comments, please send them to the list. > > >> > > >> Otherwise, we are waiting for the AD to give us a green light > > >> to move ahead with a submission to address the IESG comments. > > >> > > >> Thanks, > > >> -acbegen > > >> > > >> > > >> 10. Operations and Management Considerations > > >> > > >> The FEC Framework is concerned about the FEC encoding and > > > decoding > > >> operations, and the configuration information that is > essential > > > to > > >> control the hosts running these operations. Defining tools > for > > > the > > >> operation and management of these hosts is not within the > scope > > > of > > >> this specification. > > >> > > >> Some applications using the CDPs compatible with the FEC > > > Framework > > >> are one-way meaning that they do not have a way to gather > > >> any kind of > > >> feedback from receivers (e.g., broadcast), while some > > of them may > > >> collect detailed feedback (in case it is a one-to-one > > >> application) or > > >> occasional feedback (in case it is a multicast > > application). All > > >> these applications have naturally different management > aspects. > > > If > > >> any, they also have different requirements or features for > > >> collecting > > >> feedback, processing it and acting on it. The data structures > > > for > > >> carrying the feedback also vary. > > >> > > >> On the operations side, it is not advisable for the FEC > > >> Framework to > > >> explicitly list what the hosts (sender or receiver or even > > >> a middle- > > >> box) could do upon observing something in particular or > > receiving > > > a > > >> specific feedback. The CDPs and the FEC schemes > > >> compatible with the > > >> FEC Framework SHOULD make use of existing tools as much as > > > possible > > >> and to the extent possible. For example, for repair flows > > >> using RTP > > >> transport, benefiting from all the features of RTCP > > mechanisms is > > >> strongly RECOMMENDED since RTCP has already solved many of > these > > >> issues in an agnostic way of the data carried with RTP. > > >> > > >> Overall, the CDPs and FEC schemes compatible with the FEC > > > Framework > > >> widely differ in their capabilities, application and > deployment > > >> scenarios such that a common operation and management tool > > >> that works > > >> well for all of them does not exist. Thus, as a design > choice, > > > the > > >> FEC Framework does not dictate the use of any particular > > > technology > > >> or protocol for transporting FEC data, managing the hosts, > > >> signaling > > >> the configuration information or encoding the configuration > > >> information. This provides flexibility and was one of the > > >> main goals > > >> of the FEC Framework. > > >> _______________________________________________ > > >> Fecframe mailing list > > >> Fecframe@ietf.org > > >> https://www.ietf.org/mailman/listinfo/fecframe > > >> > > > > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe > > From abegen@cisco.com Mon Jan 17 14:53:56 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 187CE3A6F56 for ; Mon, 17 Jan 2011 14:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dST2sArud65r for ; Mon, 17 Jan 2011 14:53:54 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4083A3A6D87 for ; Mon, 17 Jan 2011 14:53:54 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFdXNE2rR7Ht/2dsb2JhbACkVXOoKpk4gxKCPgSEb4lZ Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 17 Jan 2011 22:56:29 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0HMuT70016803; Mon, 17 Jan 2011 22:56:29 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 14:56:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 14:56:00 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCF6@xmb-sjc-215.amer.cisco.com> In-Reply-To: <6E57A7F4-41B8-474B-A140-A0566B9EB481@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Operations and Management Considerations (text for theframework) Thread-Index: Acu2jk0s1anxJWLnSUe+O2NOFGajxgACwFAQ References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> <04CAD96D4C5A3D48B1919248A8FE0D540DE2DDF1@xmb-sjc-215.amer.cisco.com> <65B2271C-42CB-4357-A79A-85908A9EC661@cisco.com> <6E57A7F4-41B8-474B-A140-A0566B9EB481@cisco.com> From: "Ali C. Begen (abegen)" To: "Dave Oran (oran)" , "David Harrington" X-OriginalArrivalTime: 17 Jan 2011 22:56:29.0407 (UTC) FILETIME=[C6F026F0:01CBB699] Cc: fecframe@ietf.org Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 22:53:56 -0000 > -----Original Message----- > From: Dave Oran (oran) > Sent: Monday, January 17, 2011 4:34 PM > To: David Harrington > Cc: Ali C. Begen (abegen); fecframe@ietf.org; 'Lars Eggert' > Subject: Re: [Fecframe] Operations and Management Considerations (text = for theframework) >=20 > Thanks for getting back to me on this. I think we're converging = (somewhat), or at least talking about the same things. >=20 > On Jan 17, 2011, at 4:06 PM, David Harrington wrote: >=20 > > Hi, > > > > I agree that it may make more sense to focus on the interoperability > > of specific fec schemes and features. > > > > The framework ops+mgmt considerations should SAY that, and should = set > > the requirement that framework-compliant components MUST specify > > mandatory-to-implement protocols for config and monitoring, so > > independently developed implementations have at least one protocol > > available for operators to deploy to provide interoperable = operations > > and interoperable management for each chosen fec scheme. > > > This seems a reasonable principle to follow. The devil is in the = details, especially in how the config and management for the > overall system(s) interact with the FEC-specific pieces. See below for = more. >=20 > > Of course, if each scheme chooses a different mandatory-to-implement > > protocol, then an entity that supports multiple fec schemes might = end > > up with a panoply of mandatory-to-implement protocols for config and > > monitoring, so it might make more sense to have at least one > > mandatory-to-implement protocol at the framework level, to ensure a > > minimum level of interoperability for config and monitoring. > > > If FEC schemes were "top-of-the-foodchain" kinds of protocol, like = TCP, or RTP, or SIP, then following this rule would in fact > help a lot in ensuring system-level interoperability for the = operations and management components of making the protocol > work and instrumenting it. Unfortunately (or perhaps in my view = fortunately), that's not the case here. FEC schemes are > pretty much without exception *embedded* in a "top-of-the-food-chain" = protocol like RTP, or reliable multicast file transfer. > That means one REALLY wants the operations and management protocols = and instrumentation framework to be dictated by > the embedding and not by the FEC scheme. In fact, I would consider it = undesirable if we picked and mandatory-to-implement > config/management protocol (e.g. SDP) for an FEC scheme, and then = embedded it in a different "top-of-the-food-chain" > system that has no need of SDP for anything. This is not entirely = theoretical; we already have FEC schemes in use by other > SDOs that use multicast file transfer and XML to describe and manage = the protocols with which which the FEC scheme is > based. It makes much more sense to ensure that the necessary = configuration and instrumentation information is present in > those protocols, than to declare the implementation non-compliant in = the IETF because the implementer didn't (uselessly) > put SDP in the system. >=20 > Therefore, I still maintain that: > - There isn't a lot to say in the framework draft, and find your = suggestion to limit language in that draft to saying that the > operations and management of FEC is "scheme specific" and that the = scheme RFCs MUST address O&M with the appropriate > O&M considerations section. This makes sense and agrees with what WG implicitly assumed so far IMO. > - if you at all buy my logic above, then it is not appropriate to = require "mandatory to implement" protocols in the scheme > drafts; rather, the requirement is for enough specific information = about configuration and instrumentation to give > implementors guidance about what changes/enhancements may be needed to = the protocols used in the "enclosing" protocol > environment. Indeed. One just needs to look at where FEC has been deployed so far and = how it has been used in large networks to appreciate the statement = above. =20 -acbegen > > The approach so far taken by this WG seems to be "let's just declare > > it out of scope" - i.e., have no standard mechanisms for configuring > > or monitoring FEC operations or specific FEC schemes. > That's a correct assessment of the WG's general approach, but I do not = view that criticism as necessarily all that serious > given the nature of the work. >=20 > > As far as I can > > see, that means that if vendor A's server wants to use fec = protection > > for something it is sending to a client from vendor B, and vendor A > > chooses one protocol for config, such as SDP, and vendor B chooses = not > > to support the same protocol, then the two endpoints cannot > > communicate to agree on a configuration. That would be a pretty sad > > situation for an IETF standard. > > > Not as sad as having an FEC scheme used with both RTP and with = Reliable file transfer being forced to add a lot of useless > complexity and introduce new interoperability problems for the system = they are embedded in because the two systems for > good reason use different configuration and management protocols. >=20 > I'm of course encouraged by the discussion, which has shed some light = on the underlying issues. I think that at least at this > point we are not in agreement about the right way forward, but = hopefully this has helped make some progress. >=20 > DaveO. >=20 >=20 > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > >> -----Original Message----- > >> From: David R Oran [mailto:oran@cisco.com] > >> Sent: Saturday, December 11, 2010 3:26 PM > >> To: Ali C. Begen (abegen) > >> Cc: David Harrington; fecframe@ietf.org > >> Subject: Re: [Fecframe] Operations and Management > >> Considerations (text for theframework) > >> > >> It seems to me that since this is a framework draft, what it > >> needs is a framework for how the FEC parts of a bigger system > >> affect the overall operations and management of that system. > >> While the current text may be view by the IESG as inadequate, > >> there is frankly not a whole lot other than motherhood to say > >> here. The framework is not a protocol with specific > >> mechanisms and state machines that need configuration and/or > >> fail in particular ways that need to be managed. Therefore, > >> while I think some of the cited requirements on enhancing the > >> draft make a certain amount of sense, the level of > >> specificity that is possible is quite low, so the "pain-gain" > >> ratio strikes at least this WG participant as not warranting > >> a whole lot of work. > >> > >> The kind of drafts where the O&M considerations become > >> concrete are documents like > >> > >> > > = http://datatracker.ietf.org/doc/draft-ietf-fecframe-config-signaling/ > >> > >> and > >> > >> http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/ > >> > >> I think there's more bang-for-the-buck in focusing the > >> limited energies of the FEC community there. > >> > >> DaveO. > >> > >> > >> On Dec 11, 2010, at 2:26 PM, Ali C. Begen (abegen) wrote: > >> > >>> Hi David, All, > >>> > >>> This was not an attempt for a punt or refusal. This was > >> simply a summary of what has been discussed in the WG and > >> design team in the past three years. I might have done a poor > >> job in summarizing it but your email is not concerned about it. > >>> > >>> I offered the text based on my knowledge and past meetings, > >> and asked the WG to provide input on it. There were no > >> objections. And from what we saw, I can tell that those of us > >> who actually run FEC systems were happy with the points or > >> arguments summarized in this section. I agree there is not > >> much detailed information but the section offers why it is so. > >>> > >>> The list you provided below involves many things that were > >> never discussed in this WG (at least to my knowledge), > >> largely because they were left outside the scope since the > >> beginning. I was still at school when fecframe was formed and > >> chartered but the current charter does not have much > >> (actually anything at all) related to the list below. If > >> these things indeed needed a specification, the charter > >> should have said so and they should have been worked on when > >> the framework draft was still developing and during the time > >> when we had a larger participation in the WG. > >>> > >>> I am happy with what the WG decides to do. As one of the > >> current editors, I am willing to contribute but this is a > >> daunting task, which will certainly require more than one > >> person. However, first I would like to see what everybody > >> thinks: are we missing essential information that we would > >> need in the field for fecframe apps? > >>> > >>> -acbegen > >>> > >>>> -----Original Message----- > >>>> From: David Harrington [mailto:ietfdbh@comcast.net] > >>>> Sent: Friday, December 10, 2010 8:31 AM > >>>> To: Ali C. Begen (abegen); fecframe@ietf.org > >>>> Subject: RE: [Fecframe] Operations and Management > >> Considerations (text for theframework) > >>>> > >>>> Hi, > >>>> > >>>> This is not adequate to address IESG concerns. > >>>> > >>>> You need to talk about what needs to be managed, and how it can > > be > >>>> managed in an interoperable manner. > >>>> > >>>> Excerpts from the IETF Mission statement: > >>>> The mission of the IETF is to make the Internet work better by > >>>> producing high quality, relevant technical documents that > > influence > >>>> the way people design, use, and manage the Internet... > >> when the IETF > >>>> takes ownership of a protocol or function, it accepts the > >>>> responsibility for all aspects of the protocol. > >>>> > >>>> This is an excerpt from another conversation that is > >> happening in the > >>>> IESG, and the statement has IESG and IAB consensus: > >>>> "IETF [...] has negative experience with two standards in the > > same > >>>> general area. When one vendor implements one standard and > > another > >>>> vendor implements the other standard, there is no > > interoperability. > >>>> The result is two disjoint communities, which is > >> considered a failure > >>>> in the IETF." > >>>> > >>>> Some IESG responses to your proposed text: > >>>> > >>>> - This is worse than a punt. This is an explicit refusal > >> to consider > >>>> the issues of operation or management, plus the addition > >> of text that > >>>> states "we will not do this in this draft". > >>>> > >>>> - As holder of the DISCUSS I would not clear the DISCUSS > >> based on the > >>>> proposed text. > >>>>> Defining tools for the operation and management of these hosts > > is > >>>> not within the scope of this specification. > >>>> Sure - it's a framework document. Yet discussion of the > >> operations and > >>>> management interoperability is IMO within scope as it is > >> part of the > >>>> interoperable framework. > >>>> > >>>> I strongly support these IESG positions. > >>>> > >>>> So, going forward, what we need to produce, as a starter, is > >>>> discussion of > >>>> 1) what are the critical errors in FEC processing, and how should > >>>> operators and applications respond to these errors? > >>>> 2) How should critical errors get reported to operators and > > network > >>>> management applications? > >>>> 3) How are the critical errors reported in a vendor-neutral > > manner? > >>>> 4) what is the ***standard*** for configuring FEC parameters, so > > we > >>>> have a minimum level of interoperability across vendors? > >> If there is > >>>> no need for such a standard, then it is questionable > >> whether this is > >>>> IETF work because the IETF works to develop vendor-neutral > >> standards > >>>> for interoperability across vendors. > >>>> 5) A standard set of functionality can be supplemented with > >>>> proprietary methods if desired, but there should be ONE method > > that > >>>> all compliant implementations support. > >>>> 6) What statistics should be maintained by senders and recievers > > of > >>>> FEC-protected content? Faults? performance measures? connections? > >>>> 7) What is the range of the statistics? What happens to > >> the statistics > >>>> when a device reboots? or a session restarts? > >>>> 8) I recommend you expand section 6 to standardize this feedback > >>>> information model in more detail. > >>>> - see RFC3444 about information models, > >>>> - see the BRIDGE-MIB for some guidelines about limiting the > >>>> information model to necessary infromation > >>>> - for those that participate in IEEE 802.1, you might want to > >>>> look at how they separate the information model form the data > > model > >>>> - how does pre- and post-encryption affect those statistics? > >>>> Should the use of pre-, -post-, or both encryption be > >> reported so an > >>>> operator can tell whether FEC configuration is properly > >> aligned with > >>>> domains of trust? > >>>> 9) How are the statistics reported to an operator or NM > >> application, > >>>> especially NM applications from another vendor? > >>>> 10) How are the statistics reported between receiver and sender? > > is > >>>> there in-line OAM functionality? What happens if there is a > > proxy? > >>>> > >>>> One of things that happens, when you refuse to properly consider > >>>> security and/or operations and management, is that you > >> tend to get a > >>>> bigger pushback in response. I think you are seriously beyond the > >>>> point of being able to say "how security is handled and > >> how operations > >>>> and manageent are handled is up to the operator." > >>>> > >>>> when the IETF takes ownership of a protocol or function, it > > accepts > >>>> the responsibility for all aspects of the protocol. > >>>> > >>>> David Harrington > >>>> Director, IETF Transport Area > >>>> ietfdbh@comcast.net (preferred for ietf) > >>>> dbharrington@huaweisymantec.com > >>>> +1 603 828 1401 (cell) > >>>> > >>>>> -----Original Message----- > >>>>> From: fecframe-bounces@ietf.org > >>>>> [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen > >>>> (abegen) > >>>>> Sent: Thursday, December 09, 2010 12:30 PM > >>>>> To: fecframe@ietf.org > >>>>> Subject: [Fecframe] Operations and Management Considerations > >>>>> (text for theframework) > >>>>> > >>>>> This is the text that will be incorporated into the framework > >>>>> draft (following up on the earlier discussion in the list). > >>>>> If there are any final comments, please send them to the list. > >>>>> > >>>>> Otherwise, we are waiting for the AD to give us a green light > >>>>> to move ahead with a submission to address the IESG comments. > >>>>> > >>>>> Thanks, > >>>>> -acbegen > >>>>> > >>>>> > >>>>> 10. Operations and Management Considerations > >>>>> > >>>>> The FEC Framework is concerned about the FEC encoding and > >>>> decoding > >>>>> operations, and the configuration information that is > > essential > >>>> to > >>>>> control the hosts running these operations. Defining tools > > for > >>>> the > >>>>> operation and management of these hosts is not within the > > scope > >>>> of > >>>>> this specification. > >>>>> > >>>>> Some applications using the CDPs compatible with the FEC > >>>> Framework > >>>>> are one-way meaning that they do not have a way to gather > >>>>> any kind of > >>>>> feedback from receivers (e.g., broadcast), while some > >> of them may > >>>>> collect detailed feedback (in case it is a one-to-one > >>>>> application) or > >>>>> occasional feedback (in case it is a multicast > >> application). All > >>>>> these applications have naturally different management > > aspects. > >>>> If > >>>>> any, they also have different requirements or features for > >>>>> collecting > >>>>> feedback, processing it and acting on it. The data structures > >>>> for > >>>>> carrying the feedback also vary. > >>>>> > >>>>> On the operations side, it is not advisable for the FEC > >>>>> Framework to > >>>>> explicitly list what the hosts (sender or receiver or even > >>>>> a middle- > >>>>> box) could do upon observing something in particular or > >> receiving > >>>> a > >>>>> specific feedback. The CDPs and the FEC schemes > >>>>> compatible with the > >>>>> FEC Framework SHOULD make use of existing tools as much as > >>>> possible > >>>>> and to the extent possible. For example, for repair flows > >>>>> using RTP > >>>>> transport, benefiting from all the features of RTCP > >> mechanisms is > >>>>> strongly RECOMMENDED since RTCP has already solved many of > > these > >>>>> issues in an agnostic way of the data carried with RTP. > >>>>> > >>>>> Overall, the CDPs and FEC schemes compatible with the FEC > >>>> Framework > >>>>> widely differ in their capabilities, application and > > deployment > >>>>> scenarios such that a common operation and management tool > >>>>> that works > >>>>> well for all of them does not exist. Thus, as a design > > choice, > >>>> the > >>>>> FEC Framework does not dictate the use of any particular > >>>> technology > >>>>> or protocol for transporting FEC data, managing the hosts, > >>>>> signaling > >>>>> the configuration information or encoding the configuration > >>>>> information. This provides flexibility and was one of the > >>>>> main goals > >>>>> of the FEC Framework. > >>>>> _______________________________________________ > >>>>> Fecframe mailing list > >>>>> Fecframe@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/fecframe > >>>>> > >>> > >>> _______________________________________________ > >>> Fecframe mailing list > >>> Fecframe@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fecframe > >> > >> > > From tme@americafree.tv Mon Jan 17 19:10:03 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB7128C0DC for ; Mon, 17 Jan 2011 19:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.259 X-Spam-Level: X-Spam-Status: No, score=-102.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIRRjdnllH3m for ; Mon, 17 Jan 2011 19:10:01 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 450BD3A6EE0 for ; Mon, 17 Jan 2011 19:10:01 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id A09669AE119F; Mon, 17 Jan 2011 22:12:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCF5@xmb-sjc-215.amer.cisco.com> Date: Mon, 17 Jan 2011 22:12:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> <6ADE359AAAF849669355FADD50F17053@davidPC> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCF5@xmb-sjc-215.amer.cisco.com> To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1081) Cc: fecframe@ietf.org Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 03:10:03 -0000 On Jan 17, 2011, at 5:51 PM, Ali C. Begen (abegen) wrote: > FWIW, none of the RTP deployments I am aware of (and I know several) = support RTP MIB. So, do different RTP implementations fail to = interoperate? Absolutely not. >=20 This matches my experience.=20 Regards Marshall > -acbegen >=20 >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Monday, January 17, 2011 5:36 PM >> To: 'Luby, Michael'; Ali C. Begen (abegen); fecframe@ietf.org >> Subject: RE: [Fecframe] Operations and Management Considerations = (text for theframework) >>=20 >> Hi Mike, >>=20 >> Sure, I'll take a whack! >>=20 >> The fecframe charter says "A primary objective of this framework is = to >> support FEC for real-time >> media applications using RTP over UDP, such as on demand streaming = and >>=20 >> audio/video broadcast." >>=20 >> The RTP MIB (RFC2959) is an example of the AVT approach to >> standardizing operations and management support. >> While RTP can support a variety of payloads, just as the FEC = framework >> can support multiple fec schemes, there are certain properties that >> exist regardless of payload (and correspondingly, regardless of fec >> scheme). >> The RTP MIB document discusses operational issues and how the MIB can >> be applied to detect/monitor/address those issues. >> For example, the RTP MIB allows an operator to >> 1) monitor what RTP sessions exist, >> 2) monitor what senders are active in the sessions, >> 3) monitor what receivers are active in the senders, >> 4) monitor statistics and operational state about the sessions, and >> 5) create and configure new sessions. >>=20 >> So the RTP MIB, and FEC-specific extensions to the RTP MIB, could be = a >> likely candidate for how to manage FEC sessions. >> A MIB module is a data model, that provides a concrete expression of >> an information model (see RFC3444). >>=20 >> If you'd like to write a MIB module, feel free. >> But the IESG is not demanding a MIB module. There are multiple >> protocols and data modeling languages that have been standardized >> since the RTP MIB was written, that might provide the necessary >> functionality, including syslog/SDE, netconf/YANG, ipfix/IE, and SDP. >> Other protocols might be more suitable to the environments where FEC >> may be applied. >>=20 >> The IESG is asking for a discussion of operational and management >> issues related to forward error correction, at the framework level, >> and a discussion of how independent implementations will be >> interoperable for operations and management: >> "[a framework] document is expected to include information about >> operational impact and manageability of >> devices and networks that will compy to the framework, also = indication >> about >> what kind of operations and manageability information future >> specifications of >> protocols that comply to the framwork would include. This document >> includes no >> such information." >>=20 >> My recommendation is to add a section that discusses operational >> impact, such as the expected increase in traffic load caused by >> deploying FEC. It would probabyl be good to require each FEC scheme = to >> discuss the expected impact of that scheme, and the effect of certain >> configuration settings. >> I recommend adding another section that addresses >> cross-vendor-interoperable manageability of entities complying with >> the framework, including interoperable configuration mechanisms, and >> interoperable mechanisms for reporting asynchronous errors, and >> interoperable mechanisms for reporting operational state and >> statistics. At some level, there should be mandatory-to-implement >> protocols and/or data models to ensure a minimum level of >> interoperability across implementations. The framework should = identify >> which level in the framework MUST require that interoperability. >>=20 >> David Harrington >> Director, IETF Transport Area >> ietfdbh@comcast.net (preferred for ietf) >> dbharrington@huaweisymantec.com >> +1 603 828 1401 (cell) >>=20 >>> -----Original Message----- >>> From: Luby, Michael [mailto:luby@qualcomm.com] >>> Sent: Saturday, December 11, 2010 4:40 PM >>> To: David Harrington; Ali C. Begen (abegen); fecframe@ietf.org >>> Subject: Re: [Fecframe] Operations and Management >>> Considerations (text for theframework) >>>=20 >>> Hi Dave, >>> Perhaps you could provide the equivalent text from the AVT >>> working group >>> that addresses this issue as a starting point for what the >>> corresponding >>> text could be in FECFRAME? The reason I suggest this is that >>> the AVT is >>> somewhat similar to FECFRAME, as in AVT there is the >>> standardization of >>> delivering different video codec formats to receivers, and >>> FECFRAME is about >>> delivering FEC data that protects those deliveries, so in this sense >>> FECFRAME is an adjunct to AVT and should be able to leverage >>> the general >>> framework specifications that AVT has that describes how to >>> manage video >>> delivery in an interoperable way. I'm sure there must be an >>> AVT standard >>> that addresses all the issues you raise below, and it sure >>> would be use that >>> as a starting point. >>> Mike >>>=20 >>>=20 >>> On 12/10/10 5:31 AM, "David Harrington" wrote: >>>=20 >>>> Hi, >>>>=20 >>>> This is not adequate to address IESG concerns. >>>>=20 >>>> You need to talk about what needs to be managed, and how it can be >>>> managed in an interoperable manner. >>>>=20 >>>> Excerpts from the IETF Mission statement: >>>> The mission of the IETF is to make the Internet work better by >>>> producing high quality, relevant technical documents that >> influence >>>> the way people design, use, and manage the Internet... when the >> IETF >>>> takes ownership of a protocol or function, it accepts the >>>> responsibility for all aspects of the protocol. >>>>=20 >>>> This is an excerpt from another conversation that is >>> happening in the >>>> IESG, and the statement has IESG and IAB consensus: >>>> "IETF [...] has negative experience with two standards in the same >>>> general area. When one vendor implements one standard and another >>>> vendor implements the other standard, there is no >> interoperability. >>>> The result is two disjoint communities, which is considered >>> a failure >>>> in the IETF." >>>>=20 >>>> Some IESG responses to your proposed text: >>>>=20 >>>> - This is worse than a punt. This is an explicit refusal to >> consider >>>> the issues of operation or management, plus the addition of >>> text that >>>> states "we will not do this in this draft". >>>>=20 >>>> - As holder of the DISCUSS I would not clear the DISCUSS >>> based on the >>>> proposed text. >>>>> Defining tools for the operation and management of these hosts is >>>> not within the scope of this specification. >>>> Sure - it's a framework document. Yet discussion of the >>> operations and >>>> management interoperability is IMO within scope as it is part of >> the >>>> interoperable framework. >>>>=20 >>>> I strongly support these IESG positions. >>>>=20 >>>> So, going forward, what we need to produce, as a starter, is >>>> discussion of >>>> 1) what are the critical errors in FEC processing, and how should >>>> operators and applications respond to these errors? >>>> 2) How should critical errors get reported to operators and >> network >>>> management applications? >>>> 3) How are the critical errors reported in a vendor-neutral >> manner? >>>> 4) what is the ***standard*** for configuring FEC parameters, so >> we >>>> have a minimum level of interoperability across vendors? If there >> is >>>> no need for such a standard, then it is questionable whether this >> is >>>> IETF work because the IETF works to develop vendor-neutral >> standards >>>> for interoperability across vendors. >>>> 5) A standard set of functionality can be supplemented with >>>> proprietary methods if desired, but there should be ONE method >> that >>>> all compliant implementations support. >>>> 6) What statistics should be maintained by senders and recievers >> of >>>> FEC-protected content? Faults? performance measures? connections? >>>> 7) What is the range of the statistics? What happens to the >>> statistics >>>> when a device reboots? or a session restarts? >>>> 8) I recommend you expand section 6 to standardize this feedback >>>> information model in more detail. >>>> - see RFC3444 about information models, >>>> - see the BRIDGE-MIB for some guidelines about limiting the >>>> information model to necessary infromation >>>> - for those that participate in IEEE 802.1, you might want to >>>> look at how they separate the information model form the data >> model >>>> - how does pre- and post-encryption affect those statistics? >>>> Should the use of pre-, -post-, or both encryption be reported so >> an >>>> operator can tell whether FEC configuration is properly aligned >> with >>>> domains of trust? >>>> 9) How are the statistics reported to an operator or NM >> application, >>>> especially NM applications from another vendor? >>>> 10) How are the statistics reported between receiver and sender? >> is >>>> there in-line OAM functionality? What happens if there is a proxy? >>>>=20 >>>> One of things that happens, when you refuse to properly consider >>>> security and/or operations and management, is that you tend to get >> a >>>> bigger pushback in response. I think you are seriously beyond the >>>> point of being able to say "how security is handled and how >>> operations >>>> and manageent are handled is up to the operator." >>>>=20 >>>> when the IETF takes ownership of a protocol or function, it >> accepts >>>> the responsibility for all aspects of the protocol. >>>>=20 >>>> David Harrington >>>> Director, IETF Transport Area >>>> ietfdbh@comcast.net (preferred for ietf) >>>> dbharrington@huaweisymantec.com >>>> +1 603 828 1401 (cell) >>>>=20 >>>>> -----Original Message----- >>>>> From: fecframe-bounces@ietf.org >>>>> [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen >>>> (abegen) >>>>> Sent: Thursday, December 09, 2010 12:30 PM >>>>> To: fecframe@ietf.org >>>>> Subject: [Fecframe] Operations and Management Considerations >>>>> (text for theframework) >>>>>=20 >>>>> This is the text that will be incorporated into the framework >>>>> draft (following up on the earlier discussion in the list). >>>>> If there are any final comments, please send them to the list. >>>>>=20 >>>>> Otherwise, we are waiting for the AD to give us a green light >>>>> to move ahead with a submission to address the IESG comments. >>>>>=20 >>>>> Thanks, >>>>> -acbegen >>>>>=20 >>>>>=20 >>>>> 10. Operations and Management Considerations >>>>>=20 >>>>> The FEC Framework is concerned about the FEC encoding and >>>> decoding >>>>> operations, and the configuration information that is >> essential >>>> to >>>>> control the hosts running these operations. Defining tools >> for >>>> the >>>>> operation and management of these hosts is not within the >> scope >>>> of >>>>> this specification. >>>>>=20 >>>>> Some applications using the CDPs compatible with the FEC >>>> Framework >>>>> are one-way meaning that they do not have a way to gather >>>>> any kind of >>>>> feedback from receivers (e.g., broadcast), while some >>> of them may >>>>> collect detailed feedback (in case it is a one-to-one >>>>> application) or >>>>> occasional feedback (in case it is a multicast >>> application). All >>>>> these applications have naturally different management >> aspects. >>>> If >>>>> any, they also have different requirements or features for >>>>> collecting >>>>> feedback, processing it and acting on it. The data structures >>>> for >>>>> carrying the feedback also vary. >>>>>=20 >>>>> On the operations side, it is not advisable for the FEC >>>>> Framework to >>>>> explicitly list what the hosts (sender or receiver or even >>>>> a middle- >>>>> box) could do upon observing something in particular or >>> receiving >>>> a >>>>> specific feedback. The CDPs and the FEC schemes >>>>> compatible with the >>>>> FEC Framework SHOULD make use of existing tools as much as >>>> possible >>>>> and to the extent possible. For example, for repair flows >>>>> using RTP >>>>> transport, benefiting from all the features of RTCP >>> mechanisms is >>>>> strongly RECOMMENDED since RTCP has already solved many of >> these >>>>> issues in an agnostic way of the data carried with RTP. >>>>>=20 >>>>> Overall, the CDPs and FEC schemes compatible with the FEC >>>> Framework >>>>> widely differ in their capabilities, application and >> deployment >>>>> scenarios such that a common operation and management tool >>>>> that works >>>>> well for all of them does not exist. Thus, as a design >> choice, >>>> the >>>>> FEC Framework does not dictate the use of any particular >>>> technology >>>>> or protocol for transporting FEC data, managing the hosts, >>>>> signaling >>>>> the configuration information or encoding the configuration >>>>> information. This provides flexibility and was one of the >>>>> main goals >>>>> of the FEC Framework. >>>>> _______________________________________________ >>>>> Fecframe mailing list >>>>> Fecframe@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/fecframe >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fecframe >>>=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 From ietfdbh@comcast.net Mon Jan 17 19:19:36 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284833A6E1B for ; Mon, 17 Jan 2011 19:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.775 X-Spam-Level: X-Spam-Status: No, score=-102.775 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RA6SgBzkU94 for ; Mon, 17 Jan 2011 19:19:34 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 25E9A3A6DB3 for ; Mon, 17 Jan 2011 19:19:34 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id wrJR1f0031c6gX85DrNAA7; Tue, 18 Jan 2011 03:22:10 +0000 Received: from davidPC ([67.189.235.106]) by omta23.westchester.pa.mail.comcast.net with comcast id wrN91f00C2JQnJT3jrN9g7; Tue, 18 Jan 2011 03:22:10 +0000 From: "David Harrington" To: "'Ali C. Begen \(abegen\)'" , "'Luby, Michael'" , References: <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> <6ADE359AAAF849669355FADD50F17053@davidPC> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCF5@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DCF5@xmb-sjc-215.amer.cisco.com> Date: Mon, 17 Jan 2011 22:21:56 -0500 Message-ID: <809E5EF191494DE79FDE66734F7D739C@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAnWz4wAEZTJucHQ9QboAADT1QQAAlPxUA= Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 03:19:36 -0000 The question is not whether RTP fails to interoperate but whether the management of RTP fails to interoperate. To configure a device and monitor RTP faults and performance can an operator use a standard protocol with a standard data model, or is the operator required to write custom scripts for each vendor's device, and possibly even each vendor's model? dbh > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Monday, January 17, 2011 5:51 PM > To: David Harrington; Luby, Michael; fecframe@ietf.org > Subject: RE: [Fecframe] Operations and Management > Considerations (text for theframework) > > FWIW, none of the RTP deployments I am aware of (and I know > several) support RTP MIB. So, do different RTP > implementations fail to interoperate? Absolutely not. > > -acbegen > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Monday, January 17, 2011 5:36 PM > > To: 'Luby, Michael'; Ali C. Begen (abegen); fecframe@ietf.org > > Subject: RE: [Fecframe] Operations and Management > Considerations (text for theframework) > > > > Hi Mike, > > > > Sure, I'll take a whack! > > > > The fecframe charter says "A primary objective of this > framework is to > > support FEC for real-time > > media applications using RTP over UDP, such as on demand > streaming and > > > > audio/video broadcast." > > > > The RTP MIB (RFC2959) is an example of the AVT approach to > > standardizing operations and management support. > > While RTP can support a variety of payloads, just as the > FEC framework > > can support multiple fec schemes, there are certain properties that > > exist regardless of payload (and correspondingly, regardless of fec > > scheme). > > The RTP MIB document discusses operational issues and how > the MIB can > > be applied to detect/monitor/address those issues. > > For example, the RTP MIB allows an operator to > > 1) monitor what RTP sessions exist, > > 2) monitor what senders are active in the sessions, > > 3) monitor what receivers are active in the senders, > > 4) monitor statistics and operational state about the sessions, and > > 5) create and configure new sessions. > > > > So the RTP MIB, and FEC-specific extensions to the RTP MIB, > could be a > > likely candidate for how to manage FEC sessions. > > A MIB module is a data model, that provides a concrete expression of > > an information model (see RFC3444). > > > > If you'd like to write a MIB module, feel free. > > But the IESG is not demanding a MIB module. There are multiple > > protocols and data modeling languages that have been standardized > > since the RTP MIB was written, that might provide the necessary > > functionality, including syslog/SDE, netconf/YANG, > ipfix/IE, and SDP. > > Other protocols might be more suitable to the environments where FEC > > may be applied. > > > > The IESG is asking for a discussion of operational and management > > issues related to forward error correction, at the framework level, > > and a discussion of how independent implementations will be > > interoperable for operations and management: > > "[a framework] document is expected to include information about > > operational impact and manageability of > > devices and networks that will compy to the framework, also > indication > > about > > what kind of operations and manageability information future > > specifications of > > protocols that comply to the framwork would include. This document > > includes no > > such information." > > > > My recommendation is to add a section that discusses operational > > impact, such as the expected increase in traffic load caused by > > deploying FEC. It would probabyl be good to require each > FEC scheme to > > discuss the expected impact of that scheme, and the effect > of certain > > configuration settings. > > I recommend adding another section that addresses > > cross-vendor-interoperable manageability of entities complying with > > the framework, including interoperable configuration mechanisms, and > > interoperable mechanisms for reporting asynchronous errors, and > > interoperable mechanisms for reporting operational state and > > statistics. At some level, there should be mandatory-to-implement > > protocols and/or data models to ensure a minimum level of > > interoperability across implementations. The framework > should identify > > which level in the framework MUST require that interoperability. > > > > David Harrington > > Director, IETF Transport Area > > ietfdbh@comcast.net (preferred for ietf) > > dbharrington@huaweisymantec.com > > +1 603 828 1401 (cell) > > > > > -----Original Message----- > > > From: Luby, Michael [mailto:luby@qualcomm.com] > > > Sent: Saturday, December 11, 2010 4:40 PM > > > To: David Harrington; Ali C. Begen (abegen); fecframe@ietf.org > > > Subject: Re: [Fecframe] Operations and Management > > > Considerations (text for theframework) > > > > > > Hi Dave, > > > Perhaps you could provide the equivalent text from the AVT > > > working group > > > that addresses this issue as a starting point for what the > > > corresponding > > > text could be in FECFRAME? The reason I suggest this is that > > > the AVT is > > > somewhat similar to FECFRAME, as in AVT there is the > > > standardization of > > > delivering different video codec formats to receivers, and > > > FECFRAME is about > > > delivering FEC data that protects those deliveries, so in > this sense > > > FECFRAME is an adjunct to AVT and should be able to leverage > > > the general > > > framework specifications that AVT has that describes how to > > > manage video > > > delivery in an interoperable way. I'm sure there must be an > > > AVT standard > > > that addresses all the issues you raise below, and it sure > > > would be use that > > > as a starting point. > > > Mike > > > > > > > > > On 12/10/10 5:31 AM, "David Harrington" > wrote: > > > > > > > Hi, > > > > > > > > This is not adequate to address IESG concerns. > > > > > > > > You need to talk about what needs to be managed, and > how it can be > > > > managed in an interoperable manner. > > > > > > > > Excerpts from the IETF Mission statement: > > > > The mission of the IETF is to make the Internet work better by > > > > producing high quality, relevant technical documents that > > influence > > > > the way people design, use, and manage the Internet... when the > > IETF > > > > takes ownership of a protocol or function, it accepts the > > > > responsibility for all aspects of the protocol. > > > > > > > > This is an excerpt from another conversation that is > > > happening in the > > > > IESG, and the statement has IESG and IAB consensus: > > > > "IETF [...] has negative experience with two standards > in the same > > > > general area. When one vendor implements one standard > and another > > > > vendor implements the other standard, there is no > > interoperability. > > > > The result is two disjoint communities, which is considered > > > a failure > > > > in the IETF." > > > > > > > > Some IESG responses to your proposed text: > > > > > > > > - This is worse than a punt. This is an explicit refusal to > > consider > > > > the issues of operation or management, plus the addition of > > > text that > > > > states "we will not do this in this draft". > > > > > > > > - As holder of the DISCUSS I would not clear the DISCUSS > > > based on the > > > > proposed text. > > > >> Defining tools for the operation and management of > these hosts is > > > > not within the scope of this specification. > > > > Sure - it's a framework document. Yet discussion of the > > > operations and > > > > management interoperability is IMO within scope as it is part of > > the > > > > interoperable framework. > > > > > > > > I strongly support these IESG positions. > > > > > > > > So, going forward, what we need to produce, as a starter, is > > > > discussion of > > > > 1) what are the critical errors in FEC processing, and > how should > > > > operators and applications respond to these errors? > > > > 2) How should critical errors get reported to operators and > > network > > > > management applications? > > > > 3) How are the critical errors reported in a vendor-neutral > > manner? > > > > 4) what is the ***standard*** for configuring FEC parameters, so > > we > > > > have a minimum level of interoperability across > vendors? If there > > is > > > > no need for such a standard, then it is questionable > whether this > > is > > > > IETF work because the IETF works to develop vendor-neutral > > standards > > > > for interoperability across vendors. > > > > 5) A standard set of functionality can be supplemented with > > > > proprietary methods if desired, but there should be ONE method > > that > > > > all compliant implementations support. > > > > 6) What statistics should be maintained by senders and recievers > > of > > > > FEC-protected content? Faults? performance measures? > connections? > > > > 7) What is the range of the statistics? What happens to the > > > statistics > > > > when a device reboots? or a session restarts? > > > > 8) I recommend you expand section 6 to standardize this feedback > > > > information model in more detail. > > > > - see RFC3444 about information models, > > > > - see the BRIDGE-MIB for some guidelines about limiting the > > > > information model to necessary infromation > > > > - for those that participate in IEEE 802.1, you might want to > > > > look at how they separate the information model form the data > > model > > > > - how does pre- and post-encryption affect those statistics? > > > > Should the use of pre-, -post-, or both encryption be > reported so > > an > > > > operator can tell whether FEC configuration is properly aligned > > with > > > > domains of trust? > > > > 9) How are the statistics reported to an operator or NM > > application, > > > > especially NM applications from another vendor? > > > > 10) How are the statistics reported between receiver and sender? > > is > > > > there in-line OAM functionality? What happens if there > is a proxy? > > > > > > > > One of things that happens, when you refuse to properly consider > > > > security and/or operations and management, is that you > tend to get > > a > > > > bigger pushback in response. I think you are seriously > beyond the > > > > point of being able to say "how security is handled and how > > > operations > > > > and manageent are handled is up to the operator." > > > > > > > > when the IETF takes ownership of a protocol or function, it > > accepts > > > > the responsibility for all aspects of the protocol. > > > > > > > > David Harrington > > > > Director, IETF Transport Area > > > > ietfdbh@comcast.net (preferred for ietf) > > > > dbharrington@huaweisymantec.com > > > > +1 603 828 1401 (cell) > > > > > > > >> -----Original Message----- > > > >> From: fecframe-bounces@ietf.org > > > >> [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen > > > > (abegen) > > > >> Sent: Thursday, December 09, 2010 12:30 PM > > > >> To: fecframe@ietf.org > > > >> Subject: [Fecframe] Operations and Management Considerations > > > >> (text for theframework) > > > >> > > > >> This is the text that will be incorporated into the framework > > > >> draft (following up on the earlier discussion in the list). > > > >> If there are any final comments, please send them to the list. > > > >> > > > >> Otherwise, we are waiting for the AD to give us a green light > > > >> to move ahead with a submission to address the IESG comments. > > > >> > > > >> Thanks, > > > >> -acbegen > > > >> > > > >> > > > >> 10. Operations and Management Considerations > > > >> > > > >> The FEC Framework is concerned about the FEC encoding and > > > > decoding > > > >> operations, and the configuration information that is > > essential > > > > to > > > >> control the hosts running these operations. Defining tools > > for > > > > the > > > >> operation and management of these hosts is not within the > > scope > > > > of > > > >> this specification. > > > >> > > > >> Some applications using the CDPs compatible with the FEC > > > > Framework > > > >> are one-way meaning that they do not have a way to gather > > > >> any kind of > > > >> feedback from receivers (e.g., broadcast), while some > > > of them may > > > >> collect detailed feedback (in case it is a one-to-one > > > >> application) or > > > >> occasional feedback (in case it is a multicast > > > application). All > > > >> these applications have naturally different management > > aspects. > > > > If > > > >> any, they also have different requirements or features for > > > >> collecting > > > >> feedback, processing it and acting on it. The data > structures > > > > for > > > >> carrying the feedback also vary. > > > >> > > > >> On the operations side, it is not advisable for the FEC > > > >> Framework to > > > >> explicitly list what the hosts (sender or receiver or even > > > >> a middle- > > > >> box) could do upon observing something in particular or > > > receiving > > > > a > > > >> specific feedback. The CDPs and the FEC schemes > > > >> compatible with the > > > >> FEC Framework SHOULD make use of existing tools as much as > > > > possible > > > >> and to the extent possible. For example, for repair flows > > > >> using RTP > > > >> transport, benefiting from all the features of RTCP > > > mechanisms is > > > >> strongly RECOMMENDED since RTCP has already solved many of > > these > > > >> issues in an agnostic way of the data carried with RTP. > > > >> > > > >> Overall, the CDPs and FEC schemes compatible with the FEC > > > > Framework > > > >> widely differ in their capabilities, application and > > deployment > > > >> scenarios such that a common operation and management tool > > > >> that works > > > >> well for all of them does not exist. Thus, as a design > > choice, > > > > the > > > >> FEC Framework does not dictate the use of any particular > > > > technology > > > >> or protocol for transporting FEC data, managing the hosts, > > > >> signaling > > > >> the configuration information or encoding the configuration > > > >> information. This provides flexibility and was one of the > > > >> main goals > > > >> of the FEC Framework. > > > >> _______________________________________________ > > > >> Fecframe mailing list > > > >> Fecframe@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/fecframe > > > >> > > > > > > > > _______________________________________________ > > > > Fecframe mailing list > > > > Fecframe@ietf.org > > > > https://www.ietf.org/mailman/listinfo/fecframe > > > > > From abegen@cisco.com Mon Jan 17 19:46:06 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250C428C0E2 for ; Mon, 17 Jan 2011 19:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.451 X-Spam-Level: X-Spam-Status: No, score=-10.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4k2ZmI0ZBPQ for ; Mon, 17 Jan 2011 19:46:04 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 09DCA3A6DB3 for ; Mon, 17 Jan 2011 19:46:04 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHycNE2rR7Ht/2dsb2JhbACkVnOoVplkgngagj4EhG+JWQ Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 18 Jan 2011 03:48:39 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0I3mdTH004224; Tue, 18 Jan 2011 03:48:39 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 19:48:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Jan 2011 19:48:36 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DD26@xmb-sjc-215.amer.cisco.com> In-Reply-To: <809E5EF191494DE79FDE66734F7D739C@davidPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Operations and Management Considerations (text for theframework) Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAnWz4wAEZTJucHQ9QboAADT1QQAAlPxUAAAG4/AA== References: <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> <6ADE359AAAF849669355FADD50F17053@davidPC> <04CAD96D4C5A3D48B1919248A8FE0D540E16DCF5@xmb-sjc-215.amer.cisco.com> <809E5EF191494DE79FDE66734F7D739C@davidPC> From: "Ali C. Begen (abegen)" To: "David Harrington" , "Luby, Michael" , X-OriginalArrivalTime: 18 Jan 2011 03:48:39.0821 (UTC) FILETIME=[97E10BD0:01CBB6C2] Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 03:46:06 -0000 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Monday, January 17, 2011 10:22 PM > To: Ali C. Begen (abegen); 'Luby, Michael'; fecframe@ietf.org > Subject: RE: [Fecframe] Operations and Management Considerations (text = for theframework) >=20 > The question is not whether RTP fails to interoperate but whether the > management of RTP fails to interoperate. RTP has a mandatory control protocol called RTCP not necessarily for = management only but for several things. Fecframe does not have such a = protocol and it does not need to have one. If RTP transport is used for = fecframe, one will directly use whatever tools available to RTP = including RTCP. RTP also makes use of SDP heavily. But, that is not to say that to use = RTP, one needs to implement SDP. Yeah, in the IETF world, we tend to = focus on SDP as the session description protocol but in the outer world, = different things are being used (e.g., XML based configuration files). To me, requiring SDP or something like XML for fecframe configuration is = a mistake. Similarly, requiring a MIB or something different for = feedback collection is also a mistake.=20 > To configure a device and monitor RTP faults and performance can an > operator use a standard protocol with a standard data model, or is the As I said, when possible/available, standard tools can be easily used by = fecframe.=20 > operator required to write custom scripts for each vendor's device, > and possibly even each vendor's model? Not if all those vendors followed the spec that made use of the fec = framework. Let me give you an example. If another organization wants to = use our framework in one of their standards, they will get the framework = but then they will likely to choose a transport protocol according to = their requirements, a configuration/session description protocol, a = signaling protocol and a feedback protocol - all according to their = needs. They will also decide what needs to be collected from the = endpoints as a feedback, and they might even go one step further and = define the actions that need to be taken for each such feedback. They = will outline and specify anything they think as necessary. They might = say, no more than X% of redundancy will ever be used. Or, they may limit = their spec to use certain fec schemes.=20 That is perfectly fine from their perspective and mine. But if we try to = do the same thing in the framework draft, we will not only confuse them = but doing so will also probably discourage them from using our framework = because our requirements may not be a good fit for their scenarios.=20 BTW, the framework draft is not an FEC 101 guide for operators. That is, = the framework draft should not be the first thing they need to read = about fec. That would be a gross mistake IMO. Framework draft is rather = a spec that defines some concepts so that fec schemes and CDPs can be = developed on top of it and it allows others to follow the same concepts = while also imposing some additional requirements.=20 -acbegen =20 > dbh >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Monday, January 17, 2011 5:51 PM > > To: David Harrington; Luby, Michael; fecframe@ietf.org > > Subject: RE: [Fecframe] Operations and Management > > Considerations (text for theframework) > > > > FWIW, none of the RTP deployments I am aware of (and I know > > several) support RTP MIB. So, do different RTP > > implementations fail to interoperate? Absolutely not. > > > > -acbegen > > > > > -----Original Message----- > > > From: David Harrington [mailto:ietfdbh@comcast.net] > > > Sent: Monday, January 17, 2011 5:36 PM > > > To: 'Luby, Michael'; Ali C. Begen (abegen); fecframe@ietf.org > > > Subject: RE: [Fecframe] Operations and Management > > Considerations (text for theframework) > > > > > > Hi Mike, > > > > > > Sure, I'll take a whack! > > > > > > The fecframe charter says "A primary objective of this > > framework is to > > > support FEC for real-time > > > media applications using RTP over UDP, such as on demand > > streaming and > > > > > > audio/video broadcast." > > > > > > The RTP MIB (RFC2959) is an example of the AVT approach to > > > standardizing operations and management support. > > > While RTP can support a variety of payloads, just as the > > FEC framework > > > can support multiple fec schemes, there are certain properties > that > > > exist regardless of payload (and correspondingly, regardless of > fec > > > scheme). > > > The RTP MIB document discusses operational issues and how > > the MIB can > > > be applied to detect/monitor/address those issues. > > > For example, the RTP MIB allows an operator to > > > 1) monitor what RTP sessions exist, > > > 2) monitor what senders are active in the sessions, > > > 3) monitor what receivers are active in the senders, > > > 4) monitor statistics and operational state about the sessions, > and > > > 5) create and configure new sessions. > > > > > > So the RTP MIB, and FEC-specific extensions to the RTP MIB, > > could be a > > > likely candidate for how to manage FEC sessions. > > > A MIB module is a data model, that provides a concrete expression > of > > > an information model (see RFC3444). > > > > > > If you'd like to write a MIB module, feel free. > > > But the IESG is not demanding a MIB module. There are multiple > > > protocols and data modeling languages that have been standardized > > > since the RTP MIB was written, that might provide the necessary > > > functionality, including syslog/SDE, netconf/YANG, > > ipfix/IE, and SDP. > > > Other protocols might be more suitable to the environments where > FEC > > > may be applied. > > > > > > The IESG is asking for a discussion of operational and management > > > issues related to forward error correction, at the framework > level, > > > and a discussion of how independent implementations will be > > > interoperable for operations and management: > > > "[a framework] document is expected to include information about > > > operational impact and manageability of > > > devices and networks that will compy to the framework, also > > indication > > > about > > > what kind of operations and manageability information future > > > specifications of > > > protocols that comply to the framwork would include. This > document > > > includes no > > > such information." > > > > > > My recommendation is to add a section that discusses operational > > > impact, such as the expected increase in traffic load caused by > > > deploying FEC. It would probabyl be good to require each > > FEC scheme to > > > discuss the expected impact of that scheme, and the effect > > of certain > > > configuration settings. > > > I recommend adding another section that addresses > > > cross-vendor-interoperable manageability of entities complying > with > > > the framework, including interoperable configuration mechanisms, > and > > > interoperable mechanisms for reporting asynchronous errors, and > > > interoperable mechanisms for reporting operational state and > > > statistics. At some level, there should be mandatory-to-implement > > > protocols and/or data models to ensure a minimum level of > > > interoperability across implementations. The framework > > should identify > > > which level in the framework MUST require that interoperability. > > > > > > David Harrington > > > Director, IETF Transport Area > > > ietfdbh@comcast.net (preferred for ietf) > > > dbharrington@huaweisymantec.com > > > +1 603 828 1401 (cell) > > > > > > > -----Original Message----- > > > > From: Luby, Michael [mailto:luby@qualcomm.com] > > > > Sent: Saturday, December 11, 2010 4:40 PM > > > > To: David Harrington; Ali C. Begen (abegen); fecframe@ietf.org > > > > Subject: Re: [Fecframe] Operations and Management > > > > Considerations (text for theframework) > > > > > > > > Hi Dave, > > > > Perhaps you could provide the equivalent text from the AVT > > > > working group > > > > that addresses this issue as a starting point for what the > > > > corresponding > > > > text could be in FECFRAME? The reason I suggest this is that > > > > the AVT is > > > > somewhat similar to FECFRAME, as in AVT there is the > > > > standardization of > > > > delivering different video codec formats to receivers, and > > > > FECFRAME is about > > > > delivering FEC data that protects those deliveries, so in > > this sense > > > > FECFRAME is an adjunct to AVT and should be able to leverage > > > > the general > > > > framework specifications that AVT has that describes how to > > > > manage video > > > > delivery in an interoperable way. I'm sure there must be an > > > > AVT standard > > > > that addresses all the issues you raise below, and it sure > > > > would be use that > > > > as a starting point. > > > > Mike > > > > > > > > > > > > On 12/10/10 5:31 AM, "David Harrington" > > wrote: > > > > > > > > > Hi, > > > > > > > > > > This is not adequate to address IESG concerns. > > > > > > > > > > You need to talk about what needs to be managed, and > > how it can be > > > > > managed in an interoperable manner. > > > > > > > > > > Excerpts from the IETF Mission statement: > > > > > The mission of the IETF is to make the Internet work better by > > > > > producing high quality, relevant technical documents that > > > influence > > > > > the way people design, use, and manage the Internet... when > the > > > IETF > > > > > takes ownership of a protocol or function, it accepts the > > > > > responsibility for all aspects of the protocol. > > > > > > > > > > This is an excerpt from another conversation that is > > > > happening in the > > > > > IESG, and the statement has IESG and IAB consensus: > > > > > "IETF [...] has negative experience with two standards > > in the same > > > > > general area. When one vendor implements one standard > > and another > > > > > vendor implements the other standard, there is no > > > interoperability. > > > > > The result is two disjoint communities, which is considered > > > > a failure > > > > > in the IETF." > > > > > > > > > > Some IESG responses to your proposed text: > > > > > > > > > > - This is worse than a punt. This is an explicit refusal to > > > consider > > > > > the issues of operation or management, plus the addition of > > > > text that > > > > > states "we will not do this in this draft". > > > > > > > > > > - As holder of the DISCUSS I would not clear the DISCUSS > > > > based on the > > > > > proposed text. > > > > >> Defining tools for the operation and management of > > these hosts is > > > > > not within the scope of this specification. > > > > > Sure - it's a framework document. Yet discussion of the > > > > operations and > > > > > management interoperability is IMO within scope as it is part > of > > > the > > > > > interoperable framework. > > > > > > > > > > I strongly support these IESG positions. > > > > > > > > > > So, going forward, what we need to produce, as a starter, is > > > > > discussion of > > > > > 1) what are the critical errors in FEC processing, and > > how should > > > > > operators and applications respond to these errors? > > > > > 2) How should critical errors get reported to operators and > > > network > > > > > management applications? > > > > > 3) How are the critical errors reported in a vendor-neutral > > > manner? > > > > > 4) what is the ***standard*** for configuring FEC parameters, > so > > > we > > > > > have a minimum level of interoperability across > > vendors? If there > > > is > > > > > no need for such a standard, then it is questionable > > whether this > > > is > > > > > IETF work because the IETF works to develop vendor-neutral > > > standards > > > > > for interoperability across vendors. > > > > > 5) A standard set of functionality can be supplemented with > > > > > proprietary methods if desired, but there should be ONE method > > > that > > > > > all compliant implementations support. > > > > > 6) What statistics should be maintained by senders and > recievers > > > of > > > > > FEC-protected content? Faults? performance measures? > > connections? > > > > > 7) What is the range of the statistics? What happens to the > > > > statistics > > > > > when a device reboots? or a session restarts? > > > > > 8) I recommend you expand section 6 to standardize this > feedback > > > > > information model in more detail. > > > > > - see RFC3444 about information models, > > > > > - see the BRIDGE-MIB for some guidelines about limiting the > > > > > information model to necessary infromation > > > > > - for those that participate in IEEE 802.1, you might want to > > > > > look at how they separate the information model form the data > > > model > > > > > - how does pre- and post-encryption affect those statistics? > > > > > Should the use of pre-, -post-, or both encryption be > > reported so > > > an > > > > > operator can tell whether FEC configuration is properly > aligned > > > with > > > > > domains of trust? > > > > > 9) How are the statistics reported to an operator or NM > > > application, > > > > > especially NM applications from another vendor? > > > > > 10) How are the statistics reported between receiver and > sender? > > > is > > > > > there in-line OAM functionality? What happens if there > > is a proxy? > > > > > > > > > > One of things that happens, when you refuse to properly > consider > > > > > security and/or operations and management, is that you > > tend to get > > > a > > > > > bigger pushback in response. I think you are seriously > > beyond the > > > > > point of being able to say "how security is handled and how > > > > operations > > > > > and manageent are handled is up to the operator." > > > > > > > > > > when the IETF takes ownership of a protocol or function, it > > > accepts > > > > > the responsibility for all aspects of the protocol. > > > > > > > > > > David Harrington > > > > > Director, IETF Transport Area > > > > > ietfdbh@comcast.net (preferred for ietf) > > > > > dbharrington@huaweisymantec.com > > > > > +1 603 828 1401 (cell) > > > > > > > > > >> -----Original Message----- > > > > >> From: fecframe-bounces@ietf.org > > > > >> [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen > > > > > (abegen) > > > > >> Sent: Thursday, December 09, 2010 12:30 PM > > > > >> To: fecframe@ietf.org > > > > >> Subject: [Fecframe] Operations and Management Considerations > > > > >> (text for theframework) > > > > >> > > > > >> This is the text that will be incorporated into the framework > > > > >> draft (following up on the earlier discussion in the list). > > > > >> If there are any final comments, please send them to the > list. > > > > >> > > > > >> Otherwise, we are waiting for the AD to give us a green light > > > > >> to move ahead with a submission to address the IESG comments. > > > > >> > > > > >> Thanks, > > > > >> -acbegen > > > > >> > > > > >> > > > > >> 10. Operations and Management Considerations > > > > >> > > > > >> The FEC Framework is concerned about the FEC encoding and > > > > > decoding > > > > >> operations, and the configuration information that is > > > essential > > > > > to > > > > >> control the hosts running these operations. Defining > tools > > > for > > > > > the > > > > >> operation and management of these hosts is not within the > > > scope > > > > > of > > > > >> this specification. > > > > >> > > > > >> Some applications using the CDPs compatible with the FEC > > > > > Framework > > > > >> are one-way meaning that they do not have a way to gather > > > > >> any kind of > > > > >> feedback from receivers (e.g., broadcast), while some > > > > of them may > > > > >> collect detailed feedback (in case it is a one-to-one > > > > >> application) or > > > > >> occasional feedback (in case it is a multicast > > > > application). All > > > > >> these applications have naturally different management > > > aspects. > > > > > If > > > > >> any, they also have different requirements or features for > > > > >> collecting > > > > >> feedback, processing it and acting on it. The data > > structures > > > > > for > > > > >> carrying the feedback also vary. > > > > >> > > > > >> On the operations side, it is not advisable for the FEC > > > > >> Framework to > > > > >> explicitly list what the hosts (sender or receiver or even > > > > >> a middle- > > > > >> box) could do upon observing something in particular or > > > > receiving > > > > > a > > > > >> specific feedback. The CDPs and the FEC schemes > > > > >> compatible with the > > > > >> FEC Framework SHOULD make use of existing tools as much as > > > > > possible > > > > >> and to the extent possible. For example, for repair flows > > > > >> using RTP > > > > >> transport, benefiting from all the features of RTCP > > > > mechanisms is > > > > >> strongly RECOMMENDED since RTCP has already solved many of > > > these > > > > >> issues in an agnostic way of the data carried with RTP. > > > > >> > > > > >> Overall, the CDPs and FEC schemes compatible with the FEC > > > > > Framework > > > > >> widely differ in their capabilities, application and > > > deployment > > > > >> scenarios such that a common operation and management tool > > > > >> that works > > > > >> well for all of them does not exist. Thus, as a design > > > choice, > > > > > the > > > > >> FEC Framework does not dictate the use of any particular > > > > > technology > > > > >> or protocol for transporting FEC data, managing the hosts, > > > > >> signaling > > > > >> the configuration information or encoding the > configuration > > > > >> information. This provides flexibility and was one of the > > > > >> main goals > > > > >> of the FEC Framework. > > > > >> _______________________________________________ > > > > >> Fecframe mailing list > > > > >> Fecframe@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/fecframe > > > > >> > > > > > > > > > > _______________________________________________ > > > > > Fecframe mailing list > > > > > Fecframe@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/fecframe > > > > > > > > From ietfdbh@comcast.net Tue Jan 18 10:07:22 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13EE28C0F1; Tue, 18 Jan 2011 10:07:22 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2ty+fGn6Xlv; Tue, 18 Jan 2011 10:07:22 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6EA3A7054; Tue, 18 Jan 2011 10:07:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: David Harrington To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110118180721.10571.34908.idtracker@localhost> Date: Tue, 18 Jan 2011 10:07:21 -0800 Cc: fecframe-chairs@tools.ietf.org, draft-ietf-fecframe-framework@tools.ietf.org, fecframe@ietf.org Subject: [Fecframe] David Harrington's Discuss on draft-ietf-fecframe-framework-11: (with DISCUSS) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:07:23 -0000 David Harrington has entered the following ballot position for draft-ietf-fecframe-framework-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1) I support Dan's and Adrian's concerns about the lack of operations and m= anagement considerations in this draft. It is the intention of the area directors and chairs to close this WG soon.= Therefore, there is no planned work on operations and management in charte= red drafts, making it even more important that it be discussed in the curre= nt WG document set. FEC is an add-on functionality to other streams of data, and the nature of = that data can vary widely, and the requirements for the corresponding FEC p= rotection can vary widely as a result. The operational impact and the manag= ement of the FEC add-on functionality depends a great deal on the specifics= of the data environment. The WG consensus is that the existing management = solution used in the data environment should be used to provide the managem= ent of the FEC add-on, and no mandatory-to-implement protocols or data mode= ls, or even information models are called for. As a result, the WG consensu= s is that there really isn't much to say about operations and management. = I disagree with this WG assessment. I agree the framework document in parti= cular should include information about operational impact of using FEC prot= ection, the expected manageability of devices and networks that will comply= to the framework, and discussion of what kind of operations and manageabil= ity information future specifications of protocols and components that comply to the framework, such as new FEC sche= mes, should include in their discussions of operations and management. = I think the document should discuss the design decision to have management = provided by the existing management solution of the data environment, and t= he impact this will have on management interoperability, and the operationa= l impact of having no mandatory-to-implement management functionality avail= able for operators to choose to use in their deployment. 2) This is a discuss-discuss about mandatory-to-implement components for a = standard. = Part of the problem that leads to my #1 point is that the framework appears= to have no mandatory-to-implement components.Despite a charter that states= that "A primary objective of this framework is to support FEC for real-tim= e media applications using RTP over UDP, such as on demand streaming and au= dio/video broadcast", the WG has chosen to not make RTP a mandatory-to-impl= ement component of the framework. The WG is producing an SDP draft for the= framework, but makes it optional to implement. The security considerations= section does not make any protocol mandatory to implement. and there is no= mandatory-to-implement management protocol. = Having dealt with the SNMPv3 franeowrk and its mandatory parts, I have rese= rvations about making specific components mandatory, but I think not making= any mandatory is a problem. = From ietfdbh@comcast.net Tue Jan 18 10:10:54 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779013A7023 for ; Tue, 18 Jan 2011 10:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=-0.454, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2FWT7sj6sdY for ; Tue, 18 Jan 2011 10:10:52 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id C64183A705E for ; Tue, 18 Jan 2011 10:10:51 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id x5g41f00A1ap0As516DW93; Tue, 18 Jan 2011 18:13:30 +0000 Received: from davidPC ([67.189.235.106]) by omta22.westchester.pa.mail.comcast.net with comcast id x6DV1f0062JQnJT3i6DVcS; Tue, 18 Jan 2011 18:13:30 +0000 From: "David Harrington" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D540DEF39DC@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DEF39DC@xmb-sjc-215.amer.cisco.com> Date: Tue, 18 Jan 2011 13:13:15 -0500 Message-ID: <3159C2BDFE7341DEA5226A1098062050@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: AcueCxews5v+ilRKRFaHhxvsQr3dHAZL9NyA Subject: Re: [Fecframe] Revised security section for the framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:10:54 -0000 Hi, FYI. Today I raised my concerns to the level of a DISCUSS. The content of the DISCUSS is being sent under a separate email. I have two parts to my discuss 1) the lack of discussion of ops+mgmt. I have tried to make my comments actionable. 2) a larger concern thatthe frameowkr has no mandatory-to-implement components. This is a discuss-discuss, which means I am opening the discussion within the IESG about whether this is acceptable for a Proposed Standard framework document. dbh > -----Original Message----- > From: fecframe-bounces@ietf.org > [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) > Sent: Friday, December 17, 2010 11:57 AM > To: fecframe@ietf.org > Subject: [Fecframe] Revised security section for the framework > > Please let us know if these changes are good or if you have > comments. We would like to conclude this work soon. > > -acbegen > > > 9. Security Considerations > > First of all, it must be clear that the application of FEC > protection > to a stream does not provide any kind of security. On the > opposite, > the FEC Framework itself could be subject to attacks, or could pose > new security risks. The goals of this section are to state the > problem, discuss the risks and identify solutions when > feasible. It > also defines a mandatory to implement (but not mandatory to use) > security scheme. > > 9.1. Problem Statement > > A content delivery system is potentially subject to many attacks. > Attacks can target the content, or the CDP, or the network itself, > with completely different consequences, in particular in > terms of the > number of impacted nodes. > > Attacks can have several goals: > > o They can try to give access to a confidential content (e.g., in > case of a non-free content). > > o They can try to corrupt the source flows (e.g., to prevent a > receiver from using them), which is a form of DoS attack. > > o They can try to compromise the receiver's behavior (e.g., by > making the decoding of an object computationally > expensive), which > is another form of DoS attack. > > o They can try to compromise the network's behavior (e.g., by > causing congestion within the network), which > potentially impacts > a large number of nodes. > > These attacks can be launched either against the source > and/or repair > flows (e.g., by sending fake FEC source and/or repair packets) or > against the FEC parameters that are sent either in-band > (e.g., in the > Repair FEC Payload ID or in the Explicit Source FEC Payload ID) or > out-of-band (e.g., in the FEC Framework Configuration Information). > > Several dimensions to the problem need to be considered. The first > one is the way the FEC Framework is used. The FEC Framework can be > used end-to-end, i.e., it can be included in the final end-device > where the upper application runs; or the FEC Framework can > be used in > middleboxes, for instance, to globally protect several source flows > exchanged between two or more distant sites. > > A second dimension is the threat model. When the FEC Framework > operates in the end-device, this device (e.g., a personal computer) > might be subject to attacks. Here, the attacker is either the end- > user (who might want to access confidential content) or somebody > else. In all cases the attacker has access to the end-device, but > not necessarily to the full control of the end-device (a secure > domain can exist). Similarly, when the FEC Framework operates in a > middlebox, this middlebox can be subject to attacks or the attacker > can gain access to it. The threats can also concern the end-to-end > transport (e.g., through Internet). Here, examples of threats > include the transmission of fake FEC source or repair packets, the > replay of valid packets, the drop, delay or misordering of packets, > and of course traffic eavesdropping. > > The third dimension consists in the desired security > services. Among > them, the content integrity and sender authentication services are > probably the most important features. We can also mention DoS > mitigation, anti-replay protection or content confidentiality. > > Finally, the fourth dimension consists in the security tools > available. This is the case of the various Digital Rights > Management > (DRM) systems, defined out of the context of the IETF and > that can be > proprietary solutions. Otherwise SRTP and IPsec/ESP are two tools > that can turn out to be useful in the context of the FEC Framework. > Note that using SRTP requires that the application generates RTP > source flows and, when applied below the FEC Framework, > that both the > FEC source and repair packets to be regular RTP packets. Therefore > SRTP is not considered as a universal solution applicable > in all use > cases. > > In the following sections, we further discuss security aspects > related to the use of the FEC Framework. > > 9.2. Attacks Against the Data Flows > > 9.2.1. Access to Confidential Content > > Access control to the source flow being transmitted is typically > provided by means of encryption. This encryption can be > done by the > content provider itself, or within the application (for instance by > using the Secure Real-time Transport Protocol (SRTP) [RFC3711]), or > at the network layer, on a per-packet basis when IPsec/ESP is used > [RFC4303]. If confidentiality is a concern, it is RECOMMENDED that > one of these solutions is used. Even if we mention these attacks > here, they are neither related to nor facilitated by the > use of FEC. > > Note that when encryption is applied, this encryption MUST > either be > applied on the source data before the FEC protection, or if done > after the FEC protection, then both the FEC source packets > and repair > packets MUST be encrypted (and an encryption at least as > cryptographically secure as the encryption applied on the > FEC source > packets MUST be used for the FEC repair packets). Otherwise, if > encryption were to be performed only on the FEC source > packets after > FEC encoding, a non-authorized receiver could be able to > recover the > source data after decoding the FEC repair packets provided that a > sufficient number of such packets were available. > > The following considerations apply when choosing where to apply > encryption (and more generally where to apply security services > beyond encryption). Once decryption has taken place, the > source data > is in plaintext. The full path between the output of the > deciphering > module and the final destination (e.g., the TV display in case of a > video) MUST be secured, in order to prevent any unauthorized access > to the source data. > > When the FEC Framework endpoint is the end system (i.e., where the > upper application runs) and if the threat model includes the > possibility that an attacker has access to this end > system, then the > end system architecture is very important. More > precisely, in order > to prevent an attacker to get hold of the plaintext, all > processings, > once deciphering has taken place, MUST occur in a protected > environment. If encryption is applied after FEC protection at the > sending side (i.e., below FEC Framework), it means that > FEC decoding > MUST take place in the protected environment. With certain use > cases, this MAY be complicated or even impossible. In that case > applying encryption before FEC protection is preferred. > > When the FEC Framework endpoint is a middlebox, the > recovered source > flow, after FEC decoding, SHOULD NOT be sent in plaintext to the > final destination(s) if the threat model includes the possibility > that an attacker eavesdrops the traffic. In that case also it is > preferred to apply encryption before FEC protection. > > In some cases, encryption could be applied both before and > after the > FEC protection. The considerations described above still apply in > such cases. > > 9.2.2. Content Corruption > > Protection against corruptions (e.g., against forged FEC source/ > repair packets) is achieved by means of a content integrity > verification/source authentication scheme. This service is usually > provided at the packet level. In this case, after removing all the > forged packets, the source flow might sometimes be recovered. > Several techniques can provide this content integrity/source > authentication service: > > o At the application layer, SRTP [RFC3711] provides several > solutions to check the integrity and authenticate the source of > RTP and RTCP messages, among other services. For instance, > associated to the Timed Efficient Stream Loss-Tolerant > Authentication (TESLA) [RFC4383], SRTP is an attractive solution > that is robust to losses, provides a true > authentication/integrity > service, and does not create any prohibitive processing load or > transmission overhead. Yet, checking a packet requires a small > delay (a second or more) after its reception with > TESLA. Whether > this extra delay, both in terms of startup delay at the > client and > end-to-end delay, is appropriate or not depends on the > target use > case. In some situations, this might degrade the user > experience. > In other situations, this will not be an issue. Other building > blocks can be used within SRTP to provide content integrity/ > authentication services. > > o At the network layer, IPsec/ESP [RFC4303] offers (among other > services) an integrity verification mechanism that can > be used to > provide authentication/content integrity services. > > It is up to the developer and the person in charge of > deployment, who > know the security requirements and features of the target > application > area, to define which solution is the most appropriate. > Nonetheless > it is RECOMMENDED that at least one of these techniques is used. > > Note that when integrity protection is applied, it is RECOMMENDED > that it takes place on both FEC source and repair packets. The > motivation is to avoid corrupted packets to be considered during > decoding, which would often lead to a decoding failure or > result in a > corrupted decoded source flow. > > 9.3. Attacks Against the FEC Parameters > > Attacks on these FEC parameters can prevent the decoding of the > associated object. For instance, modifying the finite > field size of > a Reed-Solomon FEC scheme (when applicable) will lead a receiver to > consider a different FEC code. > > It is therefore RECOMMENDED that security measures are taken to > guarantee the FEC Framework Configuration Information integrity. > Since the FEC Framework does not define how the FEC Framework > Configuration Information is communicated from sender to > receiver, we > cannot provide further recommendations on how to guarantee its > integrity. However, any complete CDP specification MUST give > recommendations on how to achieve it. When the FEC Framework > Configuration Information is sent out-of-band, e.g., in a session > description, it SHOULD be protected, for instance, by digitally > signing it. > > Attacks are also possible against some FEC parameters > included in the > Explicit Source FEC Payload ID and Repair FEC Payload ID. For > instance, modifying the Source Block Number of an FEC source or > repair packet will lead a receiver to assign this packet to a wrong > block. > > It is therefore RECOMMENDED that security measures are taken to > guarantee the Explicit Source FEC Payload ID and Repair FEC Payload > ID integrity. To that purpose, one of the packet-level source > authentication/content integrity techniques of Section 9.2.2 can be > used. > > 9.4. When Several Source Flows are to be Protected Together > > When several source flows, with different security > requirements, need > to be FEC protected jointly, within a single FEC Framework > instance, > then each flow MAY be processed appropriately, before the > protection. > For instance, source Flows that require access control MAY be > encrypted before they are FEC protected. > > There are also situations where the only insecure domain is the one > over which the FEC Framework operates. In that case, this > situation > MAY be addressed at the network layer, using IPsec/ESP (see > Section 9.5), even if only a subset of the source flows have strict > security requirements. > > Since the use of FEC Framework should not add any > additional threat, > it is RECOMMENDED that the FEC Framework aggregate flow be in line > with the maximum security requirements of the individual source > flows. For instance, if denial-of-service (DoS) protection is > required, an integrity protection SHOULD be provided below the FEC > Framework, using for instance IPsec/ESP. > > Generally speaking, whenever feasible, it is RECOMMENDED > to avoid FEC > protecting flows with totally different security requirements. > Otherwise, an important processing would be added to protect the > source flows that do not need it. > > 9.5. Baseline Secure FEC Framework Operation > > This section describes a baseline mode of secure FEC Framework > operation based on the application of the IPsec security protocol, > which is one possible solution to solve or mitigate the security > threats introduced by the use of the FEC Framework. > > Two related documents are of interest. First, Section 5.1 of > [RFC5775] defines a baseline secure ALC operation for > sender-to-group > transmissions, assuming the presence of a single sender > and a source- > specific multicast (SSM) or SSM-like operation. The proposed > solution, based on IPsec/ESP, can be used to provide a baseline FEC > Framework secure operation, for the downstream source flow. > > Second, Section 7.1 of [RFC5740] defines a baseline secure NORM > operation, for sender-to-group transmissions as well as unicast > feedbacks from receivers. Here, it is also assumed there > is a single > sender. The proposed solution is also based on IPsec/ESP. > However, > the difference with respect to the first document relies on the > management of IPsec Security Associations (SA) and corresponding > Security Policy Database (SPD) entries, since NORM > requires a second > set of SA and SPD to be defined to protect unicast feedbacks from > receivers. > > The FEC Framework has been defined in such a way to be independent > from the application that generates source flows. Some > applications > might use purely unidirectional flows, while other > applications might > also use unicast feedbacks from the receivers. For > instance, this is > the case when considering RTP/RTCP based source flows. > Depending on > the specific situation, it is RECOMMENDED that the baseline secure > FEC Framework operation inherits from [RFC5775] in case of purely > unidirectional sender-to-group flows, or [RFC5740] in case both > sender-to-group and unicast feedbacks flows are needed. > > Note that the IPsec/ESP requirements profiles outlined in [RFC5775] > and [RFC5740] are commonly available on many potential hosts. They > can form the basis of a secure mode of operation. One potential > limitation, however, is the need for privileged user authorization. > However, automated key management implementations are typically > configured with the privileges necessary to affect system IPsec > configuration. > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From abegen@cisco.com Tue Jan 18 10:14:34 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38933A705E for ; Tue, 18 Jan 2011 10:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.156 X-Spam-Level: X-Spam-Status: No, score=-10.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZ+tCehjr41P for ; Tue, 18 Jan 2011 10:14:33 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1BE1F3A7058 for ; Tue, 18 Jan 2011 10:14:33 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOpnNU2rR7Ht/2dsb2JhbACkVHOoNZoJgniCWASEb4lZ Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 18 Jan 2011 18:17:10 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0IIH8CB016821; Tue, 18 Jan 2011 18:17:10 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 10:17:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jan 2011 10:17:08 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DE62@xmb-sjc-215.amer.cisco.com> In-Reply-To: <3159C2BDFE7341DEA5226A1098062050@davidPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Revised security section for the framework Thread-Index: AcueCxews5v+ilRKRFaHhxvsQr3dHAZL9NyAAAA5QBA= References: <04CAD96D4C5A3D48B1919248A8FE0D540DEF39DC@xmb-sjc-215.amer.cisco.com> <3159C2BDFE7341DEA5226A1098062050@davidPC> From: "Ali C. Begen (abegen)" To: "David Harrington" , X-OriginalArrivalTime: 18 Jan 2011 18:17:09.0054 (UTC) FILETIME=[EB66FDE0:01CBB73B] Subject: Re: [Fecframe] Revised security section for the framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:14:34 -0000 Should we submit the current version we have with the extended security = cons section so that at least we can try to clear the sec related = discusses?=20 -acbegen > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, January 18, 2011 1:13 PM > To: Ali C. Begen (abegen); fecframe@ietf.org > Subject: RE: [Fecframe] Revised security section for the framework >=20 > Hi, >=20 > FYI. Today I raised my concerns to the level of a DISCUSS. > The content of the DISCUSS is being sent under a separate email. >=20 > I have two parts to my discuss > 1) the lack of discussion of ops+mgmt. I have tried to make my > comments actionable. > 2) a larger concern thatthe frameowkr has no mandatory-to-implement > components. This is a discuss-discuss, which means I am opening the > discussion within the IESG about whether this is acceptable for a > Proposed Standard framework document. >=20 > dbh >=20 > > -----Original Message----- > > From: fecframe-bounces@ietf.org > > [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen > (abegen) > > Sent: Friday, December 17, 2010 11:57 AM > > To: fecframe@ietf.org > > Subject: [Fecframe] Revised security section for the framework > > > > Please let us know if these changes are good or if you have > > comments. We would like to conclude this work soon. > > > > -acbegen > > > > > > 9. Security Considerations > > > > First of all, it must be clear that the application of FEC > > protection > > to a stream does not provide any kind of security. On the > > opposite, > > the FEC Framework itself could be subject to attacks, or could > pose > > new security risks. The goals of this section are to state the > > problem, discuss the risks and identify solutions when > > feasible. It > > also defines a mandatory to implement (but not mandatory to use) > > security scheme. > > > > 9.1. Problem Statement > > > > A content delivery system is potentially subject to many attacks. > > Attacks can target the content, or the CDP, or the network > itself, > > with completely different consequences, in particular in > > terms of the > > number of impacted nodes. > > > > Attacks can have several goals: > > > > o They can try to give access to a confidential content (e.g., > in > > case of a non-free content). > > > > o They can try to corrupt the source flows (e.g., to prevent a > > receiver from using them), which is a form of DoS attack. > > > > o They can try to compromise the receiver's behavior (e.g., by > > making the decoding of an object computationally > > expensive), which > > is another form of DoS attack. > > > > o They can try to compromise the network's behavior (e.g., by > > causing congestion within the network), which > > potentially impacts > > a large number of nodes. > > > > These attacks can be launched either against the source > > and/or repair > > flows (e.g., by sending fake FEC source and/or repair packets) or > > against the FEC parameters that are sent either in-band > > (e.g., in the > > Repair FEC Payload ID or in the Explicit Source FEC Payload ID) > or > > out-of-band (e.g., in the FEC Framework Configuration > Information). > > > > Several dimensions to the problem need to be considered. The > first > > one is the way the FEC Framework is used. The FEC Framework can > be > > used end-to-end, i.e., it can be included in the final end-device > > where the upper application runs; or the FEC Framework can > > be used in > > middleboxes, for instance, to globally protect several source > flows > > exchanged between two or more distant sites. > > > > A second dimension is the threat model. When the FEC Framework > > operates in the end-device, this device (e.g., a personal > computer) > > might be subject to attacks. Here, the attacker is either the > end- > > user (who might want to access confidential content) or somebody > > else. In all cases the attacker has access to the end-device, > but > > not necessarily to the full control of the end-device (a secure > > domain can exist). Similarly, when the FEC Framework operates in > a > > middlebox, this middlebox can be subject to attacks or the > attacker > > can gain access to it. The threats can also concern the > end-to-end > > transport (e.g., through Internet). Here, examples of threats > > include the transmission of fake FEC source or repair packets, > the > > replay of valid packets, the drop, delay or misordering of > packets, > > and of course traffic eavesdropping. > > > > The third dimension consists in the desired security > > services. Among > > them, the content integrity and sender authentication services > are > > probably the most important features. We can also mention DoS > > mitigation, anti-replay protection or content confidentiality. > > > > Finally, the fourth dimension consists in the security tools > > available. This is the case of the various Digital Rights > > Management > > (DRM) systems, defined out of the context of the IETF and > > that can be > > proprietary solutions. Otherwise SRTP and IPsec/ESP are two > tools > > that can turn out to be useful in the context of the FEC > Framework. > > Note that using SRTP requires that the application generates RTP > > source flows and, when applied below the FEC Framework, > > that both the > > FEC source and repair packets to be regular RTP packets. > Therefore > > SRTP is not considered as a universal solution applicable > > in all use > > cases. > > > > In the following sections, we further discuss security aspects > > related to the use of the FEC Framework. > > > > 9.2. Attacks Against the Data Flows > > > > 9.2.1. Access to Confidential Content > > > > Access control to the source flow being transmitted is typically > > provided by means of encryption. This encryption can be > > done by the > > content provider itself, or within the application (for instance > by > > using the Secure Real-time Transport Protocol (SRTP) [RFC3711]), > or > > at the network layer, on a per-packet basis when IPsec/ESP is > used > > [RFC4303]. If confidentiality is a concern, it is RECOMMENDED > that > > one of these solutions is used. Even if we mention these attacks > > here, they are neither related to nor facilitated by the > > use of FEC. > > > > Note that when encryption is applied, this encryption MUST > > either be > > applied on the source data before the FEC protection, or if done > > after the FEC protection, then both the FEC source packets > > and repair > > packets MUST be encrypted (and an encryption at least as > > cryptographically secure as the encryption applied on the > > FEC source > > packets MUST be used for the FEC repair packets). Otherwise, if > > encryption were to be performed only on the FEC source > > packets after > > FEC encoding, a non-authorized receiver could be able to > > recover the > > source data after decoding the FEC repair packets provided that a > > sufficient number of such packets were available. > > > > The following considerations apply when choosing where to apply > > encryption (and more generally where to apply security services > > beyond encryption). Once decryption has taken place, the > > source data > > is in plaintext. The full path between the output of the > > deciphering > > module and the final destination (e.g., the TV display in case of > a > > video) MUST be secured, in order to prevent any unauthorized > access > > to the source data. > > > > When the FEC Framework endpoint is the end system (i.e., where > the > > upper application runs) and if the threat model includes the > > possibility that an attacker has access to this end > > system, then the > > end system architecture is very important. More > > precisely, in order > > to prevent an attacker to get hold of the plaintext, all > > processings, > > once deciphering has taken place, MUST occur in a protected > > environment. If encryption is applied after FEC protection at > the > > sending side (i.e., below FEC Framework), it means that > > FEC decoding > > MUST take place in the protected environment. With certain use > > cases, this MAY be complicated or even impossible. In that case > > applying encryption before FEC protection is preferred. > > > > When the FEC Framework endpoint is a middlebox, the > > recovered source > > flow, after FEC decoding, SHOULD NOT be sent in plaintext to the > > final destination(s) if the threat model includes the possibility > > that an attacker eavesdrops the traffic. In that case also it is > > preferred to apply encryption before FEC protection. > > > > In some cases, encryption could be applied both before and > > after the > > FEC protection. The considerations described above still apply > in > > such cases. > > > > 9.2.2. Content Corruption > > > > Protection against corruptions (e.g., against forged FEC source/ > > repair packets) is achieved by means of a content integrity > > verification/source authentication scheme. This service is > usually > > provided at the packet level. In this case, after removing all > the > > forged packets, the source flow might sometimes be recovered. > > Several techniques can provide this content integrity/source > > authentication service: > > > > o At the application layer, SRTP [RFC3711] provides several > > solutions to check the integrity and authenticate the source > of > > RTP and RTCP messages, among other services. For instance, > > associated to the Timed Efficient Stream Loss-Tolerant > > Authentication (TESLA) [RFC4383], SRTP is an attractive > solution > > that is robust to losses, provides a true > > authentication/integrity > > service, and does not create any prohibitive processing load > or > > transmission overhead. Yet, checking a packet requires a > small > > delay (a second or more) after its reception with > > TESLA. Whether > > this extra delay, both in terms of startup delay at the > > client and > > end-to-end delay, is appropriate or not depends on the > > target use > > case. In some situations, this might degrade the user > > experience. > > In other situations, this will not be an issue. Other > building > > blocks can be used within SRTP to provide content integrity/ > > authentication services. > > > > o At the network layer, IPsec/ESP [RFC4303] offers (among other > > services) an integrity verification mechanism that can > > be used to > > provide authentication/content integrity services. > > > > It is up to the developer and the person in charge of > > deployment, who > > know the security requirements and features of the target > > application > > area, to define which solution is the most appropriate. > > Nonetheless > > it is RECOMMENDED that at least one of these techniques is used. > > > > Note that when integrity protection is applied, it is RECOMMENDED > > that it takes place on both FEC source and repair packets. The > > motivation is to avoid corrupted packets to be considered during > > decoding, which would often lead to a decoding failure or > > result in a > > corrupted decoded source flow. > > > > 9.3. Attacks Against the FEC Parameters > > > > Attacks on these FEC parameters can prevent the decoding of the > > associated object. For instance, modifying the finite > > field size of > > a Reed-Solomon FEC scheme (when applicable) will lead a receiver > to > > consider a different FEC code. > > > > It is therefore RECOMMENDED that security measures are taken to > > guarantee the FEC Framework Configuration Information integrity. > > Since the FEC Framework does not define how the FEC Framework > > Configuration Information is communicated from sender to > > receiver, we > > cannot provide further recommendations on how to guarantee its > > integrity. However, any complete CDP specification MUST give > > recommendations on how to achieve it. When the FEC Framework > > Configuration Information is sent out-of-band, e.g., in a session > > description, it SHOULD be protected, for instance, by digitally > > signing it. > > > > Attacks are also possible against some FEC parameters > > included in the > > Explicit Source FEC Payload ID and Repair FEC Payload ID. For > > instance, modifying the Source Block Number of an FEC source or > > repair packet will lead a receiver to assign this packet to a > wrong > > block. > > > > It is therefore RECOMMENDED that security measures are taken to > > guarantee the Explicit Source FEC Payload ID and Repair FEC > Payload > > ID integrity. To that purpose, one of the packet-level source > > authentication/content integrity techniques of Section 9.2.2 can > be > > used. > > > > 9.4. When Several Source Flows are to be Protected Together > > > > When several source flows, with different security > > requirements, need > > to be FEC protected jointly, within a single FEC Framework > > instance, > > then each flow MAY be processed appropriately, before the > > protection. > > For instance, source Flows that require access control MAY be > > encrypted before they are FEC protected. > > > > There are also situations where the only insecure domain is the > one > > over which the FEC Framework operates. In that case, this > > situation > > MAY be addressed at the network layer, using IPsec/ESP (see > > Section 9.5), even if only a subset of the source flows have > strict > > security requirements. > > > > Since the use of FEC Framework should not add any > > additional threat, > > it is RECOMMENDED that the FEC Framework aggregate flow be in > line > > with the maximum security requirements of the individual source > > flows. For instance, if denial-of-service (DoS) protection is > > required, an integrity protection SHOULD be provided below the > FEC > > Framework, using for instance IPsec/ESP. > > > > Generally speaking, whenever feasible, it is RECOMMENDED > > to avoid FEC > > protecting flows with totally different security requirements. > > Otherwise, an important processing would be added to protect the > > source flows that do not need it. > > > > 9.5. Baseline Secure FEC Framework Operation > > > > This section describes a baseline mode of secure FEC Framework > > operation based on the application of the IPsec security > protocol, > > which is one possible solution to solve or mitigate the security > > threats introduced by the use of the FEC Framework. > > > > Two related documents are of interest. First, Section 5.1 of > > [RFC5775] defines a baseline secure ALC operation for > > sender-to-group > > transmissions, assuming the presence of a single sender > > and a source- > > specific multicast (SSM) or SSM-like operation. The proposed > > solution, based on IPsec/ESP, can be used to provide a baseline > FEC > > Framework secure operation, for the downstream source flow. > > > > Second, Section 7.1 of [RFC5740] defines a baseline secure NORM > > operation, for sender-to-group transmissions as well as unicast > > feedbacks from receivers. Here, it is also assumed there > > is a single > > sender. The proposed solution is also based on IPsec/ESP. > > However, > > the difference with respect to the first document relies on the > > management of IPsec Security Associations (SA) and corresponding > > Security Policy Database (SPD) entries, since NORM > > requires a second > > set of SA and SPD to be defined to protect unicast feedbacks from > > receivers. > > > > The FEC Framework has been defined in such a way to be > independent > > from the application that generates source flows. Some > > applications > > might use purely unidirectional flows, while other > > applications might > > also use unicast feedbacks from the receivers. For > > instance, this is > > the case when considering RTP/RTCP based source flows. > > Depending on > > the specific situation, it is RECOMMENDED that the baseline > secure > > FEC Framework operation inherits from [RFC5775] in case of purely > > unidirectional sender-to-group flows, or [RFC5740] in case both > > sender-to-group and unicast feedbacks flows are needed. > > > > Note that the IPsec/ESP requirements profiles outlined in > [RFC5775] > > and [RFC5740] are commonly available on many potential hosts. > They > > can form the basis of a secure mode of operation. One potential > > limitation, however, is the need for privileged user > authorization. > > However, automated key management implementations are typically > > configured with the privileges necessary to affect system IPsec > > configuration. > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > From ietfdbh@comcast.net Tue Jan 18 10:26:34 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CEDF3A7078 for ; Tue, 18 Jan 2011 10:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2eFZwECpH45 for ; Tue, 18 Jan 2011 10:26:32 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 65D4E3A707E for ; Tue, 18 Jan 2011 10:26:32 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta01.westchester.pa.mail.comcast.net with comcast id x6Qf1f0050ldTLk516VB8b; Tue, 18 Jan 2011 18:29:11 +0000 Received: from davidPC ([67.189.235.106]) by omta04.westchester.pa.mail.comcast.net with comcast id x6VA1f0042JQnJT3Q6VANV; Tue, 18 Jan 2011 18:29:11 +0000 From: "David Harrington" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D540DEF39DC@xmb-sjc-215.amer.cisco.com> <3159C2BDFE7341DEA5226A1098062050@davidPC> <04CAD96D4C5A3D48B1919248A8FE0D540E16DE62@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E16DE62@xmb-sjc-215.amer.cisco.com> Date: Tue, 18 Jan 2011 13:28:56 -0500 Message-ID: <0F53745179AB40F89024950AA68F23CA@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: AcueCxews5v+ilRKRFaHhxvsQr3dHAZL9NyAAAA5QBAAAFwjQA== Subject: Re: [Fecframe] Revised security section for the framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 18:26:34 -0000 yes. please do, and I will push the other ADs to review the changes and clear where possible. I will note that the new text does not seem to specify that IPsec implementation is REQUIRED (using RFC2119 language). It is only presented as a baseline, and one possible approach. Therefore, I expect it will not satisfy Sean's DISCUSS. dbh > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Tuesday, January 18, 2011 1:17 PM > To: David Harrington; fecframe@ietf.org > Subject: RE: [Fecframe] Revised security section for the framework > > Should we submit the current version we have with the > extended security cons section so that at least we can try to > clear the sec related discusses? > > -acbegen > > > -----Original Message----- > > From: David Harrington [mailto:ietfdbh@comcast.net] > > Sent: Tuesday, January 18, 2011 1:13 PM > > To: Ali C. Begen (abegen); fecframe@ietf.org > > Subject: RE: [Fecframe] Revised security section for the framework > > > > Hi, > > > > FYI. Today I raised my concerns to the level of a DISCUSS. > > The content of the DISCUSS is being sent under a separate email. > > > > I have two parts to my discuss > > 1) the lack of discussion of ops+mgmt. I have tried to make my > > comments actionable. > > 2) a larger concern thatthe frameowkr has no mandatory-to-implement > > components. This is a discuss-discuss, which means I am opening the > > discussion within the IESG about whether this is acceptable for a > > Proposed Standard framework document. > > > > dbh > > > > > -----Original Message----- > > > From: fecframe-bounces@ietf.org > > > [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen > > (abegen) > > > Sent: Friday, December 17, 2010 11:57 AM > > > To: fecframe@ietf.org > > > Subject: [Fecframe] Revised security section for the framework > > > > > > Please let us know if these changes are good or if you have > > > comments. We would like to conclude this work soon. > > > > > > -acbegen > > > > > > > > > 9. Security Considerations > > > > > > First of all, it must be clear that the application of FEC > > > protection > > > to a stream does not provide any kind of security. On the > > > opposite, > > > the FEC Framework itself could be subject to attacks, or could > > pose > > > new security risks. The goals of this section are to state the > > > problem, discuss the risks and identify solutions when > > > feasible. It > > > also defines a mandatory to implement (but not > mandatory to use) > > > security scheme. > > > > > > 9.1. Problem Statement > > > > > > A content delivery system is potentially subject to > many attacks. > > > Attacks can target the content, or the CDP, or the network > > itself, > > > with completely different consequences, in particular in > > > terms of the > > > number of impacted nodes. > > > > > > Attacks can have several goals: > > > > > > o They can try to give access to a confidential content (e.g., > > in > > > case of a non-free content). > > > > > > o They can try to corrupt the source flows (e.g., to prevent a > > > receiver from using them), which is a form of DoS attack. > > > > > > o They can try to compromise the receiver's behavior (e.g., by > > > making the decoding of an object computationally > > > expensive), which > > > is another form of DoS attack. > > > > > > o They can try to compromise the network's behavior (e.g., by > > > causing congestion within the network), which > > > potentially impacts > > > a large number of nodes. > > > > > > These attacks can be launched either against the source > > > and/or repair > > > flows (e.g., by sending fake FEC source and/or repair > packets) or > > > against the FEC parameters that are sent either in-band > > > (e.g., in the > > > Repair FEC Payload ID or in the Explicit Source FEC Payload ID) > > or > > > out-of-band (e.g., in the FEC Framework Configuration > > Information). > > > > > > Several dimensions to the problem need to be considered. The > > first > > > one is the way the FEC Framework is used. The FEC > Framework can > > be > > > used end-to-end, i.e., it can be included in the final > end-device > > > where the upper application runs; or the FEC Framework can > > > be used in > > > middleboxes, for instance, to globally protect several source > > flows > > > exchanged between two or more distant sites. > > > > > > A second dimension is the threat model. When the FEC Framework > > > operates in the end-device, this device (e.g., a personal > > computer) > > > might be subject to attacks. Here, the attacker is either the > > end- > > > user (who might want to access confidential content) > or somebody > > > else. In all cases the attacker has access to the end-device, > > but > > > not necessarily to the full control of the end-device (a secure > > > domain can exist). Similarly, when the FEC Framework > operates in > > a > > > middlebox, this middlebox can be subject to attacks or the > > attacker > > > can gain access to it. The threats can also concern the > > end-to-end > > > transport (e.g., through Internet). Here, examples of threats > > > include the transmission of fake FEC source or repair packets, > > the > > > replay of valid packets, the drop, delay or misordering of > > packets, > > > and of course traffic eavesdropping. > > > > > > The third dimension consists in the desired security > > > services. Among > > > them, the content integrity and sender authentication services > > are > > > probably the most important features. We can also mention DoS > > > mitigation, anti-replay protection or content confidentiality. > > > > > > Finally, the fourth dimension consists in the security tools > > > available. This is the case of the various Digital Rights > > > Management > > > (DRM) systems, defined out of the context of the IETF and > > > that can be > > > proprietary solutions. Otherwise SRTP and IPsec/ESP are two > > tools > > > that can turn out to be useful in the context of the FEC > > Framework. > > > Note that using SRTP requires that the application > generates RTP > > > source flows and, when applied below the FEC Framework, > > > that both the > > > FEC source and repair packets to be regular RTP packets. > > Therefore > > > SRTP is not considered as a universal solution applicable > > > in all use > > > cases. > > > > > > In the following sections, we further discuss security aspects > > > related to the use of the FEC Framework. > > > > > > 9.2. Attacks Against the Data Flows > > > > > > 9.2.1. Access to Confidential Content > > > > > > Access control to the source flow being transmitted is > typically > > > provided by means of encryption. This encryption can be > > > done by the > > > content provider itself, or within the application > (for instance > > by > > > using the Secure Real-time Transport Protocol (SRTP) > [RFC3711]), > > or > > > at the network layer, on a per-packet basis when IPsec/ESP is > > used > > > [RFC4303]. If confidentiality is a concern, it is RECOMMENDED > > that > > > one of these solutions is used. Even if we mention > these attacks > > > here, they are neither related to nor facilitated by the > > > use of FEC. > > > > > > Note that when encryption is applied, this encryption MUST > > > either be > > > applied on the source data before the FEC protection, > or if done > > > after the FEC protection, then both the FEC source packets > > > and repair > > > packets MUST be encrypted (and an encryption at least as > > > cryptographically secure as the encryption applied on the > > > FEC source > > > packets MUST be used for the FEC repair packets). > Otherwise, if > > > encryption were to be performed only on the FEC source > > > packets after > > > FEC encoding, a non-authorized receiver could be able to > > > recover the > > > source data after decoding the FEC repair packets > provided that a > > > sufficient number of such packets were available. > > > > > > The following considerations apply when choosing where to apply > > > encryption (and more generally where to apply security services > > > beyond encryption). Once decryption has taken place, the > > > source data > > > is in plaintext. The full path between the output of the > > > deciphering > > > module and the final destination (e.g., the TV display > in case of > > a > > > video) MUST be secured, in order to prevent any unauthorized > > access > > > to the source data. > > > > > > When the FEC Framework endpoint is the end system (i.e., where > > the > > > upper application runs) and if the threat model includes the > > > possibility that an attacker has access to this end > > > system, then the > > > end system architecture is very important. More > > > precisely, in order > > > to prevent an attacker to get hold of the plaintext, all > > > processings, > > > once deciphering has taken place, MUST occur in a protected > > > environment. If encryption is applied after FEC protection at > > the > > > sending side (i.e., below FEC Framework), it means that > > > FEC decoding > > > MUST take place in the protected environment. With certain use > > > cases, this MAY be complicated or even impossible. In > that case > > > applying encryption before FEC protection is preferred. > > > > > > When the FEC Framework endpoint is a middlebox, the > > > recovered source > > > flow, after FEC decoding, SHOULD NOT be sent in > plaintext to the > > > final destination(s) if the threat model includes the > possibility > > > that an attacker eavesdrops the traffic. In that case > also it is > > > preferred to apply encryption before FEC protection. > > > > > > In some cases, encryption could be applied both before and > > > after the > > > FEC protection. The considerations described above still apply > > in > > > such cases. > > > > > > 9.2.2. Content Corruption > > > > > > Protection against corruptions (e.g., against forged > FEC source/ > > > repair packets) is achieved by means of a content integrity > > > verification/source authentication scheme. This service is > > usually > > > provided at the packet level. In this case, after removing all > > the > > > forged packets, the source flow might sometimes be recovered. > > > Several techniques can provide this content integrity/source > > > authentication service: > > > > > > o At the application layer, SRTP [RFC3711] provides several > > > solutions to check the integrity and authenticate the source > > of > > > RTP and RTCP messages, among other services. For instance, > > > associated to the Timed Efficient Stream Loss-Tolerant > > > Authentication (TESLA) [RFC4383], SRTP is an attractive > > solution > > > that is robust to losses, provides a true > > > authentication/integrity > > > service, and does not create any prohibitive processing load > > or > > > transmission overhead. Yet, checking a packet requires a > > small > > > delay (a second or more) after its reception with > > > TESLA. Whether > > > this extra delay, both in terms of startup delay at the > > > client and > > > end-to-end delay, is appropriate or not depends on the > > > target use > > > case. In some situations, this might degrade the user > > > experience. > > > In other situations, this will not be an issue. Other > > building > > > blocks can be used within SRTP to provide content integrity/ > > > authentication services. > > > > > > o At the network layer, IPsec/ESP [RFC4303] offers > (among other > > > services) an integrity verification mechanism that can > > > be used to > > > provide authentication/content integrity services. > > > > > > It is up to the developer and the person in charge of > > > deployment, who > > > know the security requirements and features of the target > > > application > > > area, to define which solution is the most appropriate. > > > Nonetheless > > > it is RECOMMENDED that at least one of these > techniques is used. > > > > > > Note that when integrity protection is applied, it is > RECOMMENDED > > > that it takes place on both FEC source and repair packets. The > > > motivation is to avoid corrupted packets to be > considered during > > > decoding, which would often lead to a decoding failure or > > > result in a > > > corrupted decoded source flow. > > > > > > 9.3. Attacks Against the FEC Parameters > > > > > > Attacks on these FEC parameters can prevent the decoding of the > > > associated object. For instance, modifying the finite > > > field size of > > > a Reed-Solomon FEC scheme (when applicable) will lead > a receiver > > to > > > consider a different FEC code. > > > > > > It is therefore RECOMMENDED that security measures are taken to > > > guarantee the FEC Framework Configuration Information > integrity. > > > Since the FEC Framework does not define how the FEC Framework > > > Configuration Information is communicated from sender to > > > receiver, we > > > cannot provide further recommendations on how to guarantee its > > > integrity. However, any complete CDP specification MUST give > > > recommendations on how to achieve it. When the FEC Framework > > > Configuration Information is sent out-of-band, e.g., > in a session > > > description, it SHOULD be protected, for instance, by digitally > > > signing it. > > > > > > Attacks are also possible against some FEC parameters > > > included in the > > > Explicit Source FEC Payload ID and Repair FEC Payload ID. For > > > instance, modifying the Source Block Number of an FEC source or > > > repair packet will lead a receiver to assign this packet to a > > wrong > > > block. > > > > > > It is therefore RECOMMENDED that security measures are taken to > > > guarantee the Explicit Source FEC Payload ID and Repair FEC > > Payload > > > ID integrity. To that purpose, one of the packet-level source > > > authentication/content integrity techniques of Section > 9.2.2 can > > be > > > used. > > > > > > 9.4. When Several Source Flows are to be Protected Together > > > > > > When several source flows, with different security > > > requirements, need > > > to be FEC protected jointly, within a single FEC Framework > > > instance, > > > then each flow MAY be processed appropriately, before the > > > protection. > > > For instance, source Flows that require access control MAY be > > > encrypted before they are FEC protected. > > > > > > There are also situations where the only insecure domain is the > > one > > > over which the FEC Framework operates. In that case, this > > > situation > > > MAY be addressed at the network layer, using IPsec/ESP (see > > > Section 9.5), even if only a subset of the source flows have > > strict > > > security requirements. > > > > > > Since the use of FEC Framework should not add any > > > additional threat, > > > it is RECOMMENDED that the FEC Framework aggregate flow be in > > line > > > with the maximum security requirements of the individual source > > > flows. For instance, if denial-of-service (DoS) protection is > > > required, an integrity protection SHOULD be provided below the > > FEC > > > Framework, using for instance IPsec/ESP. > > > > > > Generally speaking, whenever feasible, it is RECOMMENDED > > > to avoid FEC > > > protecting flows with totally different security requirements. > > > Otherwise, an important processing would be added to > protect the > > > source flows that do not need it. > > > > > > 9.5. Baseline Secure FEC Framework Operation > > > > > > This section describes a baseline mode of secure FEC Framework > > > operation based on the application of the IPsec security > > protocol, > > > which is one possible solution to solve or mitigate > the security > > > threats introduced by the use of the FEC Framework. > > > > > > Two related documents are of interest. First, Section 5.1 of > > > [RFC5775] defines a baseline secure ALC operation for > > > sender-to-group > > > transmissions, assuming the presence of a single sender > > > and a source- > > > specific multicast (SSM) or SSM-like operation. The proposed > > > solution, based on IPsec/ESP, can be used to provide a baseline > > FEC > > > Framework secure operation, for the downstream source flow. > > > > > > Second, Section 7.1 of [RFC5740] defines a baseline secure NORM > > > operation, for sender-to-group transmissions as well as unicast > > > feedbacks from receivers. Here, it is also assumed there > > > is a single > > > sender. The proposed solution is also based on IPsec/ESP. > > > However, > > > the difference with respect to the first document relies on the > > > management of IPsec Security Associations (SA) and > corresponding > > > Security Policy Database (SPD) entries, since NORM > > > requires a second > > > set of SA and SPD to be defined to protect unicast > feedbacks from > > > receivers. > > > > > > The FEC Framework has been defined in such a way to be > > independent > > > from the application that generates source flows. Some > > > applications > > > might use purely unidirectional flows, while other > > > applications might > > > also use unicast feedbacks from the receivers. For > > > instance, this is > > > the case when considering RTP/RTCP based source flows. > > > Depending on > > > the specific situation, it is RECOMMENDED that the baseline > > secure > > > FEC Framework operation inherits from [RFC5775] in > case of purely > > > unidirectional sender-to-group flows, or [RFC5740] in case both > > > sender-to-group and unicast feedbacks flows are needed. > > > > > > Note that the IPsec/ESP requirements profiles outlined in > > [RFC5775] > > > and [RFC5740] are commonly available on many potential hosts. > > They > > > can form the basis of a secure mode of operation. One > potential > > > limitation, however, is the need for privileged user > > authorization. > > > However, automated key management implementations are typically > > > configured with the privileges necessary to affect system IPsec > > > configuration. > > > > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe > > > > > From stewe@stewe.org Tue Jan 18 11:08:03 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC073A7061 for ; Tue, 18 Jan 2011 11:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC6THl-ihh0X for ; Tue, 18 Jan 2011 11:08:01 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 57C963A7030 for ; Tue, 18 Jan 2011 11:08:00 -0800 (PST) Received: from [172.16.7.249] (unverified [160.79.219.114]) by stewe.org (SurgeMail 3.9e) with ESMTP id 52542-1743317 for multiple; Tue, 18 Jan 2011 20:10:36 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Tue, 18 Jan 2011 14:10:25 -0500 From: Stephan Wenger To: David Harrington , Message-ID: Thread-Topic: [Fecframe] Revised security section for the framework In-Reply-To: <0F53745179AB40F89024950AA68F23CA@davidPC> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 160.79.219.114 X-Authenticated-User: stewe@stewe.org Subject: Re: [Fecframe] Revised security section for the framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 19:08:03 -0000 Hi David, IESG, I don't believe the DISCUSSes are helpful. You guys are pushing the WG to add text that the WG does not deem necessary. Have you thought about the reasons for the WG's position? My understanding is that the fecframe protocol suite will, practically, used in conjunction with IPTV, mobile TV, and so on. Many, of not most, of this applications run over IP networks that are NOT the Internet (in that a majority of the traffic may not be Internet traffic, though there may be Internet traffic routed on the same infrastructure to the same endpoints). In this application space, (perhaps) most security issues, and certainly most, if not all, operational issues, are either not formally standardized, or standardized in documents by 3GPP, ETSI, ITU, whatnot. These customer organizations may refer to IETF specs for solving any issues they deem necessary to be solved, or they may devise their own solution. One example for this is, in the IPTV field, the XML-coded session descriptions Ali has already referred to. The IETF specs of fecframe are low level, media-plane tools. Interoperability absolutely must be possible on that low level. But that's it, IMO. Requiring certain security or operational technologies, that the customer SDOs may be specifying very differently, is counter productive, as the relevant sections may well be ignored by the majority, if not by all, implementations, for reasons of practicality. Since you cannot enforce the implementation of those technologies (beyond putting meaningless 2119 words in the sections in question), why do you try? So my suggestion would be that -the security, ops, congestion control, whatnot sections ideally should point out the security/ops/cc/whatnot issues the framework may have, but leave the implementer or customer SDO to choose between available tools to solve those issues if there is a commercial need for solving them. In other words, those sections should include requirements. They may hint to solutions, but should not require implementation or use. -if you insist on adding requirements that an implementation can ignore without hurting the core protocol's interoperability, then at least qualify your 2119 requirements with a phrase such as "if used on the Internet". If you don't, you may have formally non-compliant implementations out there, to which, arguably, many of the IPR declarations do not apply. This cannot be your wish, can it? Regards, Stephan On 1.18.2011 13:28 , "David Harrington" wrote: >yes. please do, and I will push the other ADs to review the changes >and clear where possible. > >I will note that the new text does not seem to specify that IPsec >implementation is REQUIRED (using RFC2119 language). >It is only presented as a baseline, and one possible approach. >Therefore, I expect it will not satisfy Sean's DISCUSS. > >dbh > >> -----Original Message----- >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> Sent: Tuesday, January 18, 2011 1:17 PM >> To: David Harrington; fecframe@ietf.org >> Subject: RE: [Fecframe] Revised security section for the framework >> >> Should we submit the current version we have with the >> extended security cons section so that at least we can try to >> clear the sec related discusses? >> >> -acbegen >> >> > -----Original Message----- >> > From: David Harrington [mailto:ietfdbh@comcast.net] >> > Sent: Tuesday, January 18, 2011 1:13 PM >> > To: Ali C. Begen (abegen); fecframe@ietf.org >> > Subject: RE: [Fecframe] Revised security section for the framework >> > >> > Hi, >> > >> > FYI. Today I raised my concerns to the level of a DISCUSS. >> > The content of the DISCUSS is being sent under a separate email. >> > >> > I have two parts to my discuss >> > 1) the lack of discussion of ops+mgmt. I have tried to make my >> > comments actionable. >> > 2) a larger concern thatthe frameowkr has no >mandatory-to-implement >> > components. This is a discuss-discuss, which means I am opening >the >> > discussion within the IESG about whether this is acceptable for a >> > Proposed Standard framework document. >> > >> > dbh >> > >> > > -----Original Message----- >> > > From: fecframe-bounces@ietf.org >> > > [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen >> > (abegen) >> > > Sent: Friday, December 17, 2010 11:57 AM >> > > To: fecframe@ietf.org >> > > Subject: [Fecframe] Revised security section for the framework >> > > >> > > Please let us know if these changes are good or if you have >> > > comments. We would like to conclude this work soon. >> > > >> > > -acbegen >> > > >> > > >> > > 9. Security Considerations >> > > >> > > First of all, it must be clear that the application of FEC >> > > protection >> > > to a stream does not provide any kind of security. On the >> > > opposite, >> > > the FEC Framework itself could be subject to attacks, or >could >> > pose >> > > new security risks. The goals of this section are to state >the >> > > problem, discuss the risks and identify solutions when >> > > feasible. It >> > > also defines a mandatory to implement (but not >> mandatory to use) >> > > security scheme. >> > > >> > > 9.1. Problem Statement >> > > >> > > A content delivery system is potentially subject to >> many attacks. >> > > Attacks can target the content, or the CDP, or the network >> > itself, >> > > with completely different consequences, in particular in >> > > terms of the >> > > number of impacted nodes. >> > > >> > > Attacks can have several goals: >> > > >> > > o They can try to give access to a confidential content >(e.g., >> > in >> > > case of a non-free content). >> > > >> > > o They can try to corrupt the source flows (e.g., to prevent >a >> > > receiver from using them), which is a form of DoS attack. >> > > >> > > o They can try to compromise the receiver's behavior (e.g., >by >> > > making the decoding of an object computationally >> > > expensive), which >> > > is another form of DoS attack. >> > > >> > > o They can try to compromise the network's behavior (e.g., >by >> > > causing congestion within the network), which >> > > potentially impacts >> > > a large number of nodes. >> > > >> > > These attacks can be launched either against the source >> > > and/or repair >> > > flows (e.g., by sending fake FEC source and/or repair >> packets) or >> > > against the FEC parameters that are sent either in-band >> > > (e.g., in the >> > > Repair FEC Payload ID or in the Explicit Source FEC Payload >ID) >> > or >> > > out-of-band (e.g., in the FEC Framework Configuration >> > Information). >> > > >> > > Several dimensions to the problem need to be considered. The >> > first >> > > one is the way the FEC Framework is used. The FEC >> Framework can >> > be >> > > used end-to-end, i.e., it can be included in the final >> end-device >> > > where the upper application runs; or the FEC Framework can >> > > be used in >> > > middleboxes, for instance, to globally protect several source >> > flows >> > > exchanged between two or more distant sites. >> > > >> > > A second dimension is the threat model. When the FEC >Framework >> > > operates in the end-device, this device (e.g., a personal >> > computer) >> > > might be subject to attacks. Here, the attacker is either >the >> > end- >> > > user (who might want to access confidential content) >> or somebody >> > > else. In all cases the attacker has access to the >end-device, >> > but >> > > not necessarily to the full control of the end-device (a >secure >> > > domain can exist). Similarly, when the FEC Framework >> operates in >> > a >> > > middlebox, this middlebox can be subject to attacks or the >> > attacker >> > > can gain access to it. The threats can also concern the >> > end-to-end >> > > transport (e.g., through Internet). Here, examples of >threats >> > > include the transmission of fake FEC source or repair >packets, >> > the >> > > replay of valid packets, the drop, delay or misordering of >> > packets, >> > > and of course traffic eavesdropping. >> > > >> > > The third dimension consists in the desired security >> > > services. Among >> > > them, the content integrity and sender authentication >services >> > are >> > > probably the most important features. We can also mention >DoS >> > > mitigation, anti-replay protection or content >confidentiality. >> > > >> > > Finally, the fourth dimension consists in the security tools >> > > available. This is the case of the various Digital Rights >> > > Management >> > > (DRM) systems, defined out of the context of the IETF and >> > > that can be >> > > proprietary solutions. Otherwise SRTP and IPsec/ESP are two >> > tools >> > > that can turn out to be useful in the context of the FEC >> > Framework. >> > > Note that using SRTP requires that the application >> generates RTP >> > > source flows and, when applied below the FEC Framework, >> > > that both the >> > > FEC source and repair packets to be regular RTP packets. >> > Therefore >> > > SRTP is not considered as a universal solution applicable >> > > in all use >> > > cases. >> > > >> > > In the following sections, we further discuss security >aspects >> > > related to the use of the FEC Framework. >> > > >> > > 9.2. Attacks Against the Data Flows >> > > >> > > 9.2.1. Access to Confidential Content >> > > >> > > Access control to the source flow being transmitted is >> typically >> > > provided by means of encryption. This encryption can be >> > > done by the >> > > content provider itself, or within the application >> (for instance >> > by >> > > using the Secure Real-time Transport Protocol (SRTP) >> [RFC3711]), >> > or >> > > at the network layer, on a per-packet basis when IPsec/ESP is >> > used >> > > [RFC4303]. If confidentiality is a concern, it is >RECOMMENDED >> > that >> > > one of these solutions is used. Even if we mention >> these attacks >> > > here, they are neither related to nor facilitated by the >> > > use of FEC. >> > > >> > > Note that when encryption is applied, this encryption MUST >> > > either be >> > > applied on the source data before the FEC protection, >> or if done >> > > after the FEC protection, then both the FEC source packets >> > > and repair >> > > packets MUST be encrypted (and an encryption at least as >> > > cryptographically secure as the encryption applied on the >> > > FEC source >> > > packets MUST be used for the FEC repair packets). >> Otherwise, if >> > > encryption were to be performed only on the FEC source >> > > packets after >> > > FEC encoding, a non-authorized receiver could be able to >> > > recover the >> > > source data after decoding the FEC repair packets >> provided that a >> > > sufficient number of such packets were available. >> > > >> > > The following considerations apply when choosing where to >apply >> > > encryption (and more generally where to apply security >services >> > > beyond encryption). Once decryption has taken place, the >> > > source data >> > > is in plaintext. The full path between the output of the >> > > deciphering >> > > module and the final destination (e.g., the TV display >> in case of >> > a >> > > video) MUST be secured, in order to prevent any unauthorized >> > access >> > > to the source data. >> > > >> > > When the FEC Framework endpoint is the end system (i.e., >where >> > the >> > > upper application runs) and if the threat model includes the >> > > possibility that an attacker has access to this end >> > > system, then the >> > > end system architecture is very important. More >> > > precisely, in order >> > > to prevent an attacker to get hold of the plaintext, all >> > > processings, >> > > once deciphering has taken place, MUST occur in a protected >> > > environment. If encryption is applied after FEC protection >at >> > the >> > > sending side (i.e., below FEC Framework), it means that >> > > FEC decoding >> > > MUST take place in the protected environment. With certain >use >> > > cases, this MAY be complicated or even impossible. In >> that case >> > > applying encryption before FEC protection is preferred. >> > > >> > > When the FEC Framework endpoint is a middlebox, the >> > > recovered source >> > > flow, after FEC decoding, SHOULD NOT be sent in >> plaintext to the >> > > final destination(s) if the threat model includes the >> possibility >> > > that an attacker eavesdrops the traffic. In that case >> also it is >> > > preferred to apply encryption before FEC protection. >> > > >> > > In some cases, encryption could be applied both before and >> > > after the >> > > FEC protection. The considerations described above still >apply >> > in >> > > such cases. >> > > >> > > 9.2.2. Content Corruption >> > > >> > > Protection against corruptions (e.g., against forged >> FEC source/ >> > > repair packets) is achieved by means of a content integrity >> > > verification/source authentication scheme. This service is >> > usually >> > > provided at the packet level. In this case, after removing >all >> > the >> > > forged packets, the source flow might sometimes be recovered. >> > > Several techniques can provide this content integrity/source >> > > authentication service: >> > > >> > > o At the application layer, SRTP [RFC3711] provides several >> > > solutions to check the integrity and authenticate the >source >> > of >> > > RTP and RTCP messages, among other services. For >instance, >> > > associated to the Timed Efficient Stream Loss-Tolerant >> > > Authentication (TESLA) [RFC4383], SRTP is an attractive >> > solution >> > > that is robust to losses, provides a true >> > > authentication/integrity >> > > service, and does not create any prohibitive processing >load >> > or >> > > transmission overhead. Yet, checking a packet requires a >> > small >> > > delay (a second or more) after its reception with >> > > TESLA. Whether >> > > this extra delay, both in terms of startup delay at the >> > > client and >> > > end-to-end delay, is appropriate or not depends on the >> > > target use >> > > case. In some situations, this might degrade the user >> > > experience. >> > > In other situations, this will not be an issue. Other >> > building >> > > blocks can be used within SRTP to provide content >integrity/ >> > > authentication services. >> > > >> > > o At the network layer, IPsec/ESP [RFC4303] offers >> (among other >> > > services) an integrity verification mechanism that can >> > > be used to >> > > provide authentication/content integrity services. >> > > >> > > It is up to the developer and the person in charge of >> > > deployment, who >> > > know the security requirements and features of the target >> > > application >> > > area, to define which solution is the most appropriate. >> > > Nonetheless >> > > it is RECOMMENDED that at least one of these >> techniques is used. >> > > >> > > Note that when integrity protection is applied, it is >> RECOMMENDED >> > > that it takes place on both FEC source and repair packets. >The >> > > motivation is to avoid corrupted packets to be >> considered during >> > > decoding, which would often lead to a decoding failure or >> > > result in a >> > > corrupted decoded source flow. >> > > >> > > 9.3. Attacks Against the FEC Parameters >> > > >> > > Attacks on these FEC parameters can prevent the decoding of >the >> > > associated object. For instance, modifying the finite >> > > field size of >> > > a Reed-Solomon FEC scheme (when applicable) will lead >> a receiver >> > to >> > > consider a different FEC code. >> > > >> > > It is therefore RECOMMENDED that security measures are taken >to >> > > guarantee the FEC Framework Configuration Information >> integrity. >> > > Since the FEC Framework does not define how the FEC Framework >> > > Configuration Information is communicated from sender to >> > > receiver, we >> > > cannot provide further recommendations on how to guarantee >its >> > > integrity. However, any complete CDP specification MUST give >> > > recommendations on how to achieve it. When the FEC Framework >> > > Configuration Information is sent out-of-band, e.g., >> in a session >> > > description, it SHOULD be protected, for instance, by >digitally >> > > signing it. >> > > >> > > Attacks are also possible against some FEC parameters >> > > included in the >> > > Explicit Source FEC Payload ID and Repair FEC Payload ID. >For >> > > instance, modifying the Source Block Number of an FEC source >or >> > > repair packet will lead a receiver to assign this packet to a >> > wrong >> > > block. >> > > >> > > It is therefore RECOMMENDED that security measures are taken >to >> > > guarantee the Explicit Source FEC Payload ID and Repair FEC >> > Payload >> > > ID integrity. To that purpose, one of the packet-level >source >> > > authentication/content integrity techniques of Section >> 9.2.2 can >> > be >> > > used. >> > > >> > > 9.4. When Several Source Flows are to be Protected Together >> > > >> > > When several source flows, with different security >> > > requirements, need >> > > to be FEC protected jointly, within a single FEC Framework >> > > instance, >> > > then each flow MAY be processed appropriately, before the >> > > protection. >> > > For instance, source Flows that require access control MAY be >> > > encrypted before they are FEC protected. >> > > >> > > There are also situations where the only insecure domain is >the >> > one >> > > over which the FEC Framework operates. In that case, this >> > > situation >> > > MAY be addressed at the network layer, using IPsec/ESP (see >> > > Section 9.5), even if only a subset of the source flows have >> > strict >> > > security requirements. >> > > >> > > Since the use of FEC Framework should not add any >> > > additional threat, >> > > it is RECOMMENDED that the FEC Framework aggregate flow be in >> > line >> > > with the maximum security requirements of the individual >source >> > > flows. For instance, if denial-of-service (DoS) protection >is >> > > required, an integrity protection SHOULD be provided below >the >> > FEC >> > > Framework, using for instance IPsec/ESP. >> > > >> > > Generally speaking, whenever feasible, it is RECOMMENDED >> > > to avoid FEC >> > > protecting flows with totally different security >requirements. >> > > Otherwise, an important processing would be added to >> protect the >> > > source flows that do not need it. >> > > >> > > 9.5. Baseline Secure FEC Framework Operation >> > > >> > > This section describes a baseline mode of secure FEC >Framework >> > > operation based on the application of the IPsec security >> > protocol, >> > > which is one possible solution to solve or mitigate >> the security >> > > threats introduced by the use of the FEC Framework. >> > > >> > > Two related documents are of interest. First, Section 5.1 of >> > > [RFC5775] defines a baseline secure ALC operation for >> > > sender-to-group >> > > transmissions, assuming the presence of a single sender >> > > and a source- >> > > specific multicast (SSM) or SSM-like operation. The proposed >> > > solution, based on IPsec/ESP, can be used to provide a >baseline >> > FEC >> > > Framework secure operation, for the downstream source flow. >> > > >> > > Second, Section 7.1 of [RFC5740] defines a baseline secure >NORM >> > > operation, for sender-to-group transmissions as well as >unicast >> > > feedbacks from receivers. Here, it is also assumed there >> > > is a single >> > > sender. The proposed solution is also based on IPsec/ESP. >> > > However, >> > > the difference with respect to the first document relies on >the >> > > management of IPsec Security Associations (SA) and >> corresponding >> > > Security Policy Database (SPD) entries, since NORM >> > > requires a second >> > > set of SA and SPD to be defined to protect unicast >> feedbacks from >> > > receivers. >> > > >> > > The FEC Framework has been defined in such a way to be >> > independent >> > > from the application that generates source flows. Some >> > > applications >> > > might use purely unidirectional flows, while other >> > > applications might >> > > also use unicast feedbacks from the receivers. For >> > > instance, this is >> > > the case when considering RTP/RTCP based source flows. >> > > Depending on >> > > the specific situation, it is RECOMMENDED that the baseline >> > secure >> > > FEC Framework operation inherits from [RFC5775] in >> case of purely >> > > unidirectional sender-to-group flows, or [RFC5740] in case >both >> > > sender-to-group and unicast feedbacks flows are needed. >> > > >> > > Note that the IPsec/ESP requirements profiles outlined in >> > [RFC5775] >> > > and [RFC5740] are commonly available on many potential hosts. >> > They >> > > can form the basis of a secure mode of operation. One >> potential >> > > limitation, however, is the need for privileged user >> > authorization. >> > > However, automated key management implementations are >typically >> > > configured with the privileges necessary to affect system >IPsec >> > > configuration. >> > > >> > > _______________________________________________ >> > > Fecframe mailing list >> > > Fecframe@ietf.org >> > > https://www.ietf.org/mailman/listinfo/fecframe >> > > >> >> > >_______________________________________________ >Fecframe mailing list >Fecframe@ietf.org >https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Tue Jan 18 13:54:03 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1DF3A6DCE for ; Tue, 18 Jan 2011 13:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-ccsgD3XiAh for ; Tue, 18 Jan 2011 13:54:02 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 633DF3A6EF5 for ; Tue, 18 Jan 2011 13:54:02 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPKbNU2rR7Ht/2dsb2JhbACkXHOoIpo3hVAEhG+JWQ Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 18 Jan 2011 21:56:32 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0ILuWSP014038; Tue, 18 Jan 2011 21:56:32 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Jan 2011 13:56:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jan 2011 13:56:19 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E16DFC4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <0F53745179AB40F89024950AA68F23CA@davidPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Revised security section for the framework Thread-Index: AcueCxews5v+ilRKRFaHhxvsQr3dHAZL9NyAAAA5QBAAAFwjQAAHPJjQ References: <04CAD96D4C5A3D48B1919248A8FE0D540DEF39DC@xmb-sjc-215.amer.cisco.com> <3159C2BDFE7341DEA5226A1098062050@davidPC> <04CAD96D4C5A3D48B1919248A8FE0D540E16DE62@xmb-sjc-215.amer.cisco.com> <0F53745179AB40F89024950AA68F23CA@davidPC> From: "Ali C. Begen (abegen)" To: "David Harrington" , X-OriginalArrivalTime: 18 Jan 2011 21:56:32.0133 (UTC) FILETIME=[91357350:01CBB75A] Subject: Re: [Fecframe] Revised security section for the framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 21:54:03 -0000 I submitted -12. It should address Russ', Robert's and Sean's discusses = if not all. -acbegen > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, January 18, 2011 1:29 PM > To: Ali C. Begen (abegen); fecframe@ietf.org > Subject: RE: [Fecframe] Revised security section for the framework >=20 > yes. please do, and I will push the other ADs to review the changes > and clear where possible. >=20 > I will note that the new text does not seem to specify that IPsec > implementation is REQUIRED (using RFC2119 language). > It is only presented as a baseline, and one possible approach. > Therefore, I expect it will not satisfy Sean's DISCUSS. >=20 > dbh From Internet-Drafts@ietf.org Tue Jan 18 14:00:03 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170E23A6F57; Tue, 18 Jan 2011 14:00:03 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL3o0DrYjTdS; Tue, 18 Jan 2011 14:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3326F3A6DCE; Tue, 18 Jan 2011 14:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110118220002.15554.39834.idtracker@localhost> Date: Tue, 18 Jan 2011 14:00:02 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-framework-12.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 22:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Forward Error Correction (FEC) Framework Author(s) : M. Watson, et al. Filename : draft-ietf-fecframe-framework-12.txt Pages : 45 Date : 2011-01-18 This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC scheme, and FEC schemes can be defined which are not specific to a particular Content Delivery Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-framework-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-framework-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-18135007.I-D@ietf.org> --NextPart-- From ietfdbh@comcast.net Tue Jan 18 16:55:48 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433C528C0FF for ; Tue, 18 Jan 2011 16:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0wZN+ccTvkS for ; Tue, 18 Jan 2011 16:55:46 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 8E44D28B797 for ; Tue, 18 Jan 2011 16:55:45 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta08.westchester.pa.mail.comcast.net with comcast id xCyP1f0030ldTLk58CyQW1; Wed, 19 Jan 2011 00:58:24 +0000 Received: from davidPC ([67.189.235.106]) by omta04.westchester.pa.mail.comcast.net with comcast id xCyP1f01M2JQnJT3QCyPRe; Wed, 19 Jan 2011 00:58:24 +0000 From: "David Harrington" To: "'Stephan Wenger'" , References: <0F53745179AB40F89024950AA68F23CA@davidPC> In-Reply-To: Date: Tue, 18 Jan 2011 19:58:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Thread-Index: Acu3Q2hBxR3DdUnSQyue91pNpAnwzgALfNKA Subject: Re: [Fecframe] Revised security section for the framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 00:55:48 -0000 Hi Stephan, The really sad part about this whole conversation is that what the IESG has been pushing for is a documented consideration of the ops and mgmt perspective, much like the one in your email, and Ali's emails, and Dave's emails, and Mike's emails, but they want the discussion captured **** in the document ****. But what we get in the document is the assertion that the WG has decided any such discussion is out of scope of the document (and presumably the framework), rather than documenting the details of the WG's considerations. My #2 discuss is about whether we should expect some mandatory-to-implement components or not, since without mandatory-to-implement components, vendors ar elikely to not implement common components, and operators cannot choose a consistent set of components for their deployments in multi-vendor environments. This is a discuss-discuss, which means I am not pushing for any action by the authors; I want a discussion among the IESG about the potential impact of not having mandatory components, and whether fecframe is one of the acceptable exceptions to the rule. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: Stephan Wenger [mailto:stewe@stewe.org] > Sent: Tuesday, January 18, 2011 2:10 PM > To: David Harrington; fecframe@ietf.org > Subject: Re: [Fecframe] Revised security section for the framework > > Hi David, IESG, > I don't believe the DISCUSSes are helpful. You guys are > pushing the WG to > add text that the WG does not deem necessary. Have you > thought about the > reasons for the WG's position? > My understanding is that the fecframe protocol suite will, > practically, > used in conjunction with IPTV, mobile TV, and so on. Many, > of not most, > of this applications run over IP networks that are NOT the > Internet (in > that a majority of the traffic may not be Internet traffic, > though there > may be Internet traffic routed on the same infrastructure to the same > endpoints). In this application space, (perhaps) most > security issues, > and certainly most, if not all, operational issues, are either not > formally standardized, or standardized in documents by 3GPP, > ETSI, ITU, > whatnot. These customer organizations may refer to IETF > specs for solving > any issues they deem necessary to be solved, or they may > devise their own > solution. One example for this is, in the IPTV field, the XML-coded > session descriptions Ali has already referred to. > The IETF specs of fecframe are low level, media-plane tools. > Interoperability absolutely must be possible on that low level. But > that's it, IMO. Requiring certain security or operational > technologies, > that the customer SDOs may be specifying very differently, is counter > productive, as the relevant sections may well be ignored by > the majority, > if not by all, implementations, for reasons of practicality. > Since you > cannot enforce the implementation of those technologies > (beyond putting > meaningless 2119 words in the sections in question), why do you try? > So my suggestion would be that > -the security, ops, congestion control, whatnot sections > ideally should > point out the security/ops/cc/whatnot issues the framework > may have, but > leave the implementer or customer SDO to choose between > available tools to > solve those issues if there is a commercial need for solving them. In > other words, those sections should include requirements. > They may hint to > solutions, but should not require implementation or use. > -if you insist on adding requirements that an implementation > can ignore > without hurting the core protocol's interoperability, then at least > qualify your 2119 requirements with a phrase such as "if used on the > Internet". If you don't, you may have formally non-compliant > implementations out there, to which, arguably, many of the IPR > declarations do not apply. This cannot be your wish, can it? > Regards, > Stephan > > > > On 1.18.2011 13:28 , "David Harrington" wrote: > > >yes. please do, and I will push the other ADs to review the changes > >and clear where possible. > > > >I will note that the new text does not seem to specify that IPsec > >implementation is REQUIRED (using RFC2119 language). > >It is only presented as a baseline, and one possible approach. > >Therefore, I expect it will not satisfy Sean's DISCUSS. > > > >dbh > > > >> -----Original Message----- > >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > >> Sent: Tuesday, January 18, 2011 1:17 PM > >> To: David Harrington; fecframe@ietf.org > >> Subject: RE: [Fecframe] Revised security section for the framework > >> > >> Should we submit the current version we have with the > >> extended security cons section so that at least we can try to > >> clear the sec related discusses? > >> > >> -acbegen > >> > >> > -----Original Message----- > >> > From: David Harrington [mailto:ietfdbh@comcast.net] > >> > Sent: Tuesday, January 18, 2011 1:13 PM > >> > To: Ali C. Begen (abegen); fecframe@ietf.org > >> > Subject: RE: [Fecframe] Revised security section for the > framework > >> > > >> > Hi, > >> > > >> > FYI. Today I raised my concerns to the level of a DISCUSS. > >> > The content of the DISCUSS is being sent under a separate email. > >> > > >> > I have two parts to my discuss > >> > 1) the lack of discussion of ops+mgmt. I have tried to make my > >> > comments actionable. > >> > 2) a larger concern thatthe frameowkr has no > >mandatory-to-implement > >> > components. This is a discuss-discuss, which means I am opening > >the > >> > discussion within the IESG about whether this is acceptable for a > >> > Proposed Standard framework document. > >> > > >> > dbh > >> > > >> > > -----Original Message----- > >> > > From: fecframe-bounces@ietf.org > >> > > [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen > >> > (abegen) > >> > > Sent: Friday, December 17, 2010 11:57 AM > >> > > To: fecframe@ietf.org > >> > > Subject: [Fecframe] Revised security section for the framework > >> > > > >> > > Please let us know if these changes are good or if you have > >> > > comments. We would like to conclude this work soon. > >> > > > >> > > -acbegen > >> > > > >> > > > >> > > 9. Security Considerations > >> > > > >> > > First of all, it must be clear that the application of FEC > >> > > protection > >> > > to a stream does not provide any kind of security. On the > >> > > opposite, > >> > > the FEC Framework itself could be subject to attacks, or > >could > >> > pose > >> > > new security risks. The goals of this section are to state > >the > >> > > problem, discuss the risks and identify solutions when > >> > > feasible. It > >> > > also defines a mandatory to implement (but not > >> mandatory to use) > >> > > security scheme. > >> > > > >> > > 9.1. Problem Statement > >> > > > >> > > A content delivery system is potentially subject to > >> many attacks. > >> > > Attacks can target the content, or the CDP, or the network > >> > itself, > >> > > with completely different consequences, in particular in > >> > > terms of the > >> > > number of impacted nodes. > >> > > > >> > > Attacks can have several goals: > >> > > > >> > > o They can try to give access to a confidential content > >(e.g., > >> > in > >> > > case of a non-free content). > >> > > > >> > > o They can try to corrupt the source flows (e.g., > to prevent > >a > >> > > receiver from using them), which is a form of DoS attack. > >> > > > >> > > o They can try to compromise the receiver's behavior (e.g., > >by > >> > > making the decoding of an object computationally > >> > > expensive), which > >> > > is another form of DoS attack. > >> > > > >> > > o They can try to compromise the network's behavior (e.g., > >by > >> > > causing congestion within the network), which > >> > > potentially impacts > >> > > a large number of nodes. > >> > > > >> > > These attacks can be launched either against the source > >> > > and/or repair > >> > > flows (e.g., by sending fake FEC source and/or repair > >> packets) or > >> > > against the FEC parameters that are sent either in-band > >> > > (e.g., in the > >> > > Repair FEC Payload ID or in the Explicit Source FEC Payload > >ID) > >> > or > >> > > out-of-band (e.g., in the FEC Framework Configuration > >> > Information). > >> > > > >> > > Several dimensions to the problem need to be > considered. The > >> > first > >> > > one is the way the FEC Framework is used. The FEC > >> Framework can > >> > be > >> > > used end-to-end, i.e., it can be included in the final > >> end-device > >> > > where the upper application runs; or the FEC Framework can > >> > > be used in > >> > > middleboxes, for instance, to globally protect > several source > >> > flows > >> > > exchanged between two or more distant sites. > >> > > > >> > > A second dimension is the threat model. When the FEC > >Framework > >> > > operates in the end-device, this device (e.g., a personal > >> > computer) > >> > > might be subject to attacks. Here, the attacker is either > >the > >> > end- > >> > > user (who might want to access confidential content) > >> or somebody > >> > > else. In all cases the attacker has access to the > >end-device, > >> > but > >> > > not necessarily to the full control of the end-device (a > >secure > >> > > domain can exist). Similarly, when the FEC Framework > >> operates in > >> > a > >> > > middlebox, this middlebox can be subject to attacks or the > >> > attacker > >> > > can gain access to it. The threats can also concern the > >> > end-to-end > >> > > transport (e.g., through Internet). Here, examples of > >threats > >> > > include the transmission of fake FEC source or repair > >packets, > >> > the > >> > > replay of valid packets, the drop, delay or misordering of > >> > packets, > >> > > and of course traffic eavesdropping. > >> > > > >> > > The third dimension consists in the desired security > >> > > services. Among > >> > > them, the content integrity and sender authentication > >services > >> > are > >> > > probably the most important features. We can also mention > >DoS > >> > > mitigation, anti-replay protection or content > >confidentiality. > >> > > > >> > > Finally, the fourth dimension consists in the security tools > >> > > available. This is the case of the various Digital Rights > >> > > Management > >> > > (DRM) systems, defined out of the context of the IETF and > >> > > that can be > >> > > proprietary solutions. Otherwise SRTP and IPsec/ESP are two > >> > tools > >> > > that can turn out to be useful in the context of the FEC > >> > Framework. > >> > > Note that using SRTP requires that the application > >> generates RTP > >> > > source flows and, when applied below the FEC Framework, > >> > > that both the > >> > > FEC source and repair packets to be regular RTP packets. > >> > Therefore > >> > > SRTP is not considered as a universal solution applicable > >> > > in all use > >> > > cases. > >> > > > >> > > In the following sections, we further discuss security > >aspects > >> > > related to the use of the FEC Framework. > >> > > > >> > > 9.2. Attacks Against the Data Flows > >> > > > >> > > 9.2.1. Access to Confidential Content > >> > > > >> > > Access control to the source flow being transmitted is > >> typically > >> > > provided by means of encryption. This encryption can be > >> > > done by the > >> > > content provider itself, or within the application > >> (for instance > >> > by > >> > > using the Secure Real-time Transport Protocol (SRTP) > >> [RFC3711]), > >> > or > >> > > at the network layer, on a per-packet basis when > IPsec/ESP is > >> > used > >> > > [RFC4303]. If confidentiality is a concern, it is > >RECOMMENDED > >> > that > >> > > one of these solutions is used. Even if we mention > >> these attacks > >> > > here, they are neither related to nor facilitated by the > >> > > use of FEC. > >> > > > >> > > Note that when encryption is applied, this encryption MUST > >> > > either be > >> > > applied on the source data before the FEC protection, > >> or if done > >> > > after the FEC protection, then both the FEC source packets > >> > > and repair > >> > > packets MUST be encrypted (and an encryption at least as > >> > > cryptographically secure as the encryption applied on the > >> > > FEC source > >> > > packets MUST be used for the FEC repair packets). > >> Otherwise, if > >> > > encryption were to be performed only on the FEC source > >> > > packets after > >> > > FEC encoding, a non-authorized receiver could be able to > >> > > recover the > >> > > source data after decoding the FEC repair packets > >> provided that a > >> > > sufficient number of such packets were available. > >> > > > >> > > The following considerations apply when choosing where to > >apply > >> > > encryption (and more generally where to apply security > >services > >> > > beyond encryption). Once decryption has taken place, the > >> > > source data > >> > > is in plaintext. The full path between the output of the > >> > > deciphering > >> > > module and the final destination (e.g., the TV display > >> in case of > >> > a > >> > > video) MUST be secured, in order to prevent any unauthorized > >> > access > >> > > to the source data. > >> > > > >> > > When the FEC Framework endpoint is the end system (i.e., > >where > >> > the > >> > > upper application runs) and if the threat model includes the > >> > > possibility that an attacker has access to this end > >> > > system, then the > >> > > end system architecture is very important. More > >> > > precisely, in order > >> > > to prevent an attacker to get hold of the plaintext, all > >> > > processings, > >> > > once deciphering has taken place, MUST occur in a protected > >> > > environment. If encryption is applied after FEC protection > >at > >> > the > >> > > sending side (i.e., below FEC Framework), it means that > >> > > FEC decoding > >> > > MUST take place in the protected environment. With certain > >use > >> > > cases, this MAY be complicated or even impossible. In > >> that case > >> > > applying encryption before FEC protection is preferred. > >> > > > >> > > When the FEC Framework endpoint is a middlebox, the > >> > > recovered source > >> > > flow, after FEC decoding, SHOULD NOT be sent in > >> plaintext to the > >> > > final destination(s) if the threat model includes the > >> possibility > >> > > that an attacker eavesdrops the traffic. In that case > >> also it is > >> > > preferred to apply encryption before FEC protection. > >> > > > >> > > In some cases, encryption could be applied both before and > >> > > after the > >> > > FEC protection. The considerations described above still > >apply > >> > in > >> > > such cases. > >> > > > >> > > 9.2.2. Content Corruption > >> > > > >> > > Protection against corruptions (e.g., against forged > >> FEC source/ > >> > > repair packets) is achieved by means of a content integrity > >> > > verification/source authentication scheme. This service is > >> > usually > >> > > provided at the packet level. In this case, after removing > >all > >> > the > >> > > forged packets, the source flow might sometimes be > recovered. > >> > > Several techniques can provide this content integrity/source > >> > > authentication service: > >> > > > >> > > o At the application layer, SRTP [RFC3711] provides several > >> > > solutions to check the integrity and authenticate the > >source > >> > of > >> > > RTP and RTCP messages, among other services. For > >instance, > >> > > associated to the Timed Efficient Stream Loss-Tolerant > >> > > Authentication (TESLA) [RFC4383], SRTP is an attractive > >> > solution > >> > > that is robust to losses, provides a true > >> > > authentication/integrity > >> > > service, and does not create any prohibitive processing > >load > >> > or > >> > > transmission overhead. Yet, checking a packet requires a > >> > small > >> > > delay (a second or more) after its reception with > >> > > TESLA. Whether > >> > > this extra delay, both in terms of startup delay at the > >> > > client and > >> > > end-to-end delay, is appropriate or not depends on the > >> > > target use > >> > > case. In some situations, this might degrade the user > >> > > experience. > >> > > In other situations, this will not be an issue. Other > >> > building > >> > > blocks can be used within SRTP to provide content > >integrity/ > >> > > authentication services. > >> > > > >> > > o At the network layer, IPsec/ESP [RFC4303] offers > >> (among other > >> > > services) an integrity verification mechanism that can > >> > > be used to > >> > > provide authentication/content integrity services. > >> > > > >> > > It is up to the developer and the person in charge of > >> > > deployment, who > >> > > know the security requirements and features of the target > >> > > application > >> > > area, to define which solution is the most appropriate. > >> > > Nonetheless > >> > > it is RECOMMENDED that at least one of these > >> techniques is used. > >> > > > >> > > Note that when integrity protection is applied, it is > >> RECOMMENDED > >> > > that it takes place on both FEC source and repair packets. > >The > >> > > motivation is to avoid corrupted packets to be > >> considered during > >> > > decoding, which would often lead to a decoding failure or > >> > > result in a > >> > > corrupted decoded source flow. > >> > > > >> > > 9.3. Attacks Against the FEC Parameters > >> > > > >> > > Attacks on these FEC parameters can prevent the decoding of > >the > >> > > associated object. For instance, modifying the finite > >> > > field size of > >> > > a Reed-Solomon FEC scheme (when applicable) will lead > >> a receiver > >> > to > >> > > consider a different FEC code. > >> > > > >> > > It is therefore RECOMMENDED that security measures are taken > >to > >> > > guarantee the FEC Framework Configuration Information > >> integrity. > >> > > Since the FEC Framework does not define how the FEC > Framework > >> > > Configuration Information is communicated from sender to > >> > > receiver, we > >> > > cannot provide further recommendations on how to guarantee > >its > >> > > integrity. However, any complete CDP specification > MUST give > >> > > recommendations on how to achieve it. When the FEC > Framework > >> > > Configuration Information is sent out-of-band, e.g., > >> in a session > >> > > description, it SHOULD be protected, for instance, by > >digitally > >> > > signing it. > >> > > > >> > > Attacks are also possible against some FEC parameters > >> > > included in the > >> > > Explicit Source FEC Payload ID and Repair FEC Payload ID. > >For > >> > > instance, modifying the Source Block Number of an FEC source > >or > >> > > repair packet will lead a receiver to assign this > packet to a > >> > wrong > >> > > block. > >> > > > >> > > It is therefore RECOMMENDED that security measures are taken > >to > >> > > guarantee the Explicit Source FEC Payload ID and Repair FEC > >> > Payload > >> > > ID integrity. To that purpose, one of the packet-level > >source > >> > > authentication/content integrity techniques of Section > >> 9.2.2 can > >> > be > >> > > used. > >> > > > >> > > 9.4. When Several Source Flows are to be Protected Together > >> > > > >> > > When several source flows, with different security > >> > > requirements, need > >> > > to be FEC protected jointly, within a single FEC Framework > >> > > instance, > >> > > then each flow MAY be processed appropriately, before the > >> > > protection. > >> > > For instance, source Flows that require access > control MAY be > >> > > encrypted before they are FEC protected. > >> > > > >> > > There are also situations where the only insecure domain is > >the > >> > one > >> > > over which the FEC Framework operates. In that case, this > >> > > situation > >> > > MAY be addressed at the network layer, using IPsec/ESP (see > >> > > Section 9.5), even if only a subset of the source flows have > >> > strict > >> > > security requirements. > >> > > > >> > > Since the use of FEC Framework should not add any > >> > > additional threat, > >> > > it is RECOMMENDED that the FEC Framework aggregate > flow be in > >> > line > >> > > with the maximum security requirements of the individual > >source > >> > > flows. For instance, if denial-of-service (DoS) protection > >is > >> > > required, an integrity protection SHOULD be provided below > >the > >> > FEC > >> > > Framework, using for instance IPsec/ESP. > >> > > > >> > > Generally speaking, whenever feasible, it is RECOMMENDED > >> > > to avoid FEC > >> > > protecting flows with totally different security > >requirements. > >> > > Otherwise, an important processing would be added to > >> protect the > >> > > source flows that do not need it. > >> > > > >> > > 9.5. Baseline Secure FEC Framework Operation > >> > > > >> > > This section describes a baseline mode of secure FEC > >Framework > >> > > operation based on the application of the IPsec security > >> > protocol, > >> > > which is one possible solution to solve or mitigate > >> the security > >> > > threats introduced by the use of the FEC Framework. > >> > > > >> > > Two related documents are of interest. First, > Section 5.1 of > >> > > [RFC5775] defines a baseline secure ALC operation for > >> > > sender-to-group > >> > > transmissions, assuming the presence of a single sender > >> > > and a source- > >> > > specific multicast (SSM) or SSM-like operation. > The proposed > >> > > solution, based on IPsec/ESP, can be used to provide a > >baseline > >> > FEC > >> > > Framework secure operation, for the downstream source flow. > >> > > > >> > > Second, Section 7.1 of [RFC5740] defines a baseline secure > >NORM > >> > > operation, for sender-to-group transmissions as well as > >unicast > >> > > feedbacks from receivers. Here, it is also assumed there > >> > > is a single > >> > > sender. The proposed solution is also based on IPsec/ESP. > >> > > However, > >> > > the difference with respect to the first document relies on > >the > >> > > management of IPsec Security Associations (SA) and > >> corresponding > >> > > Security Policy Database (SPD) entries, since NORM > >> > > requires a second > >> > > set of SA and SPD to be defined to protect unicast > >> feedbacks from > >> > > receivers. > >> > > > >> > > The FEC Framework has been defined in such a way to be > >> > independent > >> > > from the application that generates source flows. Some > >> > > applications > >> > > might use purely unidirectional flows, while other > >> > > applications might > >> > > also use unicast feedbacks from the receivers. For > >> > > instance, this is > >> > > the case when considering RTP/RTCP based source flows. > >> > > Depending on > >> > > the specific situation, it is RECOMMENDED that the baseline > >> > secure > >> > > FEC Framework operation inherits from [RFC5775] in > >> case of purely > >> > > unidirectional sender-to-group flows, or [RFC5740] in case > >both > >> > > sender-to-group and unicast feedbacks flows are needed. > >> > > > >> > > Note that the IPsec/ESP requirements profiles outlined in > >> > [RFC5775] > >> > > and [RFC5740] are commonly available on many > potential hosts. > >> > They > >> > > can form the basis of a secure mode of operation. One > >> potential > >> > > limitation, however, is the need for privileged user > >> > authorization. > >> > > However, automated key management implementations are > >typically > >> > > configured with the privileges necessary to affect system > >IPsec > >> > > configuration. > >> > > > >> > > _______________________________________________ > >> > > Fecframe mailing list > >> > > Fecframe@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/fecframe > >> > > > >> > >> > > > >_______________________________________________ > >Fecframe mailing list > >Fecframe@ietf.org > >https://www.ietf.org/mailman/listinfo/fecframe > > > From gjshep@gmail.com Tue Jan 18 17:34:42 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396EC3A7066 for ; Tue, 18 Jan 2011 17:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.091 X-Spam-Level: X-Spam-Status: No, score=-103.091 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrOU6ltnU6sf for ; Tue, 18 Jan 2011 17:34:39 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 663AA3A6F73 for ; Tue, 18 Jan 2011 17:34:38 -0800 (PST) Received: by bwz12 with SMTP id 12so339798bwz.31 for ; Tue, 18 Jan 2011 17:37:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JS3Mtl9pK+WsRq+EkIJrtm5laMA/yJNT4Z29li4cdLc=; b=v15eYRlctGJuPLEwrNz8TEtTgHeYEyUVq+3WcpMurVG80EyZWJPJLPcNMu1mISok5r yzxUXlMkSks7UYEPBgjFmATpzzsFuqDaC/R6tRo08554zVqcs602+Y9E4TwU+H79Qu/R Hjc4dQig6tah+g+Ptyu2XuoU2ZLfZ8+I+QPVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=MZiyqG/XxTLAMVum99d+WG+rxnNPqse47baxvvEsQU2KJDt6L/OFJK98bHATGkzYRY uQ7X2rK7d+Vw2Xqhf3KhPmutMCVmKYu66BnSR1SYcPPGHSbhbQSfIKzrgy+HeHKbz7/9 FXAYF99azMNRvqi3kaSWUzAixX0+94sqnCTeo= MIME-Version: 1.0 Received: by 10.204.51.65 with SMTP id c1mr32719bkg.185.1295401034980; Tue, 18 Jan 2011 17:37:14 -0800 (PST) Received: by 10.204.80.6 with HTTP; Tue, 18 Jan 2011 17:37:14 -0800 (PST) In-Reply-To: References: <0F53745179AB40F89024950AA68F23CA@davidPC> Date: Tue, 18 Jan 2011 17:37:14 -0800 Message-ID: From: Greg Shepherd To: David Harrington Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: Re: [Fecframe] Revised security section for the framework X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 01:34:42 -0000 While we're talking sad.. I find it very sad that the IESG had previously approved our charter, and now after years of work we're hearing that our charter is lacking. I also find it sad that these persons having issues with our framework draft and our charter are not responding to the list to engage in discussion but are working through our AD as a proxy for their opinions. This makes it very hard to make progress, though moving issues to DISCUSS may help. Thanks, Greg On Tue, Jan 18, 2011 at 4:58 PM, David Harrington wro= te: > Hi Stephan, > > The really sad part about this whole conversation is that what the > IESG has been pushing for is a documented consideration of the ops and > mgmt perspective, much like the one in your email, and Ali's emails, > and Dave's emails, and Mike's emails, but they want the discussion > captured **** in the document ****. > > But what we get in the document is the assertion that the WG has > decided any such discussion is out of scope of the document (and > presumably the framework), rather than documenting the details of the > WG's considerations. > > My #2 discuss is about whether we should expect some > mandatory-to-implement components or not, since without > mandatory-to-implement components, vendors ar elikely to not implement > common components, and operators cannot choose a consistent set of > components for their deployments in multi-vendor environments. > > This is a discuss-discuss, which means I am not pushing for any action > by the authors; I want a discussion among the IESG about the potential > impact of not having mandatory components, and whether fecframe is one > of the acceptable exceptions to the rule. > > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) > >> -----Original Message----- >> From: Stephan Wenger [mailto:stewe@stewe.org] >> Sent: Tuesday, January 18, 2011 2:10 PM >> To: David Harrington; fecframe@ietf.org >> Subject: Re: [Fecframe] Revised security section for the framework >> >> Hi David, IESG, >> I don't believe the DISCUSSes are helpful. =A0You guys are >> pushing the WG to >> add text that the WG does not deem necessary. =A0Have you >> thought about the >> reasons for the WG's position? >> My understanding is that the fecframe protocol suite will, >> practically, >> used in conjunction with IPTV, mobile TV, and so on. =A0Many, >> of not most, >> of this applications run over IP networks that are NOT the >> Internet (in >> that a majority of the traffic may not be Internet traffic, >> though there >> may be Internet traffic routed on the same infrastructure to the > same >> endpoints). =A0In this application space, (perhaps) most >> security issues, >> and certainly most, if not all, operational issues, are either not >> formally standardized, or standardized in documents by 3GPP, >> ETSI, ITU, >> whatnot. =A0These customer organizations may refer to IETF >> specs for solving >> any issues they deem necessary to be solved, or they may >> devise their own >> solution. =A0One example for this is, in the IPTV field, the XML-coded >> session descriptions Ali has already referred to. >> The IETF specs of fecframe are low level, media-plane tools. >> Interoperability absolutely must be possible on that low level. =A0But >> that's it, IMO. =A0Requiring certain security or operational >> technologies, >> that the customer SDOs may be specifying very differently, is > counter >> productive, as the relevant sections may well be ignored by >> the majority, >> if not by all, implementations, for reasons of practicality. >> Since you >> cannot enforce the implementation of those technologies >> (beyond putting >> meaningless 2119 words in the sections in question), why do you try? >> So my suggestion would be that >> -the security, ops, congestion control, whatnot sections >> ideally should >> point out the security/ops/cc/whatnot issues the framework >> may have, but >> leave the implementer or customer SDO to choose between >> available tools to >> solve those issues if there is a commercial need for solving them. > In >> other words, those sections should include requirements. >> They may hint to >> solutions, but should not require implementation or use. >> -if you insist on adding requirements that an implementation >> can ignore >> without hurting the core protocol's interoperability, then at least >> qualify your 2119 requirements with a phrase such as "if used on the >> Internet". =A0If you don't, you may have formally non-compliant >> implementations out there, to which, arguably, many of the IPR >> declarations do not apply. =A0This cannot be your wish, can it? >> Regards, >> Stephan >> >> >> >> On 1.18.2011 13:28 , "David Harrington" wrote: >> >> >yes. please do, and I will push the other ADs to review the changes >> >and clear where possible. >> > >> >I will note that the new text does not seem to specify that IPsec >> >implementation is REQUIRED (using RFC2119 language). >> >It is only presented as a baseline, and one possible approach. >> >Therefore, I expect it will not satisfy Sean's DISCUSS. >> > >> >dbh >> > >> >> -----Original Message----- >> >> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> >> Sent: Tuesday, January 18, 2011 1:17 PM >> >> To: David Harrington; fecframe@ietf.org >> >> Subject: RE: [Fecframe] Revised security section for the > framework >> >> >> >> Should we submit the current version we have with the >> >> extended security cons section so that at least we can try to >> >> clear the sec related discusses? >> >> >> >> -acbegen >> >> >> >> > -----Original Message----- >> >> > From: David Harrington [mailto:ietfdbh@comcast.net] >> >> > Sent: Tuesday, January 18, 2011 1:13 PM >> >> > To: Ali C. Begen (abegen); fecframe@ietf.org >> >> > Subject: RE: [Fecframe] Revised security section for the >> framework >> >> > >> >> > Hi, >> >> > >> >> > FYI. Today I raised my concerns to the level of a DISCUSS. >> >> > The content of the DISCUSS is being sent under a separate > email. >> >> > >> >> > I have two parts to my discuss >> >> > 1) the lack of discussion of ops+mgmt. I have tried to make my >> >> > comments actionable. >> >> > 2) a larger concern thatthe frameowkr has no >> >mandatory-to-implement >> >> > components. This is a discuss-discuss, which means I am opening >> >the >> >> > discussion within the IESG about whether this is acceptable for > a >> >> > Proposed Standard framework document. >> >> > >> >> > dbh >> >> > >> >> > > -----Original Message----- >> >> > > From: fecframe-bounces@ietf.org >> >> > > [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen >> >> > (abegen) >> >> > > Sent: Friday, December 17, 2010 11:57 AM >> >> > > To: fecframe@ietf.org >> >> > > Subject: [Fecframe] Revised security section for the > framework >> >> > > >> >> > > Please let us know if these changes are good or if you have >> >> > > comments. We would like to conclude this work soon. >> >> > > >> >> > > -acbegen >> >> > > >> >> > > >> >> > > 9. =A0Security Considerations >> >> > > >> >> > > =A0 =A0First of all, it must be clear that the application of FEC >> >> > > protection >> >> > > =A0 =A0to a stream does not provide any kind of security. =A0On t= he >> >> > > opposite, >> >> > > =A0 =A0the FEC Framework itself could be subject to attacks, or >> >could >> >> > pose >> >> > > =A0 =A0new security risks. =A0The goals of this section are to > state >> >the >> >> > > =A0 =A0problem, discuss the risks and identify solutions when >> >> > > feasible. =A0It >> >> > > =A0 =A0also defines a mandatory to implement (but not >> >> mandatory to use) >> >> > > =A0 =A0security scheme. >> >> > > >> >> > > 9.1. =A0Problem Statement >> >> > > >> >> > > =A0 =A0A content delivery system is potentially subject to >> >> many attacks. >> >> > > =A0 =A0Attacks can target the content, or the CDP, or the network >> >> > itself, >> >> > > =A0 =A0with completely different consequences, in particular in >> >> > > terms of the >> >> > > =A0 =A0number of impacted nodes. >> >> > > >> >> > > =A0 =A0Attacks can have several goals: >> >> > > >> >> > > =A0 =A0o =A0They can try to give access to a confidential content >> >(e.g., >> >> > in >> >> > > =A0 =A0 =A0 case of a non-free content). >> >> > > >> >> > > =A0 =A0o =A0They can try to corrupt the source flows (e.g., >> to prevent >> >a >> >> > > =A0 =A0 =A0 receiver from using them), which is a form of DoS > attack. >> >> > > >> >> > > =A0 =A0o =A0They can try to compromise the receiver's behavior > (e.g., >> >by >> >> > > =A0 =A0 =A0 making the decoding of an object computationally >> >> > > expensive), which >> >> > > =A0 =A0 =A0 is another form of DoS attack. >> >> > > >> >> > > =A0 =A0o =A0They can try to compromise the network's behavior > (e.g., >> >by >> >> > > =A0 =A0 =A0 causing congestion within the network), which >> >> > > potentially impacts >> >> > > =A0 =A0 =A0 a large number of nodes. >> >> > > >> >> > > =A0 =A0These attacks can be launched either against the source >> >> > > and/or repair >> >> > > =A0 =A0flows (e.g., by sending fake FEC source and/or repair >> >> packets) or >> >> > > =A0 =A0against the FEC parameters that are sent either in-band >> >> > > (e.g., in the >> >> > > =A0 =A0Repair FEC Payload ID or in the Explicit Source FEC > Payload >> >ID) >> >> > or >> >> > > =A0 =A0out-of-band (e.g., in the FEC Framework Configuration >> >> > Information). >> >> > > >> >> > > =A0 =A0Several dimensions to the problem need to be >> considered. =A0The >> >> > first >> >> > > =A0 =A0one is the way the FEC Framework is used. =A0The FEC >> >> Framework can >> >> > be >> >> > > =A0 =A0used end-to-end, i.e., it can be included in the final >> >> end-device >> >> > > =A0 =A0where the upper application runs; or the FEC Framework can >> >> > > be used in >> >> > > =A0 =A0middleboxes, for instance, to globally protect >> several source >> >> > flows >> >> > > =A0 =A0exchanged between two or more distant sites. >> >> > > >> >> > > =A0 =A0A second dimension is the threat model. =A0When the FEC >> >Framework >> >> > > =A0 =A0operates in the end-device, this device (e.g., a personal >> >> > computer) >> >> > > =A0 =A0might be subject to attacks. =A0Here, the attacker is eith= er >> >the >> >> > end- >> >> > > =A0 =A0user (who might want to access confidential content) >> >> or somebody >> >> > > =A0 =A0else. =A0In all cases the attacker has access to the >> >end-device, >> >> > but >> >> > > =A0 =A0not necessarily to the full control of the end-device (a >> >secure >> >> > > =A0 =A0domain can exist). =A0Similarly, when the FEC Framework >> >> operates in >> >> > a >> >> > > =A0 =A0middlebox, this middlebox can be subject to attacks or the >> >> > attacker >> >> > > =A0 =A0can gain access to it. =A0The threats can also concern the >> >> > end-to-end >> >> > > =A0 =A0transport (e.g., through Internet). =A0Here, examples of >> >threats >> >> > > =A0 =A0include the transmission of fake FEC source or repair >> >packets, >> >> > the >> >> > > =A0 =A0replay of valid packets, the drop, delay or misordering of >> >> > packets, >> >> > > =A0 =A0and of course traffic eavesdropping. >> >> > > >> >> > > =A0 =A0The third dimension consists in the desired security >> >> > > services. =A0Among >> >> > > =A0 =A0them, the content integrity and sender authentication >> >services >> >> > are >> >> > > =A0 =A0probably the most important features. =A0We can also menti= on >> >DoS >> >> > > =A0 =A0mitigation, anti-replay protection or content >> >confidentiality. >> >> > > >> >> > > =A0 =A0Finally, the fourth dimension consists in the security > tools >> >> > > =A0 =A0available. =A0This is the case of the various Digital Righ= ts >> >> > > Management >> >> > > =A0 =A0(DRM) systems, defined out of the context of the IETF and >> >> > > that can be >> >> > > =A0 =A0proprietary solutions. =A0Otherwise SRTP and IPsec/ESP are > two >> >> > tools >> >> > > =A0 =A0that can turn out to be useful in the context of the FEC >> >> > Framework. >> >> > > =A0 =A0Note that using SRTP requires that the application >> >> generates RTP >> >> > > =A0 =A0source flows and, when applied below the FEC Framework, >> >> > > that both the >> >> > > =A0 =A0FEC source and repair packets to be regular RTP packets. >> >> > Therefore >> >> > > =A0 =A0SRTP is not considered as a universal solution applicable >> >> > > in all use >> >> > > =A0 =A0cases. >> >> > > >> >> > > =A0 =A0In the following sections, we further discuss security >> >aspects >> >> > > =A0 =A0related to the use of the FEC Framework. >> >> > > >> >> > > 9.2. =A0Attacks Against the Data Flows >> >> > > >> >> > > 9.2.1. =A0Access to Confidential Content >> >> > > >> >> > > =A0 =A0Access control to the source flow being transmitted is >> >> typically >> >> > > =A0 =A0provided by means of encryption. =A0This encryption can be >> >> > > done by the >> >> > > =A0 =A0content provider itself, or within the application >> >> (for instance >> >> > by >> >> > > =A0 =A0using the Secure Real-time Transport Protocol (SRTP) >> >> [RFC3711]), >> >> > or >> >> > > =A0 =A0at the network layer, on a per-packet basis when >> IPsec/ESP is >> >> > used >> >> > > =A0 =A0[RFC4303]. =A0If confidentiality is a concern, it is >> >RECOMMENDED >> >> > that >> >> > > =A0 =A0one of these solutions is used. =A0Even if we mention >> >> these attacks >> >> > > =A0 =A0here, they are neither related to nor facilitated by the >> >> > > use of FEC. >> >> > > >> >> > > =A0 =A0Note that when encryption is applied, this encryption MUST >> >> > > either be >> >> > > =A0 =A0applied on the source data before the FEC protection, >> >> or if done >> >> > > =A0 =A0after the FEC protection, then both the FEC source packets >> >> > > and repair >> >> > > =A0 =A0packets MUST be encrypted (and an encryption at least as >> >> > > =A0 =A0cryptographically secure as the encryption applied on the >> >> > > FEC source >> >> > > =A0 =A0packets MUST be used for the FEC repair packets). >> >> Otherwise, if >> >> > > =A0 =A0encryption were to be performed only on the FEC source >> >> > > packets after >> >> > > =A0 =A0FEC encoding, a non-authorized receiver could be able to >> >> > > recover the >> >> > > =A0 =A0source data after decoding the FEC repair packets >> >> provided that a >> >> > > =A0 =A0sufficient number of such packets were available. >> >> > > >> >> > > =A0 =A0The following considerations apply when choosing where to >> >apply >> >> > > =A0 =A0encryption (and more generally where to apply security >> >services >> >> > > =A0 =A0beyond encryption). =A0Once decryption has taken place, th= e >> >> > > source data >> >> > > =A0 =A0is in plaintext. =A0The full path between the output of th= e >> >> > > deciphering >> >> > > =A0 =A0module and the final destination (e.g., the TV display >> >> in case of >> >> > a >> >> > > =A0 =A0video) MUST be secured, in order to prevent any > unauthorized >> >> > access >> >> > > =A0 =A0to the source data. >> >> > > >> >> > > =A0 =A0When the FEC Framework endpoint is the end system (i.e., >> >where >> >> > the >> >> > > =A0 =A0upper application runs) and if the threat model includes > the >> >> > > =A0 =A0possibility that an attacker has access to this end >> >> > > system, then the >> >> > > =A0 =A0end system architecture is very important. =A0More >> >> > > precisely, in order >> >> > > =A0 =A0to prevent an attacker to get hold of the plaintext, all >> >> > > processings, >> >> > > =A0 =A0once deciphering has taken place, MUST occur in a > protected >> >> > > =A0 =A0environment. =A0If encryption is applied after FEC > protection >> >at >> >> > the >> >> > > =A0 =A0sending side (i.e., below FEC Framework), it means that >> >> > > FEC decoding >> >> > > =A0 =A0MUST take place in the protected environment. =A0With > certain >> >use >> >> > > =A0 =A0cases, this MAY be complicated or even impossible. =A0In >> >> that case >> >> > > =A0 =A0applying encryption before FEC protection is preferred. >> >> > > >> >> > > =A0 =A0When the FEC Framework endpoint is a middlebox, the >> >> > > recovered source >> >> > > =A0 =A0flow, after FEC decoding, SHOULD NOT be sent in >> >> plaintext to the >> >> > > =A0 =A0final destination(s) if the threat model includes the >> >> possibility >> >> > > =A0 =A0that an attacker eavesdrops the traffic. =A0In that case >> >> also it is >> >> > > =A0 =A0preferred to apply encryption before FEC protection. >> >> > > >> >> > > =A0 =A0In some cases, encryption could be applied both before and >> >> > > after the >> >> > > =A0 =A0FEC protection. =A0The considerations described above stil= l >> >apply >> >> > in >> >> > > =A0 =A0such cases. >> >> > > >> >> > > 9.2.2. =A0Content Corruption >> >> > > >> >> > > =A0 =A0Protection against corruptions (e.g., against forged >> >> FEC source/ >> >> > > =A0 =A0repair packets) is achieved by means of a content > integrity >> >> > > =A0 =A0verification/source authentication scheme. =A0This service > is >> >> > usually >> >> > > =A0 =A0provided at the packet level. =A0In this case, after > removing >> >all >> >> > the >> >> > > =A0 =A0forged packets, the source flow might sometimes be >> recovered. >> >> > > =A0 =A0Several techniques can provide this content > integrity/source >> >> > > =A0 =A0authentication service: >> >> > > >> >> > > =A0 =A0o =A0At the application layer, SRTP [RFC3711] provides > several >> >> > > =A0 =A0 =A0 solutions to check the integrity and authenticate the >> >source >> >> > of >> >> > > =A0 =A0 =A0 RTP and RTCP messages, among other services. =A0For >> >instance, >> >> > > =A0 =A0 =A0 associated to the Timed Efficient Stream Loss-Toleran= t >> >> > > =A0 =A0 =A0 Authentication (TESLA) [RFC4383], SRTP is an attracti= ve >> >> > solution >> >> > > =A0 =A0 =A0 that is robust to losses, provides a true >> >> > > authentication/integrity >> >> > > =A0 =A0 =A0 service, and does not create any prohibitive processi= ng >> >load >> >> > or >> >> > > =A0 =A0 =A0 transmission overhead. =A0Yet, checking a packet requ= ires > a >> >> > small >> >> > > =A0 =A0 =A0 delay (a second or more) after its reception with >> >> > > TESLA. =A0Whether >> >> > > =A0 =A0 =A0 this extra delay, both in terms of startup delay at t= he >> >> > > client and >> >> > > =A0 =A0 =A0 end-to-end delay, is appropriate or not depends on th= e >> >> > > target use >> >> > > =A0 =A0 =A0 case. =A0In some situations, this might degrade the u= ser >> >> > > experience. >> >> > > =A0 =A0 =A0 In other situations, this will not be an issue. =A0Ot= her >> >> > building >> >> > > =A0 =A0 =A0 blocks can be used within SRTP to provide content >> >integrity/ >> >> > > =A0 =A0 =A0 authentication services. >> >> > > >> >> > > =A0 =A0o =A0At the network layer, IPsec/ESP [RFC4303] offers >> >> (among other >> >> > > =A0 =A0 =A0 services) an integrity verification mechanism that ca= n >> >> > > be used to >> >> > > =A0 =A0 =A0 provide authentication/content integrity services. >> >> > > >> >> > > =A0 =A0It is up to the developer and the person in charge of >> >> > > deployment, who >> >> > > =A0 =A0know the security requirements and features of the target >> >> > > application >> >> > > =A0 =A0area, to define which solution is the most appropriate. >> >> > > Nonetheless >> >> > > =A0 =A0it is RECOMMENDED that at least one of these >> >> techniques is used. >> >> > > >> >> > > =A0 =A0Note that when integrity protection is applied, it is >> >> RECOMMENDED >> >> > > =A0 =A0that it takes place on both FEC source and repair packets. >> >The >> >> > > =A0 =A0motivation is to avoid corrupted packets to be >> >> considered during >> >> > > =A0 =A0decoding, which would often lead to a decoding failure or >> >> > > result in a >> >> > > =A0 =A0corrupted decoded source flow. >> >> > > >> >> > > 9.3. =A0Attacks Against the FEC Parameters >> >> > > >> >> > > =A0 =A0Attacks on these FEC parameters can prevent the decoding > of >> >the >> >> > > =A0 =A0associated object. =A0For instance, modifying the finite >> >> > > field size of >> >> > > =A0 =A0a Reed-Solomon FEC scheme (when applicable) will lead >> >> a receiver >> >> > to >> >> > > =A0 =A0consider a different FEC code. >> >> > > >> >> > > =A0 =A0It is therefore RECOMMENDED that security measures are > taken >> >to >> >> > > =A0 =A0guarantee the FEC Framework Configuration Information >> >> integrity. >> >> > > =A0 =A0Since the FEC Framework does not define how the FEC >> Framework >> >> > > =A0 =A0Configuration Information is communicated from sender to >> >> > > receiver, we >> >> > > =A0 =A0cannot provide further recommendations on how to guarantee >> >its >> >> > > =A0 =A0integrity. =A0However, any complete CDP specification >> MUST give >> >> > > =A0 =A0recommendations on how to achieve it. =A0When the FEC >> Framework >> >> > > =A0 =A0Configuration Information is sent out-of-band, e.g., >> >> in a session >> >> > > =A0 =A0description, it SHOULD be protected, for instance, by >> >digitally >> >> > > =A0 =A0signing it. >> >> > > >> >> > > =A0 =A0Attacks are also possible against some FEC parameters >> >> > > included in the >> >> > > =A0 =A0Explicit Source FEC Payload ID and Repair FEC Payload ID. >> >For >> >> > > =A0 =A0instance, modifying the Source Block Number of an FEC > source >> >or >> >> > > =A0 =A0repair packet will lead a receiver to assign this >> packet to a >> >> > wrong >> >> > > =A0 =A0block. >> >> > > >> >> > > =A0 =A0It is therefore RECOMMENDED that security measures are > taken >> >to >> >> > > =A0 =A0guarantee the Explicit Source FEC Payload ID and Repair > FEC >> >> > Payload >> >> > > =A0 =A0ID integrity. =A0To that purpose, one of the packet-level >> >source >> >> > > =A0 =A0authentication/content integrity techniques of Section >> >> 9.2.2 can >> >> > be >> >> > > =A0 =A0used. >> >> > > >> >> > > 9.4. =A0When Several Source Flows are to be Protected Together >> >> > > >> >> > > =A0 =A0When several source flows, with different security >> >> > > requirements, need >> >> > > =A0 =A0to be FEC protected jointly, within a single FEC Framework >> >> > > instance, >> >> > > =A0 =A0then each flow MAY be processed appropriately, before the >> >> > > protection. >> >> > > =A0 =A0For instance, source Flows that require access >> control MAY be >> >> > > =A0 =A0encrypted before they are FEC protected. >> >> > > >> >> > > =A0 =A0There are also situations where the only insecure domain > is >> >the >> >> > one >> >> > > =A0 =A0over which the FEC Framework operates. =A0In that case, th= is >> >> > > situation >> >> > > =A0 =A0MAY be addressed at the network layer, using IPsec/ESP > (see >> >> > > =A0 =A0Section 9.5), even if only a subset of the source flows > have >> >> > strict >> >> > > =A0 =A0security requirements. >> >> > > >> >> > > =A0 =A0Since the use of FEC Framework should not add any >> >> > > additional threat, >> >> > > =A0 =A0it is RECOMMENDED that the FEC Framework aggregate >> flow be in >> >> > line >> >> > > =A0 =A0with the maximum security requirements of the individual >> >source >> >> > > =A0 =A0flows. =A0For instance, if denial-of-service (DoS) > protection >> >is >> >> > > =A0 =A0required, an integrity protection SHOULD be provided below >> >the >> >> > FEC >> >> > > =A0 =A0Framework, using for instance IPsec/ESP. >> >> > > >> >> > > =A0 =A0Generally speaking, whenever feasible, it is RECOMMENDED >> >> > > to avoid FEC >> >> > > =A0 =A0protecting flows with totally different security >> >requirements. >> >> > > =A0 =A0Otherwise, an important processing would be added to >> >> protect the >> >> > > =A0 =A0source flows that do not need it. >> >> > > >> >> > > 9.5. =A0Baseline Secure FEC Framework Operation >> >> > > >> >> > > =A0 =A0This section describes a baseline mode of secure FEC >> >Framework >> >> > > =A0 =A0operation based on the application of the IPsec security >> >> > protocol, >> >> > > =A0 =A0which is one possible solution to solve or mitigate >> >> the security >> >> > > =A0 =A0threats introduced by the use of the FEC Framework. >> >> > > >> >> > > =A0 =A0Two related documents are of interest. =A0First, >> Section 5.1 of >> >> > > =A0 =A0[RFC5775] defines a baseline secure ALC operation for >> >> > > sender-to-group >> >> > > =A0 =A0transmissions, assuming the presence of a single sender >> >> > > and a source- >> >> > > =A0 =A0specific multicast (SSM) or SSM-like operation. >> The proposed >> >> > > =A0 =A0solution, based on IPsec/ESP, can be used to provide a >> >baseline >> >> > FEC >> >> > > =A0 =A0Framework secure operation, for the downstream source > flow. >> >> > > >> >> > > =A0 =A0Second, Section 7.1 of [RFC5740] defines a baseline secure >> >NORM >> >> > > =A0 =A0operation, for sender-to-group transmissions as well as >> >unicast >> >> > > =A0 =A0feedbacks from receivers. =A0Here, it is also assumed ther= e >> >> > > is a single >> >> > > =A0 =A0sender. =A0The proposed solution is also based on IPsec/ES= P. >> >> > > =A0However, >> >> > > =A0 =A0the difference with respect to the first document relies > on >> >the >> >> > > =A0 =A0management of IPsec Security Associations (SA) and >> >> corresponding >> >> > > =A0 =A0Security Policy Database (SPD) entries, since NORM >> >> > > requires a second >> >> > > =A0 =A0set of SA and SPD to be defined to protect unicast >> >> feedbacks from >> >> > > =A0 =A0receivers. >> >> > > >> >> > > =A0 =A0The FEC Framework has been defined in such a way to be >> >> > independent >> >> > > =A0 =A0from the application that generates source flows. =A0Some >> >> > > applications >> >> > > =A0 =A0might use purely unidirectional flows, while other >> >> > > applications might >> >> > > =A0 =A0also use unicast feedbacks from the receivers. =A0For >> >> > > instance, this is >> >> > > =A0 =A0the case when considering RTP/RTCP based source flows. >> >> > > Depending on >> >> > > =A0 =A0the specific situation, it is RECOMMENDED that the > baseline >> >> > secure >> >> > > =A0 =A0FEC Framework operation inherits from [RFC5775] in >> >> case of purely >> >> > > =A0 =A0unidirectional sender-to-group flows, or [RFC5740] in case >> >both >> >> > > =A0 =A0sender-to-group and unicast feedbacks flows are needed. >> >> > > >> >> > > =A0 =A0Note that the IPsec/ESP requirements profiles outlined in >> >> > [RFC5775] >> >> > > =A0 =A0and [RFC5740] are commonly available on many >> potential hosts. >> >> > They >> >> > > =A0 =A0can form the basis of a secure mode of operation. =A0One >> >> potential >> >> > > =A0 =A0limitation, however, is the need for privileged user >> >> > authorization. >> >> > > =A0 =A0However, automated key management implementations are >> >typically >> >> > > =A0 =A0configured with the privileges necessary to affect system >> >IPsec >> >> > > =A0 =A0configuration. >> >> > > >> >> > > _______________________________________________ >> >> > > Fecframe mailing list >> >> > > Fecframe@ietf.org >> >> > > https://www.ietf.org/mailman/listinfo/fecframe >> >> > > >> >> >> >> >> > >> >_______________________________________________ >> >Fecframe mailing list >> >Fecframe@ietf.org >> >https://www.ietf.org/mailman/listinfo/fecframe >> >> >> > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >