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

From: Greg Shepherd <[email-masked]>
Date: Mon, 10 Jan 2011 10:22:17 -0800

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

Thanks,
Greg

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 10 Jan 2011 20:35:38 +0100

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

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

-acbegen

---

From: "David Harrington" <[email-masked]>
Date: Sat, 15 Jan 2011 13:00:35 -0500

Hi,
 
Since this is a framework document, it is likely to be the first
document an operator will read regarding the deployment of fec in
their existing environment.
 
Please add a section to the document: operational considerations.
(this is really deployment considerations)
In this section please discuss what an operator should know about
deploying fec.
This should include the expected impact to traffic loads, what
infrastructure must exist to support fec (e.g DNS) , and so on.
 
Please add a section to the document: management considerations.
In this section, please discuss how an operator/NOC/NMS is expected to
communicate with the devices on which fec is deployed.
Mostly this should deal with how does one configure fec, and how does
one monitor fec?
It should include a discussion of configuration issues, the
asynchronous reporting of fec error conditions, and the querying of
operational state and statistics.
>From a framework perspective ...
 
dbh

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ali C. Begen (abegen)
Sent: Monday, January 10, 2011 2:36 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Fecframe] Proposed changes to the framework draft
-part2(security)

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

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

-acbegen

Thanks,
Greg

On Wed, Dec 15, 2010 at 2:58 AM, Vincent Roca
<[email-masked]> wrote:
>  <mailto:[email-masked]> [email-masked]
>  <https://www.ietf.org/mailman/listinfo/fecframe>
_______________________________________________
Fecframe mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/fecframe>
https://www.ietf.org/mailman/listinfo/fecframe

---

From: Greg Shepherd <[email-masked]>
Date: Sat, 15 Jan 2011 17:19:04 -0800

Dave,

Can you please read and comment on the other feedback on this thread
before adding more requirements?

Thanks,
Greg

On Sat, Jan 15, 2011 at 10:00 AM, David Harrington <[email-masked]> wrote:
> Hi,
>
> Since this is a framework document, it is likely to be the first document an
> operator will read regarding the deployment of fec in their existing
> environment.
>
> In this section please discuss what an operator should know about deploying
> fec.
> Mostly this should deal with how does one configure fec, and how does one
> monitor fec?
> It should include a discussion of configuration issues, the asynchronous
> reporting of fec error conditions, and the querying of operational state and
> statistics.
> ________________________________
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ali C. Begen (abegen)
> Yes the discusses around the sec issues should be resolved with the revision
> but I am still expecting to hear from the AD about the other discuss related
> to the ops and management. He is yet to respond to the responses made to his
> email about the proposed text.