From abegen@cisco.com Wed Dec 1 09:29:22 2010 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 221C93A6C60 for ; Wed, 1 Dec 2010 09:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.38 X-Spam-Level: X-Spam-Status: No, score=-10.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 3qbRsZpIMFBG for ; Wed, 1 Dec 2010 09:29:12 -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 881613A6C7E for ; Wed, 1 Dec 2010 09:29:05 -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: AvsEAKoU9kyrR7Ht/2dsb2JhbACjGHGpDIlGkVuCcYJWBIReiR4 X-IronPort-AV: E=Sophos;i="4.59,284,1288569600"; d="scan'208";a="629018229" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 01 Dec 2010 17:30:18 +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 oB1HUISu029855 for ; Wed, 1 Dec 2010 17:30:18 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); Wed, 1 Dec 2010 09:30:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Dec 2010 09:29:34 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DC938DA@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed changes to the framework draft - part 2 (security) Thread-Index: AcuRedz3sHHRfwQAR1qNNFQTbkgBUQ== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 01 Dec 2010 17:30:18.0183 (UTC) FILETIME=[6C2A1D70:01CB917D] Subject: [Fecframe] Proposed changes to the framework draft - part 2 (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: Wed, 01 Dec 2010 17:29:22 -0000 This is the 2nd part for the changes we need to make in the framework = draft. This part is related to the security issues. Please refer to the = tracker to see the comments from the IESG. https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ I would like to thank Vincent for providing this brand new security = section. I just added a few minor points into the text. If there are any objections, please speak up. If you are OK with these = changes, please also speak up so that we can show WG consensus.=20 Thanks, -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. Some of them target the network (e.g., to compromise the routing infrastructure by compromising the congestion control component), others can target the Content Delivery Protocol (CDP) (e.g., to compromise its normal behavior), and finally some attacks target the content itself. More specifically, these 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 and/or repair flows (e.g., to prevent a receiver from using them). o They can try to compromise the receiver's behavior (e.g., by making the decoding of an object computationally expensive). o They can try to compromise the network's behavior (e.g., by causing congestion within the network). These attacks can be launched either against the source and/or repair flows (e.g., by sending forged 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 a session description). 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 before the FEC protection, or, if done after the FEC protection, then this encryption MUST be applied on both the FEC source packets and repair packets. Otherwise, if encryption were to be performed only on the FEC source packets after FEC encoding, then a non-authorized receiver could be able to recover the source data after decoding the repair packets provided that a sufficient number of such packets were available. 9.2.2. Content Corruption Protection against corruptions (e.g., after sending 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. 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 knows 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. 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 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. This approach is documented here to provide a reference of an interoperable secure mode of operation. However, other approaches, including other forms of IPsec application, MAY be used or specified in the future. 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. From gjshep@gmail.com Wed Dec 1 09:49:16 2010 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 8AA113A6C1A for ; Wed, 1 Dec 2010 09:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.867 X-Spam-Level: X-Spam-Status: No, score=-102.867 tagged_above=-999 required=5 tests=[AWL=0.732, 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 pm6dEy3li-Cg for ; Wed, 1 Dec 2010 09:49:15 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id E6DDE3A6BED for ; Wed, 1 Dec 2010 09:49:14 -0800 (PST) Received: by yxp4 with SMTP id 4so694371yxp.31 for ; Wed, 01 Dec 2010 09:50:28 -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=/Q8AVII6AB7snrY/rhzkJPmP32GRngBrTQMviqfLN5E=; b=lnhevTM4/oMGzJ5OfH5NUd/KYlRjR7TfpfP8tbGa++dcCY5DYxuDt9eoO7/N+kmLS8 JeJC6GU3Z1gnJKhLRyEluuXfjldSeQ1H+qLn2XpnSi7Gkx9KgCJe2MDZzHpbmZN0A9mi EA++YRhIGEo6rMsdtvcHbMNhmcmOOvsEtOowc= 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=Ed/ZSLdHWZw/6ML39b3f0oaKHm00bBNwh4NAAugixt3+nZxBL/BUQ3pnQYtJAbRGyL 5zHK/xMMv7A++N0WlNUrNMuPsYgGeuqVur7n+m+DzgY8P7zHPhzlF6c9DfXKzusl18ml 8kT2YyEaKil2kCfhT/CvLzCecTncxbmPuqn7w= MIME-Version: 1.0 Received: by 10.204.136.70 with SMTP id q6mr7964677bkt.208.1291225826498; Wed, 01 Dec 2010 09:50:26 -0800 (PST) Received: by 10.204.112.71 with HTTP; Wed, 1 Dec 2010 09:50:26 -0800 (PST) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DC938DA@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540DC938DA@xmb-sjc-215.amer.cisco.com> Date: Wed, 1 Dec 2010 09:50:26 -0800 Message-ID: From: Greg Shepherd To: "Ali C. Begen (abegen)" 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: Wed, 01 Dec 2010 17:49:16 -0000 Thanks Vincent and Ali! So far we've had no feedback on the list for these changes. Please read and respond ASAP - even if you approve please send your approval to the list. We are so close to finishing up this WG.. let's not stumble now. Thanks, Greg On Wed, Dec 1, 2010 at 9:29 AM, Ali C. Begen (abegen) wr= ote: > This is the 2nd part for the changes we need to make in the framework dra= ft. This part is related to the security issues. Please refer to the tracke= r to see the comments from the IESG. > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ > > I would like to thank Vincent for providing this brand new security secti= on. I just added a few minor points into the text. > > If there are any objections, please speak up. If you are OK with these ch= anges, please also speak up so that we can show WG consensus. > > Thanks, > -acbegen > > > > > 9. =A0Security Considerations > > =A0 First of all, it must be clear that the application of FEC protection > =A0 to a stream does not provide any kind of security. =A0On the opposite= , > =A0 the FEC Framework itself could be subject to attacks, or could pose > =A0 new security risks. =A0The goals of this section are to state the > =A0 problem, discuss the risks and identify solutions when feasible. =A0I= t > =A0 also defines a mandatory to implement (but not mandatory to use) > =A0 security scheme. > > 9.1. =A0Problem Statement > > =A0 A content delivery system is potentially subject to many attacks. > =A0 Some of them target the network (e.g., to compromise the routing > =A0 infrastructure by compromising the congestion control component), > =A0 others can target the Content Delivery Protocol (CDP) (e.g., to > =A0 compromise its normal behavior), and finally some attacks target the > =A0 content itself. > > =A0 More specifically, these attacks can have several goals: > > =A0 o =A0They can try to give access to a confidential content (e.g., in > =A0 =A0 =A0case of a non-free content). > > =A0 o =A0They can try to corrupt the source and/or repair flows (e.g., to > =A0 =A0 =A0prevent a receiver from using them). > > =A0 o =A0They can try to compromise the receiver's behavior (e.g., by > =A0 =A0 =A0making the decoding of an object computationally expensive). > > =A0 o =A0They can try to compromise the network's behavior (e.g., by > =A0 =A0 =A0causing congestion within the network). > > =A0 These attacks can be launched either against the source and/or repair > =A0 flows (e.g., by sending forged FEC source and/or repair packets) or > =A0 against the FEC parameters that are sent either in-band (e.g., in the > =A0 Repair FEC Payload ID, or in the Explicit Source FEC Payload ID) or > =A0 out-of-band (e.g., in a session description). > > 9.2. =A0Attacks Against the Data Flows > > 9.2.1. =A0Access to Confidential Content > > =A0 Access control to the source flow being transmitted is typically > =A0 provided by means of encryption. =A0This encryption can be done by th= e > =A0 content provider itself, or within the application (for instance by > =A0 using the Secure Real-time Transport Protocol (SRTP) [RFC3711]), or > =A0 at the network layer, on a per-packet basis when IPsec/ESP is used > =A0 [RFC4303]. =A0If confidentiality is a concern, it is RECOMMENDED that > =A0 one of these solutions is used. =A0Even if we mention these attacks > =A0 here, they are neither related to nor facilitated by the use of FEC. > > =A0 Note that when encryption is applied, this encryption MUST either be > =A0 applied before the FEC protection, or, if done after the FEC > =A0 protection, then this encryption MUST be applied on both the FEC > =A0 source packets and repair packets. =A0Otherwise, if encryption were t= o > =A0 be performed only on the FEC source packets after FEC encoding, then > =A0 a non-authorized receiver could be able to recover the source data > =A0 after decoding the repair packets provided that a sufficient number > =A0 of such packets were available. > > 9.2.2. =A0Content Corruption > > =A0 Protection against corruptions (e.g., after sending forged FEC > =A0 source/repair packets) is achieved by means of a content integrity > =A0 verification/source authentication scheme. =A0This service is usually > =A0 provided at the packet level. =A0In this case, after removing all the > =A0 forged packets, the source flow might sometimes be recovered. > =A0 Several techniques can provide this content integrity/source > =A0 authentication service: > > =A0 o =A0At the application layer, SRTP [RFC3711] provides several > =A0 =A0 =A0solutions to check the integrity and authenticate the source o= f > =A0 =A0 =A0RTP and RTCP messages, among other services. =A0For instance, > =A0 =A0 =A0associated to the Timed Efficient Stream Loss-Tolerant > =A0 =A0 =A0Authentication (TESLA) [RFC4383], SRTP is an attractive soluti= on > =A0 =A0 =A0that is robust to losses, provides a true authentication/integ= rity > =A0 =A0 =A0service, and does not create any prohibitive processing load o= r > =A0 =A0 =A0transmission overhead. =A0Yet, checking a packet requires a sm= all > =A0 =A0 =A0delay (a second or more) after its reception with TESLA. =A0Ot= her > =A0 =A0 =A0building blocks can be used within SRTP to provide content > =A0 =A0 =A0integrity/authentication services. > > =A0 o =A0At the network layer, IPsec/ESP [RFC4303] offers (among other > =A0 =A0 =A0services) an integrity verification mechanism that can be used= to > =A0 =A0 =A0provide authentication/content integrity services. > > =A0 It is up to the developer and the person in charge of deployment, who > =A0 knows the security requirements and features of the target > =A0 application area, to define which solution is the most appropriate. > =A0 Nonetheless it is RECOMMENDED that at least one of these techniques > =A0 is used. > > =A0 Note that when integrity protection is applied, it is RECOMMENDED > =A0 that it takes place on both FEC source and repair packets. =A0The > =A0 motivation is to avoid corrupted packets to be considered during > =A0 decoding, which would often lead to a decoding failure or result in a > =A0 corrupted decoded source flow. > > 9.3. =A0Attacks Against the FEC Parameters > > =A0 Attacks on these FEC parameters can prevent the decoding of the > =A0 associated object. =A0For instance, modifying the finite field size o= f > =A0 a Reed-Solomon FEC scheme (when applicable) will lead a receiver to > =A0 consider a different FEC code. > > =A0 It is therefore RECOMMENDED that security measures are taken to > =A0 guarantee the FEC Framework Configuration Information integrity. > =A0 When the FEC Framework Configuration Information is sent out-of-band, > =A0 e.g., in a session description, it SHOULD be protected, for instance > =A0 by digitally signing it. > > =A0 Attacks are also possible against some FEC parameters included in the > =A0 Explicit Source FEC Payload ID and Repair FEC Payload ID. =A0For > =A0 instance, modifying the Source Block Number of an FEC source or > =A0 repair packet will lead a receiver to assign this packet to a wrong > =A0 block. > > =A0 It is therefore RECOMMENDED that security measures are taken to > =A0 guarantee the Explicit Source FEC Payload ID and Repair FEC Payload > =A0 ID integrity. =A0To that purpose, one of the packet-level source > =A0 authentication/content integrity techniques of Section 9.2.2 can be > =A0 used. > > 9.4. =A0When Several Source Flows are to be Protected Together > > =A0 When several source flows, with different security requirements, need > =A0 to be FEC protected jointly, within a single FEC Framework instance, > =A0 then each flow MAY be processed appropriately, before the protection. > =A0 For instance, source Flows that require access control MAY be > =A0 encrypted before they are FEC protected. > > =A0 There are also situations where the only insecure domain is the one > =A0 over which the FEC Framework operates. =A0In that case, this situatio= n > =A0 MAY be addressed at the network layer, using IPsec/ESP (see > =A0 Section 9.5), even if only a subset of the source flows have strict > =A0 security requirements. > > =A0 Since the use of FEC Framework should not add any additional threat, > =A0 it is RECOMMENDED that the FEC Framework aggregate flow be in line > =A0 with the maximum security requirements of the individual source > =A0 flows. =A0For instance, if denial-of-service (DoS) protection is > =A0 required, an integrity protection SHOULD be provided below the FEC > =A0 Framework, using IPsec/ESP. > > =A0 Generally speaking, whenever feasible, it is RECOMMENDED to avoid FEC > =A0 protecting flows with totally different security requirements. > =A0 Otherwise, an important processing would be added to protect the > =A0 source flows that do not need it. > > 9.5. =A0Baseline Secure FEC Framework Operation > > =A0 This section describes a baseline mode of secure FEC Framework > =A0 operation based on the application of the IPsec security protocol. > =A0 This approach is documented here to provide a reference of an > =A0 interoperable secure mode of operation. =A0However, other approaches, > =A0 including other forms of IPsec application, MAY be used or specified > =A0 in the future. > > =A0 Two related documents are of interest. =A0First, Section 5.1 of > =A0 [RFC5775] defines a baseline secure ALC operation for sender-to-group > =A0 transmissions, assuming the presence of a single sender and a source- > =A0 specific multicast (SSM) or SSM-like operation. =A0The proposed > =A0 solution, based on IPsec/ESP, can be used to provide a baseline FEC > =A0 Framework secure operation, for the downstream source flow. > > =A0 Second, Section 7.1 of [RFC5740] defines a baseline secure NORM > =A0 operation, for sender-to-group transmissions as well as unicast > =A0 feedbacks from receivers. =A0Here, it is also assumed there is a sing= le > =A0 sender. =A0The proposed solution is also based on IPsec/ESP. =A0Howev= er, > =A0 the difference with respect to the first document relies on the > =A0 management of IPsec Security Associations (SA) and corresponding > =A0 Security Policy Database (SPD) entries, since NORM requires a second > =A0 set of SA and SPD to be defined to protect unicast feedbacks from > =A0 receivers. > > =A0 The FEC Framework has been defined in such a way to be independent > =A0 from the application that generates source flows. =A0Some application= s > =A0 might use purely unidirectional flows, while other applications might > =A0 also use unicast feedbacks from the receivers. =A0For instance, this = is > =A0 the case when considering RTP/RTCP based source flows. =A0Depending o= n > =A0 the specific situation, it is RECOMMENDED that the baseline secure > =A0 FEC Framework operation inherits from [RFC5775] in case of purely > =A0 unidirectional sender-to-group flows, or [RFC5740] in case both > =A0 sender-to-group and unicast feedbacks flows are needed. > > =A0 Note that the IPsec/ESP requirements profiles outlined in [RFC5775] > =A0 and [RFC5740] are commonly available on many potential hosts. =A0They > =A0 can form the basis of a secure mode of operation. =A0One potential > =A0 limitation, however, is the need for privileged user authorization. > =A0 However, automated key management implementations are typically > =A0 configured with the privileges necessary to affect system IPsec > =A0 configuration. > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From csp@csperkins.org Wed Dec 1 10:32:58 2010 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 024113A6C93 for ; Wed, 1 Dec 2010 10:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.079 X-Spam-Level: X-Spam-Status: No, score=-103.079 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 m51d0hnbSc0U for ; Wed, 1 Dec 2010 10:32:53 -0800 (PST) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id 835E43A6C9A for ; Wed, 1 Dec 2010 10:32:52 -0800 (PST) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PNrVG-0002AD-jN; Wed, 01 Dec 2010 18:34:06 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-92--611376291 From: Colin Perkins In-Reply-To: Date: Wed, 1 Dec 2010 18:33:56 +0000 Message-Id: References: <20101125193001.16083.70034.idtracker@localhost> To: Thomas Stockhammer X-Mailer: Apple Mail (2.1082) Cc: fecframe@ietf.org Subject: Re: [Fecframe] Fwd: I-D Action:draft-ietf-fecframe-rtp-raptor-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: Wed, 01 Dec 2010 18:32:58 -0000 --Apple-Mail-92--611376291 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thomas, I've just (very quickly) read the -04 draft. Some comments from an RTP = perspective: - Section 4.1: explain how the RTP payload type is chosen (dynamic = assignment) and signalled using SDP. - Section 4.1: explain how the SSRC is assigned, and how the repair RTP = session is associated with the source RTP session using RTCP. They = should probably be sent as separate RTP sessions, using RTCP CNAME to = align, but this somewhat depends on whether the FEC is systematic or = not. - Section 5: "Applications that use this media type" is not specified. - Section 10: the SDP is incorrect: RTP/AVT on the m=3D line should be = RTP/AVP and the fmt is not specified. - Section 10: is the grouping using FID mandatory, or an example of how = it can be done? - Section 9 should probably give many more details on how the RTP = headers are constructed, and how the repair flow and source flows are = associated. It seems somewhat light. Cheers, Colin On 25 Nov 2010, at 19:45, Thomas Stockhammer wrote: > Experts, >=20 > we also have reactivated draft-ietf-fecframe-rtp-raptor-04. Highlights = of the changes compared to -03 > - Update of authors > - Alignment with draft-ietf-rmt-bb-fec-raptorq-04 > - Alignment with draft-ietf-fecframe-raptor-03 > - Alignment with draft-ietf-fecframe-11 > - Some minor editorial updates > - Updates of references > - A significant amount of comments from Ali are integrated in the = revised version. Non-implemented comments were resolved offline with Ali > - Some small comments from Mike Luby on terminology are integrated. >=20 > Thanks to Ali and Mike. >=20 > I think it is time to get this out of the queue.=20 >=20 > The document should also be forwarded to AVT once we have a stable = version. >=20 > Thanks and Best regards and Happy Thanksgivings ... >=20 > Thomas >=20 >=20 > Begin forwarded message: >=20 >> From: Internet-Drafts@ietf.org >> Date: November 25, 2010 8:30:01 PM GMT+01:00 >> To: i-d-announce@ietf.org >> Cc: fecframe@ietf.org >> Subject: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-04.txt >>=20 >> 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. >>=20 >>=20 >> Title : RTP Payload Format for Raptor FEC >> Author(s) : M. Watson, T. Stockhammer >> Filename : draft-ietf-fecframe-rtp-raptor-04.txt >> Pages : 25 >> Date : 2010-11-25 >>=20 >> This document specifies an RTP payload format for Forward Error >> Correction /(FEC) repair data produced by the Raptor FEC schemes. >> Raptor FEC schemes are specified for use with the IETF FEC Framework >> which supports transport of repair data over both UDP and RTP. This >> document specifies the payload format which is required for the use >> of RTP to carry Raptor repair flows. >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-04.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. > >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >=20 > --- > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com > Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >=20 >=20 >=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-92--611376291 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

- Section 10: the = SDP is incorrect: RTP/AVT on the m=3D line should be RTP/AVP and the fmt = is not specified.

- Section 10: is the grouping = using FID mandatory, or an example of how it can be = done?

- Section 9 should probably give many = more details on how the RTP headers are constructed, and how the repair = flow and source flows are associated. It seems somewhat = light.

Cheers,
Colin



On 25 Nov 2010, at 19:45, Thomas = Stockhammer wrote:
Experts,

we also = have reactivated draft-ietf-fecframe-rtp-raptor-04. Highlights of = the changes compared to -03
- Update of authors
- = Alignment with draft-ietf-rmt-bb-fec-raptorq-04
- = Alignment with draft-ietf-fecframe-raptor-03
- = Alignment with draft-ietf-fecframe-11
- Some minor = editorial updates
- Updates of references
- A = significant amount of comments from Ali are integrated in the revised = version. Non-implemented comments were resolved offline with = Ali
- Some small comments from Mike Luby on terminology are = integrated.

Thanks to Ali and = Mike.

I think it is time to get this out of the = queue. 

The document should also be = forwarded to AVT once we have a stable = version.

Thanks and Best regards and Happy = Thanksgivings = ...

Thomas

<= div>
Begin forwarded message:

Date: November 25, 2010 8:30:01 PM = GMT+01:00
Subject: [Fecframe] I-D = Action:draft-ietf-fecframe-rtp-raptor-04.txt

= 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 =           : RTP = Payload Format for Raptor FEC
Author(s) =       : M. Watson, T. Stockhammer
Filename =        : = draft-ietf-fecframe-rtp-raptor-04.txt
Pages =           : = 25
= Date =            : = 2010-11-25

This document specifies an RTP payload format for = Forward Error
Correction /(FEC) repair data produced by the Raptor = FEC schemes.
Raptor FEC schemes are specified for use with the IETF = FEC Framework
which supports transport of repair data over both UDP = and RTP.  This
document specifies the payload format which is = required for the use
of RTP to carry Raptor repair flows.

A = URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-rapto= r-04.txt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of = the
Internet-Draft.
<M= ail Attachment>
_______________________________________________
Fecf= rame mailing list
Fecframe@ietf.org
https://www.iet= f.org/mailman/listinfo/fecframe

stockhammer@nomor.de || = phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com<= /div>
Nomor Research GmbH  -  Sitz = der Gesellschaft: M=FCnchen - Registergericht: M=FCnchen, HRB 165856 =96 = Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas = Stockhammer, Dr. Ingo Viering.


=
_______________________________________________
Fecfram= e mailing list
Fecframe@ietf.org
https://www.iet= f.org/mailman/listinfo/fecframe



-- 
Colin Perkins



= --Apple-Mail-92--611376291-- From luby@qualcomm.com Wed Dec 1 10:55:55 2010 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 32AA63A6C64 for ; Wed, 1 Dec 2010 10:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLfMM3AsQiMJ for ; Wed, 1 Dec 2010 10:55:53 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 5092A3A6C60 for ; Wed, 1 Dec 2010 10:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1291229827; x=1322765827; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Gr eg=20Shepherd=20,=20"Ali=20C.=20Begen =20(abegen)"=0D=0A=09|CC:=20"fecframe@i etf.org"=20|Date:=20Wed,=201=20Dec=202 010=2010:57:03=20-0800|Subject:=20Re:=20[Fecframe]=20Prop osed=20changes=20to=20the=20framework=20draft=20-=20part =202=0D=0A=20(security)|Thread-Topic:=20[Fecframe]=20Prop osed=20changes=20to=20the=20framework=20draft=20-=20part =202=0D=0A=20(security)|Thread-Index:=20AcuRgEDAPGhr7mjtS YScar5uilqbUwACUm7a|Message-ID:=20|In-Reply-To:=20|Accept-Language:=20en-U S|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|user-agent:=20Microsoft-Entourage/ 13.7.0.100913|acceptlanguage:=20en-US|Content-Type:=20tex t/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=5r6KRbtzKSo9hPqkH990spo0Vg1RUb57OeUONP9lR00=; b=I+fLANgZg7k+p/QLH3cfC4jLz/rf86CnwtdgCcvaYOKAh/Vkc4fln1Z5 dQusP5WM6PdgIkzGLgq4QCMQ4+uw0pOqCistnP9UW+g2vc/wQRYWa+ogH GJ23XWhBWDljh0gTMRf+PTZ3bWODmKGUf4TGXZj2WMtgZqpJ1Q2J4wIiy 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6184"; a="64864747" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 01 Dec 2010 10:57:07 -0800 X-IronPort-AV: E=Sophos;i="4.59,283,1288594800"; d="scan'208";a="14322490" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 01 Dec 2010 10:57:07 -0800 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 1 Dec 2010 10:57:06 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Wed, 1 Dec 2010 10:57:06 -0800 From: "Luby, Michael" To: Greg Shepherd , "Ali C. Begen (abegen)" Date: Wed, 1 Dec 2010 10:57:03 -0800 Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2 (security) Thread-Index: AcuRgEDAPGhr7mjtSYScar5uilqbUwACUm7a Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 18:55:55 -0000 I skimmed the new security section and it looks ok to me. I noticed that there are some recommendations to use some of the security measures based o= n some of the work in the RMT wg, and on TESLA, etc. One thing that is quite different in streaming than in object delivery (focus of RMT) is that the startup delay at the client (and the end-to-end-delay) is a crucial concern for streaming, whereas it is not so much for object delivery. I haven't checked and presumably there aren't issues, but perhaps it should be discussed in the security section (and checked against some of the proposed solution) that, if possible, any security added should impact the potential startup delay (and the end-to-end delay) of the client as little as possible? Startup delay is the time from when a user decides to watch a stream till it shows up on the screen. On 12/1/10 9:50 AM, "Greg Shepherd" wrote: > Thanks Vincent and Ali! >=20 > So far we've had no feedback on the list for these changes. Please > read and respond ASAP - even if you approve please send your approval > to the list. We are so close to finishing up this WG.. let's not > stumble now. >=20 > Thanks, > Greg >=20 > On Wed, Dec 1, 2010 at 9:29 AM, Ali C. Begen (abegen) > wrote: >> This is the 2nd part for the changes we need to make in the framework dr= aft. >> This part is related to the security issues. Please refer to the tracker= to >> see the comments from the IESG. >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ >>=20 >> I would like to thank Vincent for providing this brand new security sect= ion. >> I just added a few minor points into the text. >>=20 >> If there are any objections, please speak up. If you are OK with these >> changes, please also speak up so that we can show WG consensus. >>=20 >> Thanks, >> -acbegen >>=20 >>=20 >>=20 >>=20 >> 9. Security Considerations >>=20 >> 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. >>=20 >> 9.1. Problem Statement >>=20 >> A content delivery system is potentially subject to many attacks. >> Some of them target the network (e.g., to compromise the routing >> infrastructure by compromising the congestion control component), >> others can target the Content Delivery Protocol (CDP) (e.g., to >> compromise its normal behavior), and finally some attacks target the >> content itself. >>=20 >> More specifically, these attacks can have several goals: >>=20 >> o They can try to give access to a confidential content (e.g., in >> case of a non-free content). >>=20 >> o They can try to corrupt the source and/or repair flows (e.g., to >> prevent a receiver from using them). >>=20 >> o They can try to compromise the receiver's behavior (e.g., by >> making the decoding of an object computationally expensive). >>=20 >> o They can try to compromise the network's behavior (e.g., by >> causing congestion within the network). >>=20 >> These attacks can be launched either against the source and/or repair >> flows (e.g., by sending forged 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 a session description). >>=20 >> 9.2. Attacks Against the Data Flows >>=20 >> 9.2.1. Access to Confidential Content >>=20 >> 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. >>=20 >> Note that when encryption is applied, this encryption MUST either be >> applied before the FEC protection, or, if done after the FEC >> protection, then this encryption MUST be applied on both the FEC >> source packets and repair packets. Otherwise, if encryption were to >> be performed only on the FEC source packets after FEC encoding, then >> a non-authorized receiver could be able to recover the source data >> after decoding the repair packets provided that a sufficient number >> of such packets were available. >>=20 >> 9.2.2. Content Corruption >>=20 >> Protection against corruptions (e.g., after sending 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: >>=20 >> 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. Other >> building blocks can be used within SRTP to provide content >> integrity/authentication services. >>=20 >> 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. >>=20 >> It is up to the developer and the person in charge of deployment, who >> knows 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. >>=20 >> 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. >>=20 >> 9.3. Attacks Against the FEC Parameters >>=20 >> 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. >>=20 >> It is therefore RECOMMENDED that security measures are taken to >> guarantee the FEC Framework Configuration Information integrity. >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 9.4. When Several Source Flows are to be Protected Together >>=20 >> 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. >>=20 >> 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. >>=20 >> 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 IPsec/ESP. >>=20 >> 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. >>=20 >> 9.5. Baseline Secure FEC Framework Operation >>=20 >> This section describes a baseline mode of secure FEC Framework >> operation based on the application of the IPsec security protocol. >> This approach is documented here to provide a reference of an >> interoperable secure mode of operation. However, other approaches, >> including other forms of IPsec application, MAY be used or specified >> in the future. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >>=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From luby@qualcomm.com Wed Dec 1 11:06:16 2010 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 05A183A6C20 for ; Wed, 1 Dec 2010 11:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 fvF8vY4GFAxX for ; Wed, 1 Dec 2010 11:06:12 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9E6FD3A6B46 for ; Wed, 1 Dec 2010 11:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1291230446; x=1322766446; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"L uby,=20Michael"=20,=20Greg=20Shepherd =20,=0D=0A=09"Ali=20C.=20Begen=20(abege n)"=20|CC:=20"fecframe@ietf.org"=20|Date:=20Wed,=201=20Dec=202010=2011:07:05 =20-0800|Subject:=20Re:=20[Fecframe]=20Proposed=20changes =20to=20the=20framework=20draft=20-=20part=202=0D=0A=20(s ecurity)|Thread-Topic:=20[Fecframe]=20Proposed=20changes =20to=20the=20framework=20draft=20-=20part=202=0D=0A=20(s ecurity)|Thread-Index:=20AcuRgEDAPGhr7mjtSYScar5uilqbUwAC Um7aAABZtfY=3D|Message-ID:=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.7.0.100913|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ansMS82lzn1mHDivxvAw4/IVrSlswlI/ha2RtPLCPC8=; b=HnuvT+pLUfTaOaZP200vrf/hMWfkN8A+QV3UHIgF8g/FAYjIxGH8pRga 4EQw6HmM+IIslQXew4wziFSTIcPwG3yZ9z+LkSDsUiOPxl3Cbs1zeDbdF h0y9GsDlNvn0FMHEVsozbhL/uwdyZFOefpaN8ZWlGqM04k904eg4EtOu9 Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6184"; a="65059610" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 01 Dec 2010 11:07:11 -0800 X-IronPort-AV: E=Sophos;i="4.59,283,1288594800"; d="scan'208";a="14327426" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 01 Dec 2010 11:07:11 -0800 Received: from nasanexhc08.na.qualcomm.com (172.30.39.7) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 1 Dec 2010 11:07:11 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhc08.na.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 1 Dec 2010 11:07:11 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Wed, 1 Dec 2010 11:07:03 -0800 From: "Luby, Michael" To: "Luby, Michael" , Greg Shepherd , "Ali C. Begen (abegen)" Date: Wed, 1 Dec 2010 11:07:05 -0800 Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2 (security) Thread-Index: AcuRgEDAPGhr7mjtSYScar5uilqbUwACUm7aAABZtfY= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 19:06:16 -0000 Actually, maybe the way to think about this is that if the security added t= o the solution degrades the user experience (in terms of either the startup delay or the end-to-end delay) then it can be viewed as an attack on the service. One would want a security that doesn't compromise these aspects even when there is no attack. But, there could also be attacks on the security, where the attack attempts to delay the client security verification, and thus although the security is still there, the attack slows down the startup delay or the end-to-end delay. Perhaps both of thes= e are worth considering/commenting on (both =3D (1) providing security that doesn't negatively impact startup/end-to-end delay; (2) discussing attacks on security that could negatively impact user experience, such as startup/end-to-end delay). On 12/1/10 10:57 AM, "Luby, Michael" wrote: > I skimmed the new security section and it looks ok to me. I noticed that > there are some recommendations to use some of the security measures based= on > some of the work in the RMT wg, and on TESLA, etc. One thing that is quit= e > different in streaming than in object delivery (focus of RMT) is that the > startup delay at the client (and the end-to-end-delay) is a crucial conce= rn > for streaming, whereas it is not so much for object delivery. I haven't > checked and presumably there aren't issues, but perhaps it should be > discussed in the security section (and checked against some of the propos= ed > solution) that, if possible, any security added should impact the potenti= al > startup delay (and the end-to-end delay) of the client as little as > possible? Startup delay is the time from when a user decides to watch a > stream till it shows up on the screen. >=20 >=20 > On 12/1/10 9:50 AM, "Greg Shepherd" wrote: >=20 >> Thanks Vincent and Ali! >>=20 >> So far we've had no feedback on the list for these changes. Please >> read and respond ASAP - even if you approve please send your approval >> to the list. We are so close to finishing up this WG.. let's not >> stumble now. >>=20 >> Thanks, >> Greg >>=20 >> On Wed, Dec 1, 2010 at 9:29 AM, Ali C. Begen (abegen) >> wrote: >>> This is the 2nd part for the changes we need to make in the framework d= raft. >>> This part is related to the security issues. Please refer to the tracke= r to >>> see the comments from the IESG. >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ >>>=20 >>> I would like to thank Vincent for providing this brand new security sec= tion. >>> I just added a few minor points into the text. >>>=20 >>> If there are any objections, please speak up. If you are OK with these >>> changes, please also speak up so that we can show WG consensus. >>>=20 >>> Thanks, >>> -acbegen >>>=20 >>>=20 >>>=20 >>>=20 >>> 9. Security Considerations >>>=20 >>> 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. >>>=20 >>> 9.1. Problem Statement >>>=20 >>> A content delivery system is potentially subject to many attacks. >>> Some of them target the network (e.g., to compromise the routing >>> infrastructure by compromising the congestion control component), >>> others can target the Content Delivery Protocol (CDP) (e.g., to >>> compromise its normal behavior), and finally some attacks target the >>> content itself. >>>=20 >>> More specifically, these attacks can have several goals: >>>=20 >>> o They can try to give access to a confidential content (e.g., in >>> case of a non-free content). >>>=20 >>> o They can try to corrupt the source and/or repair flows (e.g., to >>> prevent a receiver from using them). >>>=20 >>> o They can try to compromise the receiver's behavior (e.g., by >>> making the decoding of an object computationally expensive). >>>=20 >>> o They can try to compromise the network's behavior (e.g., by >>> causing congestion within the network). >>>=20 >>> These attacks can be launched either against the source and/or repair >>> flows (e.g., by sending forged 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 a session description). >>>=20 >>> 9.2. Attacks Against the Data Flows >>>=20 >>> 9.2.1. Access to Confidential Content >>>=20 >>> 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. >>>=20 >>> Note that when encryption is applied, this encryption MUST either be >>> applied before the FEC protection, or, if done after the FEC >>> protection, then this encryption MUST be applied on both the FEC >>> source packets and repair packets. Otherwise, if encryption were to >>> be performed only on the FEC source packets after FEC encoding, then >>> a non-authorized receiver could be able to recover the source data >>> after decoding the repair packets provided that a sufficient number >>> of such packets were available. >>>=20 >>> 9.2.2. Content Corruption >>>=20 >>> Protection against corruptions (e.g., after sending 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: >>>=20 >>> 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. Other >>> building blocks can be used within SRTP to provide content >>> integrity/authentication services. >>>=20 >>> 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. >>>=20 >>> It is up to the developer and the person in charge of deployment, who >>> knows 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. >>>=20 >>> 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. >>>=20 >>> 9.3. Attacks Against the FEC Parameters >>>=20 >>> 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. >>>=20 >>> It is therefore RECOMMENDED that security measures are taken to >>> guarantee the FEC Framework Configuration Information integrity. >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 9.4. When Several Source Flows are to be Protected Together >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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 IPsec/ESP. >>>=20 >>> 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. >>>=20 >>> 9.5. Baseline Secure FEC Framework Operation >>>=20 >>> This section describes a baseline mode of secure FEC Framework >>> operation based on the application of the IPsec security protocol. >>> This approach is documented here to provide a reference of an >>> interoperable secure mode of operation. However, other approaches, >>> including other forms of IPsec application, MAY be used or specified >>> in the future. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>>=20 >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Wed Dec 1 12:05:17 2010 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 7CB823A6D11 for ; Wed, 1 Dec 2010 12:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.386 X-Spam-Level: X-Spam-Status: No, score=-10.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 1Ew75F7+E7V4 for ; Wed, 1 Dec 2010 12:05:15 -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 C23DB3A6D01 for ; Wed, 1 Dec 2010 12:05:15 -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: AvsEAHc59kyrR7Hu/2dsb2JhbACjHnGoeolGkV6CcRMIgjsEhF6JHoJs X-IronPort-AV: E=Sophos;i="4.59,285,1288569600"; d="scan'208";a="295874700" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 01 Dec 2010 20:06:29 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oB1K6TDG021525; Wed, 1 Dec 2010 20:06:29 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); Wed, 1 Dec 2010 12:06: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: Wed, 1 Dec 2010 12:06:23 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DC939D9@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2 (security) Thread-Index: AcuRgEDAPGhr7mjtSYScar5uilqbUwACUm7aAABZtfYAARum4A== References: From: "Ali C. Begen (abegen)" To: "Luby, Michael" , "Greg Shepherd" X-OriginalArrivalTime: 01 Dec 2010 20:06:29.0570 (UTC) FILETIME=[3DF24A20:01CB9193] 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 20:05:17 -0000 Hi Mike, > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Wednesday, December 01, 2010 2:07 PM > To: Luby, Michael; Greg Shepherd; Ali C. Begen (abegen) > Cc: fecframe@ietf.org > Subject: Re: [Fecframe] Proposed changes to the framework draft - part = 2 (security) >=20 > Actually, maybe the way to think about this is that if the security = added to > the solution degrades the user experience (in terms of either the = startup > delay or the end-to-end delay) then it can be viewed as an attack on = the Agree but security is something decided upon before the content is = actually delivered. So, when deciding on the method, they will take into = account whether delay-wise there is any problems. > service. One would want a security that doesn't compromise these = aspects > even when there is no attack. But, there could also be attacks on the > security, where the attack attempts to delay the client security > verification, and thus although the security is still there, the = attack > slows down the startup delay or the end-to-end delay. Perhaps both of = these > are worth considering/commenting on (both =3D (1) providing security = that > doesn't negatively impact startup/end-to-end delay; (2) discussing = attacks > on security that could negatively impact user experience, such as > startup/end-to-end delay). Ok, should we just mention these? Are we recommending anything at all? -acbegen >=20 >=20 > On 12/1/10 10:57 AM, "Luby, Michael" wrote: >=20 > > I skimmed the new security section and it looks ok to me. I noticed = that > > there are some recommendations to use some of the security measures = based on > > some of the work in the RMT wg, and on TESLA, etc. One thing that is = quite > > different in streaming than in object delivery (focus of RMT) is = that the > > startup delay at the client (and the end-to-end-delay) is a crucial = concern > > for streaming, whereas it is not so much for object delivery. I = haven't > > checked and presumably there aren't issues, but perhaps it should be > > discussed in the security section (and checked against some of the = proposed > > solution) that, if possible, any security added should impact the = potential > > startup delay (and the end-to-end delay) of the client as little as > > possible? Startup delay is the time from when a user decides to = watch a > > stream till it shows up on the screen. > > > > > > On 12/1/10 9:50 AM, "Greg Shepherd" wrote: > > > >> Thanks Vincent and Ali! > >> > >> So far we've had no feedback on the list for these changes. Please > >> read and respond ASAP - even if you approve please send your = approval > >> to the list. We are so close to finishing up this WG.. let's not > >> stumble now. > >> > >> Thanks, > >> Greg > >> > >> On Wed, Dec 1, 2010 at 9:29 AM, Ali C. Begen (abegen) = > >> wrote: > >>> This is the 2nd part for the changes we need to make in the = framework draft. > >>> This part is related to the security issues. Please refer to the = tracker to > >>> see the comments from the IESG. > >>> > >>> = https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ > >>> > >>> I would like to thank Vincent for providing this brand new = security section. > >>> I just added a few minor points into the text. > >>> > >>> If there are any objections, please speak up. If you are OK with = these > >>> changes, please also speak up so that we can show WG consensus. > >>> > >>> Thanks, > >>> -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. > >>> Some of them target the network (e.g., to compromise the routing > >>> infrastructure by compromising the congestion control = component), > >>> others can target the Content Delivery Protocol (CDP) (e.g., to > >>> compromise its normal behavior), and finally some attacks target = the > >>> content itself. > >>> > >>> More specifically, these 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 and/or repair flows (e.g., = to > >>> prevent a receiver from using them). > >>> > >>> o They can try to compromise the receiver's behavior (e.g., by > >>> making the decoding of an object computationally expensive). > >>> > >>> o They can try to compromise the network's behavior (e.g., by > >>> causing congestion within the network). > >>> > >>> These attacks can be launched either against the source and/or = repair > >>> flows (e.g., by sending forged 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 a session description). > >>> > >>> 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 before the FEC protection, or, if done after the FEC > >>> protection, then this encryption MUST be applied on both the FEC > >>> source packets and repair packets. Otherwise, if encryption = were to > >>> be performed only on the FEC source packets after FEC encoding, = then > >>> a non-authorized receiver could be able to recover the source = data > >>> after decoding the repair packets provided that a sufficient = number > >>> of such packets were available. > >>> > >>> 9.2.2. Content Corruption > >>> > >>> Protection against corruptions (e.g., after sending 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. = 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 > >>> knows 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. > >>> 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 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. > >>> This approach is documented here to provide a reference of an > >>> interoperable secure mode of operation. However, other = approaches, > >>> including other forms of IPsec application, MAY be used or = specified > >>> in the future. > >>> > >>> 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 > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe From gjshep@gmail.com Mon Dec 6 13:04:21 2010 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 2E92F3A68C1 for ; Mon, 6 Dec 2010 13:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.013 X-Spam-Level: X-Spam-Status: No, score=-103.013 tagged_above=-999 required=5 tests=[AWL=0.586, 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 v2H6-Uggo2Nz for ; Mon, 6 Dec 2010 13:04:20 -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 C47FD3A68BA for ; Mon, 6 Dec 2010 13:04:19 -0800 (PST) Received: by fxm9 with SMTP id 9so10521925fxm.31 for ; Mon, 06 Dec 2010 13:05:43 -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 :content-transfer-encoding; bh=ZJSO3OA1ZY0Y/k60a+V+5BhSNyGIfjsE75oytz+atj0=; b=r3Xq2BONq37jUmTTZY3nLSuCvAE9Z59jikGUVxqEDHKVxGv+2dqb1OVBur1RyDygS2 CTBqPqFHQETDCWPDEUTyRuyzRnbSh/S0uO2YWlXkVlf+vj2ae4cWq4WGcoWF39Ew7QoK NPkqyyS/BcVwRxptt3+rmR+8qHhJ+V5/Wy1Dk= 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:content-transfer-encoding; b=edeVku76xnWHW1I5U6KodOo+9d8+Q1yZLNkkTXgj3DGHSi3fX46WPl2orJWm034Fd7 d/9P9e/MaQCVtBXPdRHBoBwgMoZ+H6AEjcdN6EjT4Oo3ZMcQ1by17XqENoPFDN1xl8lP nf33WvmFDleFhb4fKIljWKJnZT6JiU7SlkKag= MIME-Version: 1.0 Received: by 10.223.79.4 with SMTP id n4mr6126108fak.69.1291669543371; Mon, 06 Dec 2010 13:05:43 -0800 (PST) Received: by 10.204.80.6 with HTTP; Mon, 6 Dec 2010 13:05:43 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Dec 2010 13:05:43 -0800 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Fecframe] WG Minutes 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, 06 Dec 2010 21:04:21 -0000 I'd like to post these ASAP. Please review and respond with corrections of approvals. Thanks, Greg On Fri, Nov 26, 2010 at 10:11 AM, Greg Shepherd wrote: > First, a huge thank you to Ali for stepping here to chair in my > absence. Here are the minutes from the meeting. Please let me know if > you have any corrections/clarifications or if you approve of the > minutes as is. I'd like to post these asap. > > Thanks, > Greg > > ----snip--- > The interim chair goes over the agenda and draft status. Thomas S. is > the new editor for the Raptor drafts. Questions about Raptor drafts > (should they be informational as opposed to standards track?). Magnus > says there is benefit in publishing them in standards track (as RMT > did). > > The AD wants to confirm that the next two drafts (that Vincent is to > present) are in the charter or not. They are not in the charter > specifically but they are within the scope of FEC schemes. > > Vincent starts with the first slide deck. Goes over the issues > (related to IPR) that were addressed in the latest version. Says the > draft is pretty mature to be adopted. The chair will ask the list. > > The second slide deck. This is the RTP payload format for the RS > codes. It will be finished by the next meeting, and accompanies the RS > draft. AVT will have to review this and the chair will ask the WG to > adopt it or not. > > The AD - on the mic - says that if these FEC schemes will not be > implemented by multiple vendors, they could actually go thru the > AD-sponsored path. > > The third deck. Motivation for this work is the low-decoding > complexity for high-bitrate apps. It has different use cases compared > to other existing FEC schemes. Discussing a very recent paper that > explains the code and its performance. The AD asks whether there is > any IPR on this. Vincent says "today, there is not on this draft but > there are some IPR disclosures on a related RFC," which is 5170. > > Ali starts discussing the IESG comments for the framework draft (Ali > is the new editor). > > * Concerning Management and Operations: > > AD: IESG want to make sure that you properly thought about these > issues, so try to put some simple text and guidelines. What should an > operator like to know? What should a FECFRAME implementation provide? > > * Concerning Congestion Control: > > AD: If you don't know the history of the WG, it's hard to figure out > why there is this rule of no more than twice the bandwidth. > Colin: There is a frequent misunderstanding about congestion control and = FEC. > > * Concerning Security: > > Vincent: I'm the one who performed the SecDir review for this > document. I think it's extremely important to have a detailed > "security > considerations" section since this is a framework document that is > referenced by all =A0other FECFRAME documents. Among the things I think > are required is a "mandatory to implement but not necessarily to use" > security mechanism. It seems that requiring IPsec/ESP be mandatory is > fine. > AD: I agree. > > David (AD hat off): if we anticipate that FECFRAME will be used for > something else than real-time flows, for instance for MIKEY or other > applications, then it's better to mention it. MIKEY was just an > example. > Magnus: You can use it as well for DNS. It needs to be better clarified. > David: You can have a discussion on how to apply it to a specific > use-case in the Operations and Management section. > > Concerning some fields starting from 0: > Colin: Clarify the assumptions about wrapping. There's also an issue > about possible rekeying before the end of a block. You can have a look > at the RTP security considerations. > > Discussion started on how to handle future FEC Schemes if the FECFRAME > is closed. Proposal is to have schemes with RTP framing of repair > packets be managed by the AVT WG, and other schemes by the TSV WG. > ---snip--- > From vincent.roca@inrialpes.fr Wed Dec 8 12:37:34 2010 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 4A4713A68B7 for ; Wed, 8 Dec 2010 12:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.257 X-Spam-Level: X-Spam-Status: No, score=-9.257 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_FR=0.35, 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 u5ZPpdLpbCL6 for ; Wed, 8 Dec 2010 12:37:25 -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 5B4F83A6860 for ; Wed, 8 Dec 2010 12:37:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,317,1288566000"; d="scan'208";a="82287982" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-de-roca.local) ([82.236.155.50]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 08 Dec 2010 21:38:48 +0100 Message-ID: <4CFF4088.9050108@inrialpes.fr> Date: Wed, 08 Dec 2010 09:23:36 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAAE4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DBBAAE4@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: Re: [Fecframe] Proposed changes to the framework draft - part 1 (ops/managament) 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, 08 Dec 2010 20:37:34 -0000 Hello Ali, That's a good summary of the way FECFRAME can be used. I fully support it. Vincent Le 26/11/10 16:34, Ali C. Begen (abegen) a =E9crit : > Hi everyone, > > As you know the framework draft is in the IESG review process. As we di= scussed in the last meeting, for two of these issues (the others were alr= eady addressed) we would like to consult with the WG. This email is about= the DISCUSS relating to the ops/management issues. There will be a separ= ate thread for the security issues. > > Please see the comments from the IESG and then the proposed changes in = the framework draft below. We need your input so that we can provide a re= vision soon. > > Comment from Adrian F.: > > It would be helpful, I think, if a framework/architecture like this > included a discussion of how the systems and networks described are > operated and managed. You might look at RFC 5706 for guidance. > > Discuss from Dan R.: > > I would like to raise the issue raised by Adrian to a DISCUSS - such a = document > is expected to include information about operational impact and managea= bility of > devices and networks that will comply to the framework, also indication= about > what kind of operations and manageability information future specificat= ions of > protocols that comply to the framework would include. This document inc= ludes no > such information. I would like to discuss this in the call, maybe these= issues > are covered in other fecframe documents, or future work planned by the = WG. > > -- > > Some background: > > Essentially, the IESG wants to make sure that the WG has discussed thes= e issues adequately and wants to see a text for some guidelines. As a mat= ter of fact, in the early days, the design team has discussed these issue= s in detail (both in the IETF meetings as well as offsite meetings). The = general consensus was that the FEC schemes differed widely about their ca= pabilities, application and deployment scenarios such that coming up with= a single tool that worked for all of them was almost impossible. Certain= apps are one-way meaning that they don't have any kind of feedback back = from receivers (e.g., broadcast), while some of them may collect detailed= feedback (maybe it is a one-to-one app) or occasional transport-layer fe= edback (such as multicast). These applications have different management = aspects. If any, they also have different requirements or features for co= llecting feedback, processing it and acting on it. Their data structures = also vary for carrying the feedback. > > On the operations side, it is not advisable for the framework draft to = explicitly list what the applications (sender or receiver or a middle-box= ) could do upon observing something in particular or receiving a specific= feedback. At best, the framework can make use of existing tools as much = as possible and to the extent possible. For example, for repair flows usi= ng RTP transport, benefiting from all the features of RTCP mechanisms is = strongly encouraged since RTCP has already solved many of these issues in= an agnostic way of the data carried with RTP. > > Overall, the framework as it stands now makes use of existing specifica= tions as much as possible and does not dictate the use of any particular = technology for transporting FEC data, managing the endpoints, signaling t= he configuration information, or encoding the configuration information. = We had this flexibility since the beginning to cover all the wide range o= f all possible scenarios where this framework (and the resulting CDPs and= schemes) could be used. > > Proposed changes to the framework: > > I think the IESG is right for expecting to see some text about this. My= proposal is to have a summary at the end of the document mostly mentioni= ng the things I provided above (of course after incorporating any feedbac= k from you). > > If anybody has another proposal or objects to this, please speak up. If= you are OK with this, your email would also help to show the WG consensu= s to the IESG. > > Thanks, > -acbegen > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From vincent.roca@inrialpes.fr Wed Dec 8 12:37:35 2010 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 EC2263A68B7 for ; Wed, 8 Dec 2010 12:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.218 X-Spam-Level: X-Spam-Status: No, score=-9.218 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_FR=0.35, 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 KkR5dXypv4dd for ; Wed, 8 Dec 2010 12:37:28 -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 4B3CA3A68AB for ; Wed, 8 Dec 2010 12:37:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,317,1288566000"; d="scan'208";a="82287990" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-de-roca.local) ([82.236.155.50]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 08 Dec 2010 21:38:50 +0100 Message-ID: <4CFF499F.9030805@inrialpes.fr> Date: Wed, 08 Dec 2010 10:02:23 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: fecframe@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Fecframe] WG Minutes 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, 08 Dec 2010 20:37:35 -0000 I'm okay with these minutes. Vincent Le 06/12/10 22:05, Greg Shepherd a écrit : > I'd like to post these ASAP. Please review and respond with > corrections of approvals. > > Thanks, > Greg > > On Fri, Nov 26, 2010 at 10:11 AM, Greg Shepherd wrote: >> First, a huge thank you to Ali for stepping here to chair in my >> absence. Here are the minutes from the meeting. Please let me know if >> you have any corrections/clarifications or if you approve of the >> minutes as is. I'd like to post these asap. >> >> Thanks, >> Greg >> >> ----snip--- >> The interim chair goes over the agenda and draft status. Thomas S. is >> the new editor for the Raptor drafts. Questions about Raptor drafts >> (should they be informational as opposed to standards track?). Magnus >> says there is benefit in publishing them in standards track (as RMT >> did). >> >> The AD wants to confirm that the next two drafts (that Vincent is to >> present) are in the charter or not. They are not in the charter >> specifically but they are within the scope of FEC schemes. >> >> Vincent starts with the first slide deck. Goes over the issues >> (related to IPR) that were addressed in the latest version. Says the >> draft is pretty mature to be adopted. The chair will ask the list. >> >> The second slide deck. This is the RTP payload format for the RS >> codes. It will be finished by the next meeting, and accompanies the RS >> draft. AVT will have to review this and the chair will ask the WG to >> adopt it or not. >> >> The AD - on the mic - says that if these FEC schemes will not be >> implemented by multiple vendors, they could actually go thru the >> AD-sponsored path. >> >> The third deck. Motivation for this work is the low-decoding >> complexity for high-bitrate apps. It has different use cases compared >> to other existing FEC schemes. Discussing a very recent paper that >> explains the code and its performance. The AD asks whether there is >> any IPR on this. Vincent says "today, there is not on this draft but >> there are some IPR disclosures on a related RFC," which is 5170. >> >> Ali starts discussing the IESG comments for the framework draft (Ali >> is the new editor). >> >> * Concerning Management and Operations: >> >> AD: IESG want to make sure that you properly thought about these >> issues, so try to put some simple text and guidelines. What should an >> operator like to know? What should a FECFRAME implementation provide? >> >> * Concerning Congestion Control: >> >> AD: If you don't know the history of the WG, it's hard to figure out >> why there is this rule of no more than twice the bandwidth. >> Colin: There is a frequent misunderstanding about congestion control and FEC. >> >> * Concerning Security: >> >> Vincent: I'm the one who performed the SecDir review for this >> document. I think it's extremely important to have a detailed >> "security >> considerations" section since this is a framework document that is >> referenced by all other FECFRAME documents. Among the things I think >> are required is a "mandatory to implement but not necessarily to use" >> security mechanism. It seems that requiring IPsec/ESP be mandatory is >> fine. >> AD: I agree. >> >> David (AD hat off): if we anticipate that FECFRAME will be used for >> something else than real-time flows, for instance for MIKEY or other >> applications, then it's better to mention it. MIKEY was just an >> example. >> Magnus: You can use it as well for DNS. It needs to be better clarified. >> David: You can have a discussion on how to apply it to a specific >> use-case in the Operations and Management section. >> >> Concerning some fields starting from 0: >> Colin: Clarify the assumptions about wrapping. There's also an issue >> about possible rekeying before the end of a block. You can have a look >> at the RTP security considerations. >> >> Discussion started on how to handle future FEC Schemes if the FECFRAME >> is closed. Proposal is to have schemes with RTP framing of repair >> packets be managed by the AVT WG, and other schemes by the TSV WG. >> ---snip--- >> > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From vincent.roca@inrialpes.fr Wed Dec 8 12:37:36 2010 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 8F77B3A6989 for ; Wed, 8 Dec 2010 12:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.199 X-Spam-Level: X-Spam-Status: No, score=-9.199 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_FR=0.35, 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 4DKEbQ05MZOG for ; Wed, 8 Dec 2010 12:37:34 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 043643A687D for ; Wed, 8 Dec 2010 12:37:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,317,1288566000"; d="scan'208";a="70167121" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-de-roca.local) ([82.236.155.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 08 Dec 2010 21:38:55 +0100 Message-ID: <4CFF5598.4000300@inrialpes.fr> Date: Wed, 08 Dec 2010 10:53:28 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D540DC939D9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DC939D9@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2010 20:37:36 -0000 Hello Mike, Thanks a lot for your feedback. My answers: - the new security section mentions the possibility of using TESLA within SRTP. It is therefore different from my RFC that describes how to use TESLA within RMT protocols, even if the basic idea is identical. Additionally, it's merely an example, not the recommended solution: the "baseline security solution" relies on IPsec/ESP. - Concerning the delay introduced by TESLA/SRTP, it is currently said: "Yet, checking a packet requires a small delay (a second or more) after its reception with TESLA." I suggest to add: "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 may degrade the user experience. In other situations this will not be an issue." In any case, as reminded by Ali, FECFRAME is agnostic WRT the upper application and will be used with non real time flows as well. So it's not necessarily an issue. - No matter the provided security mechanisms, attacks that negatively impact the user experience (e.g. startup / e2e delay) may exist. Imagine an attacker capable of delaying all the traffic sent by the source (e.g. by taking control of a forwarding device, by modifying the routing path, etc.). The fundamental question here is what is the threat model and what do we want to address? However I don't think this document has to provide an exhaustive analysis and we need to acknowledge that a powerfull attacker will cause a lot of dammage... but the receivers will in any case identify attacks and mitigate them when feasible, dropping corrupted contents, etc. That's the goal. Hope this makes sense. Cheers, Vincent On 01/12/10 21:06, Ali C. Begen (abegen) wrote: > Hi Mike, > >> -----Original Message----- >> From: Luby, Michael [mailto:luby@qualcomm.com] >> Sent: Wednesday, December 01, 2010 2:07 PM >> To: Luby, Michael; Greg Shepherd; Ali C. Begen (abegen) >> Cc: fecframe@ietf.org >> Subject: Re: [Fecframe] Proposed changes to the framework draft - part 2 (security) >> >> Actually, maybe the way to think about this is that if the security added to >> the solution degrades the user experience (in terms of either the startup >> delay or the end-to-end delay) then it can be viewed as an attack on the > Agree but security is something decided upon before the content is actually delivered. So, when deciding on the method, they will take into account whether delay-wise there is any problems. > >> service. One would want a security that doesn't compromise these aspects >> even when there is no attack. But, there could also be attacks on the >> security, where the attack attempts to delay the client security >> verification, and thus although the security is still there, the attack >> slows down the startup delay or the end-to-end delay. Perhaps both of these >> are worth considering/commenting on (both = (1) providing security that >> doesn't negatively impact startup/end-to-end delay; (2) discussing attacks >> on security that could negatively impact user experience, such as >> startup/end-to-end delay). > Ok, should we just mention these? Are we recommending anything at all? > > -acbegen > >> >> On 12/1/10 10:57 AM, "Luby, Michael" wrote: >> >>> I skimmed the new security section and it looks ok to me. I noticed that >>> there are some recommendations to use some of the security measures based on >>> some of the work in the RMT wg, and on TESLA, etc. One thing that is quite >>> different in streaming than in object delivery (focus of RMT) is that the >>> startup delay at the client (and the end-to-end-delay) is a crucial concern >>> for streaming, whereas it is not so much for object delivery. I haven't >>> checked and presumably there aren't issues, but perhaps it should be >>> discussed in the security section (and checked against some of the proposed >>> solution) that, if possible, any security added should impact the potential >>> startup delay (and the end-to-end delay) of the client as little as >>> possible? Startup delay is the time from when a user decides to watch a >>> stream till it shows up on the screen. >>> >>> >>> On 12/1/10 9:50 AM, "Greg Shepherd" wrote: >>> >>>> Thanks Vincent and Ali! >>>> >>>> So far we've had no feedback on the list for these changes. Please >>>> read and respond ASAP - even if you approve please send your approval >>>> to the list. We are so close to finishing up this WG.. let's not >>>> stumble now. >>>> >>>> Thanks, >>>> Greg >>>> >>>> On Wed, Dec 1, 2010 at 9:29 AM, Ali C. Begen (abegen) >>>> wrote: >>>>> This is the 2nd part for the changes we need to make in the framework draft. >>>>> This part is related to the security issues. Please refer to the tracker to >>>>> see the comments from the IESG. >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ >>>>> >>>>> I would like to thank Vincent for providing this brand new security section. >>>>> I just added a few minor points into the text. >>>>> >>>>> If there are any objections, please speak up. If you are OK with these >>>>> changes, please also speak up so that we can show WG consensus. >>>>> >>>>> Thanks, >>>>> -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. >>>>> Some of them target the network (e.g., to compromise the routing >>>>> infrastructure by compromising the congestion control component), >>>>> others can target the Content Delivery Protocol (CDP) (e.g., to >>>>> compromise its normal behavior), and finally some attacks target the >>>>> content itself. >>>>> >>>>> More specifically, these 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 and/or repair flows (e.g., to >>>>> prevent a receiver from using them). >>>>> >>>>> o They can try to compromise the receiver's behavior (e.g., by >>>>> making the decoding of an object computationally expensive). >>>>> >>>>> o They can try to compromise the network's behavior (e.g., by >>>>> causing congestion within the network). >>>>> >>>>> These attacks can be launched either against the source and/or repair >>>>> flows (e.g., by sending forged 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 a session description). >>>>> >>>>> 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 before the FEC protection, or, if done after the FEC >>>>> protection, then this encryption MUST be applied on both the FEC >>>>> source packets and repair packets. Otherwise, if encryption were to >>>>> be performed only on the FEC source packets after FEC encoding, then >>>>> a non-authorized receiver could be able to recover the source data >>>>> after decoding the repair packets provided that a sufficient number >>>>> of such packets were available. >>>>> >>>>> 9.2.2. Content Corruption >>>>> >>>>> Protection against corruptions (e.g., after sending 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. 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 >>>>> knows 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. >>>>> 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 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. >>>>> This approach is documented here to provide a reference of an >>>>> interoperable secure mode of operation. However, other approaches, >>>>> including other forms of IPsec application, MAY be used or specified >>>>> in the future. >>>>> >>>>> 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 >>> _______________________________________________ >>> 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 Wed Dec 8 14:52:25 2010 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 0B55C3A69AD for ; Wed, 8 Dec 2010 14:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.111 X-Spam-Level: X-Spam-Status: No, score=-103.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 mzZ4EQeR-x58 for ; Wed, 8 Dec 2010 14:52:24 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 899763A69B1 for ; Wed, 8 Dec 2010 14:52:23 -0800 (PST) Received: by bwz8 with SMTP id 8so2052171bwz.38 for ; Wed, 08 Dec 2010 14:53:51 -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=8GpVfxtVPq3Qq27xe6/2kqVs3sNBzz4+UPK16K2LWk0=; b=E+XfmLGLVDd0CkKFvAIKwcezVdt7ajwzU99cOM9ThBDkdxmOq/Xa7E854XKPEOfRE3 pAMa64YYaa4HGxRLWF1ydGqBeMlHeH6TdSEPKMPhV9VRtGfNvVOQqHl0jxmeUZzGs9i2 NDo2YyBjvKhVpoqD5F37PwsPbVJhZg7pmLv4Q= 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=gm2VYQxmEx114yryXh081S2fMBCvxhdI/MDLP43dPWaVj5KU+1VH4m4ErTSYiAV13H vE/O81HitoJHLVT9rS3ivH8fHr2QzBhhF4dW1kZ0slxFTHP8ltA4wS/rTMyigQXvsQFm jHhKwD8nlVqRTRnonaFbYv/VlYBz16KsZYEvU= MIME-Version: 1.0 Received: by 10.204.74.11 with SMTP id s11mr2559419bkj.185.1291848830128; Wed, 08 Dec 2010 14:53:50 -0800 (PST) Received: by 10.204.80.6 with HTTP; Wed, 8 Dec 2010 14:53:50 -0800 (PST) In-Reply-To: <4CFF499F.9030805@inrialpes.fr> References: <4CFF499F.9030805@inrialpes.fr> Date: Wed, 8 Dec 2010 14:53:50 -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] WG Minutes 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, 08 Dec 2010 22:52:25 -0000 Thanks Vincent! They are posted. Greg On Wed, Dec 8, 2010 at 1:02 AM, Vincent Roca wr= ote: > I'm okay with these minutes. > > =A0 Vincent > > Le 06/12/10 22:05, Greg Shepherd a =E9crit : >> >> I'd like to post these ASAP. Please review and respond with >> corrections of approvals. >> >> Thanks, >> Greg >> >> On Fri, Nov 26, 2010 at 10:11 AM, Greg Shepherd =A0wro= te: >>> >>> First, a huge thank you to Ali for stepping here to chair in my >>> absence. Here are the minutes from the meeting. Please let me know if >>> you have any corrections/clarifications or if you approve of the >>> minutes as is. I'd like to post these asap. >>> >>> Thanks, >>> Greg >>> >>> ----snip--- >>> The interim chair goes over the agenda and draft status. Thomas S. is >>> the new editor for the Raptor drafts. Questions about Raptor drafts >>> (should they be informational as opposed to standards track?). Magnus >>> says there is benefit in publishing them in standards track (as RMT >>> did). >>> >>> The AD wants to confirm that the next two drafts (that Vincent is to >>> present) are in the charter or not. They are not in the charter >>> specifically but they are within the scope of FEC schemes. >>> >>> Vincent starts with the first slide deck. Goes over the issues >>> (related to IPR) that were addressed in the latest version. Says the >>> draft is pretty mature to be adopted. The chair will ask the list. >>> >>> The second slide deck. This is the RTP payload format for the RS >>> codes. It will be finished by the next meeting, and accompanies the RS >>> draft. AVT will have to review this and the chair will ask the WG to >>> adopt it or not. >>> >>> The AD - on the mic - says that if these FEC schemes will not be >>> implemented by multiple vendors, they could actually go thru the >>> AD-sponsored path. >>> >>> The third deck. Motivation for this work is the low-decoding >>> complexity for high-bitrate apps. It has different use cases compared >>> to other existing FEC schemes. Discussing a very recent paper that >>> explains the code and its performance. The AD asks whether there is >>> any IPR on this. Vincent says "today, there is not on this draft but >>> there are some IPR disclosures on a related RFC," which is 5170. >>> >>> Ali starts discussing the IESG comments for the framework draft (Ali >>> is the new editor). >>> >>> * Concerning Management and Operations: >>> >>> AD: IESG want to make sure that you properly thought about these >>> issues, so try to put some simple text and guidelines. What should an >>> operator like to know? What should a FECFRAME implementation provide? >>> >>> * Concerning Congestion Control: >>> >>> AD: If you don't know the history of the WG, it's hard to figure out >>> why there is this rule of no more than twice the bandwidth. >>> Colin: There is a frequent misunderstanding about congestion control an= d >>> FEC. >>> >>> * Concerning Security: >>> >>> Vincent: I'm the one who performed the SecDir review for this >>> document. I think it's extremely important to have a detailed >>> "security >>> considerations" section since this is a framework document that is >>> referenced by all =A0other FECFRAME documents. Among the things I think >>> are required is a "mandatory to implement but not necessarily to use" >>> security mechanism. It seems that requiring IPsec/ESP be mandatory is >>> fine. >>> AD: I agree. >>> >>> David (AD hat off): if we anticipate that FECFRAME will be used for >>> something else than real-time flows, for instance for MIKEY or other >>> applications, then it's better to mention it. MIKEY was just an >>> example. >>> Magnus: You can use it as well for DNS. It needs to be better clarified= . >>> David: You can have a discussion on how to apply it to a specific >>> use-case in the Operations and Management section. >>> >>> Concerning some fields starting from 0: >>> Colin: Clarify the assumptions about wrapping. There's also an issue >>> about possible rekeying before the end of a block. You can have a look >>> at the RTP security considerations. >>> >>> Discussion started on how to handle future FEC Schemes if the FECFRAME >>> is closed. Proposal is to have schemes with RTP framing of repair >>> packets be managed by the AVT WG, and other schemes by the TSV WG. >>> ---snip--- >>> >> _______________________________________________ >> 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 luby@qualcomm.com Wed Dec 8 16:19:15 2010 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 867933A68BA for ; Wed, 8 Dec 2010 16:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Y5Z6fPyty4kS for ; Wed, 8 Dec 2010 16:19:13 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 39E573A68D4 for ; Wed, 8 Dec 2010 16:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1291854041; x=1323390041; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Vi ncent=20Roca=20,=20"Ali=20C. =20Begen=20(abegen)"=0D=0A=09|CC:=20Gre g=20Shepherd=20,=20"fecframe@ietf.org" =20,=0D=0A=09"Luby,=20Michael"=20|Date:=20Wed,=208=20Dec=202010=2016:20:21 =20-0800|Subject:=20Re:=20[Fecframe]=20Proposed=20changes =20to=20the=20framework=20draft=20-=20part=202=0D=0A=20(s ecurity)|Thread-Topic:=20[Fecframe]=20Proposed=20changes =20to=20the=20framework=20draft=20-=20part=202=0D=0A=20(s ecurity)|Thread-Index:=20AcuXGByc8NOvkuOzQwa6iLEJ8s/e8wAH sDdU|Message-ID:=20 |In-Reply-To:=20<4CFF5598.4000300@inrialpes.fr> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.7.0.100913|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=QgZsn94cfG7FyVRxyUmijOs0pxG9LGhWTgtc5FfHw14=; b=OftTrN+Eh9CwOKGKCyfiIvW13udrOooLVOK+pGOeJ2xyx2/WlbWe7GrB g8OvFD4w14ySm6X+xlFn6XQq80GmWQ3KxFnDQZWEVSy65o7kUeYVooDQl oy/pF4FA4RDUXSw4Yz+0gSNfk013uhA9Ns1ffKE0AJCA0dCcATof/szAi 8=; X-IronPort-AV: E=McAfee;i="5400,1158,6191"; a="65857005" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 08 Dec 2010 16:20:26 -0800 X-IronPort-AV: E=Sophos;i="4.59,315,1288594800"; d="scan'208";a="98989923" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 08 Dec 2010 16:20:26 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 8 Dec 2010 16:20:26 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Wed, 8 Dec 2010 16:20:21 -0800 From: "Luby, Michael" To: Vincent Roca , "Ali C. Begen (abegen)" Date: Wed, 8 Dec 2010 16:20:21 -0800 Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2 (security) Thread-Index: AcuXGByc8NOvkuOzQwa6iLEJ8s/e8wAHsDdU Message-ID: In-Reply-To: <4CFF5598.4000300@inrialpes.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 00:19:15 -0000 Thanks Vincent, this is all fine. One other thing: does the security part of the document say anything about the order in which FEC encoding/decoding is performed relative to security/encryption? This is one issue that is specific to FECFRAME, and that is whether encryption should be applied before/after FEC encoding at the sender and whether decryption should be applied after/before FEC decoding at the receiver. Does it make sense to recommend the former over the latter, as if the latter is used then the FEC decoding would have to be done in a trusted environment to uphold commonly desired security properties, which could be quite a burden in many architectures? On 12/8/10 1:53 AM, "Vincent Roca" wrote: > Hello Mike, > > Thanks a lot for your feedback. My answers: > > - the new security section mentions the possibility of using TESLA > within SRTP. It is therefore different from my RFC that describes > how to use TESLA within RMT protocols, even if the basic idea > is identical. Additionally, it's merely an example, not the > recommended solution: the "baseline security solution" relies on > IPsec/ESP. > > - Concerning the delay introduced by TESLA/SRTP, it is currently said: > "Yet, checking a packet requires a small delay (a second or > more) after > its reception with TESLA." > I suggest to add: > "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 may degrade the us= er > experience. In other situations this will not be an issue." > > In any case, as reminded by Ali, FECFRAME is agnostic WRT the upper > application and will be used with non real time flows as well. So it'= s > not necessarily an issue. > > - No matter the provided security mechanisms, attacks that negatively > impact the user experience (e.g. startup / e2e delay) may exist. > Imagine an attacker capable of delaying all the traffic sent by the > source (e.g. by taking control of a forwarding device, by modifying > the routing path, etc.). The fundamental question here is what is the > threat model and what do we want to address? > However I don't think this document has to provide an exhaustive > analysis and we need to acknowledge that a powerfull attacker > will cause a lot of dammage... but the receivers will in any case > identify attacks and mitigate them when feasible, dropping corrupted > contents, etc. That's the goal. > > Hope this makes sense. > Cheers, > > Vincent > > > On 01/12/10 21:06, Ali C. Begen (abegen) wrote: >> Hi Mike, >> >>> -----Original Message----- >>> From: Luby, Michael [mailto:luby@qualcomm.com] >>> Sent: Wednesday, December 01, 2010 2:07 PM >>> To: Luby, Michael; Greg Shepherd; Ali C. Begen (abegen) >>> Cc: fecframe@ietf.org >>> Subject: Re: [Fecframe] Proposed changes to the framework draft - part = 2 >>> (security) >>> >>> Actually, maybe the way to think about this is that if the security add= ed to >>> the solution degrades the user experience (in terms of either the start= up >>> delay or the end-to-end delay) then it can be viewed as an attack on th= e >> Agree but security is something decided upon before the content is actua= lly >> delivered. So, when deciding on the method, they will take into account >> whether delay-wise there is any problems. >> >>> service. One would want a security that doesn't compromise these aspec= ts >>> even when there is no attack. But, there could also be attacks on the >>> security, where the attack attempts to delay the client security >>> verification, and thus although the security is still there, the attack >>> slows down the startup delay or the end-to-end delay. Perhaps both of = these >>> are worth considering/commenting on (both =3D (1) providing security th= at >>> doesn't negatively impact startup/end-to-end delay; (2) discussing atta= cks >>> on security that could negatively impact user experience, such as >>> startup/end-to-end delay). >> Ok, should we just mention these? Are we recommending anything at all? >> >> -acbegen >> >>> >>> On 12/1/10 10:57 AM, "Luby, Michael" wrote: >>> >>>> I skimmed the new security section and it looks ok to me. I noticed t= hat >>>> there are some recommendations to use some of the security measures ba= sed >>>> on >>>> some of the work in the RMT wg, and on TESLA, etc. One thing that is q= uite >>>> different in streaming than in object delivery (focus of RMT) is that = the >>>> startup delay at the client (and the end-to-end-delay) is a crucial co= ncern >>>> for streaming, whereas it is not so much for object delivery. I haven= 't >>>> checked and presumably there aren't issues, but perhaps it should be >>>> discussed in the security section (and checked against some of the pro= posed >>>> solution) that, if possible, any security added should impact the pote= ntial >>>> startup delay (and the end-to-end delay) of the client as little as >>>> possible? Startup delay is the time from when a user decides to watch= a >>>> stream till it shows up on the screen. >>>> >>>> >>>> On 12/1/10 9:50 AM, "Greg Shepherd" wrote: >>>> >>>>> Thanks Vincent and Ali! >>>>> >>>>> So far we've had no feedback on the list for these changes. Please >>>>> read and respond ASAP - even if you approve please send your approval >>>>> to the list. We are so close to finishing up this WG.. let's not >>>>> stumble now. >>>>> >>>>> Thanks, >>>>> Greg >>>>> >>>>> On Wed, Dec 1, 2010 at 9:29 AM, Ali C. Begen (abegen) >>>>> wrote: >>>>>> This is the 2nd part for the changes we need to make in the framewor= k >>>>>> draft. >>>>>> This part is related to the security issues. Please refer to the tra= cker >>>>>> to >>>>>> see the comments from the IESG. >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballo= t/ >>>>>> >>>>>> I would like to thank Vincent for providing this brand new security >>>>>> section. >>>>>> I just added a few minor points into the text. >>>>>> >>>>>> If there are any objections, please speak up. If you are OK with the= se >>>>>> changes, please also speak up so that we can show WG consensus. >>>>>> >>>>>> Thanks, >>>>>> -acbegen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 9. Security Considerations >>>>>> >>>>>> First of all, it must be clear that the application of FEC protec= tion >>>>>> to a stream does not provide any kind of security. On the opposi= te, >>>>>> the FEC Framework itself could be subject to attacks, or could po= se >>>>>> 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. >>>>>> Some of them target the network (e.g., to compromise the routing >>>>>> infrastructure by compromising the congestion control component), >>>>>> others can target the Content Delivery Protocol (CDP) (e.g., to >>>>>> compromise its normal behavior), and finally some attacks target = the >>>>>> content itself. >>>>>> >>>>>> More specifically, these attacks can have several goals: >>>>>> >>>>>> o They can try to give access to a confidential content (e.g., i= n >>>>>> case of a non-free content). >>>>>> >>>>>> o They can try to corrupt the source and/or repair flows (e.g., = to >>>>>> prevent a receiver from using them). >>>>>> >>>>>> o They can try to compromise the receiver's behavior (e.g., by >>>>>> making the decoding of an object computationally expensive). >>>>>> >>>>>> o They can try to compromise the network's behavior (e.g., by >>>>>> causing congestion within the network). >>>>>> >>>>>> These attacks can be launched either against the source and/or re= pair >>>>>> flows (e.g., by sending forged 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 a session description). >>>>>> >>>>>> 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 use= d >>>>>> [RFC4303]. If confidentiality is a concern, it is RECOMMENDED th= at >>>>>> one of these solutions is used. Even if we mention these attacks >>>>>> here, they are neither related to nor facilitated by the use of F= EC. >>>>>> >>>>>> Note that when encryption is applied, this encryption MUST either= be >>>>>> applied before the FEC protection, or, if done after the FEC >>>>>> protection, then this encryption MUST be applied on both the FEC >>>>>> source packets and repair packets. Otherwise, if encryption were= to >>>>>> be performed only on the FEC source packets after FEC encoding, t= hen >>>>>> a non-authorized receiver could be able to recover the source dat= a >>>>>> after decoding the repair packets provided that a sufficient numb= er >>>>>> of such packets were available. >>>>>> >>>>>> 9.2.2. Content Corruption >>>>>> >>>>>> Protection against corruptions (e.g., after sending forged FEC >>>>>> source/repair packets) is achieved by means of a content integrit= y >>>>>> verification/source authentication scheme. This service is usual= ly >>>>>> provided at the packet level. In this case, after removing all t= he >>>>>> 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 o= f >>>>>> RTP and RTCP messages, among other services. For instance, >>>>>> associated to the Timed Efficient Stream Loss-Tolerant >>>>>> Authentication (TESLA) [RFC4383], SRTP is an attractive soluti= on >>>>>> that is robust to losses, provides a true authentication/integ= rity >>>>>> service, and does not create any prohibitive processing load o= r >>>>>> transmission overhead. Yet, checking a packet requires a smal= l >>>>>> delay (a second or more) after its reception with TESLA. Othe= r >>>>>> 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 >>>>>> knows the security requirements and features of the target >>>>>> application area, to define which solution is the most appropriat= e. >>>>>> Nonetheless it is RECOMMENDED that at least one of these techniqu= es >>>>>> 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. >>>>>> When the FEC Framework Configuration Information is sent out-of-b= and, >>>>>> e.g., in a session description, it SHOULD be protected, for insta= nce >>>>>> 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 wro= ng >>>>>> block. >>>>>> >>>>>> It is therefore RECOMMENDED that security measures are taken to >>>>>> guarantee the Explicit Source FEC Payload ID and Repair FEC Paylo= ad >>>>>> 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 instan= ce, >>>>>> then each flow MAY be processed appropriately, before the protect= ion. >>>>>> 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 o= ne >>>>>> over which the FEC Framework operates. In that case, this situat= ion >>>>>> MAY be addressed at the network layer, using IPsec/ESP (see >>>>>> Section 9.5), even if only a subset of the source flows have stri= ct >>>>>> security requirements. >>>>>> >>>>>> Since the use of FEC Framework should not add any additional thre= at, >>>>>> it is RECOMMENDED that the FEC Framework aggregate flow be in lin= e >>>>>> 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 FE= C >>>>>> Framework, using 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= . >>>>>> This approach is documented here to provide a reference of an >>>>>> interoperable secure mode of operation. However, other approache= s, >>>>>> including other forms of IPsec application, MAY be used or specif= ied >>>>>> in the future. >>>>>> >>>>>> Two related documents are of interest. First, Section 5.1 of >>>>>> [RFC5775] defines a baseline secure ALC operation for sender-to-g= roup >>>>>> transmissions, assuming the presence of a single sender and a sou= rce- >>>>>> specific multicast (SSM) or SSM-like operation. The proposed >>>>>> solution, based on IPsec/ESP, can be used to provide a baseline F= EC >>>>>> 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 si= ngle >>>>>> sender. The proposed solution is also based on IPsec/ESP. Howev= er, >>>>>> 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 sec= ond >>>>>> 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 independen= t >>>>>> from the application that generates source flows. Some applicati= ons >>>>>> might use purely unidirectional flows, while other applications m= ight >>>>>> also use unicast feedbacks from the receivers. For instance, thi= s is >>>>>> the case when considering RTP/RTCP based source flows. Depending= on >>>>>> the specific situation, it is RECOMMENDED that the baseline secur= e >>>>>> 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 [RFC577= 5] >>>>>> and [RFC5740] are commonly available on many potential hosts. Th= ey >>>>>> can form the basis of a secure mode of operation. One potential >>>>>> limitation, however, is the need for privileged user authorizatio= n. >>>>>> 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 >>>> _______________________________________________ >>>> 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 Wed Dec 8 18:31:18 2010 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 989B73A69AD for ; Wed, 8 Dec 2010 18:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.384 X-Spam-Level: X-Spam-Status: No, score=-10.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 DT0qx3+Xsb7a for ; Wed, 8 Dec 2010 18:31:17 -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 B1C253A695E for ; Wed, 8 Dec 2010 18:31:17 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKvO/0yrR7Hu/2dsb2JhbACjaHilNJsqhUkEhGKJKQ X-IronPort-AV: E=Sophos;i="4.59,318,1288569600"; d="scan'208";a="389153206" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 09 Dec 2010 02:32:46 +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 oB92Wk5c017239; Thu, 9 Dec 2010 02:32:46 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); Wed, 8 Dec 2010 18:32:46 -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: Wed, 8 Dec 2010 18:32:05 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DD51C34@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2 (security) Thread-Index: AcuXGByc8NOvkuOzQwa6iLEJ8s/e8wAHsDdUAARU6UA= References: <4CFF5598.4000300@inrialpes.fr> From: "Ali C. Begen (abegen)" To: "Luby, Michael" , "Vincent Roca" X-OriginalArrivalTime: 09 Dec 2010 02:32:46.0254 (UTC) FILETIME=[5D37DCE0:01CB9749] 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 02:31:18 -0000 I got Vincent's additional text into the revision. Regarding your = question below: > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Wednesday, December 08, 2010 7:20 PM > To: Vincent Roca; Ali C. Begen (abegen) > Cc: Greg Shepherd; fecframe@ietf.org; Luby, Michael > Subject: Re: [Fecframe] Proposed changes to the framework draft - part = 2 (security) >=20 > Thanks Vincent, this is all fine. One other thing: does the security = part > of the document say anything about the order in which FEC = encoding/decoding > is performed relative to security/encryption? This is one issue that = is > specific to FECFRAME, and that is whether encryption should be applied > before/after FEC encoding at the sender and whether decryption should = be > applied after/before FEC decoding at the receiver. Does it make sense = to > recommend the former over the latter, as if the latter is used then = the FEC > decoding would have to be done in a trusted environment to uphold = commonly > desired security properties, which could be quite a burden in many > architectures? The current text (in the revision to be submitted soon) says: Note that when encryption is applied, this encryption MUST either be = applied before the FEC protection, or, if done after the FEC protection, = then this encryption MUST be applied on both the FEC source packets and = repair packets. Otherwise, if encryption were to be performed only on = the FEC source packets after FEC encoding, then a non-authorized = receiver could be able to recover the source data after decoding the = repair packets provided that a sufficient number of such packets were = available. So, we mention both possibilities but do not recommend one over the = other. I think the text here is sufficient to say that doing encryption = after fec encoding also requires encrypting the FEC packets (which is = clearly an additional task which could have been avoided otherwise). = Does this require further text? -acbegen From tme@americafree.tv Wed Dec 8 19:41:57 2010 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 8CDD83A6982 for ; Wed, 8 Dec 2010 19:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.062 X-Spam-Level: X-Spam-Status: No, score=-102.062 tagged_above=-999 required=5 tests=[AWL=0.537, 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 HvBoXoengY45 for ; Wed, 8 Dec 2010 19:41:56 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id E37783A682B for ; Wed, 8 Dec 2010 19:41:54 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id EC18396330B9; Wed, 8 Dec 2010 22:42:10 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DD51C34@xmb-sjc-215.amer.cisco.com> Date: Wed, 8 Dec 2010 22:41:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CFF5598.4000300@inrialpes.fr> <04CAD96D4C5A3D48B1919248A8FE0D540DD51C34@xmb-sjc-215.amer.cisco.com> To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1081) 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 03:41:57 -0000 On Dec 8, 2010, at 9:32 PM, Ali C. Begen (abegen) wrote: > I got Vincent's additional text into the revision. Regarding your = question below: >=20 >> -----Original Message----- >> From: Luby, Michael [mailto:luby@qualcomm.com] >> Sent: Wednesday, December 08, 2010 7:20 PM >> To: Vincent Roca; Ali C. Begen (abegen) >> Cc: Greg Shepherd; fecframe@ietf.org; Luby, Michael >> Subject: Re: [Fecframe] Proposed changes to the framework draft - = part 2 (security) >>=20 >> Thanks Vincent, this is all fine. One other thing: does the security = part >> of the document say anything about the order in which FEC = encoding/decoding >> is performed relative to security/encryption? This is one issue that = is >> specific to FECFRAME, and that is whether encryption should be = applied >> before/after FEC encoding at the sender and whether decryption should = be >> applied after/before FEC decoding at the receiver. Does it make = sense to >> recommend the former over the latter, as if the latter is used then = the FEC >> decoding would have to be done in a trusted environment to uphold = commonly >> desired security properties, which could be quite a burden in many >> architectures? >=20 > The current text (in the revision to be submitted soon) says: >=20 > > Note that when encryption is applied, this encryption MUST either be = applied before the FEC protection, or, if done after the FEC protection, = then this encryption MUST be applied on both the FEC source packets and = repair packets. Otherwise, if encryption were to be performed only on = the FEC source packets after FEC encoding, then a non-authorized = receiver could be able to recover the source data after decoding the = repair packets provided that a sufficient number of such packets were = available. > >=20 > So, we mention both possibilities but do not recommend one over the = other. I think the text here is sufficient to say that doing encryption = after fec encoding also requires encrypting the FEC packets (which is = clearly an additional task which could have been avoided otherwise). = Does this require further text? I think that this text is very reasonable. WFM. Regards Marshall >=20 > -acbegen > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 From luby@qualcomm.com Wed Dec 8 19:51:53 2010 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 8F41B3A6888 for ; Wed, 8 Dec 2010 19:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 N+7W9pj3u6hZ for ; Wed, 8 Dec 2010 19:51:52 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id DEB473A682B for ; Wed, 8 Dec 2010 19:51:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1291866800; x=1323402800; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Ma rshall=20Eubanks=20,=20"Ali=20C.=20Be gen=20(abegen)"=0D=0A=09|CC:=20Vincent =20Roca=20,=20"fecframe@ietf.o rg"=0D=0A=09|Date:=20Wed,=208=20Dec=20 2010=2019:53:03=20-0800|Subject:=20Re:=20[Fecframe]=20Pro posed=20changes=20to=20the=20framework=20draft=20-=20part =202=0D=0A=20(security)|Thread-Topic:=20[Fecframe]=20Prop osed=20changes=20to=20the=20framework=20draft=20-=20part =202=0D=0A=20(security)|Thread-Index:=20AcuXUzxv71PSZPZJR ue5H+U0h9w8ogAAVfKh|Message-ID:=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|user-agent:=20Microsoft-Entourage/ 13.7.0.100913|acceptlanguage:=20en-US|Content-Type:=20tex t/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=RFQvI46dVqPxnxWy86tGsMjnb7NEEi81CiocyloK894=; b=eDQjvOkG6bW74uLgeVz88Lt/fZa/4n3MnX92Wz2bFb72gJTMKoInXrLw bmSQuHY2hHzR62wIrU4LCUglaoiMFn6M5mCF0pUghHlQJ2WPifz1Fi4NL IczDChBUGC8lcPCMCHfpsR9zJ1RtY7cJ2Nd6MW80ucyl1Lv9K/1OtmvpO k=; X-IronPort-AV: E=McAfee;i="5400,1158,6191"; a="66081970" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 08 Dec 2010 19:53:05 -0800 X-IronPort-AV: E=Sophos;i="4.59,318,1288594800"; d="scan'208";a="34804341" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 08 Dec 2010 19:53:05 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.3.83.0; Wed, 8 Dec 2010 19:53:05 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Wed, 8 Dec 2010 19:52:59 -0800 From: "Luby, Michael" To: Marshall Eubanks , "Ali C. Begen (abegen)" Date: Wed, 8 Dec 2010 19:53:03 -0800 Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2 (security) Thread-Index: AcuXUzxv71PSZPZJRue5H+U0h9w8ogAAVfKh Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 03:51:53 -0000 I don't think I made the issue very clear, so let me try again. The issue is that if decryption happens before FEC decoding then since the media is i= n plaintext at this point, the FEC decoding operations must occur in a truste= d environment, since if a bad guy can control or have access to the process that does the FEC decoding then the bad guy can steal the original media. If instead decryption happens after FEC decoding then the FEC is operating on ciphertext, so the FEC decoding operations don't have to occur in a trusted environment, since if a bad buy can control or have access to the process that does the FEC decoding then the bad guy is only able to steal encrypted media. Perhaps rewording the above appropriately and making this clear is enough. In any case, it is an extra security risk unique to FEC in this context. On 12/8/10 7:41 PM, "Marshall Eubanks" wrote: >=20 > On Dec 8, 2010, at 9:32 PM, Ali C. Begen (abegen) wrote: >=20 >> I got Vincent's additional text into the revision. Regarding your questi= on >> below: >>=20 >>> -----Original Message----- >>> From: Luby, Michael [mailto:luby@qualcomm.com] >>> Sent: Wednesday, December 08, 2010 7:20 PM >>> To: Vincent Roca; Ali C. Begen (abegen) >>> Cc: Greg Shepherd; fecframe@ietf.org; Luby, Michael >>> Subject: Re: [Fecframe] Proposed changes to the framework draft - part = 2 >>> (security) >>>=20 >>> Thanks Vincent, this is all fine. One other thing: does the security p= art >>> of the document say anything about the order in which FEC encoding/deco= ding >>> is performed relative to security/encryption? This is one issue that i= s >>> specific to FECFRAME, and that is whether encryption should be applied >>> before/after FEC encoding at the sender and whether decryption should b= e >>> applied after/before FEC decoding at the receiver. Does it make sense = to >>> recommend the former over the latter, as if the latter is used then the= FEC >>> decoding would have to be done in a trusted environment to uphold commo= nly >>> desired security properties, which could be quite a burden in many >>> architectures? >>=20 >> The current text (in the revision to be submitted soon) says: >>=20 >> >> Note that when encryption is applied, this encryption MUST either be app= lied >> before the FEC protection, or, if done after the FEC protection, then th= is >> encryption MUST be applied on both the FEC source packets and repair pac= kets. >> Otherwise, if encryption were to be performed only on the FEC source pac= kets >> after FEC encoding, then a non-authorized receiver could be able to reco= ver >> the source data after decoding the repair packets provided that a suffic= ient >> number of such packets were available. >> >>=20 >> So, we mention both possibilities but do not recommend one over the othe= r. I >> think the text here is sufficient to say that doing encryption after fec >> encoding also requires encrypting the FEC packets (which is clearly an >> additional task which could have been avoided otherwise). Does this requ= ire >> further text? >=20 > I think that this text is very reasonable. WFM. >=20 > Regards > Marshall >=20 >=20 >>=20 >> -acbegen >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >>=20 >=20 From abegen@cisco.com Wed Dec 8 20:05:10 2010 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 965FC3A6968 for ; Wed, 8 Dec 2010 20:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.834 X-Spam-Level: X-Spam-Status: No, score=-7.834 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, 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 ETFaaRUvhy7r for ; Wed, 8 Dec 2010 20:05:09 -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 BC3813A66B4 for ; Wed, 8 Dec 2010 20:05:08 -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: AjkHAP7j/0yrR7Ht/2dsb2JhbACjAWYCeKUVmymFSQSEYoYPgxqEcQ X-IronPort-AV: E=Sophos;i="4.59,319,1288569600"; d="scan'208";a="229890208" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 09 Dec 2010 04:06:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oB946btN028454; Thu, 9 Dec 2010 04:06:37 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Dec 2010 20:06:37 -0800 Received: from 128.107.191.87 ([128.107.191.87]) by xmb-sjc-215.amer.cisco.com ([171.70.151.169]) with Microsoft Exchange Server HTTP-DAV ; Thu, 9 Dec 2010 04:06:36 +0000 References: Content-Transfer-Encoding: quoted-printable From: "Ali C. Begen (abegen)" Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2 (security) Thread-Index: AcuXVnkcT+unc0QwRYqsQgrMi5okWw== Content-Type: text/plain; charset="us-ascii" In-Reply-To: Message-ID: Date: Wed, 8 Dec 2010 23:06:33 -0500 To: "Luby, Michael" MIME-Version: 1.0 (iPhone Mail 8C148) X-OriginalArrivalTime: 09 Dec 2010 04:06:37.0100 (UTC) FILETIME=[7976C6C0:01CB9756] 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 04:05:10 -0000 Ok got it. Will summarize this after the text below. Thanks for the note.=20= -acbegen On Dec 8, 2010, at 10:53 PM, "Luby, Michael" wrote: > I don't think I made the issue very clear, so let me try again. The issue= > is that if decryption happens before FEC decoding then since the media is i= n > plaintext at this point, the FEC decoding operations must occur in a trust= ed > environment, since if a bad guy can control or have access to the process > that does the FEC decoding then the bad guy can steal the original media. > If instead decryption happens after FEC decoding then the FEC is operating= > on ciphertext, so the FEC decoding operations don't have to occur in a > trusted environment, since if a bad buy can control or have access to the > process that does the FEC decoding then the bad guy is only able to steal > encrypted media. >=20 > Perhaps rewording the above appropriately and making this clear is enough.= > In any case, it is an extra security risk unique to FEC in this context. >=20 >=20 > On 12/8/10 7:41 PM, "Marshall Eubanks" wrote: >=20 >>=20 >> On Dec 8, 2010, at 9:32 PM, Ali C. Begen (abegen) wrote: >>=20 >>> I got Vincent's additional text into the revision. Regarding your questi= on >>> below: >>>=20 >>>> -----Original Message----- >>>> From: Luby, Michael [mailto:luby@qualcomm.com] >>>> Sent: Wednesday, December 08, 2010 7:20 PM >>>> To: Vincent Roca; Ali C. Begen (abegen) >>>> Cc: Greg Shepherd; fecframe@ietf.org; Luby, Michael >>>> Subject: Re: [Fecframe] Proposed changes to the framework draft - part 2= >>>> (security) >>>>=20 >>>> Thanks Vincent, this is all fine. One other thing: does the security p= art >>>> of the document say anything about the order in which FEC encoding/deco= ding >>>> is performed relative to security/encryption? This is one issue that i= s >>>> specific to FECFRAME, and that is whether encryption should be applied >>>> before/after FEC encoding at the sender and whether decryption should b= e >>>> applied after/before FEC decoding at the receiver. Does it make sense t= o >>>> recommend the former over the latter, as if the latter is used then the= FEC >>>> decoding would have to be done in a trusted environment to uphold commo= nly >>>> desired security properties, which could be quite a burden in many >>>> architectures? >>>=20 >>> The current text (in the revision to be submitted soon) says: >>>=20 >>> >>> Note that when encryption is applied, this encryption MUST either be app= lied >>> before the FEC protection, or, if done after the FEC protection, then th= is >>> encryption MUST be applied on both the FEC source packets and repair pac= kets. >>> Otherwise, if encryption were to be performed only on the FEC source pac= kets >>> after FEC encoding, then a non-authorized receiver could be able to reco= ver >>> the source data after decoding the repair packets provided that a suffic= ient >>> number of such packets were available. >>> >>>=20 >>> So, we mention both possibilities but do not recommend one over the othe= r. I >>> think the text here is sufficient to say that doing encryption after fec= >>> encoding also requires encrypting the FEC packets (which is clearly an >>> additional task which could have been avoided otherwise). Does this requ= ire >>> further text? >>=20 >> I think that this text is very reasonable. WFM. >>=20 >> Regards >> Marshall >>=20 >>=20 >>>=20 >>> -acbegen >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>>=20 >>=20 >=20 From tme@americafree.tv Wed Dec 8 20:31:43 2010 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 002123A69C2 for ; Wed, 8 Dec 2010 20:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=0.531, 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 CMS6mWgCH+Wu for ; Wed, 8 Dec 2010 20:31:42 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C02A63A698D for ; Wed, 8 Dec 2010 20:31:41 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 8D0589633F43; Wed, 8 Dec 2010 23:33:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: Date: Wed, 8 Dec 2010 23:33:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <451396F3-3471-4027-98F7-D4389F770634@americafree.tv> References: To: "Luby, Michael" X-Mailer: Apple Mail (2.1081) 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 04:31:43 -0000 On Dec 8, 2010, at 10:53 PM, Luby, Michael wrote: > I don't think I made the issue very clear, so let me try again. The = issue > is that if decryption happens before FEC decoding then since the media = is in > plaintext at this point, the FEC decoding operations must occur in a = trusted > environment, since if a bad guy can control or have access to the = process > that does the FEC decoding then the bad guy can steal the original = media. > If instead decryption happens after FEC decoding then the FEC is = operating > on ciphertext, so the FEC decoding operations don't have to occur in a > trusted environment, since if a bad buy can control or have access to = the > process that does the FEC decoding then the bad guy is only able to = steal > encrypted media. Ah, yes, I remember discussion of this. This also means that the = encryption of the FEC data (in the decrypt first mode) needs to be at least as cryptographically secure as the encryption of = the original data. It makes no sense (to take an extreme example) to use a PKI on the data = and rot13 on the FEC. Regards Marshall >=20 > Perhaps rewording the above appropriately and making this clear is = enough. > In any case, it is an extra security risk unique to FEC in this = context. >=20 >=20 > On 12/8/10 7:41 PM, "Marshall Eubanks" wrote: >=20 >>=20 >> On Dec 8, 2010, at 9:32 PM, Ali C. Begen (abegen) wrote: >>=20 >>> I got Vincent's additional text into the revision. Regarding your = question >>> below: >>>=20 >>>> -----Original Message----- >>>> From: Luby, Michael [mailto:luby@qualcomm.com] >>>> Sent: Wednesday, December 08, 2010 7:20 PM >>>> To: Vincent Roca; Ali C. Begen (abegen) >>>> Cc: Greg Shepherd; fecframe@ietf.org; Luby, Michael >>>> Subject: Re: [Fecframe] Proposed changes to the framework draft - = part 2 >>>> (security) >>>>=20 >>>> Thanks Vincent, this is all fine. One other thing: does the = security part >>>> of the document say anything about the order in which FEC = encoding/decoding >>>> is performed relative to security/encryption? This is one issue = that is >>>> specific to FECFRAME, and that is whether encryption should be = applied >>>> before/after FEC encoding at the sender and whether decryption = should be >>>> applied after/before FEC decoding at the receiver. Does it make = sense to >>>> recommend the former over the latter, as if the latter is used then = the FEC >>>> decoding would have to be done in a trusted environment to uphold = commonly >>>> desired security properties, which could be quite a burden in many >>>> architectures? >>>=20 >>> The current text (in the revision to be submitted soon) says: >>>=20 >>> >>> Note that when encryption is applied, this encryption MUST either be = applied >>> before the FEC protection, or, if done after the FEC protection, = then this >>> encryption MUST be applied on both the FEC source packets and repair = packets. >>> Otherwise, if encryption were to be performed only on the FEC source = packets >>> after FEC encoding, then a non-authorized receiver could be able to = recover >>> the source data after decoding the repair packets provided that a = sufficient >>> number of such packets were available. >>> >>>=20 >>> So, we mention both possibilities but do not recommend one over the = other. I >>> think the text here is sufficient to say that doing encryption after = fec >>> encoding also requires encrypting the FEC packets (which is clearly = an >>> additional task which could have been avoided otherwise). Does this = require >>> further text? >>=20 >> I think that this text is very reasonable. WFM. >>=20 >> Regards >> Marshall >>=20 >>=20 >>>=20 >>> -acbegen >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>>=20 >>=20 >=20 >=20 From abegen@cisco.com Thu Dec 9 06:36:37 2010 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 2D75C28B56A for ; Thu, 9 Dec 2010 06:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.392 X-Spam-Level: X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 8l0DR63JFwWO for ; Thu, 9 Dec 2010 06:36:35 -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 0259728C103 for ; Thu, 9 Dec 2010 06:36:26 -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: AvsEAFt4AE2rR7Ht/2dsb2JhbACje3ikYJsxhUoEhGSJLw X-IronPort-AV: E=Sophos;i="4.59,320,1288569600"; d="scan'208";a="633319418" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 09 Dec 2010 14:37:55 +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 oB9EbtVb002826; Thu, 9 Dec 2010 14:37:55 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); Thu, 9 Dec 2010 06:37:55 -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: Thu, 9 Dec 2010 06:37:51 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D7C7@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2(security) Thread-Index: AcuXVnkcT+unc0QwRYqsQgrMi5okWwAV/EKQ References: From: "Ali C. Begen (abegen)" To: "Luby, Michael" X-OriginalArrivalTime: 09 Dec 2010 14:37:55.0403 (UTC) FILETIME=[AAB121B0:01CB97AE] 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 14:36:37 -0000 Here is the revised text: Note that when encryption is applied, this encryption MUST either be = applied on the FEC source packets before the FEC protection, or if done = after the FEC protection, then both the FEC source packets and repair = packets MUST be applied encryption (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, then a non-authorized receiver could be able to recover the = source data after decoding the repair packets provided that a sufficient = number of such packets were available. =20 The following considerations apply when choosing where to apply = encryption. If encryption is applied after FEC encoding on the FEC = source and repair packets, decryption will take place before FEC = decoding. Since the source and repair data will be in plaintext at this = point, the subsequent FEC decoding operations MUST occur in a trusted = environment. Conversely, if encryption is applied before FEC encoding on = the FEC source packets only, the decryption will take place after FEC = decoding. Thus, the FEC decoding operations do not have to occur in a = trusted environment.=20 -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Ali C. Begen (abegen) > Sent: Wednesday, December 08, 2010 11:07 PM > To: Luby, Michael > Cc: fecframe@ietf.org > Subject: Re: [Fecframe] Proposed changes to the framework draft - part = 2(security) >=20 > Ok got it. Will summarize this after the text below. Thanks for the = note. >=20 > -acbegen >=20 > On Dec 8, 2010, at 10:53 PM, "Luby, Michael" = wrote: >=20 > > I don't think I made the issue very clear, so let me try again. The = issue > > is that if decryption happens before FEC decoding then since the = media is in > > plaintext at this point, the FEC decoding operations must occur in a = trusted > > environment, since if a bad guy can control or have access to the = process > > that does the FEC decoding then the bad guy can steal the original = media. > > If instead decryption happens after FEC decoding then the FEC is = operating > > on ciphertext, so the FEC decoding operations don't have to occur in = a > > trusted environment, since if a bad buy can control or have access = to the > > process that does the FEC decoding then the bad guy is only able to = steal > > encrypted media. > > > > Perhaps rewording the above appropriately and making this clear is = enough. > > In any case, it is an extra security risk unique to FEC in this = context. > > > > > > On 12/8/10 7:41 PM, "Marshall Eubanks" wrote: > > > >> > >> On Dec 8, 2010, at 9:32 PM, Ali C. Begen (abegen) wrote: > >> > >>> I got Vincent's additional text into the revision. Regarding your = question > >>> below: > >>> > >>>> -----Original Message----- > >>>> From: Luby, Michael [mailto:luby@qualcomm.com] > >>>> Sent: Wednesday, December 08, 2010 7:20 PM > >>>> To: Vincent Roca; Ali C. Begen (abegen) > >>>> Cc: Greg Shepherd; fecframe@ietf.org; Luby, Michael > >>>> Subject: Re: [Fecframe] Proposed changes to the framework draft - = part 2 > >>>> (security) > >>>> > >>>> Thanks Vincent, this is all fine. One other thing: does the = security part > >>>> of the document say anything about the order in which FEC = encoding/decoding > >>>> is performed relative to security/encryption? This is one issue = that is > >>>> specific to FECFRAME, and that is whether encryption should be = applied > >>>> before/after FEC encoding at the sender and whether decryption = should be > >>>> applied after/before FEC decoding at the receiver. Does it make = sense to > >>>> recommend the former over the latter, as if the latter is used = then the FEC > >>>> decoding would have to be done in a trusted environment to uphold = commonly > >>>> desired security properties, which could be quite a burden in = many > >>>> architectures? > >>> > >>> The current text (in the revision to be submitted soon) says: > >>> > >>> > >>> Note that when encryption is applied, this encryption MUST either = be applied > >>> before the FEC protection, or, if done after the FEC protection, = then this > >>> encryption MUST be applied on both the FEC source packets and = repair packets. > >>> Otherwise, if encryption were to be performed only on the FEC = source packets > >>> after FEC encoding, then a non-authorized receiver could be able = to recover > >>> the source data after decoding the repair packets provided that a = sufficient > >>> number of such packets were available. > >>> > >>> > >>> So, we mention both possibilities but do not recommend one over = the other. I > >>> think the text here is sufficient to say that doing encryption = after fec > >>> encoding also requires encrypting the FEC packets (which is = clearly an > >>> additional task which could have been avoided otherwise). Does = this require > >>> further text? > >> > >> I think that this text is very reasonable. WFM. > >> > >> Regards > >> Marshall > >> > >> > >>> > >>> -acbegen > >>> _______________________________________________ > >>> 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 vincent.roca@inrialpes.fr Thu Dec 9 07:13:13 2010 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 CE9DD28C0D6 for ; Thu, 9 Dec 2010 07:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 waumfDuD5XKo for ; Thu, 9 Dec 2010 07:13:13 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id A4BDD28C122 for ; Thu, 9 Dec 2010 07:13:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,320,1288566000"; d="scan'208";a="91910908" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 09 Dec 2010 16:14:40 +0100 Message-ID: <4D00F260.3040509@inrialpes.fr> Date: Thu, 09 Dec 2010 16:14:40 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Marshall Eubanks References: <451396F3-3471-4027-98F7-D4389F770634@americafree.tv> In-Reply-To: <451396F3-3471-4027-98F7-D4389F770634@americafree.tv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 15:13:13 -0000 Hello everybody, This discussion is interesting. I would say that once again the key point here is the "threat model". If an attacker can get control of the FEC decoding system and does what Mike suggests, he necessarily has some control of the FECFRAME endpoint. Two situations need to be considered then: 1/ If this FECFRAME endpoint is the end system (i.e. where the upper application runs), the attacker can probably do many nasty things, like modifying the application as well. In that case the two approaches ("encrypt first, then FEC encode" or "FEC encode first, then encrypt everything") lead to the same result. I don't see a fundamental difference in intercepting cleartext at the output of the FECFRAME module or within the application, at the output of the deciphering module. 2/ If this FECFRAME endpoint is a middlebox (i.e. the recovered Source Flow is sent in cleartext to the final remote destination(s)), in that case the "encrypt first" approach is preferable to the "FEC encode first" approach. That's obvious! This is why defining the "threat model" is important. In any case, the domains where sensitive data is exchanged in cleartext MUST be secure (by "exchange" I mean either sent over a network or communicated between various software modules). There is nothing specific to FECFRAME IMHO but we can add a paragraph to highlight it. I'll propose some new text... One thing that is FECFRAME specific is the situation where several flows with different security requirements are globally protected. This is discussed in Section 9.4. This section may be further improved. I need to think it over. Cheers, Vincent From abegen@cisco.com Thu Dec 9 09:29:32 2010 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 405643A6B9A for ; Thu, 9 Dec 2010 09:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.376 X-Spam-Level: X-Spam-Status: No, score=-10.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 tqDxTd3BNCtM for ; Thu, 9 Dec 2010 09:29:30 -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 A48523A6B99 for ; Thu, 9 Dec 2010 09:29:30 -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: AkwFAKugAE2rR7H+/2dsb2JhbACVVY4meKUdmySFSgSEZIkv X-IronPort-AV: E=Sophos;i="4.59,320,1288569600"; d="scan'208";a="230218028" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 09 Dec 2010 17:31:00 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oB9HV0iI021873 for ; Thu, 9 Dec 2010 17:31:00 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); Thu, 9 Dec 2010 09:31:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Dec 2010 09:30:10 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operations and Management Considerations (text for the framework) Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtw== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 09 Dec 2010 17:31:00.0482 (UTC) FILETIME=[D8AE6E20:01CB97C6] Subject: [Fecframe] Operations and Management Considerations (text 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: Thu, 09 Dec 2010 17:29:32 -0000 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. From gjshep@gmail.com Thu Dec 9 09:39:57 2010 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 3F10D28C13E for ; Thu, 9 Dec 2010 09:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=0.419, 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 T-TjaC4w56gV for ; Thu, 9 Dec 2010 09:39:56 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 9F1F428C122 for ; Thu, 9 Dec 2010 09:39:55 -0800 (PST) Received: by bwz8 with SMTP id 8so3101497bwz.38 for ; Thu, 09 Dec 2010 09:41:24 -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 :content-transfer-encoding; bh=HRCqUmpmk5asggGHfEPsfVRaktoL3wbKAG0YPpXuTCg=; b=jVxTBcFGjMGEdXJBjl6JXOftZDMdVtFNKUf1HemY6oI6+p7ajvWjKJFUOmYcsxf/iv mk+PONGpYHs/NdI8oeAUhzE3wyer1FNSOfkGr1gGfp46FkRjwTnDj9XcWc/GyilRbHqc 8gH3QHeB4m/X+QuYdkD6mVD3zLHs3/Qk2J6ts= 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:content-transfer-encoding; b=UGK3tJthGpZ1kVoL73zAYuv1Fgyb370BD179B4JoGwxPL0vZ3z/LkSaujtdWfPNy50 sReMCVk93IKxPBzPOnMnN2NWXQtk7qsgUNiG2ecn9Pe/uZohwx6QHKVTd81Lh1X4sOke wlzo9mns0yXhD5uCMGAfuZTgASHM60ZlBXm6s= MIME-Version: 1.0 Received: by 10.204.74.11 with SMTP id s11mr3681083bkj.185.1291916483289; Thu, 09 Dec 2010 09:41:23 -0800 (PST) Received: by 10.204.80.6 with HTTP; Thu, 9 Dec 2010 09:41:23 -0800 (PST) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> Date: Thu, 9 Dec 2010 09:41:23 -0800 Message-ID: From: Greg Shepherd To: David Harrington , fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Fecframe] Fwd: Operations and Management Considerations (text 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: Thu, 09 Dec 2010 17:39:57 -0000 David, Can you please review and reply to the proposed changes to the Framework draft? Once you approve it can move back to the IESG for their approval. Thanks!, Greg ---------- Forwarded message ---------- From: Ali C. Begen (abegen) Date: Thu, Dec 9, 2010 at 9:30 AM Subject: [Fecframe] Operations and Management Considerations (text for the framework) To: fecframe@ietf.org 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. =A0Operations and Management Considerations =A0 The FEC Framework is concerned about the FEC encoding and decoding =A0 operations, and the configuration information that is essential to =A0 control the hosts running these operations. =A0Defining tools for the =A0 operation and management of these hosts is not within the scope of =A0 this specification. =A0 Some applications using the CDPs compatible with the FEC Framework =A0 are one-way meaning that they do not have a way to gather any kind of =A0 feedback from receivers (e.g., broadcast), while some of them may =A0 collect detailed feedback (in case it is a one-to-one application) or =A0 occasional feedback (in case it is a multicast application). =A0All =A0 these applications have naturally different management aspects. =A0If =A0 any, they also have different requirements or features for collecting =A0 feedback, processing it and acting on it. =A0The data structures for =A0 carrying the feedback also vary. =A0 On the operations side, it is not advisable for the FEC Framework to =A0 explicitly list what the hosts (sender or receiver or even a middle- =A0 box) could do upon observing something in particular or receiving a =A0 specific feedback. =A0The CDPs and the FEC schemes compatible with the =A0 FEC Framework SHOULD make use of existing tools as much as possible =A0 and to the extent possible. =A0For example, for repair flows using RTP =A0 transport, benefiting from all the features of RTCP mechanisms is =A0 strongly RECOMMENDED since RTCP has already solved many of these =A0 issues in an agnostic way of the data carried with RTP. =A0 Overall, the CDPs and FEC schemes compatible with the FEC Framework =A0 widely differ in their capabilities, application and deployment =A0 scenarios such that a common operation and management tool that works =A0 well for all of them does not exist. =A0Thus, as a design choice, the =A0 FEC Framework does not dictate the use of any particular technology =A0 or protocol for transporting FEC data, managing the hosts, signaling =A0 the configuration information or encoding the configuration =A0 information. =A0This provides flexibility and was one of the main goals =A0 of the FEC Framework. _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From gjshep@gmail.com Thu Dec 9 09:43:26 2010 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 4FA7428C0FB for ; Thu, 9 Dec 2010 09:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.233 X-Spam-Level: X-Spam-Status: No, score=-103.233 tagged_above=-999 required=5 tests=[AWL=0.366, 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 w5MpQqZcIqd8 for ; Thu, 9 Dec 2010 09:43:25 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id BB14428C146 for ; Thu, 9 Dec 2010 09:43:24 -0800 (PST) Received: by bwz8 with SMTP id 8so3105583bwz.38 for ; Thu, 09 Dec 2010 09:44:54 -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=uCQxWtyB7HyQN3ze3MSVrJyVhn7Tp6u/MtiJ37NKORs=; b=UNLbXF4/tEG1rL8rl9bFyxvWaOKae9MCrBAP0borfUFISP6M4CwqFGx8XMiyAnt4fv ngjDjfHmFhCv357Yz4/ft/ke0jRDvNU4OtpO+j8/re3WBMs3MNs+tpC1qu+pv1Xn94MG ehnxFgpFsHjzaD7TT+WQ9reWg2AprpoinPFKk= 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=jEyVgFz2HBao+vYcuPgWHnZjjjQPtJtZRFGFt8puCy1v8oON83yooaKLbA7JQVAoEF s+/ewF1rewveESjIQmMeFNfyMstojX++YIAndfASXZJsIrQXL+xvQdMEXQE2RrBumDmJ n3e2ZpLTdkfcPEL9ju8ckVIOuCPySkYJJQ5n8= MIME-Version: 1.0 Received: by 10.204.52.138 with SMTP id i10mr3694447bkg.23.1291916693890; Thu, 09 Dec 2010 09:44:53 -0800 (PST) Received: by 10.204.80.6 with HTTP; Thu, 9 Dec 2010 09:44:53 -0800 (PST) In-Reply-To: References: <20101123072148.DB34428C1A6@core3.amsl.com> <444DD58D-6C4D-4575-8F91-093F352DBB11@nomor.de> Date: Thu, 9 Dec 2010 09:44:53 -0800 Message-ID: From: Greg Shepherd To: Thomas Stockhammer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: Re: [Fecframe] Fwd: New Version Notification for draft-ietf-fecframe-raptor-03 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: Thu, 09 Dec 2010 17:43:26 -0000 WG, We've had good response on the raptor rtp draft but this draft went past the WG last call date and nobody responded, even with an approval. Please respond to this thread regarding this draft. I can't move this along without WG responses. WG LC will be extended to allow your responses - Jan 2, 2011. Thanks, Greg On Tue, Nov 23, 2010 at 7:33 AM, Greg Shepherd wrote: > Thanks Thomas! > > Let's move this along quickly. Consider this WGLC. Please post all > feedback to the list by the end of next week, Fri, Dec 3rd. > > Cheers, > Greg > > On Mon, Nov 22, 2010 at 11:33 PM, Thomas Stockhammer > wrote: >> Experts, >> we have reactivated=A0draft-ietf-fecframe-raptor-03. Highlights of the c= hanges >> compared to -02 >> - Update of authors >> - Alignment with=A0draft-ietf-rmt-bb-fec-raptorq-04 >> - Some minor editorial updates >> - Updates of references >> Comments from the list had already been integrated in -02. >> I think it is time to get this out of the queue. >> Best regards >> Thomas >> Begin forwarded message: >> >> From: IETF I-D Submission Tool >> Date: November 23, 2010 8:21:48 AM GMT+01:00 >> To: stockhammer@nomor.de >> Cc: watsonm@netflix.com >> Subject: New Version Notification for draft-ietf-fecframe-raptor-03 >> >> >> A new version of I-D, draft-ietf-fecframe-raptor-03.txt has been >> successfully submitted by Thomas Stockhammer and posted to the IETF >> repository. >> >> Filename: draft-ietf-fecframe-raptor >> Revision: 03 >> Title: Raptor FEC Schemes for FECFRAME >> Creation_date: 2010-11-23 >> WG ID: fecframe >> Number_of_pages: 21 >> >> Abstract: >> This document describes Fully-Specified Forward Error Correction >> (FEC) Schemes for the Raptor and RaptorQ codes and their application >> to reliable delivery of media streams in the context of FEC >> Framework. =A0The Raptor and RaptorQ codes are systematic codes, where >> a number of repair symbols are generated from a set of source symbols >> and sent in one or more repair flows in addition to the source >> symbols that are sent to the receiver(s) within a source flow. =A0The >> Raptor and RaptorQ codes offer close to optimal protection against >> arbitrary packet losses at a low computational complexity. =A0Six FEC >> Schemes are defined, two for protection of arbitrary packet flows, >> two that are optimised for small source blocks and another two for >> protection of a single flow that already contains a sequence number. >> Repair data may be sent over arbitrary datagram transport (e.g. =A0UDP) >> or using RTP. >> >> >> >> The IETF Secretariat. >> >> >> >> --- >> Dr. Thomas Stockhammer (CEO) ||=A0stockhammer@nomor.de=A0|| phone +49 89= 978980 >> 02 || cell +491725702667 || http://www.nomor-research.com >> Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - Registerg= ericht: >> M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FC= hrer: Dr. >> Thomas Stockhammer, Dr. Ingo Viering. >> >> >> >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >> >> > From gjshep@gmail.com Thu Dec 9 09:46:22 2010 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 E9ABD28C0F3 for ; Thu, 9 Dec 2010 09:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.273 X-Spam-Level: X-Spam-Status: No, score=-103.273 tagged_above=-999 required=5 tests=[AWL=0.326, 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 hMicZnkaFGXu for ; Thu, 9 Dec 2010 09:46:20 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 2098E28C0E7 for ; Thu, 9 Dec 2010 09:46:19 -0800 (PST) Received: by bwz8 with SMTP id 8so3108980bwz.38 for ; Thu, 09 Dec 2010 09:47:49 -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=iJOQ6RNpNd5ooQKlOxDKyqb5tgFrCt4wJRR+IwFaO5Y=; b=r2S9UZNuqUu4S9q9ANRf8abRI6tzYrxA4eW3O0NkdTV3b55C31bENR1mwIp/qF0kaH Os2rP8V9L1qHCQIuuSoYVdnLIXuo+FuMS7A+G6Yk3ExwE6Q9kvC9bywS3ULXiIitOWe3 3csSHX+R82G/Hyr1oM+CRKf4wSA3TuDI7v624= 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=laM59wDdXBVzXR0bWUAJGhq8Lr5rMBZT3sLlg7JCQUCV1vqjDVcLq9E45xmu/727Ex KrbZhkqyeUfRxSih6pnQ/VoLQAF9rUol98rR8QBzkzyK37aemlHPC+iX54ZWWb1DJLC9 Tv0OA4uyVWg1YJnfQwFDyOKCT5tuZzpYVrCRM= MIME-Version: 1.0 Received: by 10.204.84.138 with SMTP id j10mr3690432bkl.131.1291916867553; Thu, 09 Dec 2010 09:47:47 -0800 (PST) Received: by 10.204.80.6 with HTTP; Thu, 9 Dec 2010 09:47:47 -0800 (PST) In-Reply-To: References: <20101125193001.16083.70034.idtracker@localhost> Date: Thu, 9 Dec 2010 09:47:47 -0800 Message-ID: From: Greg Shepherd To: Colin Perkins Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: Re: [Fecframe] Fwd: I-D Action:draft-ietf-fecframe-rtp-raptor-04.txt 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: Thu, 09 Dec 2010 17:46:22 -0000 Thanks everyone! Thomas, Can you update the draft to reflect the list feedback? Once you do we can take the draft to WGLC and move it along. We're getting close folks! Thanks, Greg On Wed, Dec 1, 2010 at 10:33 AM, Colin Perkins wrote: > Thomas, > I've just (very quickly) read the -04 draft. Some comments from an RTP > perspective: > - Section 4.1: explain how the RTP payload type is chosen (dynamic > assignment) and signalled using SDP. > - Section 4.1: explain how the SSRC is assigned, and how the repair RTP > session is associated with the source RTP session using RTCP. They should > probably be sent as separate RTP sessions, using RTCP CNAME to align, but > this somewhat depends on whether the FEC is systematic or not. > - Section 5: "Applications that use this media type" is not specified. > - Section 10: the SDP is incorrect: RTP/AVT on the m=3D line should be RT= P/AVP > and the fmt is not specified. > - Section 10: is the grouping using FID mandatory, or an example of how i= t > can be done? > - Section 9 should probably give many more details on how the RTP headers > are constructed, and how the repair flow and source flows are associated.= It > seems somewhat light. > Cheers, > Colin > > > On 25 Nov 2010, at 19:45, Thomas Stockhammer wrote: > > Experts, > we also have reactivated=A0draft-ietf-fecframe-rtp-raptor-04. Highlights = of > the changes compared to -03 > - Update of authors > - Alignment with=A0draft-ietf-rmt-bb-fec-raptorq-04 > - Alignment with=A0draft-ietf-fecframe-raptor-03 > - Alignment with=A0draft-ietf-fecframe-11 > - Some minor editorial updates > - Updates of references > - A significant amount of comments from Ali are integrated in the revised > version. Non-implemented comments were resolved offline with Ali > - Some small comments from Mike Luby on terminology are integrated. > Thanks to Ali and Mike. > I think it is time to get this out of the queue. > The document should also be forwarded to AVT once we have a stable versio= n. > Thanks and Best regards and Happy Thanksgivings ... > Thomas > > Begin forwarded message: > > From: Internet-Drafts@ietf.org > Date: November 25, 2010 8:30:01 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: fecframe@ietf.org > Subject: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-04.txt > > 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 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: RTP Payload Format for Raptor FEC > Author(s) =A0=A0=A0=A0=A0=A0: M. Watson, T. Stockhammer > Filename =A0=A0=A0=A0=A0=A0=A0: draft-ietf-fecframe-rtp-raptor-04.txt > Pages =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 25 > Date =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2010-11-25 > > This document specifies an RTP payload format for Forward Error > Correction /(FEC) repair data produced by the Raptor FEC schemes. > Raptor FEC schemes are specified for use with the IETF FEC Framework > which supports transport of repair data over both UDP and RTP. =A0This > document specifies the payload format which is required for the use > of RTP to carry Raptor repair flows. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-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. > > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > --- > Dr. Thomas Stockhammer (CEO) ||=A0stockhammer@nomor.de=A0|| phone +49 89 = 978980 > 02 || cell +491725702667 || http://www.nomor-research.com > Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - Registerge= richt: > M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FCh= rer: Dr. > Thomas Stockhammer, Dr. Ingo Viering. > > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > From gjshep@gmail.com Thu Dec 9 09:48:51 2010 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 3DAB828C0F3 for ; Thu, 9 Dec 2010 09:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.306 X-Spam-Level: X-Spam-Status: No, score=-103.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 H1wyvK2+ogLo for ; Thu, 9 Dec 2010 09:48:50 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 5236628C0E7 for ; Thu, 9 Dec 2010 09:48:50 -0800 (PST) Received: by bwz8 with SMTP id 8so3112338bwz.38 for ; Thu, 09 Dec 2010 09:50:19 -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:date :message-id:subject:from:to:content-type; bh=Rc3Edb1hP5np9pbkzl4hzazjsnU2stEYurgagpD7R1c=; b=NYSOtYIaTC6TgU5ijY3iUQtCv4+5aRG8FysWCxJCUqp5CDo6S74IVgnac1xWS0UkTD K4sFvPkUv4QYo0RFBhC205+7VmThqUgXvelwsAfZse79laITjvihGlRRrKjZoVFQwYe5 WlEm76SsAf3HBCVyTFzp+9ys5W75DSxGtoctM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=P6xsRNwEnTt+QOLCMmHYIGN6Nq5p96q9QJ9RlDmArVizm4zi/dhg5rGnZJHO/o7JW4 e+1pmgvYR0A2nT9iDCDqgIOz1YhWl70GcnIuS3xb39R8xCQMEuKm44PKMtt/IsJCq+2q DmkSNt4TbQVk/0AATsg2KKcKF70zqXEaOvjNM= MIME-Version: 1.0 Received: by 10.204.52.138 with SMTP id i10mr3702712bkg.23.1291917019678; Thu, 09 Dec 2010 09:50:19 -0800 (PST) Received: by 10.204.80.6 with HTTP; Thu, 9 Dec 2010 09:50:19 -0800 (PST) Date: Thu, 9 Dec 2010 09:50:19 -0800 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [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: Thu, 09 Dec 2010 17:48:51 -0000 *, 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 abegen@cisco.com Thu Dec 9 10:32:36 2010 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 699143A6BAC for ; Thu, 9 Dec 2010 10:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.38 X-Spam-Level: X-Spam-Status: No, score=-10.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 brWy3LtAHb9b for ; Thu, 9 Dec 2010 10:32:35 -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 3E80A3A6BA8 for ; Thu, 9 Dec 2010 10:32:35 -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: AvsEAG6vAE2rR7H+/2dsb2JhbACje3ilFpsfhUoEhGSJLw X-IronPort-AV: E=Sophos;i="4.59,321,1288569600"; d="scan'208";a="300025858" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 09 Dec 2010 18:34:05 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oB9IY241011321; Thu, 9 Dec 2010 18:34:05 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Dec 2010 10:34:03 -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: Thu, 9 Dec 2010 10:33:44 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D8A8@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Adopt? Thread-Index: AcuXyY/5vf1ww6olQ/CijFUeJk+1SQABe5jQ References: From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 09 Dec 2010 18:34:03.0188 (UTC) FILETIME=[A7598F40:01CB97CF] 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: Thu, 09 Dec 2010 18:32:36 -0000 As I indicated in the meeting as well, I personally wanna see these = drafts to be completed so that we can have a more variety of FEC = schemes. The RTP payload draft is also useful to have it. -acbegen > -----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? >=20 > *, >=20 > 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: >=20 > - draft-roca-fecframe-simple-rs-01 > - draft-galanos-fecframe-rtp-reedsolomon-02 > - draft-roca-fecframe-ldpc-01 >=20 > Thanks, > Greg > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From luby@qualcomm.com Thu Dec 9 10:36:18 2010 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 B7D7728C132 for ; Thu, 9 Dec 2010 10:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, 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 OW5VRukwFqXh for ; Thu, 9 Dec 2010 10:36:17 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4D59628C0FB for ; Thu, 9 Dec 2010 10:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1291919867; x=1323455867; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Gr eg=20Shepherd=20,=20Thomas=20Stockhamme r=0D=0A=09|CC:=20"fecframe@ietf.org "=20|Date:=20Thu,=209=20Dec=202010=201 0:37:34=20-0800|Subject:=20Re:=20[Fecframe]=20Fwd:=20New =20Version=20Notification=20for=0D=0A=20draft-ietf-fecfra me-raptor-03|Thread-Topic:=20[Fecframe]=20Fwd:=20New=20Ve rsion=20Notification=20for=0D=0A=20draft-ietf-fecframe-ra ptor-03|Thread-Index:=20AcuXyM0W+FMbhldVRlGKabo9DGfB0gAB1 fqk|Message-ID:=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|user-agent:=20Microsoft-Entourage/ 13.7.0.100913|acceptlanguage:=20en-US|Content-Type:=20tex t/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=5U1UymgJ/YjSKHfrG9Q1S0O5v+kj32brzt9MBW4MNU4=; b=Xed/035JC5/1ccK7cWUlN/3sz3XlhCDSiIPUO/LDVMEZU291bqy7/+7N ZZP87iOauvgubRDe0E5beJbGTXfpgGWMmt5d0yjp2Nn3261ViC/gtykH3 dLtTu3V+Np8zTgS2D1du2eOsH3HkSgRlL1gvmUYVDn/bxtg3QymQM7/Ac 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6192"; a="65969872" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 09 Dec 2010 10:37:37 -0800 X-IronPort-AV: E=Sophos;i="4.59,320,1288594800"; d="scan'208";a="35037247" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 09 Dec 2010 10:37:37 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 9 Dec 2010 10:37:35 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Thu, 9 Dec 2010 10:37:32 -0800 From: "Luby, Michael" To: Greg Shepherd , Thomas Stockhammer Date: Thu, 9 Dec 2010 10:37:34 -0800 Thread-Topic: [Fecframe] Fwd: New Version Notification for draft-ietf-fecframe-raptor-03 Thread-Index: AcuXyM0W+FMbhldVRlGKabo9DGfB0gAB1fqk Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Fwd: New Version Notification for draft-ietf-fecframe-raptor-03 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: Thu, 09 Dec 2010 18:36:19 -0000 I provided my detailed comments just before the wglc was made,and I don't have any additional. On 12/9/10 9:44 AM, "Greg Shepherd" wrote: > WG, >=20 > We've had good response on the raptor rtp draft but this draft went > past the WG last call date and nobody responded, even with an > approval. Please respond to this thread regarding this draft. I can't > move this along without WG responses. WG LC will be extended to allow > your responses - Jan 2, 2011. >=20 > Thanks, > Greg >=20 > On Tue, Nov 23, 2010 at 7:33 AM, Greg Shepherd wrote: >> Thanks Thomas! >>=20 >> Let's move this along quickly. Consider this WGLC. Please post all >> feedback to the list by the end of next week, Fri, Dec 3rd. >>=20 >> Cheers, >> Greg >>=20 >> On Mon, Nov 22, 2010 at 11:33 PM, Thomas Stockhammer >> wrote: >>> Experts, >>> we have reactivated=A0draft-ietf-fecframe-raptor-03. Highlights of the = changes >>> compared to -02 >>> - Update of authors >>> - Alignment with=A0draft-ietf-rmt-bb-fec-raptorq-04 >>> - Some minor editorial updates >>> - Updates of references >>> Comments from the list had already been integrated in -02. >>> I think it is time to get this out of the queue. >>> Best regards >>> Thomas >>> Begin forwarded message: >>>=20 >>> From: IETF I-D Submission Tool >>> Date: November 23, 2010 8:21:48 AM GMT+01:00 >>> To: stockhammer@nomor.de >>> Cc: watsonm@netflix.com >>> Subject: New Version Notification for draft-ietf-fecframe-raptor-03 >>>=20 >>>=20 >>> A new version of I-D, draft-ietf-fecframe-raptor-03.txt has been >>> successfully submitted by Thomas Stockhammer and posted to the IETF >>> repository. >>>=20 >>> Filename: draft-ietf-fecframe-raptor >>> Revision: 03 >>> Title: Raptor FEC Schemes for FECFRAME >>> Creation_date: 2010-11-23 >>> WG ID: fecframe >>> Number_of_pages: 21 >>>=20 >>> Abstract: >>> This document describes Fully-Specified Forward Error Correction >>> (FEC) Schemes for the Raptor and RaptorQ codes and their application >>> to reliable delivery of media streams in the context of FEC >>> Framework. =A0The Raptor and RaptorQ codes are systematic codes, where >>> a number of repair symbols are generated from a set of source symbols >>> and sent in one or more repair flows in addition to the source >>> symbols that are sent to the receiver(s) within a source flow. =A0The >>> Raptor and RaptorQ codes offer close to optimal protection against >>> arbitrary packet losses at a low computational complexity. =A0Six FEC >>> Schemes are defined, two for protection of arbitrary packet flows, >>> two that are optimised for small source blocks and another two for >>> protection of a single flow that already contains a sequence number. >>> Repair data may be sent over arbitrary datagram transport (e.g. =A0UDP) >>> or using RTP. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>>=20 >>> --- >>> Dr. Thomas Stockhammer (CEO) ||=A0stockhammer@nomor.de=A0|| phone +49 8= 9 978980 >>> 02 || cell +491725702667 || http://www.nomor-research.com >>> Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - Register= gericht: >>> M=FCnchen, HRB 165856 =AD Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf= =FChrer: Dr. >>> Thomas Stockhammer, Dr. Ingo Viering. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>>=20 >>>=20 >>=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From luby@qualcomm.com Thu Dec 9 10:42:24 2010 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 78FCA28C13F for ; Thu, 9 Dec 2010 10:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 JltYv7M+NMPJ for ; Thu, 9 Dec 2010 10:42:18 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id D4AE928C132 for ; Thu, 9 Dec 2010 10:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1291920227; x=1323456227; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"A li=20C.=20Begen=20(abegen)"=20,=20"fecf rame@ietf.org"=0D=0A=09|Date:=20Thu, =209=20Dec=202010=2010:43:43=20-0800|Subject:=20Re:=20[Fe cframe]=20Operations=20and=20Management=20Considerations =20(text=20for=0D=0A=20the=20framework)|Thread-Topic:=20[ Fecframe]=20Operations=20and=20Management=20Consideration s=20(text=20for=0D=0A=20the=20framework)|Thread-Index:=20 AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAC9Y/6|Message-ID:=20|In-Reply-To:=20<04CAD96D4C5A3 D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.7.0.100913|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=oDzY2XFoJERWCx5PKEi5uQJDbBefSYWUEn2HYSIPRno=; b=zQIbDN750j73vZzbQTvhLpyDcpGOMxQI957so8Gu1EwvDsgzVshCmOY2 NVWzQGBhrfUCRYqiMrMzEhe8BzJgXR2ow7k8MFA8GD1sEyVe4dIPHHkaN Ut2kqDczDcUBsfgpn9THnETicIJf4cO8dXdXMmQsnqW0ExI04uneB+7W1 g=; X-IronPort-AV: E=McAfee;i="5400,1158,6192"; a="66170871" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 09 Dec 2010 10:43:46 -0800 X-IronPort-AV: E=Sophos;i="4.59,320,1288594800"; d="scan'208";a="16940599" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 09 Dec 2010 10:43:46 -0800 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 9 Dec 2010 10:43:45 -0800 Received: from nasclexhc01.na.qualcomm.com (172.30.48.1) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 9 Dec 2010 10:43:46 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Thu, 9 Dec 2010 10:43:45 -0800 From: "Luby, Michael" To: "Ali C. Begen (abegen)" , "fecframe@ietf.org" Date: Thu, 9 Dec 2010 10:43:43 -0800 Thread-Topic: [Fecframe] Operations and Management Considerations (text for the framework) Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAC9Y/6 Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Fecframe] Operations and Management Considerations (text 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: Thu, 09 Dec 2010 18:42:24 -0000 Is there any discussion I the framework draft (perhaps it would be in this section 10) that covers operations and management when you have a mixed population of receivers, some that do support FEC and some that do not? In such a mixed population there might be certain recommendations for how to operate and configure things so that receivers that don't support FEC are not disrupted but those that do can benefit from receiving FEC to enhance the quality of their service. On 12/9/10 9:30 AM, "Ali C. Begen (abegen)" wrote: > This is the text that will be incorporated into the framework draft (foll= owing > up on the earlier discussion in the list). If there are any final comment= s, > please send them to the list. >=20 > Otherwise, we are waiting for the AD to give us a green light to move ahe= ad > 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 From gjshep@gmail.com Thu Dec 9 10:48:47 2010 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 7EAE028C122 for ; Thu, 9 Dec 2010 10:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.033 X-Spam-Level: X-Spam-Status: No, score=-103.033 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, J_CHICKENPOX_43=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 Rc3-kHtlIMJI for ; Thu, 9 Dec 2010 10:48:46 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id B6AB73A6BA9 for ; Thu, 9 Dec 2010 10:48:45 -0800 (PST) Received: by bwz8 with SMTP id 8so3193846bwz.38 for ; Thu, 09 Dec 2010 10:50:15 -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=tp00/KvxheMJkOlu+qAF2nXnrIcprUt8lZe1F9uiOW4=; b=jtXe3NzHwBjXIQQgUiKidrGFGmWarMpCX9GB3yEwSimKyjDYZ/oos7KQ/WPVcDuIFd XYEI4uOmDDiolAbdNtwGpxMmGJNH6p03dfCe1vKOmz59HpCxlTx3/SbZ31yUNLMkF0Lw nQ7kAdN4ofVPygoRd8OBlkeifXvUd49YFKIF4= 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=LNNg73Zde+4py4t6fzwhQ4bjs8ZvThHUmNzwAWflLo6chuAeLbOKV02U1g/brp0kaj M0yxLsuOhvNAsfeMeVRTE1y2X5+ejRFKUSHf1+VeIWwUf7FX8yC8Y3ENHHt5akvnDNOH mp1jmnrzIFQj3IpykXDnCRYv+1L3eZt+USQjY= MIME-Version: 1.0 Received: by 10.204.34.130 with SMTP id l2mr3747222bkd.212.1291920613498; Thu, 09 Dec 2010 10:50:13 -0800 (PST) Received: by 10.204.80.6 with HTTP; Thu, 9 Dec 2010 10:50:13 -0800 (PST) In-Reply-To: References: Date: Thu, 9 Dec 2010 10:50:13 -0800 Message-ID: From: Greg Shepherd To: "Luby, Michael" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Fwd: New Version Notification for draft-ietf-fecframe-raptor-03 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: Thu, 09 Dec 2010 18:48:47 -0000 Thanks Mike! For some reason your comments did not show in my gmail threadview... Sorry. How about the rest of you? Progress through LC requires consensus. So far we have Mike and I approving. We need more responses to move on. Thanks, Greg On Thu, Dec 9, 2010 at 10:37 AM, Luby, Michael wrote: > I provided my detailed comments just before the wglc was made,and I don't > have any additional. > > > On 12/9/10 9:44 AM, "Greg Shepherd" wrote: > >> WG, >> >> We've had good response on the raptor rtp draft but this draft went >> past the WG last call date and nobody responded, even with an >> approval. Please respond to this thread regarding this draft. I can't >> move this along without WG responses. WG LC will be extended to allow >> your responses - Jan 2, 2011. >> >> Thanks, >> Greg >> >> On Tue, Nov 23, 2010 at 7:33 AM, Greg Shepherd wrote: >>> Thanks Thomas! >>> >>> Let's move this along quickly. Consider this WGLC. Please post all >>> feedback to the list by the end of next week, Fri, Dec 3rd. >>> >>> Cheers, >>> Greg >>> >>> On Mon, Nov 22, 2010 at 11:33 PM, Thomas Stockhammer >>> wrote: >>>> Experts, >>>> we have reactivated=A0draft-ietf-fecframe-raptor-03. Highlights of the= changes >>>> compared to -02 >>>> - Update of authors >>>> - Alignment with=A0draft-ietf-rmt-bb-fec-raptorq-04 >>>> - Some minor editorial updates >>>> - Updates of references >>>> Comments from the list had already been integrated in -02. >>>> I think it is time to get this out of the queue. >>>> Best regards >>>> Thomas >>>> Begin forwarded message: >>>> >>>> From: IETF I-D Submission Tool >>>> Date: November 23, 2010 8:21:48 AM GMT+01:00 >>>> To: stockhammer@nomor.de >>>> Cc: watsonm@netflix.com >>>> Subject: New Version Notification for draft-ietf-fecframe-raptor-03 >>>> >>>> >>>> A new version of I-D, draft-ietf-fecframe-raptor-03.txt has been >>>> successfully submitted by Thomas Stockhammer and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-ietf-fecframe-raptor >>>> Revision: 03 >>>> Title: Raptor FEC Schemes for FECFRAME >>>> Creation_date: 2010-11-23 >>>> WG ID: fecframe >>>> Number_of_pages: 21 >>>> >>>> Abstract: >>>> This document describes Fully-Specified Forward Error Correction >>>> (FEC) Schemes for the Raptor and RaptorQ codes and their application >>>> to reliable delivery of media streams in the context of FEC >>>> Framework. =A0The Raptor and RaptorQ codes are systematic codes, where >>>> a number of repair symbols are generated from a set of source symbols >>>> and sent in one or more repair flows in addition to the source >>>> symbols that are sent to the receiver(s) within a source flow. =A0The >>>> Raptor and RaptorQ codes offer close to optimal protection against >>>> arbitrary packet losses at a low computational complexity. =A0Six FEC >>>> Schemes are defined, two for protection of arbitrary packet flows, >>>> two that are optimised for small source blocks and another two for >>>> protection of a single flow that already contains a sequence number. >>>> Repair data may be sent over arbitrary datagram transport (e.g. =A0UDP= ) >>>> or using RTP. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> >>>> --- >>>> Dr. Thomas Stockhammer (CEO) ||=A0stockhammer@nomor.de=A0|| phone +49 = 89 978980 >>>> 02 || cell +491725702667 || http://www.nomor-research.com >>>> Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - Registe= rgericht: >>>> M=FCnchen, HRB 165856 =AD Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf= =FChrer: Dr. >>>> Thomas Stockhammer, Dr. Ingo Viering. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 luby@qualcomm.com Thu Dec 9 10:50:59 2010 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 0576428C122 for ; Thu, 9 Dec 2010 10:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 K4peDLnx-4ag for ; Thu, 9 Dec 2010 10:50:56 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 939D83A68A8 for ; Thu, 9 Dec 2010 10:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1291920746; x=1323456746; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Vi ncent=20Roca=20,=20Marshall=20 Eubanks=0D=0A=09|CC:=20"Ali=20C.=20Be gen=20(abegen)"=20,=20"fecframe@ietf.or g"=0D=0A=09|Date:=20Thu,=209=20Dec=202 010=2010:52:23=20-0800|Subject:=20Re:=20[Fecframe]=20Prop osed=20changes=20to=20the=20framework=20draft=20-=20part =202=0D=0A=20(security)|Thread-Topic:=20[Fecframe]=20Prop osed=20changes=20to=20the=20framework=20draft=20-=20part =202=0D=0A=20(security)|Thread-Index:=20AcuXs+HpdgbhIs36Q VyMH9NdXDN8YQAHlT7j|Message-ID:=20|In-Reply-To:=20<4D00F260.3040509@inrialpes.fr> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.7.0.100913|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=fR67Mc9ttAHata38Oqhq3snITqVEyN5evCEOV1g80w4=; b=yLLlNOuZxcwZ9Eu4vxEsc7O1ikECh0X5ndB4jwFHRbM42Mk5mmReFkFa 6W4s+QkoolbEZYrY0EOpkZZOI2bdzl2/7FGRpRquSZ8VgrZgg4GcjjyRQ Gw54oFs7Cbk2WSc7jG7iErSOiqIIWpRSiJ+w16zssUO3TgWDvCUnzRdPy Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6192"; a="66172008" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 09 Dec 2010 10:52:26 -0800 X-IronPort-AV: E=Sophos;i="4.59,320,1288594800"; d="scan'208";a="35043604" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 09 Dec 2010 10:52:26 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 9 Dec 2010 10:52:26 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Thu, 9 Dec 2010 10:52:21 -0800 From: "Luby, Michael" To: Vincent Roca , Marshall Eubanks Date: Thu, 9 Dec 2010 10:52:23 -0800 Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2 (security) Thread-Index: AcuXs+HpdgbhIs36QVyMH9NdXDN8YQAHlT7j Message-ID: In-Reply-To: <4D00F260.3040509@inrialpes.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 18:50:59 -0000 Some comments below. On 12/9/10 7:14 AM, "Vincent Roca" wrote: > Hello everybody, >=20 > This discussion is interesting. >=20 > I would say that once again the key point here is the "threat model". > If an attacker can get control of the FEC decoding system and does > what Mike suggests, he necessarily has some control of the FECFRAME > endpoint. Two situations need to be considered then: *** Depends on the scenario. This is not necessarily true, although it is = a matter of degree. >=20 > 1/ If this FECFRAME endpoint is the end system (i.e. where the upper > application runs), the attacker can probably do many nasty things, > like modifying the application as well. In that case the two approaches > ("encrypt first, then FEC encode" or "FEC encode first, then encrypt > everything") lead to the same result. I don't see a fundamental > difference in intercepting cleartext at the output of the FECFRAME > module or within the application, at the output of the deciphering > module. *** This is actually an interesting case and one I had in mind, i.e., the end user is the bad guy. This is where the architecture of the end system can be very important, i.e., do things in such a way that it is very difficult for the end user/bad guy to get hold of the plaintext. If the plaintext is available in application space then an end user can possibly hack in and get control. If the plaintext is not available in application space, i.e., there are dedicated protected modules on the end device that the end user does not have access to as the data flows through from decryption to display, then this in a sense protects the plaintext from the bad guy, since it is hard/impossible for the end user to hack in and access the plaintext within the protected modules. If the FEC decoding occurs before the decryption then this architecture is a lot harder to support the= n if FEC decoding occurs before decryption, i.e., if FEC decoding occurs afte= r decryption then the FEC decoding cannot live in application space, it has t= o live in the protected module space, which can be impossible/undesirable/ver= y complicated and expensive. =20 >=20 > 2/ If this FECFRAME endpoint is a middlebox (i.e. the recovered > Source Flow is sent in cleartext to the final remote destination(s)), > in that case the "encrypt first" approach is preferable to the "FEC > encode first" approach. That's obvious! This is why defining the > "threat model" is important. >=20 > In any case, the domains where sensitive data is exchanged in > cleartext MUST be secure (by "exchange" I mean either sent over a > network or communicated between various software modules). > There is nothing specific to FECFRAME IMHO but we can add a > paragraph to highlight it. I'll propose some new text... >=20 > One thing that is FECFRAME specific is the situation where several > flows with different security requirements are globally protected. > This is discussed in Section 9.4. This section may be further > improved. I need to think it over. >=20 > Cheers, >=20 > Vincent >=20 From abegen@cisco.com Thu Dec 9 10:53:26 2010 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 CAD0D3A696E for ; Thu, 9 Dec 2010 10:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.084 X-Spam-Level: X-Spam-Status: No, score=-10.084 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, J_CHICKENPOX_43=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 HFHWX3FL2afT for ; Thu, 9 Dec 2010 10:53:25 -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 897983A68A8 for ; Thu, 9 Dec 2010 10:53:25 -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: AvsEACq0AE2rR7Ht/2dsb2JhbACjfnilCpslAoVIBIRkiS+CbA X-IronPort-AV: E=Sophos;i="4.59,321,1288569600"; d="scan'208";a="633465940" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 09 Dec 2010 18:54:54 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oB9IssfR015087; Thu, 9 Dec 2010 18:54:54 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Dec 2010 10:54:54 -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: Thu, 9 Dec 2010 10:54:44 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D8C1@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Fwd: New Version Notification fordraft-ietf-fecframe-raptor-03 Thread-Index: AcuX0fVt9qRVFseGRFCRXUEqPrCX/AAAIMkg References: From: "Ali C. Begen (abegen)" To: , "Luby, Michael" X-OriginalArrivalTime: 09 Dec 2010 18:54:54.0375 (UTC) FILETIME=[911D8B70:01CB97D2] Cc: fecframe@ietf.org Subject: Re: [Fecframe] Fwd: New Version Notification fordraft-ietf-fecframe-raptor-03 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: Thu, 09 Dec 2010 18:53:26 -0000 I also provided my comments (was right after Mike's actually). And yes, = I approve to go ahead. A revision should be easy. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Greg Shepherd > Sent: Thursday, December 09, 2010 1:50 PM > To: Luby, Michael > Cc: fecframe@ietf.org > Subject: Re: [Fecframe] Fwd: New Version Notification = fordraft-ietf-fecframe-raptor-03 >=20 > Thanks Mike! For some reason your comments did not show in my gmail > threadview... Sorry. >=20 > How about the rest of you? Progress through LC requires consensus. So > far we have Mike and I approving. We need more responses to move on. >=20 > Thanks, > Greg >=20 > On Thu, Dec 9, 2010 at 10:37 AM, Luby, Michael = wrote: > > I provided my detailed comments just before the wglc was made,and I = don't > > have any additional. > > > > > > On 12/9/10 9:44 AM, "Greg Shepherd" wrote: > > > >> WG, > >> > >> We've had good response on the raptor rtp draft but this draft went > >> past the WG last call date and nobody responded, even with an > >> approval. Please respond to this thread regarding this draft. I = can't > >> move this along without WG responses. WG LC will be extended to = allow > >> your responses - Jan 2, 2011. > >> > >> Thanks, > >> Greg > >> > >> On Tue, Nov 23, 2010 at 7:33 AM, Greg Shepherd = wrote: > >>> Thanks Thomas! > >>> > >>> Let's move this along quickly. Consider this WGLC. Please post all > >>> feedback to the list by the end of next week, Fri, Dec 3rd. > >>> > >>> Cheers, > >>> Greg > >>> > >>> On Mon, Nov 22, 2010 at 11:33 PM, Thomas Stockhammer > >>> wrote: > >>>> Experts, > >>>> we have reactivated=A0draft-ietf-fecframe-raptor-03. Highlights = of the changes > >>>> compared to -02 > >>>> - Update of authors > >>>> - Alignment with=A0draft-ietf-rmt-bb-fec-raptorq-04 > >>>> - Some minor editorial updates > >>>> - Updates of references > >>>> Comments from the list had already been integrated in -02. > >>>> I think it is time to get this out of the queue. > >>>> Best regards > >>>> Thomas > >>>> Begin forwarded message: > >>>> > >>>> From: IETF I-D Submission Tool > >>>> Date: November 23, 2010 8:21:48 AM GMT+01:00 > >>>> To: stockhammer@nomor.de > >>>> Cc: watsonm@netflix.com > >>>> Subject: New Version Notification for = draft-ietf-fecframe-raptor-03 > >>>> > >>>> > >>>> A new version of I-D, draft-ietf-fecframe-raptor-03.txt has been > >>>> successfully submitted by Thomas Stockhammer and posted to the = IETF > >>>> repository. > >>>> > >>>> Filename: draft-ietf-fecframe-raptor > >>>> Revision: 03 > >>>> Title: Raptor FEC Schemes for FECFRAME > >>>> Creation_date: 2010-11-23 > >>>> WG ID: fecframe > >>>> Number_of_pages: 21 > >>>> > >>>> Abstract: > >>>> This document describes Fully-Specified Forward Error Correction > >>>> (FEC) Schemes for the Raptor and RaptorQ codes and their = application > >>>> to reliable delivery of media streams in the context of FEC > >>>> Framework. =A0The Raptor and RaptorQ codes are systematic codes, = where > >>>> a number of repair symbols are generated from a set of source = symbols > >>>> and sent in one or more repair flows in addition to the source > >>>> symbols that are sent to the receiver(s) within a source flow. = =A0The > >>>> Raptor and RaptorQ codes offer close to optimal protection = against > >>>> arbitrary packet losses at a low computational complexity. =A0Six = FEC > >>>> Schemes are defined, two for protection of arbitrary packet = flows, > >>>> two that are optimised for small source blocks and another two = for > >>>> protection of a single flow that already contains a sequence = number. > >>>> Repair data may be sent over arbitrary datagram transport (e.g. = =A0UDP) > >>>> or using RTP. > >>>> > >>>> > >>>> > >>>> The IETF Secretariat. > >>>> > >>>> > >>>> > >>>> --- > >>>> Dr. Thomas Stockhammer (CEO) ||=A0stockhammer@nomor.de=A0|| phone = +49 89 978980 > >>>> 02 || cell +491725702667 || http://www.nomor-research.com > >>>> Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - = Registergericht: > >>>> M=FCnchen, HRB 165856 =AD Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. > >>>> Thomas Stockhammer, Dr. Ingo Viering. > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 From abegen@cisco.com Thu Dec 9 10:55:42 2010 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 7FA1C3A696E for ; Thu, 9 Dec 2010 10:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 cs4bFN4PwRqU for ; Thu, 9 Dec 2010 10:55:41 -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 A645C3A6897 for ; Thu, 9 Dec 2010 10:55:41 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIe1AE2rRN+K/2dsb2JhbACjfnilEJsfhUoEhGSJLw X-IronPort-AV: E=Sophos;i="4.59,321,1288569600"; d="scan'208";a="389463412" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 09 Dec 2010 18:57:11 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id oB9IvAXc013483; Thu, 9 Dec 2010 18:57:11 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); Thu, 9 Dec 2010 10:57:11 -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: Thu, 9 Dec 2010 10:55:52 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D8C9@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Operations and Management Considerations (text for the framework) Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAC9Y/6AABk16A= References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Luby, Michael" , X-OriginalArrivalTime: 09 Dec 2010 18:57:11.0181 (UTC) FILETIME=[E2A87BD0:01CB97D2] Subject: Re: [Fecframe] Operations and Management Considerations (text 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: Thu, 09 Dec 2010 18:55:42 -0000 It is not in this section but there is some text about this earlier in = the draft (section 5.3). -acbegen > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Thursday, December 09, 2010 1:44 PM > To: Ali C. Begen (abegen); fecframe@ietf.org > Subject: Re: [Fecframe] Operations and Management Considerations (text = for the framework) >=20 > Is there any discussion I the framework draft (perhaps it would be in = this > section 10) that covers operations and management when you have a = mixed > population of receivers, some that do support FEC and some that do = not? In > such a mixed population there might be certain recommendations for how = to > operate and configure things so that receivers that don't support FEC = are > not disrupted but those that do can benefit from receiving FEC to = enhance > the quality of their service. >=20 >=20 > On 12/9/10 9:30 AM, "Ali C. Begen (abegen)" wrote: >=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. > > > > 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 gjshep@gmail.com Thu Dec 9 11:07:33 2010 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 9660F28C152 for ; Thu, 9 Dec 2010 11:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.03 X-Spam-Level: X-Spam-Status: No, score=-103.03 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, J_CHICKENPOX_43=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 b93OXxh+IE9k for ; Thu, 9 Dec 2010 11:07:29 -0800 (PST) Received: from mail-bw0-f51.google.com (mail-bw0-f51.google.com [209.85.214.51]) by core3.amsl.com (Postfix) with ESMTP id 97CC328C14A for ; Thu, 9 Dec 2010 11:07:28 -0800 (PST) Received: by bwz8 with SMTP id 8so3215284bwz.38 for ; Thu, 09 Dec 2010 11:08:57 -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 :content-transfer-encoding; bh=2Zr/bjQXLzhzdlBtLp5aezZmxuH0Shpnln/ZwMU5TdY=; b=jfjKNcuLZZH/IwOfmcdeI42vLrBnox8Zj/9KFdncc9ajUrFKIgV9gvj3ARF7PVv9Ra u81elvB+ypTexQvJOdSwArthgT/mbm2g8aVwiSr2LUzSuCgTstFBbIDNIAeaHGuu7aBh lJz9EgW/fx+TeEtBubKfe0FtrTRzQ/ckPvJ0k= 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:content-transfer-encoding; b=Ljf4Y7m34y0ft/lb8yo20s66/Z4Iw99p3IxpKm74nsKP2voaB5nnQ7JEtd+V5CiXHJ w5ybqPdnvgSR3a2t6cixXYK+m2I+s7mD+BWonxCmLgPTf6ra7hIgoYIeHvy5sFwvgxNk wEgje6PiQxao5GdQjuuLFYwigQxB3LG8BbtMQ= MIME-Version: 1.0 Received: by 10.204.84.138 with SMTP id j10mr3793303bkl.131.1291921737535; Thu, 09 Dec 2010 11:08:57 -0800 (PST) Received: by 10.204.80.6 with HTTP; Thu, 9 Dec 2010 11:08:57 -0800 (PST) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D8C1@xmb-sjc-215.amer.cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D8C1@xmb-sjc-215.amer.cisco.com> Date: Thu, 9 Dec 2010 11:08:57 -0800 Message-ID: From: Greg Shepherd To: "Ali C. Begen (abegen)" , fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Fecframe] Fwd: New Version Notification fordraft-ietf-fecframe-raptor-03 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: Thu, 09 Dec 2010 19:07:33 -0000 That's 3. Others please chime in. Greg On Thu, Dec 9, 2010 at 10:54 AM, Ali C. Begen (abegen) w= rote: > I also provided my comments (was right after Mike's actually). And yes, I= approve to go ahead. A revision should be easy. > > -acbegen > >> -----Original Message----- >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Be= half Of Greg Shepherd >> Sent: Thursday, December 09, 2010 1:50 PM >> To: Luby, Michael >> Cc: fecframe@ietf.org >> Subject: Re: [Fecframe] Fwd: New Version Notification fordraft-ietf-fecf= rame-raptor-03 >> >> Thanks Mike! For some reason your comments did not show in my gmail >> threadview... Sorry. >> >> How about the rest of you? Progress through LC requires consensus. So >> far we have Mike and I approving. We need more responses to move on. >> >> Thanks, >> Greg >> >> On Thu, Dec 9, 2010 at 10:37 AM, Luby, Michael wrote= : >> > I provided my detailed comments just before the wglc was made,and I do= n't >> > have any additional. >> > >> > >> > On 12/9/10 9:44 AM, "Greg Shepherd" wrote: >> > >> >> WG, >> >> >> >> We've had good response on the raptor rtp draft but this draft went >> >> past the WG last call date and nobody responded, even with an >> >> approval. Please respond to this thread regarding this draft. I can't >> >> move this along without WG responses. WG LC will be extended to allow >> >> your responses - Jan 2, 2011. >> >> >> >> Thanks, >> >> Greg >> >> >> >> On Tue, Nov 23, 2010 at 7:33 AM, Greg Shepherd wro= te: >> >>> Thanks Thomas! >> >>> >> >>> Let's move this along quickly. Consider this WGLC. Please post all >> >>> feedback to the list by the end of next week, Fri, Dec 3rd. >> >>> >> >>> Cheers, >> >>> Greg >> >>> >> >>> On Mon, Nov 22, 2010 at 11:33 PM, Thomas Stockhammer >> >>> wrote: >> >>>> Experts, >> >>>> we have reactivated=A0draft-ietf-fecframe-raptor-03. Highlights of = the changes >> >>>> compared to -02 >> >>>> - Update of authors >> >>>> - Alignment with=A0draft-ietf-rmt-bb-fec-raptorq-04 >> >>>> - Some minor editorial updates >> >>>> - Updates of references >> >>>> Comments from the list had already been integrated in -02. >> >>>> I think it is time to get this out of the queue. >> >>>> Best regards >> >>>> Thomas >> >>>> Begin forwarded message: >> >>>> >> >>>> From: IETF I-D Submission Tool >> >>>> Date: November 23, 2010 8:21:48 AM GMT+01:00 >> >>>> To: stockhammer@nomor.de >> >>>> Cc: watsonm@netflix.com >> >>>> Subject: New Version Notification for draft-ietf-fecframe-raptor-03 >> >>>> >> >>>> >> >>>> A new version of I-D, draft-ietf-fecframe-raptor-03.txt has been >> >>>> successfully submitted by Thomas Stockhammer and posted to the IETF >> >>>> repository. >> >>>> >> >>>> Filename: draft-ietf-fecframe-raptor >> >>>> Revision: 03 >> >>>> Title: Raptor FEC Schemes for FECFRAME >> >>>> Creation_date: 2010-11-23 >> >>>> WG ID: fecframe >> >>>> Number_of_pages: 21 >> >>>> >> >>>> Abstract: >> >>>> This document describes Fully-Specified Forward Error Correction >> >>>> (FEC) Schemes for the Raptor and RaptorQ codes and their applicatio= n >> >>>> to reliable delivery of media streams in the context of FEC >> >>>> Framework. =A0The Raptor and RaptorQ codes are systematic codes, wh= ere >> >>>> a number of repair symbols are generated from a set of source symbo= ls >> >>>> and sent in one or more repair flows in addition to the source >> >>>> symbols that are sent to the receiver(s) within a source flow. =A0T= he >> >>>> Raptor and RaptorQ codes offer close to optimal protection against >> >>>> arbitrary packet losses at a low computational complexity. =A0Six F= EC >> >>>> Schemes are defined, two for protection of arbitrary packet flows, >> >>>> two that are optimised for small source blocks and another two for >> >>>> protection of a single flow that already contains a sequence number= . >> >>>> Repair data may be sent over arbitrary datagram transport (e.g. =A0= UDP) >> >>>> or using RTP. >> >>>> >> >>>> >> >>>> >> >>>> The IETF Secretariat. >> >>>> >> >>>> >> >>>> >> >>>> --- >> >>>> Dr. Thomas Stockhammer (CEO) ||=A0stockhammer@nomor.de=A0|| phone += 49 89 978980 >> >>>> 02 || cell +491725702667 || http://www.nomor-research.com >> >>>> Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - Regi= stergericht: >> >>>> M=FCnchen, HRB 165856 =AD Umsatzsteuer-ID: DE238047637 - Gesch=E4ft= sf=FChrer: Dr. >> >>>> Thomas Stockhammer, Dr. Ingo Viering. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> 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 > From luby@qualcomm.com Thu Dec 9 12:22:54 2010 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 09D3D3A6BBB for ; Thu, 9 Dec 2010 12:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 K8RhdAbJ2iNO for ; Thu, 9 Dec 2010 12:22:49 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B520C3A6BB8 for ; Thu, 9 Dec 2010 12:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1291926260; x=1323462260; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"A li=20C.=20Begen=20(abegen)"=20,=20"fecf rame@ietf.org"=0D=0A=09|Date:=20Thu, =209=20Dec=202010=2012:24:14=20-0800|Subject:=20Re:=20[Fe cframe]=20Operations=20and=20Management=20Considerations =20(text=20for=0D=0A=20the=20framework)|Thread-Topic:=20[ Fecframe]=20Operations=20and=20Management=20Consideration s=20(text=20for=0D=0A=20the=20framework)|Thread-Index:=20 AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAC9Y/6AABk16AAAx3aug=3D=3D |Message-ID:=20 |In-Reply-To:=20<04CAD96D4C5A3D48B1919248A8FE0D540DE2D8C9 @xmb-sjc-215.amer.cisco.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|user-agent:=20Microsoft-Entourage/ 13.7.0.100913|acceptlanguage:=20en-US|Content-Type:=20tex t/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=tXDheR2lFsT49jyFCYS4XhMvHHm3Zt6RPHBTCVjltbI=; b=QmhYjNUyzdjptcEOg19U3+iAkvGH+zC7fWZB839WMXyK9sQgAbCZL49j JOohwWQLyBtp5lVe32q1MVUjhCplFZP9xM+Ov8Qo4IJK+Z7gB6yGeZuZd VXcX4oWbhSqNHe175I6Yg69pJ1vFmMuLsVitGW6F44rBnMa4DDPddoYAL w=; X-IronPort-AV: E=McAfee;i="5400,1158,6192"; a="66186132" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 09 Dec 2010 12:24:18 -0800 X-IronPort-AV: E=Sophos;i="4.59,320,1288594800"; d="scan'208";a="16959977" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 09 Dec 2010 12:24:17 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 9 Dec 2010 12:24:16 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Thu, 9 Dec 2010 12:24:09 -0800 From: "Luby, Michael" To: "Ali C. Begen (abegen)" , "fecframe@ietf.org" Date: Thu, 9 Dec 2010 12:24:14 -0800 Thread-Topic: [Fecframe] Operations and Management Considerations (text for the framework) Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAC9Y/6AABk16AAAx3aug== Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D8C9@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Fecframe] Operations and Management Considerations (text 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: Thu, 09 Dec 2010 20:22:54 -0000 Since this affects operations and management, should this issue be at least mentioned in the operations and management section (with perhaps a pointer to section 5.3 if that section describes the issues and solutions well enough?) On 12/9/10 10:55 AM, "Ali C. Begen (abegen)" wrote: > It is not in this section but there is some text about this earlier in th= e > draft (section 5.3). >=20 > -acbegen >=20 >> -----Original Message----- >> From: Luby, Michael [mailto:luby@qualcomm.com] >> Sent: Thursday, December 09, 2010 1:44 PM >> To: Ali C. Begen (abegen); fecframe@ietf.org >> Subject: Re: [Fecframe] Operations and Management Considerations (text f= or >> the framework) >>=20 >> Is there any discussion I the framework draft (perhaps it would be in th= is >> section 10) that covers operations and management when you have a mixed >> population of receivers, some that do support FEC and some that do not? = In >> such a mixed population there might be certain recommendations for how t= o >> operate and configure things so that receivers that don't support FEC ar= e >> not disrupted but those that do can benefit from receiving FEC to enhanc= e >> the quality of their service. >>=20 >>=20 >> On 12/9/10 9:30 AM, "Ali C. Begen (abegen)" wrote: >>=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 comme= nts, >>> please send them to the list. >>>=20 >>> Otherwise, we are waiting for the AD to give us a green light to move a= head >>> 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 o= f >>> feedback from receivers (e.g., broadcast), while some of them may >>> collect detailed feedback (in case it is a one-to-one application) o= r >>> 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 collectin= g >>> 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 work= s >>> 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 goal= s >>> of the FEC Framework. >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >=20 From stockhammer@nomor.de Thu Dec 9 12:26:50 2010 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 C179C3A6B4F for ; Thu, 9 Dec 2010 12:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 VJLqeCfiZmgi for ; Thu, 9 Dec 2010 12:26:49 -0800 (PST) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id 290113A69B3 for ; Thu, 9 Dec 2010 12:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1291926498; l=10284; s=domk; d=nomor.de; h=Mime-Version:To:References:Date:Subject:Content-Type:From: X-RZG-CLASS-ID:X-RZG-AUTH; bh=fIcvLZY3j3ccgIZH6VcJTcxnl6g=; b=s08TCgo8mcwDg4DjT5YrpKyysawzeUrDDDZIwqhwUdjEdh1fEt21m+GffeN1OUJ6VgT Yu7zwDRjKrJ4w45l+lA8d3hmlG7gebmUVN8a1UytSQKYHNwZwJ0aKv0hdyohW6iIoEFdc lonBwtPMpOP/r8twXS7lia6GQKaG6aHY5oA= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+0wBefkJA5cHz4sK4A== X-RZG-CLASS-ID: mo00 Received: from [10.0.1.3] (91-67-202-136-dynip.superkabel.de [91.67.202.136]) by post.strato.de (klopstock mo55) (RZmta 24.8) with ESMTP id y061e9mB9JEfKX for ; Thu, 9 Dec 2010 21:28:15 +0100 (MET) From: Thomas Stockhammer Content-Type: multipart/alternative; boundary=Apple-Mail-2-86682241 Date: Thu, 9 Dec 2010 21:28:14 +0100 References: <20101209202253.064D43A6BC2@core3.amsl.com> To: fecframe@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Fecframe] Fwd: New Version Notification for draft-ietf-fecframe-raptor-04 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: Thu, 09 Dec 2010 20:26:50 -0000 --Apple-Mail-2-86682241 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All, we have updated draft-ietf-fecframe-raptor-04. Highlights of the changes = compared to -03 - Update of authors - Integrated nits received from Mike Luby=20 - Integrated comments received from Ali Begen - Some minor editorial updates - Updates of references I think it is time to get this out of the queue. Best regards Thomas Begin forwarded message: > From: IETF I-D Submission Tool > Date: December 9, 2010 9:22:53 PM GMT+01:00 > To: stockhammer@nomor.de > Cc: watsonm@netflix.com, luby@qualcomm.com > Subject: New Version Notification for draft-ietf-fecframe-raptor-04=20 >=20 >=20 > A new version of I-D, draft-ietf-fecframe-raptor-04.txt has been = successfully submitted by Thomas Stockhammer and posted to the IETF = repository. >=20 > Filename: draft-ietf-fecframe-raptor > Revision: 04 > Title: Raptor FEC Schemes for FECFRAME > Creation_date: 2010-12-09 > WG ID: fecframe > Number_of_pages: 21 >=20 > Abstract: > This document describes Fully-Specified Forward Error Correction > (FEC) Schemes for the Raptor and RaptorQ codes and their application > to reliable delivery of media streams in the context of FEC > Framework. The Raptor and RaptorQ codes are systematic codes, where > a number of repair symbols are generated from a set of source symbols > and sent in one or more repair flows in addition to the source > symbols that are sent to the receiver(s) within a source flow. The > Raptor and RaptorQ codes offer close to optimal protection against > arbitrary packet losses at a low computational complexity. Six FEC > Schemes are defined, two for protection of arbitrary packet flows, > two that are optimised for small source blocks and another two for > protection of a single flow that already contains a sequence number. > Repair data may be sent over arbitrary datagram transport (e.g. UDP) > or using RTP. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. --Apple-Mail-2-86682241 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: IETF I-D Submission = Tool <idsubmission@ietf.org>
Date: December 9, 2010 9:22:53 PM = GMT+01:00
To: stockhammer@nomor.de
Subject: New Version = Notification for draft-ietf-fecframe-raptor-04 =


A new version of I-D, = draft-ietf-fecframe-raptor-04.txt has been successfully submitted by = Thomas Stockhammer and posted to the IETF = repository.

Filename: = draft-ietf-fecframe-raptor
Revision: 04
Title: Raptor = FEC Schemes for FECFRAME
Creation_date: 2010-12-09
WG ID: = fecframe
Number_of_pages: 21

Abstract:
This document = describes Fully-Specified Forward Error Correction
(FEC) Schemes for = the Raptor and RaptorQ codes and their application
to reliable = delivery of media streams in the context of FEC
Framework.  The = Raptor and RaptorQ codes are systematic codes, where
a number of = repair symbols are generated from a set of source symbols
and sent in = one or more repair flows in addition to the source
symbols that are = sent to the receiver(s) within a source flow.  The
Raptor and = RaptorQ codes offer close to optimal protection against
arbitrary = packet losses at a low computational complexity.  Six = FEC
Schemes are defined, two for protection of arbitrary packet = flows,
two that are optimised for small source blocks and another two = for
protection of a single flow that already contains a sequence = number.
Repair data may be sent over arbitrary datagram transport = (e.g.  UDP)
or using RTP.



The IETF = Secretariat.



stockhammer@nomor.de || = phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz = der Gesellschaft: M=FCnchen - Registergericht: M=FCnchen, HRB 165856 =96 = Umsatzsteuer-ID: DE238047637 - Gesch=E4ftsf=FChrer: Dr. Thomas = Stockhammer, Dr. Ingo Viering.



= --Apple-Mail-2-86682241-- From luby@qualcomm.com Thu Dec 9 12:27:01 2010 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 41B113A6B4F for ; Thu, 9 Dec 2010 12:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3LVGdQo38q7F for ; Thu, 9 Dec 2010 12:26:59 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id ABE7C3A69B3 for ; Thu, 9 Dec 2010 12:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1291926510; x=1323462510; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"A li=20C.=20Begen=20(abegen)"=20|CC:=20"f ecframe@ietf.org"=20|Date:=20Thu,=209 =20Dec=202010=2012:28:25=20-0800|Subject:=20Re:=20[Fecfra me]=20Proposed=20changes=20to=20the=20framework=20draft =20-=20part=0D=0A=202(security)|Thread-Topic:=20[Fecframe ]=20Proposed=20changes=20to=20the=20framework=20draft=20- =20part=0D=0A=202(security)|Thread-Index:=20AcuXVnkcT+unc 0QwRYqsQgrMi5okWwAV/EKQAAxNymc=3D|Message-ID:=20|In-Reply-To:=20<04CAD96D4C5A3D48 B1919248A8FE0D540DE2D7C7@xmb-sjc-215.amer.cisco.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.7.0.100913|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=oOXoMqU4EEXMBbm2LnVYPuK7TyclF7cVZcGLG8b8txg=; b=loBSLUP1PnB4STL4I3iRY8/G2OIBUsirdmB+9sjVMpAghGeVnpxTMUZI muPiZjDVr8XBlRIwhnF6FuWhxVDWBpzmn3npXCjYwQz4tUx3c4Fv0leCP JEL9AmmfBY32kqbSz1OUfoxnOBVFcYZDAWqXheDFMNKVzhtwRZuMhQNYE Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6192"; a="66186465" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 09 Dec 2010 12:28:29 -0800 X-IronPort-AV: E=Sophos;i="4.59,320,1288594800"; d="scan'208";a="99163942" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 09 Dec 2010 12:28:28 -0800 Received: from nasanexhc04.na.qualcomm.com (172.30.48.17) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.3.83.0; Thu, 9 Dec 2010 12:28:29 -0800 Received: from nasclexhc02.na.qualcomm.com (172.30.48.1) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 9 Dec 2010 12:28:27 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Thu, 9 Dec 2010 12:28:20 -0800 From: "Luby, Michael" To: "Ali C. Begen (abegen)" Date: Thu, 9 Dec 2010 12:28:25 -0800 Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2(security) Thread-Index: AcuXVnkcT+unc0QwRYqsQgrMi5okWwAV/EKQAAxNymc= Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D7C7@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 20:27:01 -0000 This seems good. The only thing perhaps worth adding is that in some cases there may be encryption both before and after FEC encoding (and corresponding operations on the receiver side), since the encryption might be serving different purposes and have different associated trust models. Not a big change to the below, but right now it reads as if though you can/should only do one encryption, and I think it should just be a bit more lenient on this point. On 12/9/10 6:37 AM, "Ali C. Begen (abegen)" wrote: > Here is the revised text: >=20 > Note that when encryption is applied, this encryption MUST either be appl= ied > on the FEC source packets before the FEC protection, or if done after the= FEC > protection, then both the FEC source packets and repair packets MUST be > applied encryption (and an encryption at least as cryptographically secur= e 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 th= e FEC > source packets after FEC encoding, then a non-authorized receiver could b= e > able to recover the source data after decoding the repair packets provide= d > that a sufficient number of such packets were available. > =20 > The following considerations apply when choosing where to apply encryptio= n. If > encryption is applied after FEC encoding on the FEC source and repair pac= kets, > decryption will take place before FEC decoding. Since the source and repa= ir > data will be in plaintext at this point, the subsequent FEC decoding > operations MUST occur in a trusted environment. Conversely, if encryption= is > applied before FEC encoding on the FEC source packets only, the decryptio= n > will take place after FEC decoding. Thus, the FEC decoding operations do = not > have to occur in a trusted environment. >=20 > -acbegen >=20 >> -----Original Message----- >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Be= half >> Of Ali C. Begen (abegen) >> Sent: Wednesday, December 08, 2010 11:07 PM >> To: Luby, Michael >> Cc: fecframe@ietf.org >> Subject: Re: [Fecframe] Proposed changes to the framework draft - part >> 2(security) >>=20 >> Ok got it. Will summarize this after the text below. Thanks for the note= . >>=20 >> -acbegen >>=20 >> On Dec 8, 2010, at 10:53 PM, "Luby, Michael" wrote: >>=20 >>> I don't think I made the issue very clear, so let me try again. The is= sue >>> is that if decryption happens before FEC decoding then since the media = is in >>> plaintext at this point, the FEC decoding operations must occur in a tr= usted >>> environment, since if a bad guy can control or have access to the proce= ss >>> that does the FEC decoding then the bad guy can steal the original medi= a. >>> If instead decryption happens after FEC decoding then the FEC is operat= ing >>> on ciphertext, so the FEC decoding operations don't have to occur in a >>> trusted environment, since if a bad buy can control or have access to t= he >>> process that does the FEC decoding then the bad guy is only able to ste= al >>> encrypted media. >>>=20 >>> Perhaps rewording the above appropriately and making this clear is enou= gh. >>> In any case, it is an extra security risk unique to FEC in this context= . >>>=20 >>>=20 >>> On 12/8/10 7:41 PM, "Marshall Eubanks" wrote: >>>=20 >>>>=20 >>>> On Dec 8, 2010, at 9:32 PM, Ali C. Begen (abegen) wrote: >>>>=20 >>>>> I got Vincent's additional text into the revision. Regarding your que= stion >>>>> below: >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Luby, Michael [mailto:luby@qualcomm.com] >>>>>> Sent: Wednesday, December 08, 2010 7:20 PM >>>>>> To: Vincent Roca; Ali C. Begen (abegen) >>>>>> Cc: Greg Shepherd; fecframe@ietf.org; Luby, Michael >>>>>> Subject: Re: [Fecframe] Proposed changes to the framework draft - pa= rt 2 >>>>>> (security) >>>>>>=20 >>>>>> Thanks Vincent, this is all fine. One other thing: does the securit= y >>>>>> part >>>>>> of the document say anything about the order in which FEC >>>>>> encoding/decoding >>>>>> is performed relative to security/encryption? This is one issue tha= t is >>>>>> specific to FECFRAME, and that is whether encryption should be appli= ed >>>>>> before/after FEC encoding at the sender and whether decryption shoul= d be >>>>>> applied after/before FEC decoding at the receiver. Does it make sen= se to >>>>>> recommend the former over the latter, as if the latter is used then = the >>>>>> FEC >>>>>> decoding would have to be done in a trusted environment to uphold >>>>>> commonly >>>>>> desired security properties, which could be quite a burden in many >>>>>> architectures? >>>>>=20 >>>>> The current text (in the revision to be submitted soon) says: >>>>>=20 >>>>> >>>>> Note that when encryption is applied, this encryption MUST either be >>>>> applied >>>>> before the FEC protection, or, if done after the FEC protection, then= this >>>>> encryption MUST be applied on both the FEC source packets and repair >>>>> packets. >>>>> Otherwise, if encryption were to be performed only on the FEC source >>>>> packets >>>>> after FEC encoding, then a non-authorized receiver could be able to >>>>> recover >>>>> the source data after decoding the repair packets provided that a >>>>> sufficient >>>>> number of such packets were available. >>>>> >>>>>=20 >>>>> So, we mention both possibilities but do not recommend one over the o= ther. >>>>> I >>>>> think the text here is sufficient to say that doing encryption after = fec >>>>> encoding also requires encrypting the FEC packets (which is clearly a= n >>>>> additional task which could have been avoided otherwise). Does this >>>>> require >>>>> further text? >>>>=20 >>>> I think that this text is very reasonable. WFM. >>>>=20 >>>> Regards >>>> Marshall >>>>=20 >>>>=20 >>>>>=20 >>>>> -acbegen >>>>> _______________________________________________ >>>>> Fecframe mailing list >>>>> Fecframe@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/fecframe >>>>>=20 >>>>=20 >>>=20 >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe From Internet-Drafts@ietf.org Thu Dec 9 12:30:03 2010 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 25A003A6B4F; Thu, 9 Dec 2010 12:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.373 X-Spam-Level: X-Spam-Status: No, score=-102.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 tNsXc130Sm0E; Thu, 9 Dec 2010 12:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5443A69B3; Thu, 9 Dec 2010 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: <20101209203001.4665.56221.idtracker@localhost> Date: Thu, 09 Dec 2010 12:30:01 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-raptor-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: Thu, 09 Dec 2010 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 : Raptor FEC Schemes for FECFRAME Author(s) : M. Watson, et al. Filename : draft-ietf-fecframe-raptor-04.txt Pages : 21 Date : 2010-12-09 This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined, two for protection of arbitrary packet flows, two that are optimised for small source blocks and another two for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-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-raptor-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-09122252.I-D@ietf.org> --NextPart-- From abegen@cisco.com Thu Dec 9 12:43:14 2010 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 BAB533A6BC3 for ; Thu, 9 Dec 2010 12:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.386 X-Spam-Level: X-Spam-Status: No, score=-10.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 pmzsIamEzeZj for ; Thu, 9 Dec 2010 12:43:12 -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 408113A6BC2 for ; Thu, 9 Dec 2010 12:43:12 -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: AvsEAF/OAE2rR7Hu/2dsb2JhbACjf3ikeZsPhUoEhGSJLw X-IronPort-AV: E=Sophos;i="4.59,322,1288569600"; d="scan'208";a="230330170" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 09 Dec 2010 20:44:36 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oB9KiaEW027097; Thu, 9 Dec 2010 20:44:36 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); Thu, 9 Dec 2010 12:44:36 -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: Thu, 9 Dec 2010 12:44:22 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D94C@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2(security) Thread-Index: AcuXVnkcT+unc0QwRYqsQgrMi5okWwAV/EKQAAxNymcAAIzrAA== References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D7C7@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Luby, Michael" X-OriginalArrivalTime: 09 Dec 2010 20:44:36.0235 (UTC) FILETIME=[E435ADB0:01CB97E1] 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 20:43:14 -0000 Good point, done. -acbegen > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Thursday, December 09, 2010 3:28 PM > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org > Subject: Re: [Fecframe] Proposed changes to the framework draft - part = 2(security) >=20 > This seems good. The only thing perhaps worth adding is that in some = cases > there may be encryption both before and after FEC encoding (and > corresponding operations on the receiver side), since the encryption = might > be serving different purposes and have different associated trust = models. > Not a big change to the below, but right now it reads as if though you > can/should only do one encryption, and I think it should just be a bit = more > lenient on this point. >=20 >=20 > On 12/9/10 6:37 AM, "Ali C. Begen (abegen)" wrote: >=20 > > Here is the revised text: > > > > Note that when encryption is applied, this encryption MUST either be = applied > > on the FEC source packets before the FEC protection, or if done = after the FEC > > protection, then both the FEC source packets and repair packets MUST = be > > applied encryption (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, then a non-authorized receiver = could be > > able to recover the source data after decoding the repair packets = provided > > that a sufficient number of such packets were available. > > > > The following considerations apply when choosing where to apply = encryption. If > > encryption is applied after FEC encoding on the FEC source and = repair packets, > > decryption will take place before FEC decoding. Since the source and = repair > > data will be in plaintext at this point, the subsequent FEC decoding > > operations MUST occur in a trusted environment. Conversely, if = encryption is > > applied before FEC encoding on the FEC source packets only, the = decryption > > will take place after FEC decoding. Thus, the FEC decoding = operations do not > > have to occur in a trusted environment. > > > > -acbegen > > > >> -----Original Message----- > >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] = On Behalf > >> Of Ali C. Begen (abegen) > >> Sent: Wednesday, December 08, 2010 11:07 PM > >> To: Luby, Michael > >> Cc: fecframe@ietf.org > >> Subject: Re: [Fecframe] Proposed changes to the framework draft - = part > >> 2(security) > >> > >> Ok got it. Will summarize this after the text below. Thanks for the = note. > >> > >> -acbegen > >> > >> On Dec 8, 2010, at 10:53 PM, "Luby, Michael" = wrote: > >> > >>> I don't think I made the issue very clear, so let me try again. = The issue > >>> is that if decryption happens before FEC decoding then since the = media is in > >>> plaintext at this point, the FEC decoding operations must occur in = a trusted > >>> environment, since if a bad guy can control or have access to the = process > >>> that does the FEC decoding then the bad guy can steal the original = media. > >>> If instead decryption happens after FEC decoding then the FEC is = operating > >>> on ciphertext, so the FEC decoding operations don't have to occur = in a > >>> trusted environment, since if a bad buy can control or have access = to the > >>> process that does the FEC decoding then the bad guy is only able = to steal > >>> encrypted media. > >>> > >>> Perhaps rewording the above appropriately and making this clear is = enough. > >>> In any case, it is an extra security risk unique to FEC in this = context. > >>> > >>> > >>> On 12/8/10 7:41 PM, "Marshall Eubanks" wrote: > >>> > >>>> > >>>> On Dec 8, 2010, at 9:32 PM, Ali C. Begen (abegen) wrote: > >>>> > >>>>> I got Vincent's additional text into the revision. Regarding = your question > >>>>> below: > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Luby, Michael [mailto:luby@qualcomm.com] > >>>>>> Sent: Wednesday, December 08, 2010 7:20 PM > >>>>>> To: Vincent Roca; Ali C. Begen (abegen) > >>>>>> Cc: Greg Shepherd; fecframe@ietf.org; Luby, Michael > >>>>>> Subject: Re: [Fecframe] Proposed changes to the framework draft = - part 2 > >>>>>> (security) > >>>>>> > >>>>>> Thanks Vincent, this is all fine. One other thing: does the = security > >>>>>> part > >>>>>> of the document say anything about the order in which FEC > >>>>>> encoding/decoding > >>>>>> is performed relative to security/encryption? This is one = issue that is > >>>>>> specific to FECFRAME, and that is whether encryption should be = applied > >>>>>> before/after FEC encoding at the sender and whether decryption = should be > >>>>>> applied after/before FEC decoding at the receiver. Does it = make sense to > >>>>>> recommend the former over the latter, as if the latter is used = then the > >>>>>> FEC > >>>>>> decoding would have to be done in a trusted environment to = uphold > >>>>>> commonly > >>>>>> desired security properties, which could be quite a burden in = many > >>>>>> architectures? > >>>>> > >>>>> The current text (in the revision to be submitted soon) says: > >>>>> > >>>>> > >>>>> Note that when encryption is applied, this encryption MUST = either be > >>>>> applied > >>>>> before the FEC protection, or, if done after the FEC protection, = then this > >>>>> encryption MUST be applied on both the FEC source packets and = repair > >>>>> packets. > >>>>> Otherwise, if encryption were to be performed only on the FEC = source > >>>>> packets > >>>>> after FEC encoding, then a non-authorized receiver could be able = to > >>>>> recover > >>>>> the source data after decoding the repair packets provided that = a > >>>>> sufficient > >>>>> number of such packets were available. > >>>>> > >>>>> > >>>>> So, we mention both possibilities but do not recommend one over = the other. > >>>>> I > >>>>> think the text here is sufficient to say that doing encryption = after fec > >>>>> encoding also requires encrypting the FEC packets (which is = clearly an > >>>>> additional task which could have been avoided otherwise). Does = this > >>>>> require > >>>>> further text? > >>>> > >>>> I think that this text is very reasonable. WFM. > >>>> > >>>> Regards > >>>> Marshall > >>>> > >>>> > >>>>> > >>>>> -acbegen > >>>>> _______________________________________________ > >>>>> 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 Thu Dec 9 13:04:47 2010 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 B8DFD3A6BC5 for ; Thu, 9 Dec 2010 13:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.39 X-Spam-Level: X-Spam-Status: No, score=-10.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 i9XryWkh87IJ for ; Thu, 9 Dec 2010 13:04:46 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C93203A6BCB for ; Thu, 9 Dec 2010 13:04:46 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA/TAE2rRN+J/2dsb2JhbACjf3ilFpsShUoEhGSJLw X-IronPort-AV: E=Sophos;i="4.59,322,1288569600"; d="scan'208";a="296893755" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 09 Dec 2010 21:06:17 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oB9L6Gwv003638; Thu, 9 Dec 2010 21:06:17 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); Thu, 9 Dec 2010 13:06:16 -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: Thu, 9 Dec 2010 13:05:59 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D96B@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Operations and Management Considerations (text for the framework) Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAC9Y/6AABk16AAAx3augABc0JQ References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D8C9@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Luby, Michael" , X-OriginalArrivalTime: 09 Dec 2010 21:06:16.0811 (UTC) FILETIME=[EB69D3B0:01CB97E4] Subject: Re: [Fecframe] Operations and Management Considerations (text 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: Thu, 09 Dec 2010 21:04:47 -0000 > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Thursday, December 09, 2010 3:24 PM > To: Ali C. Begen (abegen); fecframe@ietf.org > Subject: Re: [Fecframe] Operations and Management Considerations (text = for the framework) >=20 > Since this affects operations and management, should this issue be at = least > mentioned in the operations and management section (with perhaps a = pointer > to section 5.3 if that section describes the issues and solutions well > enough?) Done. Thanks. -acbegen From robertof@radvision.com Fri Dec 10 02:53:03 2010 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 C94513A6AC8 for ; Fri, 10 Dec 2010 02:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Hb9xn1lNuN4G for ; Fri, 10 Dec 2010 02:53:03 -0800 (PST) Received: from rvuk-mail.RADVISION.com (rvuk-mail.radvision.com [88.211.26.131]) by core3.amsl.com (Postfix) with ESMTP id BE8673A6CA5 for ; Fri, 10 Dec 2010 02:53:02 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Dec 2010 10:53:29 -0000 Message-ID: <04EA7BA4E1E2984C91FDCF52260BCE4363FB1D@rvuk-mail.RADVISION.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Adopt? Thread-Index: AcuXyY/vhlz91uKqSyqd1/JUMgvhswAjkTWg References: From: "Roberto Flaiani" To: , 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: Fri, 10 Dec 2010 10:53:03 -0000 I support the three drafts below going forward as WG items. Each application has its own requirements in terms of FEC complexity, delay and degree of protection, so it is important to have a choice of multiple FEC schemes to choose from. Roberto Flaiani RADVISION -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd Sent: Thursday, December 09, 2010 6: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 From vincent.roca@inrialpes.fr Fri Dec 10 03:39:34 2010 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 97B0A3A6ADA for ; Fri, 10 Dec 2010 03:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 MFHTcq+xZClS for ; Fri, 10 Dec 2010 03:39:33 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id C692C3A6AC9 for ; Fri, 10 Dec 2010 03:39:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,323,1288566000"; d="scan'208";a="70278176" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 10 Dec 2010 12:41:03 +0100 Message-ID: <4D0211CE.8020600@inrialpes.fr> Date: Fri, 10 Dec 2010 12:41:02 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Luby, Michael" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 11:39:34 -0000 Mike, I agree with your comments: with certain use-cases, having encryption below FECFRAME may be unpractical. Thanks for the clarification. So here is some new text, for section 9.2.1 "Access to Confidential Content". It encompasses (and modifies) the new paragraphs sent by Ali yesterday. A related question: does it still make sense to have the baseline Secure FEC Framework Operation rely on IPsec/ESP (i.e. below FECFRAME) (section 9.5) since we know it won't match some use-case requirements? Alternatively, should we select SRTP, for instance (or something else)? My point is that since FECFRAME can be used with applications that do not generate RTP flows, IPsec/ESP makes more sense than SRTP. Cheers, Vincent 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. source data /VR> Note that when encryption is required, 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, then 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 FECFRAME 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 FECFRAME), 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 preferable. When the FECFRAME endpoint is a middlebox, the recovered Source Flow, after FEC decoding, SHOULD NOT be sent in plaintext to the final remote destination(s) if the threat model includes the possibility that an attacker eavesdrops the traffic. In that case also it is preferable to apply encryption before FEC protection. On 09/12/10 19:52, Luby, Michael wrote: > Some comments below. > > > On 12/9/10 7:14 AM, "Vincent Roca" wrote: > >> Hello everybody, >> >> This discussion is interesting. >> >> I would say that once again the key point here is the "threat model". >> If an attacker can get control of the FEC decoding system and does >> what Mike suggests, he necessarily has some control of the FECFRAME >> endpoint. Two situations need to be considered then: > *** Depends on the scenario. This is not necessarily true, although it is a > matter of degree. > >> 1/ If this FECFRAME endpoint is the end system (i.e. where the upper >> application runs), the attacker can probably do many nasty things, >> like modifying the application as well. In that case the two approaches >> ("encrypt first, then FEC encode" or "FEC encode first, then encrypt >> everything") lead to the same result. I don't see a fundamental >> difference in intercepting cleartext at the output of the FECFRAME >> module or within the application, at the output of the deciphering >> module. > *** This is actually an interesting case and one I had in mind, i.e., the > end user is the bad guy. This is where the architecture of the end system > can be very important, i.e., do things in such a way that it is very > difficult for the end user/bad guy to get hold of the plaintext. If the > plaintext is available in application space then an end user can possibly > hack in and get control. If the plaintext is not available in application > space, i.e., there are dedicated protected modules on the end device that > the end user does not have access to as the data flows through from > decryption to display, then this in a sense protects the plaintext from the > bad guy, since it is hard/impossible for the end user to hack in and access > the plaintext within the protected modules. If the FEC decoding occurs > before the decryption then this architecture is a lot harder to support then > if FEC decoding occurs before decryption, i.e., if FEC decoding occurs after > decryption then the FEC decoding cannot live in application space, it has to > live in the protected module space, which can be impossible/undesirable/very > complicated and expensive. > >> 2/ If this FECFRAME endpoint is a middlebox (i.e. the recovered >> Source Flow is sent in cleartext to the final remote destination(s)), >> in that case the "encrypt first" approach is preferable to the "FEC >> encode first" approach. That's obvious! This is why defining the >> "threat model" is important. >> >> In any case, the domains where sensitive data is exchanged in >> cleartext MUST be secure (by "exchange" I mean either sent over a >> network or communicated between various software modules). >> There is nothing specific to FECFRAME IMHO but we can add a >> paragraph to highlight it. I'll propose some new text... >> >> One thing that is FECFRAME specific is the situation where several >> flows with different security requirements are globally protected. >> This is discussed in Section 9.4. This section may be further >> improved. I need to think it over. >> >> Cheers, >> >> Vincent >> From vincent.roca@inrialpes.fr Fri Dec 10 03:50:12 2010 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 031523A6AEC for ; Fri, 10 Dec 2010 03:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 niiZ8a9skinv for ; Fri, 10 Dec 2010 03:50:10 -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 BB5D93A6ADF for ; Fri, 10 Dec 2010 03:50:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,323,1288566000"; d="scan'208";a="82399125" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 10 Dec 2010 12:51:39 +0100 Message-ID: <4D02144B.9000505@inrialpes.fr> Date: Fri, 10 Dec 2010 12:51:39 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: fecframe@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 10 Dec 2010 11:50:12 -0000 Hello, For those who didn't attend Beijing meeting, you can find related information here: Concerning the two Reed-Solomon I-Ds: http://www.ietf.org/proceedings/79/slides/fecframe-1.ppt Concerning the LDPC I-D: http://www.ietf.org/proceedings/79/slides/fecframe-2.ppt Cheers, Vincent, on behalf of the authors On 09/12/10 18:50, 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 ietfdbh@comcast.net Fri Dec 10 05:30:04 2010 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 1F4F73A6CA8 for ; Fri, 10 Dec 2010 05:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 3Xmlbv2G+L9O for ; Fri, 10 Dec 2010 05:30:01 -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 342793A6B07 for ; Fri, 10 Dec 2010 05:30:01 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id hNvP1f0041vXlb851RXZXf; Fri, 10 Dec 2010 13:31:33 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta17.westchester.pa.mail.comcast.net with comcast id hRXY1f00M2JQnJT3dRXY7d; Fri, 10 Dec 2010 13:31:33 +0000 From: "David Harrington" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> Date: Fri, 10 Dec 2010 08:31:14 -0500 Message-ID: <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAnWz4w 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: Fri, 10 Dec 2010 13:30:04 -0000 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 Fri Dec 10 06:10:30 2010 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 869C83A6CAC for ; Fri, 10 Dec 2010 06:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 Be7F4nUodpCP for ; Fri, 10 Dec 2010 06:10:28 -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 12DD43A6AE8 for ; Fri, 10 Dec 2010 06:10:27 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta07.westchester.pa.mail.comcast.net with comcast id hQLr1f0071ZXKqc57SC05D; Fri, 10 Dec 2010 14:12:00 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta21.westchester.pa.mail.comcast.net with comcast id hSBz1f00M2JQnJT3hSBzfl; Fri, 10 Dec 2010 14:12:00 +0000 From: "David Harrington" To: "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D540DC938DA@xmb-sjc-215.amer.cisco.com> Date: Fri, 10 Dec 2010 09:11:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DC938DA@xmb-sjc-215.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuRedz3sHHRfwQAR1qNNFQTbkgBUQGaVW9g 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 14:10:30 -0000 Hi, I think this security text is very good. It clearly describes the possible issues, and steps to take to mitigate the issues, including recommended protocols. I fail to see a mandatory to implement solution, to support minimum interoperability. If it is in this text, it should be more clearly marked as mandatory to implement. If vendor A uses SRTP to protect against content sorruption, and vendor B uses IPsec, these two implementations will not interoperate. You are not defining either of these as mandatory-to-implement. Many vendors might choose to implement neither since neither is mandatory for compliance. That means an operator might have neither available to provide protection. I don't see a mandatory to implement protocol for protecting the session description. Please see RFC 3365, which requires strong security for IETF standards. I don't think your text provides for strong security. 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." 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: Wednesday, December 01, 2010 12:30 PM > To: fecframe@ietf.org > Subject: [Fecframe] Proposed changes to the framework draft - > part 2(security) > > This is the 2nd part for the changes we need to make in the > framework draft. This part is related to the security issues. > Please refer to the tracker to see the comments from the IESG. > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ > > I would like to thank Vincent for providing this brand new > security section. I just added a few minor points into the text. > > If there are any objections, please speak up. If you are OK > with these changes, please also speak up so that we can show > WG consensus. > > Thanks, > -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. > Some of them target the network (e.g., to compromise the routing > infrastructure by compromising the congestion control component), > others can target the Content Delivery Protocol (CDP) (e.g., to > compromise its normal behavior), and finally some attacks > target the > content itself. > > More specifically, these 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 and/or repair flows (e.g., to > prevent a receiver from using them). > > o They can try to compromise the receiver's behavior (e.g., by > making the decoding of an object computationally expensive). > > o They can try to compromise the network's behavior (e.g., by > causing congestion within the network). > > These attacks can be launched either against the source > and/or repair > flows (e.g., by sending forged 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 a session description). > > 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 before the FEC protection, or, if done after the FEC > protection, then this encryption MUST be applied on both the FEC > source packets and repair packets. Otherwise, if > encryption were to > be performed only on the FEC source packets after FEC > encoding, then > a non-authorized receiver could be able to recover the source data > after decoding the repair packets provided that a sufficient number > of such packets were available. > > 9.2.2. Content Corruption > > Protection against corruptions (e.g., after sending 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. 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 > knows 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. > 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 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. > This approach is documented here to provide a reference of an > interoperable secure mode of operation. However, other approaches, > including other forms of IPsec application, MAY be used or > specified > in the future. > > 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 Fri Dec 10 15:29:44 2010 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 3972828C172 for ; Fri, 10 Dec 2010 15:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 sf0Y8mkXCIoJ for ; Fri, 10 Dec 2010 15:29:43 -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 0E8F928C13D for ; Fri, 10 Dec 2010 15:29:42 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta01.westchester.pa.mail.comcast.net with comcast id hXe41f0040SCNGk51bXG7k; Fri, 10 Dec 2010 23:31:16 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta09.westchester.pa.mail.comcast.net with comcast id hbXF1f0042JQnJT3VbXF2m; Fri, 10 Dec 2010 23:31:16 +0000 From: "David Harrington" To: , References: Date: Fri, 10 Dec 2010 18:30:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuXyY7JlWyQL59xS1CnZszCjFHaOAAqwkvA 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: Fri, 10 Dec 2010 23:29:44 -0000 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 > From abegen@cisco.com Fri Dec 10 16:07:40 2010 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 897F83A6BE4 for ; Fri, 10 Dec 2010 16:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.409 X-Spam-Level: X-Spam-Status: No, score=-10.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 BpN7pAeZaihO for ; Fri, 10 Dec 2010 16:07:31 -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 849443A6887 for ; Fri, 10 Dec 2010 16:07:31 -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: AvsEAH5PAk2rR7Ht/2dsb2JhbACkD3ika4lUkViCchqCPgSEZIkv X-IronPort-AV: E=Sophos;i="4.59,326,1288569600"; d="scan'208";a="300757792" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 11 Dec 2010 00:09:03 +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 oBB093Lb010882; Sat, 11 Dec 2010 00:09:03 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); Fri, 10 Dec 2010 16:09:03 -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: Fri, 10 Dec 2010 16:08:25 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DE2DD4B@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2(security) Thread-Index: AcuRedz3sHHRfwQAR1qNNFQTbkgBUQGaVW9gADjeu5A= References: <04CAD96D4C5A3D48B1919248A8FE0D540DC938DA@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "David Harrington" , X-OriginalArrivalTime: 11 Dec 2010 00:09:03.0631 (UTC) FILETIME=[9E8F81F0:01CB98C7] 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 00:07:40 -0000 I will let others chime in as well. For the mandatory security protocol, neither SRTP nor IPsec nor = something else makes sense. SRTP could only be mandated for RTP flows = *maybe*. Even that I don't know why every FEC application would need to = implement security for FEC. For many such applications, the content = itself is secured and FEC is dealt separately. IPsec should not be = required every time FEC is needed, either. Some FEC applications do not = require security at all. Does fecframe really require a mandatory security solution?=20 Does every fecframe application need to protect the session description? = BTW, even using SDP is not required for fecframe so I don't understand = why we need a mandatory solution to protect the SDP descriptions. FYI, the text below has been modified based on the list discussion. See = other emails on this thread if you need the latest version. -acbegen > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Friday, December 10, 2010 9:12 AM > To: Ali C. Begen (abegen); fecframe@ietf.org > Subject: RE: [Fecframe] Proposed changes to the framework draft - part = 2(security) >=20 > Hi, >=20 > I think this security text is very good. It clearly describes the > possible issues, and steps to take to mitigate the issues, including > recommended protocols. >=20 > I fail to see a mandatory to implement solution, to support minimum > interoperability. If it is in this text, it should be more clearly > marked as mandatory to implement. >=20 > If vendor A uses SRTP to protect against content sorruption, and > vendor B uses IPsec, these two implementations will not interoperate. > You are not defining either of these as mandatory-to-implement. Many > vendors might choose to implement neither since neither is mandatory > for compliance. That means an operator might have neither available to > provide protection. >=20 > I don't see a mandatory to implement protocol for protecting the > session description. >=20 > Please see RFC 3365, which requires strong security for IETF > standards. I don't think your text provides for strong security. >=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 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 >=20 > > -----Original Message----- > > From: fecframe-bounces@ietf.org > > [mailto:fecframe-bounces@ietf.org] On Behalf Of Ali C. Begen > (abegen) > > Sent: Wednesday, December 01, 2010 12:30 PM > > To: fecframe@ietf.org > > Subject: [Fecframe] Proposed changes to the framework draft - > > part 2(security) > > > > This is the 2nd part for the changes we need to make in the > > framework draft. This part is related to the security issues. > > Please refer to the tracker to see the comments from the IESG. > > > > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ > > > > I would like to thank Vincent for providing this brand new > > security section. I just added a few minor points into the text. > > > > If there are any objections, please speak up. If you are OK > > with these changes, please also speak up so that we can show > > WG consensus. > > > > Thanks, > > -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. > > Some of them target the network (e.g., to compromise the routing > > infrastructure by compromising the congestion control component), > > others can target the Content Delivery Protocol (CDP) (e.g., to > > compromise its normal behavior), and finally some attacks > > target the > > content itself. > > > > More specifically, these 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 and/or repair flows (e.g., > to > > prevent a receiver from using them). > > > > o They can try to compromise the receiver's behavior (e.g., by > > making the decoding of an object computationally expensive). > > > > o They can try to compromise the network's behavior (e.g., by > > causing congestion within the network). > > > > These attacks can be launched either against the source > > and/or repair > > flows (e.g., by sending forged 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 a session description). > > > > 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 before the FEC protection, or, if done after the FEC > > protection, then this encryption MUST be applied on both the FEC > > source packets and repair packets. Otherwise, if > > encryption were to > > be performed only on the FEC source packets after FEC > > encoding, then > > a non-authorized receiver could be able to recover the source > data > > after decoding the repair packets provided that a sufficient > number > > of such packets were available. > > > > 9.2.2. Content Corruption > > > > Protection against corruptions (e.g., after sending 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. > 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 > > knows 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. > > 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 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. > > This approach is documented here to provide a reference of an > > interoperable secure mode of operation. However, other > approaches, > > including other forms of IPsec application, MAY be used or > > specified > > in the future. > > > > 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 luby@qualcomm.com Fri Dec 10 16:22:52 2010 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 41F2928C102 for ; Fri, 10 Dec 2010 16:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 NdYSHWqWs7Uf for ; Fri, 10 Dec 2010 16:22:49 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 3844B3A6887 for ; Fri, 10 Dec 2010 16:22:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1292027061; x=1323563061; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"A li=20C.=20Begen=20(abegen)"=20,=20David =20Harrington=0D=0A=09,=20"fecframe@ ietf.org"=20|Date:=20Fri,=2010=20Dec =202010=2016:24:18=20-0800|Subject:=20Re:=20[Fecframe]=20 Proposed=20changes=20to=20the=20framework=20draft=20-=20p art=0D=0A=202(security)|Thread-Topic:=20[Fecframe]=20Prop osed=20changes=20to=20the=20framework=20draft=20-=20part =0D=0A=202(security)|Thread-Index:=20AcuRedz3sHHRfwQAR1qN NFQTbkgBUQGaVW9gADjeu5AAAMR8Yw=3D=3D|Message-ID:=20|In-Reply-To:=20<04CAD96D4C5A3 D48B1919248A8FE0D540DE2DD4B@xmb-sjc-215.amer.cisco.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.7.0.100913|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=+sn3BGDhOYNiDvWQj6if9apEvWMiRenjNH//G4sQJ9Q=; b=IvLG4I9VD3U8WOfGWp8VFe5s1E3/TM+xj+ZCpKC+qSnhIlCwYBnMvxIb ziUWiAiczpce8yAYrP5w4VnzhGC1MmoAsd4igaZ5E++EztttgZoJMr9uV A7JtB2Uv2PZ2j27RAtX55qGxCZ8JUFoOgYqOdzGNQaHo4xXp3O6hf0iIs Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6193"; a="66156890" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 10 Dec 2010 16:24:21 -0800 X-IronPort-AV: E=Sophos;i="4.59,324,1288594800"; d="scan'208";a="17258595" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 10 Dec 2010 16:24:21 -0800 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 10 Dec 2010 16:24:20 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Fri, 10 Dec 2010 16:24:20 -0800 From: "Luby, Michael" To: "Ali C. Begen (abegen)" , David Harrington , "fecframe@ietf.org" Date: Fri, 10 Dec 2010 16:24:18 -0800 Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2(security) Thread-Index: AcuRedz3sHHRfwQAR1qNNFQTbkgBUQGaVW9gADjeu5AAAMR8Yw== Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DE2DD4B@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 00:22:52 -0000 The security provided for streaming (if used) depends a lot more on the content and characteristics of the original stream then it does on the FEC repair added to the stream (if FEC is used): the FEC is a very small part o= f the overall consideration, so it would be unusual if the security should be selected based on the FEC being used (except that of course the security, i= f used, should not be incompatible with the FEC -- but this is already discussed in the document about how FEC can affect an already selected security solution). Thus I'm wondering if it makes sense for FECFRAME to define a mandatory security? It seems similar to the congestion control issue, i.e., the FEC is a supplemental component that provides some QoS, and I think the idea there is that FEC can only add a limited fraction of bandwidth to a stream, but it is really the stream that defines the rate/congestion control, and the FEC reacts naturally in response, but the FEC doesn't define a whole ne= w congestion control because that is really a function of how the original content in the stream is delivered. Among the security solutions that would really be used for streaming, the most likely candidates are DRMs of various sorts with all kinds of differen= t IPRs. If we mandate a security solution that would really be used in practice, there is this issue as well. On 12/10/10 4:08 PM, "Ali C. Begen (abegen)" wrote: > I will let others chime in as well. > > For the mandatory security protocol, neither SRTP nor IPsec nor something= else > makes sense. SRTP could only be mandated for RTP flows *maybe*. Even that= I > don't know why every FEC application would need to implement security for= FEC. > For many such applications, the content itself is secured and FEC is deal= t > separately. IPsec should not be required every time FEC is needed, either= . > Some FEC applications do not require security at all. > > Does fecframe really require a mandatory security solution? > > Does every fecframe application need to protect the session description? = BTW, > even using SDP is not required for fecframe so I don't understand why we = need > a mandatory solution to protect the SDP descriptions. > > FYI, the text below has been modified based on the list discussion. See o= ther > emails on this thread if you need the latest version. > > -acbegen > >> -----Original Message----- >> From: David Harrington [mailto:ietfdbh@comcast.net] >> Sent: Friday, December 10, 2010 9:12 AM >> To: Ali C. Begen (abegen); fecframe@ietf.org >> Subject: RE: [Fecframe] Proposed changes to the framework draft - part >> 2(security) >> >> Hi, >> >> I think this security text is very good. It clearly describes the >> possible issues, and steps to take to mitigate the issues, including >> recommended protocols. >> >> I fail to see a mandatory to implement solution, to support minimum >> interoperability. If it is in this text, it should be more clearly >> marked as mandatory to implement. >> >> If vendor A uses SRTP to protect against content sorruption, and >> vendor B uses IPsec, these two implementations will not interoperate. >> You are not defining either of these as mandatory-to-implement. Many >> vendors might choose to implement neither since neither is mandatory >> for compliance. That means an operator might have neither available to >> provide protection. >> >> I don't see a mandatory to implement protocol for protecting the >> session description. >> >> Please see RFC 3365, which requires strong security for IETF >> standards. I don't think your text provides for strong security. >> >> 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." >> >> 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: Wednesday, December 01, 2010 12:30 PM >>> To: fecframe@ietf.org >>> Subject: [Fecframe] Proposed changes to the framework draft - >>> part 2(security) >>> >>> This is the 2nd part for the changes we need to make in the >>> framework draft. This part is related to the security issues. >>> Please refer to the tracker to see the comments from the IESG. >>> >>> >> https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ >>> >>> I would like to thank Vincent for providing this brand new >>> security section. I just added a few minor points into the text. >>> >>> If there are any objections, please speak up. If you are OK >>> with these changes, please also speak up so that we can show >>> WG consensus. >>> >>> Thanks, >>> -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. >>> Some of them target the network (e.g., to compromise the routing >>> infrastructure by compromising the congestion control component), >>> others can target the Content Delivery Protocol (CDP) (e.g., to >>> compromise its normal behavior), and finally some attacks >>> target the >>> content itself. >>> >>> More specifically, these 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 and/or repair flows (e.g., >> to >>> prevent a receiver from using them). >>> >>> o They can try to compromise the receiver's behavior (e.g., by >>> making the decoding of an object computationally expensive). >>> >>> o They can try to compromise the network's behavior (e.g., by >>> causing congestion within the network). >>> >>> These attacks can be launched either against the source >>> and/or repair >>> flows (e.g., by sending forged 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 a session description). >>> >>> 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 before the FEC protection, or, if done after the FEC >>> protection, then this encryption MUST be applied on both the FEC >>> source packets and repair packets. Otherwise, if >>> encryption were to >>> be performed only on the FEC source packets after FEC >>> encoding, then >>> a non-authorized receiver could be able to recover the source >> data >>> after decoding the repair packets provided that a sufficient >> number >>> of such packets were available. >>> >>> 9.2.2. Content Corruption >>> >>> Protection against corruptions (e.g., after sending 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. >> 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 >>> knows 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. >>> 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 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. >>> This approach is documented here to provide a reference of an >>> interoperable secure mode of operation. However, other >> approaches, >>> including other forms of IPsec application, MAY be used or >>> specified >>> in the future. >>> >>> 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 ietfdbh@comcast.net Fri Dec 10 16:39:52 2010 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 8E6E228C102 for ; Fri, 10 Dec 2010 16:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 h7kynSAONEOn for ; Fri, 10 Dec 2010 16:39:49 -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 010A428C118 for ; Fri, 10 Dec 2010 16:39:48 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta08.westchester.pa.mail.comcast.net with comcast id hU1e1f00216LCl058chNEh; Sat, 11 Dec 2010 00:41:22 +0000 Received: from 23FX1C1 ([67.189.235.106]) by omta06.westchester.pa.mail.comcast.net with comcast id hchM1f00B2JQnJT3SchMZC; Sat, 11 Dec 2010 00:41:22 +0000 From: "David Harrington" To: "'Luby, Michael'" , "'Ali C. Begen \(abegen\)'" , References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2DD4B@xmb-sjc-215.amer.cisco.com> Date: Fri, 10 Dec 2010 19:40:55 -0500 Message-ID: <986C0FD3E62E4E2BB08BF198EB0A59CF@23FX1C1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuRedz3sHHRfwQAR1qNNFQTbkgBUQGaVW9gADjeu5AAAMR8YwAAarSw 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 00:39:53 -0000 Hi Mike and Ali, If you want to avoid a mandatory-to-implement security solution, I think you should document very clearly in the security considerations section why it makes little sense to have one. The argument in this email is a good step in the right direction. 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: Friday, December 10, 2010 7:24 PM > To: Ali C. Begen (abegen); David Harrington; fecframe@ietf.org > Subject: Re: [Fecframe] Proposed changes to the framework > draft - part 2(security) > > The security provided for streaming (if used) depends a lot > more on the > content and characteristics of the original stream then it > does on the FEC > repair added to the stream (if FEC is used): the FEC is a > very small part of > the overall consideration, so it would be unusual if the > security should be > selected based on the FEC being used (except that of course > the security, if > used, should not be incompatible with the FEC -- but this is already > discussed in the document about how FEC can affect an already selected > security solution). > > Thus I'm wondering if it makes sense for FECFRAME to define a > mandatory > security? It seems similar to the congestion control issue, > i.e., the FEC > is a supplemental component that provides some QoS, and I > think the idea > there is that FEC can only add a limited fraction of > bandwidth to a stream, > but it is really the stream that defines the rate/congestion > control, and > the FEC reacts naturally in response, but the FEC doesn't > define a whole new > congestion control because that is really a function of how > the original > content in the stream is delivered. > > Among the security solutions that would really be used for > streaming, the > most likely candidates are DRMs of various sorts with all > kinds of different > IPRs. If we mandate a security solution that would really be used in > practice, there is this issue as well. > > > On 12/10/10 4:08 PM, "Ali C. Begen (abegen)" wrote: > > > I will let others chime in as well. > > > > For the mandatory security protocol, neither SRTP nor IPsec > nor something else > > makes sense. SRTP could only be mandated for RTP flows > *maybe*. Even that I > > don't know why every FEC application would need to > implement security for FEC. > > For many such applications, the content itself is secured > and FEC is dealt > > separately. IPsec should not be required every time FEC is > needed, either. > > Some FEC applications do not require security at all. > > > > Does fecframe really require a mandatory security solution? > > > > Does every fecframe application need to protect the session > description? BTW, > > even using SDP is not required for fecframe so I don't > understand why we need > > a mandatory solution to protect the SDP descriptions. > > > > FYI, the text below has been modified based on the list > discussion. See other > > emails on this thread if you need the latest version. > > > > -acbegen > > > >> -----Original Message----- > >> From: David Harrington [mailto:ietfdbh@comcast.net] > >> Sent: Friday, December 10, 2010 9:12 AM > >> To: Ali C. Begen (abegen); fecframe@ietf.org > >> Subject: RE: [Fecframe] Proposed changes to the framework > draft - part > >> 2(security) > >> > >> Hi, > >> > >> I think this security text is very good. It clearly describes the > >> possible issues, and steps to take to mitigate the issues, > including > >> recommended protocols. > >> > >> I fail to see a mandatory to implement solution, to support minimum > >> interoperability. If it is in this text, it should be more clearly > >> marked as mandatory to implement. > >> > >> If vendor A uses SRTP to protect against content sorruption, and > >> vendor B uses IPsec, these two implementations will not > interoperate. > >> You are not defining either of these as > mandatory-to-implement. Many > >> vendors might choose to implement neither since neither is > mandatory > >> for compliance. That means an operator might have neither > available to > >> provide protection. > >> > >> I don't see a mandatory to implement protocol for protecting the > >> session description. > >> > >> Please see RFC 3365, which requires strong security for IETF > >> standards. I don't think your text provides for strong security. > >> > >> 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." > >> > >> 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: Wednesday, December 01, 2010 12:30 PM > >>> To: fecframe@ietf.org > >>> Subject: [Fecframe] Proposed changes to the framework draft - > >>> part 2(security) > >>> > >>> This is the 2nd part for the changes we need to make in the > >>> framework draft. This part is related to the security issues. > >>> Please refer to the tracker to see the comments from the IESG. > >>> > >>> > >> > https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ > >>> > >>> I would like to thank Vincent for providing this brand new > >>> security section. I just added a few minor points into the text. > >>> > >>> If there are any objections, please speak up. If you are OK > >>> with these changes, please also speak up so that we can show > >>> WG consensus. > >>> > >>> Thanks, > >>> -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. > >>> Some of them target the network (e.g., to compromise > the routing > >>> infrastructure by compromising the congestion control > component), > >>> others can target the Content Delivery Protocol (CDP) (e.g., to > >>> compromise its normal behavior), and finally some attacks > >>> target the > >>> content itself. > >>> > >>> More specifically, these 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 and/or repair > flows (e.g., > >> to > >>> prevent a receiver from using them). > >>> > >>> o They can try to compromise the receiver's behavior (e.g., by > >>> making the decoding of an object computationally expensive). > >>> > >>> o They can try to compromise the network's behavior (e.g., by > >>> causing congestion within the network). > >>> > >>> These attacks can be launched either against the source > >>> and/or repair > >>> flows (e.g., by sending forged 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 a session description). > >>> > >>> 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 before the FEC protection, or, if done after the FEC > >>> protection, then this encryption MUST be applied on > both the FEC > >>> source packets and repair packets. Otherwise, if > >>> encryption were to > >>> be performed only on the FEC source packets after FEC > >>> encoding, then > >>> a non-authorized receiver could be able to recover the source > >> data > >>> after decoding the repair packets provided that a sufficient > >> number > >>> of such packets were available. > >>> > >>> 9.2.2. Content Corruption > >>> > >>> Protection against corruptions (e.g., after sending 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. > >> 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 > >>> knows 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. > >>> 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 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. > >>> This approach is documented here to provide a reference of an > >>> interoperable secure mode of operation. However, other > >> approaches, > >>> including other forms of IPsec application, MAY be used or > >>> specified > >>> in the future. > >>> > >>> 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 Fri Dec 10 23:05:58 2010 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 39C7C3A6C3D for ; Fri, 10 Dec 2010 23:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 cNM0a7+SME2N for ; Fri, 10 Dec 2010 23:05:55 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 9D9783A6BCB for ; Fri, 10 Dec 2010 23:05:54 -0800 (PST) Received: by ywk9 with SMTP id 9so2713663ywk.31 for ; Fri, 10 Dec 2010 23:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:references:in-reply-to :mime-version:content-transfer-encoding:content-type:message-id:cc :x-mailer:from:subject:date:to; bh=vAYBD0sqZdtgsntw2OGayjnarwaF4kTVkhN+18mFFT0=; b=eBHq1ZPoadfpAWU+Dodjp0Eai96Vl5w3K7Ehs/2To9FUcUCfN3hOVlAJLbDUOZ0DVu SpFUfLlZPkK59bzMU1yZtBUqikLtZA8m20icfUAh01HiGeiMD0mwxpVrBCUgUP9j8py6 IUa5Kqok3Te98Ii4JAnMls/3Rr3lfIhpDvV70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=F95kzSsISoKN3O04EY2wWQgUZnPoZbm13WQtebCylxS7/KIVOwjo1uj7hO37o5Iiwn 7zeRxN0A9PVz4dDpfqjIjzGPBiNp6qCX4finjarse5NSM5phPXZAGYBdYgkKJZWY3rTv vISerdb9mCPxcDcZFgoe6pt7D/nagBGlZj41w= Received: by 10.150.203.15 with SMTP id a15mr2803506ybg.136.1292051246285; Fri, 10 Dec 2010 23:07:26 -0800 (PST) Received: from [10.27.40.221] ([166.137.8.33]) by mx.google.com with ESMTPS id r24sm977557yba.6.2010.12.10.23.07.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 10 Dec 2010 23:07:25 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <4E3DAC27-ED71-4B28-BDEA-4F241242C842@gmail.com> X-Mailer: iPhone Mail (8A293) From: Greg Shepherd Date: Sat, 11 Dec 2010 16:06:46 +0900 To: David Harrington Cc: "" 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: Sat, 11 Dec 2010 07:05:58 -0000 Yes, you are just being a pain in the butt. Adoption as a working group item= is not the same acceptance.=20 Greg Sent from my iPhone On Dec 11, 2010, at 8:30, "David Harrington" wrote: > Hi, >=20 > Not to be a pain in the butt, but to be a pain in the butt ... ;-) >=20 > Your charter is explicit: > "the acceptance of any FEC scheme will require multiple, prior, > detailed=20 > reviews of the FEC code by independent experts from both the IETF and=20 > the broader community, since it is likely that the IETF working group=20 > will not include a large enough number of suitable experts in its=20 > working set. If these reviews are positive, then Working Group=20 > acceptance of an FEC scheme work item still needs the approval of the=20 > responsible Area Director." >=20 > 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. >=20 > 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. >=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=20 >> [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? >>=20 >> *, >>=20 >> 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: >>=20 >> - draft-roca-fecframe-simple-rs-01 >> - draft-galanos-fecframe-rtp-reedsolomon-02 >> - draft-roca-fecframe-ldpc-01 >>=20 >> Thanks, >> Greg >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >>=20 >=20 From abegen@cisco.com Sat Dec 11 11:26:45 2010 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 9F58D3A6D2F for ; Sat, 11 Dec 2010 11:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.415 X-Spam-Level: X-Spam-Status: No, score=-10.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 RjNS14sxgM3W for ; Sat, 11 Dec 2010 11:26:42 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5011A3A6B73 for ; Sat, 11 Dec 2010 11:26:41 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQEAJFfA02Q/khLgWdsb2JhbACkDhUBARYiKaRymlGDDII+BIRkiS8 X-IronPort-AV: E=Sophos;i="4.59,329,1288569600"; d="scan'208";a="71443902" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2010 19:28:14 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBBJPtGi009714; Sat, 11 Dec 2010 19:28:14 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); Sat, 11 Dec 2010 11:26:14 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 11 Dec 2010 11:26:06 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DE2DDF1@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Operations and Management Considerations (text for theframework) Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAnWz4wAEBdh1A= References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> From: "Ali C. Begen (abegen)" To: "David Harrington" , X-OriginalArrivalTime: 11 Dec 2010 19:26:14.0766 (UTC) FILETIME=[46BDF0E0:01CB9969] 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: Sat, 11 Dec 2010 19:26:46 -0000 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. =20 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.=20 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) >=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) > > > > 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 oran@cisco.com Sat Dec 11 12:24:44 2010 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 C87383A6CBA for ; Sat, 11 Dec 2010 12:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.134 X-Spam-Level: X-Spam-Status: No, score=-110.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, 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 81IB8OHT+Def for ; Sat, 11 Dec 2010 12:24:43 -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 2F8EC3A6BAC for ; Sat, 11 Dec 2010 12:24:43 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 2070 X-IronPort-AV: E=Sophos;i="4.59,329,1288569600"; d="p7s'?scan'208";a="231147439" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 11 Dec 2010 20:26:17 +0000 Received: from OranMBP.local (stealth-10-32-245-155.cisco.com [10.32.245.155]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oBBKQ6ea021920; Sat, 11 Dec 2010 20:26:16 GMT Received: from [127.0.0.1] by OranMBP.local (PGP Universal service); Sat, 11 Dec 2010 15:26:16 -0500 X-PGP-Universal: processed; by OranMBP.local on Sat, 11 Dec 2010 15:26:16 -0500 Mime-Version: 1.0 (Apple Message framework v1082) From: David R Oran In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DE2DDF1@xmb-sjc-215.amer.cisco.com> Date: Sat, 11 Dec 2010 15:26:00 -0500 Message-Id: <65B2271C-42CB-4357-A79A-85908A9EC661@cisco.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2D845@xmb-sjc-215.amer.cisco.com> <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> <04CAD96D4C5A3D48B1919248A8FE0D540DE2DDF1@xmb-sjc-215.amer.cisco.com> To: "Ali C. Begen (abegen)" X-Mailer: Apple Mail (2.1082) Content-Type: multipart/signed; boundary=Apple-Mail-30-259347776; protocol="application/pkcs7-signature"; micalg=sha1 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: Sat, 11 Dec 2010 20:24:44 -0000 --Apple-Mail-30-259347776 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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=20 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, >=20 > 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. >=20 > 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. >=20 > 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.=20 >=20 > 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? >=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 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... 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 --Apple-Mail-30-259347776 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIELTCCBCkw ggMRoAMCAQICAQEwCwYJKoZIhvcNAQEFMIGiMRMwEQYDVQQDDApEYXZpZCBPcmFuMRYwFAYDVQQK DA1DaXNjbyBTeXN0ZW1zMSowKAYDVQQLDCFDb3Jwb3JhdGUgUmVzZWFyY2ggJiBBcmNoaXRlY3R1 cmUxCzAJBgNVBAgMAk1BMQswCQYDVQQGEwJVUzEOMAwGA1UEBwwFQWN0b24xHTAbBgkqhkiG9w0B CQEWDm9yYW5AY2lzY28uY29tMB4XDTEwMTIxMDE0MzYxN1oXDTExMTIxMDE0MzYxN1owgaIxEzAR BgNVBAMMCkRhdmlkIE9yYW4xFjAUBgNVBAoMDUNpc2NvIFN5c3RlbXMxKjAoBgNVBAsMIUNvcnBv cmF0ZSBSZXNlYXJjaCAmIEFyY2hpdGVjdHVyZTELMAkGA1UECAwCTUExCzAJBgNVBAYTAlVTMQ4w DAYDVQQHDAVBY3RvbjEdMBsGCSqGSIb3DQEJARYOb3JhbkBjaXNjby5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDsoGlBFteiA4xGh3EP4vLfMZPabwEJvICVApmQ1SjTup2uttIE rffNaEgPBwzwyoVqzwT3MAsW5RAca+AqZ7dNx8BalclAdGWol0icoRIVuLb3RQvB7bWuYbzSuWgu nkPuunv3FDPC0WAOnpienMtaNGmfizl5ArxYV8OvHwtQQAfItP0P8sYWz+5wLLqXEhTe0xnRtiHU XSBN4zDsrdsnmYHrNSyXXnSagHvvaCQMSTUm0RiPQy3w0inofy0CQw9HeiDtGXp/P2b3iCok11dj qZlOsALV0PyCnle718L7tyGFmR5Nq9BciLhE/c9XJWsjTdW7yztaL7qb49dcLiXJAgMBAAGjajBo MA8GA1UdEwEB/wQFMAMBAQAwDgYDVR0PAQH/BAQDAgP4MCoGA1UdJQEB/wQgMB4GCCsGAQUFBwME BggrBgEFBQcDAgYIKwYBBQUHAwEwGQYDVR0RBBIwEIEOb3JhbkBjaXNjby5jb20wDQYJKoZIhvcN AQEFBQADggEBAFAlfFN9Ybdf7C5/XlUDq78aVRiocg0TPTAKQut8NrQwQ9j0Li7bvVBBsMv0uF2h u6Rsoru2ia8opvXA8qYX2s/Nr00RUVIjdqaCO8+5/+sH50SDnYiQCJVxb8m8jcqxzob/Drtf9SJ5 Da+bBTr2ueOPrZ6W4I/bDFysyBm6jbfJVxTG6guHsSzt6iZAluGpXdkeXMuQRSm1tgnMij/H8r+h sR9OU+ySv0VN5yXDpZMNjspVUzMRfmA+4qlhUoUyA09GOO0DElM5TYf99DjmODWiq2qHJReWjhak POXkWPSSMbDSFObxIPlH1UVGKoqPyjbUrkOt4XGkuazkL4dgEDoxggOrMIIDpwIBATCBqDCBojET MBEGA1UEAwwKRGF2aWQgT3JhbjEWMBQGA1UECgwNQ2lzY28gU3lzdGVtczEqMCgGA1UECwwhQ29y cG9yYXRlIFJlc2VhcmNoICYgQXJjaGl0ZWN0dXJlMQswCQYDVQQIDAJNQTELMAkGA1UEBhMCVVMx DjAMBgNVBAcMBUFjdG9uMR0wGwYJKoZIhvcNAQkBFg5vcmFuQGNpc2NvLmNvbQIBATAJBgUrDgMC GgUAoIIB1zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDEyMTEy MDI2MDBaMCMGCSqGSIb3DQEJBDEWBBSqOg1ozFC67XQvkSEaOVow8cFe9DCBuQYJKwYBBAGCNxAE MYGrMIGoMIGiMRMwEQYDVQQDDApEYXZpZCBPcmFuMRYwFAYDVQQKDA1DaXNjbyBTeXN0ZW1zMSow KAYDVQQLDCFDb3Jwb3JhdGUgUmVzZWFyY2ggJiBBcmNoaXRlY3R1cmUxCzAJBgNVBAgMAk1BMQsw CQYDVQQGEwJVUzEOMAwGA1UEBwwFQWN0b24xHTAbBgkqhkiG9w0BCQEWDm9yYW5AY2lzY28uY29t AgEBMIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBojETMBEGA1UEAwwKRGF2aWQgT3JhbjEWMBQGA1UE CgwNQ2lzY28gU3lzdGVtczEqMCgGA1UECwwhQ29ycG9yYXRlIFJlc2VhcmNoICYgQXJjaGl0ZWN0 dXJlMQswCQYDVQQIDAJNQTELMAkGA1UEBhMCVVMxDjAMBgNVBAcMBUFjdG9uMR0wGwYJKoZIhvcN AQkBFg5vcmFuQGNpc2NvLmNvbQIBATANBgkqhkiG9w0BAQEFAASCAQAIYsOGDp/2pH3iBdznXeu9 68IGVbcIEWokU5l2Puh9+Q3NUrOo0HC/tbzMC6u2DuxDgaI8xlai46eQfFifObRZdHU1PKLFwEb/ OtKpHB/O2xCW93pcit/A44pgiq7G+Ihu3r4svop7GMk3C9AX3HbmEr6TVW3qVcJ7PpgFy6by3g3U 9FIiLkedqrWR35yuvAr0raJoWgQ1aGwiMXY81rS4Z92MFKbwwjGhCfjc/eGqJ9W3tTepjaDpsZdQ YM58u6yeKYZ1IHMbH5ChAGN2DHn5sc7d5pjjoOATGxMbhOeiR6imeh0QjB4OxHnBB11ZJMEzVSHB 5cOLKfqWtY90hq0SAAAAAAAA --Apple-Mail-30-259347776-- From luby@qualcomm.com Sat Dec 11 13:37:59 2010 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 1CD353A6D48 for ; Sat, 11 Dec 2010 13:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 O2x08fWM8Ay9 for ; Sat, 11 Dec 2010 13:37:57 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 96A2C3A6D46 for ; Sat, 11 Dec 2010 13:37:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1292103572; x=1323639572; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Da vid=20Harrington=20,=20"Ali=20C.=20B egen=20(abegen)"=0D=0A=09,=20"fecframe@ ietf.org"=20|Date:=20Sat,=2011=20Dec =202010=2013:39:30=20-0800|Subject:=20Re:=20[Fecframe]=20 Operations=20and=20Management=20Considerations=20(text=20 for=0D=0A=20theframework)|Thread-Topic:=20[Fecframe]=20Op erations=20and=20Management=20Considerations=20(text=20fo r=0D=0A=20theframework)|Thread-Index:=20AcuXxSqy7UEhaMGYT IiS9Tz/cIgvtwAnWz4wAEZTJuc=3D|Message-ID:=20|In-Reply-To:=20<4A327AA8433F4BBA99F6 A78A05DC66D2@23FX1C1>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|user-agent:=20Microsoft-Entourage/ 13.7.0.100913|acceptlanguage:=20en-US|Content-Type:=20tex t/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=c8d+8NZv1HgOTuB2IU/NJGzq/XmhW8C1ABfAfzoUVbw=; b=qp7LQgW80yg4KgK7+69WtuGlqahNCMUjEylUYmeUhpekGZzL4DjpoWw2 6BM2AVWuEjWoLndk6WgpUqSfz1tiyM7trW43VQWwZGCVXhDlT/HOU1Ygj u93pAjagIkIayoouvcxpwWDXKPFjPwPjXFGQEZuV0wwa0P0Gj/zjeWAaX I=; X-IronPort-AV: E=McAfee;i="5400,1158,6194"; a="66450333" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 11 Dec 2010 13:39:31 -0800 X-IronPort-AV: E=Sophos;i="4.59,328,1288594800"; d="scan'208";a="99518195" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 11 Dec 2010 13:39:31 -0800 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.3.83.0; Sat, 11 Dec 2010 13:39:31 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Sat, 11 Dec 2010 13:39:31 -0800 From: "Luby, Michael" To: David Harrington , "Ali C. Begen (abegen)" , "fecframe@ietf.org" Date: Sat, 11 Dec 2010 13:39:30 -0800 Thread-Topic: [Fecframe] Operations and Management Considerations (text for theframework) Thread-Index: AcuXxSqy7UEhaMGYTIiS9Tz/cIgvtwAnWz4wAEZTJuc= Message-ID: In-Reply-To: <4A327AA8433F4BBA99F6A78A05DC66D2@23FX1C1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sat, 11 Dec 2010 21:37:59 -0000 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 abou= t 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 tha= t as a starting point. Mike=20 On 12/10/10 5:31 AM, "David Harrington" wrote: > 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 >=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.=20 >> 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=20 > 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 From vincent.roca@inrialpes.fr Mon Dec 13 13:45:32 2010 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 4977C3A6D77 for ; Mon, 13 Dec 2010 13:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.727 X-Spam-Level: X-Spam-Status: No, score=-9.727 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 rGOKGdaUavrX for ; Mon, 13 Dec 2010 13:45:30 -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 55CB73A6CC8 for ; Mon, 13 Dec 2010 13:45:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,338,1288566000"; d="scan'208";a="82546771" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-de-roca.local) ([82.236.155.50]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 13 Dec 2010 22:47:06 +0100 Message-ID: <4D069459.9060501@inrialpes.fr> Date: Mon, 13 Dec 2010 22:47:05 +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: David Harrington References: <04CAD96D4C5A3D48B1919248A8FE0D540DE2DD4B@xmb-sjc-215.amer.cisco.com> <986C0FD3E62E4E2BB08BF198EB0A59CF@23FX1C1> In-Reply-To: <986C0FD3E62E4E2BB08BF198EB0A59CF@23FX1C1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 21:45:32 -0000 Hello everybody, I think we need to distinguish two different sets of security requirements: 1/ end2end, application-level security, independently of FECFRAME: The upper application may have specific requirements. As already discussed, if encryption is needed, it's often preferable to do that above FECFRAME. This is where all types of DRM solutions fit, and SRTP may be useful too (even if it is restricted to RTP flows). => Relying on IPsec/ESP to achieve this end2end security is inappropriate (cf. previous discussion whether encryption should happen before FEC encoding or not). 2/ because of the use of FECFRAME: The motivation is that FECFRAME adds new opportunities for attacks (e.g. by sending forged repair packets). So it makes sense to follow a global security approach that prevents or mitigates these attacks, independently of the potential security requirements of individual source flows. This approach will consider all flows generated by a FECFRAME sender. => Relying on IPsec/ESP to achieve this is meaningful. On the opposite, security mechanisms that happen above FECFRAME is of little help. I don't know if there is another alternative to IPsec? Any idea? So the two sets of requirements seem complementary to me. Now there are special cases... For instance, because the network infrastructure is assumed reasonably secure (with 3GPP networks, or DVB broadcast networks, etc.) it can make sense to ignore 2/. Additionally, FECFRAME is probably just one small component of a much larger protocol stack in many deployments, as Mike reminded. Defining a mandatory to implement security solution just because a few repair packets are sent seems strange... However the guideline (RFC3365) is to be able to use a secure mode of operations in all IETF protocols. My interpretation is that because FECFRAME adds new threats, this security solution MUST prevent or mitigate these extra threats. So addressing point 2/ is the goal IMHO. When FECFRAME is used in a protected environment (e.g. 3GPP example above), this secure mode of operation won't be used, that's all. --- NB: It reminds me of a recent SecDir discussion whether the fact IPsec must be available for IPv6 conformance should be relaxed or not. some lightweight IPv6 terminals will probably never ever include IPsec. I don't remember if we reached a consensus here, but the situation is similar. Is it too much of a burden to have this "IPsec/ESP MUST implement" requirement in FECFRAME as well? --- Another point... David says: "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!). Regards, Vincent On 11/12/10 01:40, David Harrington wrote: > Hi Mike and Ali, > > If you want to avoid a mandatory-to-implement security solution, I > think you should document very clearly in the security considerations > section why it makes little sense to have one. The argument in this > email is a good step in the right direction. > > 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: Friday, December 10, 2010 7:24 PM >> To: Ali C. Begen (abegen); David Harrington; fecframe@ietf.org >> Subject: Re: [Fecframe] Proposed changes to the framework >> draft - part 2(security) >> >> The security provided for streaming (if used) depends a lot >> more on the >> content and characteristics of the original stream then it >> does on the FEC >> repair added to the stream (if FEC is used): the FEC is a >> very small part of >> the overall consideration, so it would be unusual if the >> security should be >> selected based on the FEC being used (except that of course >> the security, if >> used, should not be incompatible with the FEC -- but this is already >> discussed in the document about how FEC can affect an already > selected >> security solution). >> >> Thus I'm wondering if it makes sense for FECFRAME to define a >> mandatory >> security? It seems similar to the congestion control issue, >> i.e., the FEC >> is a supplemental component that provides some QoS, and I >> think the idea >> there is that FEC can only add a limited fraction of >> bandwidth to a stream, >> but it is really the stream that defines the rate/congestion >> control, and >> the FEC reacts naturally in response, but the FEC doesn't >> define a whole new >> congestion control because that is really a function of how >> the original >> content in the stream is delivered. >> >> Among the security solutions that would really be used for >> streaming, the >> most likely candidates are DRMs of various sorts with all >> kinds of different >> IPRs. If we mandate a security solution that would really be used > in >> practice, there is this issue as well. >> >> >> On 12/10/10 4:08 PM, "Ali C. Begen (abegen)" > wrote: >>> I will let others chime in as well. >>> >>> For the mandatory security protocol, neither SRTP nor IPsec >> nor something else >>> makes sense. SRTP could only be mandated for RTP flows >> *maybe*. Even that I >>> don't know why every FEC application would need to >> implement security for FEC. >>> For many such applications, the content itself is secured >> and FEC is dealt >>> separately. IPsec should not be required every time FEC is >> needed, either. >>> Some FEC applications do not require security at all. >>> >>> Does fecframe really require a mandatory security solution? >>> >>> Does every fecframe application need to protect the session >> description? BTW, >>> even using SDP is not required for fecframe so I don't >> understand why we need >>> a mandatory solution to protect the SDP descriptions. >>> >>> FYI, the text below has been modified based on the list >> discussion. See other >>> emails on this thread if you need the latest version. >>> >>> -acbegen >>> >>>> -----Original Message----- >>>> From: David Harrington [mailto:ietfdbh@comcast.net] >>>> Sent: Friday, December 10, 2010 9:12 AM >>>> To: Ali C. Begen (abegen); fecframe@ietf.org >>>> Subject: RE: [Fecframe] Proposed changes to the framework >> draft - part >>>> 2(security) >>>> >>>> Hi, >>>> >>>> I think this security text is very good. It clearly describes the >>>> possible issues, and steps to take to mitigate the issues, >> including >>>> recommended protocols. >>>> >>>> I fail to see a mandatory to implement solution, to support > minimum >>>> interoperability. If it is in this text, it should be more > clearly >>>> marked as mandatory to implement. >>>> >>>> If vendor A uses SRTP to protect against content sorruption, and >>>> vendor B uses IPsec, these two implementations will not >> interoperate. >>>> You are not defining either of these as >> mandatory-to-implement. Many >>>> vendors might choose to implement neither since neither is >> mandatory >>>> for compliance. That means an operator might have neither >> available to >>>> provide protection. >>>> >>>> I don't see a mandatory to implement protocol for protecting the >>>> session description. >>>> >>>> Please see RFC 3365, which requires strong security for IETF >>>> standards. I don't think your text provides for strong security. >>>> >>>> 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." >>>> >>>> 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: Wednesday, December 01, 2010 12:30 PM >>>>> To: fecframe@ietf.org >>>>> Subject: [Fecframe] Proposed changes to the framework draft - >>>>> part 2(security) >>>>> >>>>> This is the 2nd part for the changes we need to make in the >>>>> framework draft. This part is related to the security issues. >>>>> Please refer to the tracker to see the comments from the IESG. >>>>> >>>>> > https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ >>>>> I would like to thank Vincent for providing this brand new >>>>> security section. I just added a few minor points into the text. >>>>> >>>>> If there are any objections, please speak up. If you are OK >>>>> with these changes, please also speak up so that we can show >>>>> WG consensus. >>>>> >>>>> Thanks, >>>>> -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. >>>>> Some of them target the network (e.g., to compromise >> the routing >>>>> infrastructure by compromising the congestion control >> component), >>>>> others can target the Content Delivery Protocol (CDP) (e.g., > to >>>>> compromise its normal behavior), and finally some attacks >>>>> target the >>>>> content itself. >>>>> >>>>> More specifically, these 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 and/or repair >> flows (e.g., >>>> to >>>>> prevent a receiver from using them). >>>>> >>>>> o They can try to compromise the receiver's behavior (e.g., > by >>>>> making the decoding of an object computationally > expensive). >>>>> o They can try to compromise the network's behavior (e.g., > by >>>>> causing congestion within the network). >>>>> >>>>> These attacks can be launched either against the source >>>>> and/or repair >>>>> flows (e.g., by sending forged 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 a session description). >>>>> >>>>> 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 before the FEC protection, or, if done after the FEC >>>>> protection, then this encryption MUST be applied on >> both the FEC >>>>> source packets and repair packets. Otherwise, if >>>>> encryption were to >>>>> be performed only on the FEC source packets after FEC >>>>> encoding, then >>>>> a non-authorized receiver could be able to recover the source >>>> data >>>>> after decoding the repair packets provided that a sufficient >>>> number >>>>> of such packets were available. >>>>> >>>>> 9.2.2. Content Corruption >>>>> >>>>> Protection against corruptions (e.g., after sending 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. >>>> 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 >>>>> knows 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. >>>>> 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 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. >>>>> This approach is documented here to provide a reference of an >>>>> interoperable secure mode of operation. However, other >>>> approaches, >>>>> including other forms of IPsec application, MAY be used or >>>>> specified >>>>> in the future. >>>>> >>>>> 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 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From luby@qualcomm.com Mon Dec 13 15:58:16 2010 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 296463A6E0F for ; Mon, 13 Dec 2010 15:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3gWqTBrBahnZ for ; Mon, 13 Dec 2010 15:58:13 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 80FBA3A6E08 for ; Mon, 13 Dec 2010 15:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1292284792; x=1323820792; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Vi ncent=20Roca=20,=20David=20Har rington=0D=0A=09|CC:=20"Ali=20C.=20B egen=20(abegen)"=20,=20"fecframe@ietf.o rg"=0D=0A=09,=20"Luby,=20Michael"=20|Date:=20Mon,=2013=20Dec=202010=2015:59: 50=20-0800|Subject:=20Re:=20[Fecframe]=20Proposed=20chang es=20to=20the=20framework=20draft=20-=20part=0D=0A=202(se curity)|Thread-Topic:=20[Fecframe]=20Proposed=20changes =20to=20the=20framework=20draft=20-=20part=0D=0A=202(secu rity)|Thread-Index:=20AcubD1gySoU9wiBsQxmT5XGz+d7fBAAEnuc /|Message-ID:=20 |In-Reply-To:=20<4D069459.9060501@inrialpes.fr> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.7.0.100913|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=rH0ml9nwn7As1sdsOP9nA5qfNLTdWrFQ3ED/jEzmKK8=; b=ymTjicO2WDKRH/HaNPdUvLBrZTw6JWWTz+o6Cvlf7xxOIteoXz3N1V74 lQHB3I2DwrbSp51tucFhZggeeiRqfggTNJhrsl3ja5EzesOozuDjFjbDy +g0clAcuUuiXMgDrb5bSSj9DPY288dP6wAqhf2s3m087hfheYt9q3YqyH g=; X-IronPort-AV: E=McAfee;i="5400,1158,6196"; a="66684412" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 13 Dec 2010 15:59:52 -0800 X-IronPort-AV: E=Sophos;i="4.59,335,1288594800"; d="scan'208";a="36028576" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 13 Dec 2010 15:59:52 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 13 Dec 2010 15:59:52 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Mon, 13 Dec 2010 15:59:34 -0800 From: "Luby, Michael" To: Vincent Roca , David Harrington Date: Mon, 13 Dec 2010 15:59:50 -0800 Thread-Topic: [Fecframe] Proposed changes to the framework draft - part 2(security) Thread-Index: AcubD1gySoU9wiBsQxmT5XGz+d7fBAAEnuc/ Message-ID: In-Reply-To: <4D069459.9060501@inrialpes.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.7.0.100913 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 23:58:16 -0000 Vincent, I'm not really getting the distinction between (1) and (2) below in terms o= f being independent of FECFRAME or not, as I don't think that is the axis of distinction between the examples you list in (1) and (2). All the security requirements that FECFRAME needs to address are because FECFRAME is being used, i.e., roughly your category (2) below. FECFRAME is simply an augmentation of existing delivery protocols that are already being used for delivering streams of content. For example, what you list in (1) wrt whether security is done above/below FECFRAME is only an issue because of the use of FECFRAME, and the issue is that if FECFRAME is used after decryption then there is a new vulnerability introduced because of the usag= e of FECFRAME and the security model in usage, i.e., if there was no need to do any processing such as FEC decoding, there would be no issue, and thus this is very much an issue introduced by the usage of FECFRAME. This is similar to the things you've listed in category (2), i.e., there are new opportunities for attacks to send forged repair packets, exactly because FECFRAME is being used and there are repair packets sent because of the usage of FECFRAME which would not have been sent (and vulnerable) if FECFRAME were not being used. Perhaps your distinction axis is security attacks in the end-to-end transport versus security attacks within the end device, this seems to make sense. But in both cases, the security attacks that need to be discussed and dealt with are those that relate specifically to the usage of FECFRAME and where it might expose vulnerabilities in both contexts, and it seems appropriate to address both contexts. BTW, a third axis is the security in the servers that are adding FECFRAME formatting to the outgoing packets, an= d 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.) Mike On 12/13/10 1:47 PM, "Vincent Roca" wrote: > Hello everybody, > > I think we need to distinguish two different sets of security requirement= s: > > 1/ end2end, application-level security, independently of FECFRAME: > The upper application may have specific requirements. As already discusse= d, > if encryption is needed, it's often preferable to do that above FECFRAME. > This is where all types of DRM solutions fit, and SRTP may be useful too > (even if it is restricted to RTP flows). > =3D> Relying on IPsec/ESP to achieve this end2end security is inappropria= te > (cf. previous discussion whether encryption should happen before FEC > encoding or not). > > 2/ because of the use of FECFRAME: > The motivation is that FECFRAME adds new opportunities for attacks (e.g. > by sending forged repair packets). So it makes sense to follow a global > security approach that prevents or mitigates these attacks, independently > of the potential security requirements of individual source flows. This > approach will consider all flows generated by a FECFRAME sender. > =3D> Relying on IPsec/ESP to achieve this is meaningful. On the opposite, > security mechanisms that happen above FECFRAME is of little help. > I don't know if there is another alternative to IPsec? Any idea? > > So the two sets of requirements seem complementary to me. > > Now there are special cases... > For instance, because the network infrastructure is assumed reasonably > secure (with 3GPP networks, or DVB broadcast networks, etc.) it can make > sense to ignore 2/. Additionally, FECFRAME is probably just one small > component of a much larger protocol stack in many deployments, as Mike > reminded. Defining a mandatory to implement security solution just > because a few repair packets are sent seems strange... > > However the guideline (RFC3365) is to be able to use a secure mode of > operations in all IETF protocols. > My interpretation is that because FECFRAME adds new threats, this securit= y > solution MUST prevent or mitigate these extra threats. So addressing poin= t > 2/ is the goal IMHO. When FECFRAME is used in a protected environment > (e.g. 3GPP example above), this secure mode of operation won't be used, > that's all. > > --- > NB: It reminds me of a recent SecDir discussion whether the fact IPsec > must be available for IPv6 conformance should be relaxed or not. > some lightweight IPv6 terminals will probably never ever include IPsec. > I don't remember if we reached a consensus here, but the situation > is similar. Is it too much of a burden to have this "IPsec/ESP MUST > implement" requirement in FECFRAME as well? > --- > > Another point... David says: > > "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!). > > > Regards, > > Vincent > > > On 11/12/10 01:40, David Harrington wrote: >> Hi Mike and Ali, >> >> If you want to avoid a mandatory-to-implement security solution, I >> think you should document very clearly in the security considerations >> section why it makes little sense to have one. The argument in this >> email is a good step in the right direction. >> >> 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: Friday, December 10, 2010 7:24 PM >>> To: Ali C. Begen (abegen); David Harrington; fecframe@ietf.org >>> Subject: Re: [Fecframe] Proposed changes to the framework >>> draft - part 2(security) >>> >>> The security provided for streaming (if used) depends a lot >>> more on the >>> content and characteristics of the original stream then it >>> does on the FEC >>> repair added to the stream (if FEC is used): the FEC is a >>> very small part of >>> the overall consideration, so it would be unusual if the >>> security should be >>> selected based on the FEC being used (except that of course >>> the security, if >>> used, should not be incompatible with the FEC -- but this is already >>> discussed in the document about how FEC can affect an already >> selected >>> security solution). >>> >>> Thus I'm wondering if it makes sense for FECFRAME to define a >>> mandatory >>> security? It seems similar to the congestion control issue, >>> i.e., the FEC >>> is a supplemental component that provides some QoS, and I >>> think the idea >>> there is that FEC can only add a limited fraction of >>> bandwidth to a stream, >>> but it is really the stream that defines the rate/congestion >>> control, and >>> the FEC reacts naturally in response, but the FEC doesn't >>> define a whole new >>> congestion control because that is really a function of how >>> the original >>> content in the stream is delivered. >>> >>> Among the security solutions that would really be used for >>> streaming, the >>> most likely candidates are DRMs of various sorts with all >>> kinds of different >>> IPRs. If we mandate a security solution that would really be used >> in >>> practice, there is this issue as well. >>> >>> >>> On 12/10/10 4:08 PM, "Ali C. Begen (abegen)" >> wrote: >>>> I will let others chime in as well. >>>> >>>> For the mandatory security protocol, neither SRTP nor IPsec >>> nor something else >>>> makes sense. SRTP could only be mandated for RTP flows >>> *maybe*. Even that I >>>> don't know why every FEC application would need to >>> implement security for FEC. >>>> For many such applications, the content itself is secured >>> and FEC is dealt >>>> separately. IPsec should not be required every time FEC is >>> needed, either. >>>> Some FEC applications do not require security at all. >>>> >>>> Does fecframe really require a mandatory security solution? >>>> >>>> Does every fecframe application need to protect the session >>> description? BTW, >>>> even using SDP is not required for fecframe so I don't >>> understand why we need >>>> a mandatory solution to protect the SDP descriptions. >>>> >>>> FYI, the text below has been modified based on the list >>> discussion. See other >>>> emails on this thread if you need the latest version. >>>> >>>> -acbegen >>>> >>>>> -----Original Message----- >>>>> From: David Harrington [mailto:ietfdbh@comcast.net] >>>>> Sent: Friday, December 10, 2010 9:12 AM >>>>> To: Ali C. Begen (abegen); fecframe@ietf.org >>>>> Subject: RE: [Fecframe] Proposed changes to the framework >>> draft - part >>>>> 2(security) >>>>> >>>>> Hi, >>>>> >>>>> I think this security text is very good. It clearly describes the >>>>> possible issues, and steps to take to mitigate the issues, >>> including >>>>> recommended protocols. >>>>> >>>>> I fail to see a mandatory to implement solution, to support >> minimum >>>>> interoperability. If it is in this text, it should be more >> clearly >>>>> marked as mandatory to implement. >>>>> >>>>> If vendor A uses SRTP to protect against content sorruption, and >>>>> vendor B uses IPsec, these two implementations will not >>> interoperate. >>>>> You are not defining either of these as >>> mandatory-to-implement. Many >>>>> vendors might choose to implement neither since neither is >>> mandatory >>>>> for compliance. That means an operator might have neither >>> available to >>>>> provide protection. >>>>> >>>>> I don't see a mandatory to implement protocol for protecting the >>>>> session description. >>>>> >>>>> Please see RFC 3365, which requires strong security for IETF >>>>> standards. I don't think your text provides for strong security. >>>>> >>>>> 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." >>>>> >>>>> 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: Wednesday, December 01, 2010 12:30 PM >>>>>> To: fecframe@ietf.org >>>>>> Subject: [Fecframe] Proposed changes to the framework draft - >>>>>> part 2(security) >>>>>> >>>>>> This is the 2nd part for the changes we need to make in the >>>>>> framework draft. This part is related to the security issues. >>>>>> Please refer to the tracker to see the comments from the IESG. >>>>>> >>>>>> >> https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/ >>>>>> I would like to thank Vincent for providing this brand new >>>>>> security section. I just added a few minor points into the text. >>>>>> >>>>>> If there are any objections, please speak up. If you are OK >>>>>> with these changes, please also speak up so that we can show >>>>>> WG consensus. >>>>>> >>>>>> Thanks, >>>>>> -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. >>>>>> Some of them target the network (e.g., to compromise >>> the routing >>>>>> infrastructure by compromising the congestion control >>> component), >>>>>> others can target the Content Delivery Protocol (CDP) (e.g., >> to >>>>>> compromise its normal behavior), and finally some attacks >>>>>> target the >>>>>> content itself. >>>>>> >>>>>> More specifically, these 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 and/or repair >>> flows (e.g., >>>>> to >>>>>> prevent a receiver from using them). >>>>>> >>>>>> o They can try to compromise the receiver's behavior (e.g., >> by >>>>>> making the decoding of an object computationally >> expensive). >>>>>> o They can try to compromise the network's behavior (e.g., >> by >>>>>> causing congestion within the network). >>>>>> >>>>>> These attacks can be launched either against the source >>>>>> and/or repair >>>>>> flows (e.g., by sending forged 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 a session description). >>>>>> >>>>>> 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 before the FEC protection, or, if done after the FEC >>>>>> protection, then this encryption MUST be applied on >>> both the FEC >>>>>> source packets and repair packets. Otherwise, if >>>>>> encryption were to >>>>>> be performed only on the FEC source packets after FEC >>>>>> encoding, then >>>>>> a non-authorized receiver could be able to recover the source >>>>> data >>>>>> after decoding the repair packets provided that a sufficient >>>>> number >>>>>> of such packets were available. >>>>>> >>>>>> 9.2.2. Content Corruption >>>>>> >>>>>> Protection against corruptions (e.g., after sending 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. >>>>> 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 >>>>>> knows 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. >>>>>> 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 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. >>>>>> This approach is documented here to provide a reference of an >>>>>> interoperable secure mode of operation. However, other >>>>> approaches, >>>>>> including other forms of IPsec application, MAY be used or >>>>>> specified >>>>>> in the future. >>>>>> >>>>>> 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 >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe From vincent.roca@inrialpes.fr Wed Dec 15 02:57:04 2010 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 4C0B33A702B for ; Wed, 15 Dec 2010 02:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 awRi7Bz1IiIA for ; Wed, 15 Dec 2010 02:57:03 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id D230F3A702A for ; Wed, 15 Dec 2010 02:57:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.59,347,1288566000"; d="scan'208";a="92420030" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 15 Dec 2010 11:58:43 +0100 Message-ID: <4D089F54.7000304@inrialpes.fr> Date: Wed, 15 Dec 2010 11:58:28 +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: "Luby, Michael" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 10:57:04 -0000 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 From abegen@cisco.com Fri Dec 17 08:55:07 2010 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 9EB743A6B92 for ; Fri, 17 Dec 2010 08:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.429 X-Spam-Level: X-Spam-Status: No, score=-10.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 tLcUw5K15YDZ for ; Fri, 17 Dec 2010 08:55:06 -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 039873A68F1 for ; Fri, 17 Dec 2010 08:55:06 -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: AvsEAHYlC02rR7Hu/2dsb2JhbACkMXOnCJtAgnKCWASEZYk4 X-IronPort-AV: E=Sophos;i="4.59,362,1288569600"; d="scan'208";a="637558588" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 17 Dec 2010 16:56:53 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oBHGurG2011940 for ; Fri, 17 Dec 2010 16:56:53 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Dec 2010 08:56:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Dec 2010 08:56:36 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540DEF39DC@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised security section for the framework Thread-Index: AcueCxews5v+ilRKRFaHhxvsQr3dHA== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 17 Dec 2010 16:56:53.0285 (UTC) FILETIME=[67C2F550:01CB9E0B] Subject: [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: Fri, 17 Dec 2010 16:55:07 -0000 Please let us know if these changes are good or if you have comments. We = would like to conclude this work soon.=20 -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. From vincent.roca@inrialpes.fr Mon Dec 20 07:09:36 2010 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 67A613A67D4 for ; Mon, 20 Dec 2010 07:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 31a692LwbAET for ; Mon, 20 Dec 2010 07:09:34 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id D44333A67D1 for ; Mon, 20 Dec 2010 07:09:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,202,1291590000"; d="scan'208";a="71159500" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 20 Dec 2010 16:11:26 +0100 Message-ID: <4D0F721D.4020805@inrialpes.fr> Date: Mon, 20 Dec 2010 16:11:25 +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: <04CAD96D4C5A3D48B1919248A8FE0D540DEF39DC@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540DEF39DC@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 20 Dec 2010 15:09:36 -0000 Hello everybody, FYI the proposed security section below implements the comments I've sent to the list on Dec 15th. More precisely: - section 9.1 "Problem statement" => Completely rewritten to clarify the various dimensions of the problem. - Topic 1: "Should encryption be applied after or before FEC protection?" => Already discussed in the previous version of the security section. - Topic 2: "Is SRTP a solution and how should SRTP be used along with FECFRAME?" => Discussed in section 9.1, last but one paragraph, and in section 9.2.1 for encryption related aspects. - Topic 3: "Is IPsec a solution and how should it be used along with FECFRAME?" => It remains the mandatory to implement (but not mandatory to use) security scheme, even if it cannot address all possible needs (like application level content confidentiality). - Topic 4: "What about attacks on the FECFRAME component itself?" => No change (see my email date Dec 15th for more details). - Topic 5: "What about attacks on the session description?" => we updated the second paragraph of section 9.3 "Attacks against the FEC Parameters". Basically, we cannot recommend anything, but any complete CDP specification MUST provide recommendations. Let us know if you have further comments. Cheers, Vincent. On 17/12/10 17:56, Ali C. Begen (abegen) wrote: > 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 vincent.roca@inrialpes.fr Tue Dec 21 08:04:03 2010 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 D66003A6B21 for ; Tue, 21 Dec 2010 08:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 DZ6wmEbH4N3R for ; Tue, 21 Dec 2010 08:04:02 -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 272CF3A6B0C for ; Tue, 21 Dec 2010 08:04:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,208,1291590000"; d="scan'208";a="83309781" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 21 Dec 2010 17:05:57 +0100 Message-ID: <4D10D064.7090004@inrialpes.fr> Date: Tue, 21 Dec 2010 17:05:56 +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> In-Reply-To: <4E3DAC27-ED71-4B28-BDEA-4F241242C842@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 21 Dec 2010 16:04:03 -0000 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_2010jul25_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