Re: [Fecframe] Proposed changes to the framework draft - part 2 (security)

[Greg Shepherd <[e-mail]>]

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) <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fecframe
>