Subject: Re: [Fecframe] Revised security section for the framework

From: "David Harrington" <[email-masked]>
Date: Tue, 18 Jan 2011 13:13:15 -0500

Hi,

FYI. Today I raised my concerns to the level of a DISCUSS.
The content of the DISCUSS is being sent under a separate email.

I have two parts to my discuss
1) the lack of discussion of ops+mgmt. I have tried to make my
comments actionable.
2) a larger concern thatthe frameowkr has no mandatory-to-implement
components. This is a discuss-discuss, which means I am opening the
discussion within the IESG about whether this is acceptable for a
Proposed Standard framework document.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ali C. Begen
(abegen)
> Sent: Friday, December 17, 2010 11:57 AM
> To: [email-masked]
> Subject: [Fecframe] Revised security section for the framework
> 
> Please let us know if these changes are good or if you have 
> comments. We would like to conclude this work soon. 
> 
> -acbegen
> 
> 
> 9.  Security Considerations
> 
>    First of all, it must be clear that the application of FEC 
> protection
>    to a stream does not provide any kind of security.  On the 
> opposite,
>    the FEC Framework itself could be subject to attacks, or could
pose
>    new security risks.  The goals of this section are to state the
>    problem, discuss the risks and identify solutions when 
> feasible.  It
>    also defines a mandatory to implement (but not mandatory to use)
>    security scheme.
> 
> 9.1.  Problem Statement
> 
>    A content delivery system is potentially subject to many attacks.
>    Attacks can target the content, or the CDP, or the network
itself,
>    with completely different consequences, in particular in 
> terms of the
>    number of impacted nodes.
> 
>    Attacks can have several goals:
> 
>    o  They can try to give access to a confidential content (e.g.,
in
>       case of a non-free content).
> 
>    o  They can try to corrupt the source flows (e.g., to prevent a
>       receiver from using them), which is a form of DoS attack.
> 
>    o  They can try to compromise the receiver's behavior (e.g., by
>       making the decoding of an object computationally 
> expensive), which
>       is another form of DoS attack.
> 
>    o  They can try to compromise the network's behavior (e.g., by
>       causing congestion within the network), which 
> potentially impacts
>       a large number of nodes.
> 
>    These attacks can be launched either against the source 
> and/or repair
>    flows (e.g., by sending fake FEC source and/or repair packets) or
>    against the FEC parameters that are sent either in-band 
> (e.g., in the
>    Repair FEC Payload ID or in the Explicit Source FEC Payload ID)
or
>    out-of-band (e.g., in the FEC Framework Configuration
Information).
> 
>    Several dimensions to the problem need to be considered.  The
first
>    one is the way the FEC Framework is used.  The FEC Framework can
be
>    used end-to-end, i.e., it can be included in the final end-device
>    where the upper application runs; or the FEC Framework can 
> be used in
>    middleboxes, for instance, to globally protect several source
flows
>    exchanged between two or more distant sites.
> 
>    A second dimension is the threat model.  When the FEC Framework
>    operates in the end-device, this device (e.g., a personal
computer)
>    might be subject to attacks.  Here, the attacker is either the
end-
>    user (who might want to access confidential content) or somebody
>    else.  In all cases the attacker has access to the end-device,
but
>    not necessarily to the full control of the end-device (a secure
>    domain can exist).  Similarly, when the FEC Framework operates in
a
>    middlebox, this middlebox can be subject to attacks or the
attacker
>    can gain access to it.  The threats can also concern the
end-to-end
>    transport (e.g., through Internet).  Here, examples of threats
>    include the transmission of fake FEC source or repair packets,
the
>    replay of valid packets, the drop, delay or misordering of
packets,
>    and of course traffic eavesdropping.
> 
>    The third dimension consists in the desired security 
> services.  Among
>    them, the content integrity and sender authentication services
are
>    probably the most important features.  We can also mention DoS
>    mitigation, anti-replay protection or content confidentiality.
> 
>    Finally, the fourth dimension consists in the security tools
>    available.  This is the case of the various Digital Rights 
> Management
>    (DRM) systems, defined out of the context of the IETF and 
> that can be
>    proprietary solutions.  Otherwise SRTP and IPsec/ESP are two
tools
>    that can turn out to be useful in the context of the FEC
Framework.
>    Note that using SRTP requires that the application generates RTP
>    source flows and, when applied below the FEC Framework, 
> that both the
>    FEC source and repair packets to be regular RTP packets.
Therefore
>    SRTP is not considered as a universal solution applicable 
> in all use
>    cases.
> 
>    In the following sections, we further discuss security aspects
>    related to the use of the FEC Framework.
> 
> 9.2.  Attacks Against the Data Flows
> 
> 9.2.1.  Access to Confidential Content
> 
>    Access control to the source flow being transmitted is typically
>    provided by means of encryption.  This encryption can be 
> done by the
>    content provider itself, or within the application (for instance
by
>    using the Secure Real-time Transport Protocol (SRTP) [RFC3711]),
or
>    at the network layer, on a per-packet basis when IPsec/ESP is
used
>    [RFC4303].  If confidentiality is a concern, it is RECOMMENDED
that
>    one of these solutions is used.  Even if we mention these attacks
>    here, they are neither related to nor facilitated by the 
> use of FEC.
> 
>    Note that when encryption is applied, this encryption MUST 
> either be
>    applied on the source data before the FEC protection, or if done
>    after the FEC protection, then both the FEC source packets 
> and repair
>    packets MUST be encrypted (and an encryption at least as
>    cryptographically secure as the encryption applied on the 
> FEC source
>    packets MUST be used for the FEC repair packets).  Otherwise, if
>    encryption were to be performed only on the FEC source 
> packets after
>    FEC encoding, a non-authorized receiver could be able to 
> recover the
>    source data after decoding the FEC repair packets provided that a
>    sufficient number of such packets were available.
> 
>    The following considerations apply when choosing where to apply
>    encryption (and more generally where to apply security services
>    beyond encryption).  Once decryption has taken place, the 
> source data
>    is in plaintext.  The full path between the output of the 
> deciphering
>    module and the final destination (e.g., the TV display in case of
a
>    video) MUST be secured, in order to prevent any unauthorized
access
>    to the source data.
> 
>    When the FEC Framework endpoint is the end system (i.e., where
the
>    upper application runs) and if the threat model includes the
>    possibility that an attacker has access to this end 
> system, then the
>    end system architecture is very important.  More 
> precisely, in order
>    to prevent an attacker to get hold of the plaintext, all 
> processings,
>    once deciphering has taken place, MUST occur in a protected
>    environment.  If encryption is applied after FEC protection at
the
>    sending side (i.e., below FEC Framework), it means that 
> FEC decoding
>    MUST take place in the protected environment.  With certain use
>    cases, this MAY be complicated or even impossible.  In that case
>    applying encryption before FEC protection is preferred.
> 
>    When the FEC Framework endpoint is a middlebox, the 
> recovered source
>    flow, after FEC decoding, SHOULD NOT be sent in plaintext to the
>    final destination(s) if the threat model includes the possibility
>    that an attacker eavesdrops the traffic.  In that case also it is
>    preferred to apply encryption before FEC protection.
> 
>    In some cases, encryption could be applied both before and 
> after the
>    FEC protection.  The considerations described above still apply
in
>    such cases.
> 
> 9.2.2.  Content Corruption
> 
>    Protection against corruptions (e.g., against forged FEC source/
>    repair packets) is achieved by means of a content integrity
>    verification/source authentication scheme.  This service is
usually
>    provided at the packet level.  In this case, after removing all
the
>    forged packets, the source flow might sometimes be recovered.
>    Several techniques can provide this content integrity/source
>    authentication service:
> 
>    o  At the application layer, SRTP [RFC3711] provides several
>       solutions to check the integrity and authenticate the source
of
>       RTP and RTCP messages, among other services.  For instance,
>       associated to the Timed Efficient Stream Loss-Tolerant
>       Authentication (TESLA) [RFC4383], SRTP is an attractive
solution
>       that is robust to losses, provides a true 
> authentication/integrity
>       service, and does not create any prohibitive processing load
or
>       transmission overhead.  Yet, checking a packet requires a
small
>       delay (a second or more) after its reception with 
> TESLA.  Whether
>       this extra delay, both in terms of startup delay at the 
> client and
>       end-to-end delay, is appropriate or not depends on the 
> target use
>       case.  In some situations, this might degrade the user 
> experience.
>       In other situations, this will not be an issue.  Other
building
>       blocks can be used within SRTP to provide content integrity/
>       authentication services.
> 
>    o  At the network layer, IPsec/ESP [RFC4303] offers (among other
>       services) an integrity verification mechanism that can 
> be used to
>       provide authentication/content integrity services.
> 
>    It is up to the developer and the person in charge of 
> deployment, who
>    know the security requirements and features of the target 
> application
>    area, to define which solution is the most appropriate.  
> Nonetheless
>    it is RECOMMENDED that at least one of these techniques is used.
> 
>    Note that when integrity protection is applied, it is RECOMMENDED
>    that it takes place on both FEC source and repair packets.  The
>    motivation is to avoid corrupted packets to be considered during
>    decoding, which would often lead to a decoding failure or 
> result in a
>    corrupted decoded source flow.
> 
> 9.3.  Attacks Against the FEC Parameters
> 
>    Attacks on these FEC parameters can prevent the decoding of the
>    associated object.  For instance, modifying the finite 
> field size of
>    a Reed-Solomon FEC scheme (when applicable) will lead a receiver
to
>    consider a different FEC code.
> 
>    It is therefore RECOMMENDED that security measures are taken to
>    guarantee the FEC Framework Configuration Information integrity.
>    Since the FEC Framework does not define how the FEC Framework
>    Configuration Information is communicated from sender to 
> receiver, we
>    cannot provide further recommendations on how to guarantee its
>    integrity.  However, any complete CDP specification MUST give
>    recommendations on how to achieve it.  When the FEC Framework
>    Configuration Information is sent out-of-band, e.g., in a session
>    description, it SHOULD be protected, for instance, by digitally
>    signing it.
> 
>    Attacks are also possible against some FEC parameters 
> included in the
>    Explicit Source FEC Payload ID and Repair FEC Payload ID.  For
>    instance, modifying the Source Block Number of an FEC source or
>    repair packet will lead a receiver to assign this packet to a
wrong
>    block.
> 
>    It is therefore RECOMMENDED that security measures are taken to
>    guarantee the Explicit Source FEC Payload ID and Repair FEC
Payload
>    ID integrity.  To that purpose, one of the packet-level source
>    authentication/content integrity techniques of Section 9.2.2 can
be
>    used.
> 
> 9.4.  When Several Source Flows are to be Protected Together
> 
>    When several source flows, with different security 
> requirements, need
>    to be FEC protected jointly, within a single FEC Framework 
> instance,
>    then each flow MAY be processed appropriately, before the 
> protection.
>    For instance, source Flows that require access control MAY be
>    encrypted before they are FEC protected.
> 
>    There are also situations where the only insecure domain is the
one
>    over which the FEC Framework operates.  In that case, this 
> situation
>    MAY be addressed at the network layer, using IPsec/ESP (see
>    Section 9.5), even if only a subset of the source flows have
strict
>    security requirements.
> 
>    Since the use of FEC Framework should not add any 
> additional threat,
>    it is RECOMMENDED that the FEC Framework aggregate flow be in
line
>    with the maximum security requirements of the individual source
>    flows.  For instance, if denial-of-service (DoS) protection is
>    required, an integrity protection SHOULD be provided below the
FEC
>    Framework, using for instance IPsec/ESP.
> 
>    Generally speaking, whenever feasible, it is RECOMMENDED 
> to avoid FEC
>    protecting flows with totally different security requirements.
>    Otherwise, an important processing would be added to protect the
>    source flows that do not need it.
> 
> 9.5.  Baseline Secure FEC Framework Operation
> 
>    This section describes a baseline mode of secure FEC Framework
>    operation based on the application of the IPsec security
protocol,
>    which is one possible solution to solve or mitigate the security
>    threats introduced by the use of the FEC Framework.
> 
>    Two related documents are of interest.  First, Section 5.1 of
>    [RFC5775] defines a baseline secure ALC operation for 
> sender-to-group
>    transmissions, assuming the presence of a single sender 
> and a source-
>    specific multicast (SSM) or SSM-like operation.  The proposed
>    solution, based on IPsec/ESP, can be used to provide a baseline
FEC
>    Framework secure operation, for the downstream source flow.
> 
>    Second, Section 7.1 of [RFC5740] defines a baseline secure NORM
>    operation, for sender-to-group transmissions as well as unicast
>    feedbacks from receivers.  Here, it is also assumed there 
> is a single
>    sender.  The proposed solution is also based on IPsec/ESP. 
>  However,
>    the difference with respect to the first document relies on the
>    management of IPsec Security Associations (SA) and corresponding
>    Security Policy Database (SPD) entries, since NORM 
> requires a second
>    set of SA and SPD to be defined to protect unicast feedbacks from
>    receivers.
> 
>    The FEC Framework has been defined in such a way to be
independent
>    from the application that generates source flows.  Some 
> applications
>    might use purely unidirectional flows, while other 
> applications might
>    also use unicast feedbacks from the receivers.  For 
> instance, this is
>    the case when considering RTP/RTCP based source flows.  
> Depending on
>    the specific situation, it is RECOMMENDED that the baseline
secure
>    FEC Framework operation inherits from [RFC5775] in case of purely
>    unidirectional sender-to-group flows, or [RFC5740] in case both
>    sender-to-group and unicast feedbacks flows are needed.
> 
>    Note that the IPsec/ESP requirements profiles outlined in
[RFC5775]
>    and [RFC5740] are commonly available on many potential hosts.
They
>    can form the basis of a secure mode of operation.  One potential
>    limitation, however, is the need for privileged user
authorization.
>    However, automated key management implementations are typically
>    configured with the privileges necessary to affect system IPsec
>    configuration.
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 Jan 2011 10:17:08 -0800

Should we submit the current version we have with the extended security cons section so that at least we can try to clear the sec related discusses? 

-acbegen

> From: David Harrington [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2011 1:13 PM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: RE: [Fecframe] Revised security section for the framework
> 
> Hi,
>

---

From: "David Harrington" <[email-masked]>
Date: Tue, 18 Jan 2011 13:28:56 -0500

yes. please do, and I will push the other ADs to review the changes
and clear where possible.

I will note that the new text does not seem to specify that IPsec
implementation is REQUIRED (using RFC2119 language).
It is only presented as a baseline, and one possible approach.
Therefore, I expect it will not satisfy Sean's DISCUSS.

dbh 

> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Tuesday, January 18, 2011 1:17 PM
> To: David Harrington; [email-masked]
> Should we submit the current version we have with the 
> extended security cons section so that at least we can try to 
> clear the sec related discusses? 
> 
> -acbegen
>

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 18 Jan 2011 14:10:25 -0500

Hi David, IESG,
I don't believe the DISCUSSes are helpful.  You guys are pushing the WG to
add text that the WG does not deem necessary.  Have you thought about the
reasons for the WG's position?
My understanding is that the fecframe protocol suite will, practically,
used in conjunction with IPTV, mobile TV, and so on.  Many, of not most,
of this applications run over IP networks that are NOT the Internet (in
that a majority of the traffic may not be Internet traffic, though there
may be Internet traffic routed on the same infrastructure to the same
endpoints).  In this application space, (perhaps) most security issues,
and certainly most, if not all, operational issues, are either not
formally standardized, or standardized in documents by 3GPP, ETSI, ITU,
whatnot.  These customer organizations may refer to IETF specs for solving
any issues they deem necessary to be solved, or they may devise their own
solution.  One example for this is, in the IPTV field, the XML-coded
session descriptions Ali has already referred to.
The IETF specs of fecframe are low level, media-plane tools.
Interoperability absolutely must be possible on that low level.  But
that's it, IMO.  Requiring certain security or operational technologies,
that the customer SDOs may be specifying very differently, is counter
productive, as the relevant sections may well be ignored by the majority,
if not by all, implementations, for reasons of practicality.  Since you
cannot enforce the implementation of those technologies (beyond putting
meaningless 2119 words in the sections in question), why do you try?
So my suggestion would be that
-the security, ops, congestion control, whatnot sections ideally should
point out the security/ops/cc/whatnot issues the framework may have, but
leave the implementer or customer SDO to choose between available tools to
solve those issues if there is a commercial need for solving them.  In
other words, those sections should include requirements.  They may hint to
solutions, but should not require implementation or use.
-if you insist on adding requirements that an implementation can ignore
without hurting the core protocol's interoperability, then at least
qualify your 2119 requirements with a phrase such as "if used on the
Internet".  If you don't, you may have formally non-compliant
implementations out there, to which, arguably, many of the IPR
declarations do not apply.  This cannot be your wish, can it?
Regards,
Stephan

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 Jan 2011 13:56:19 -0800

I submitted -12. It should address Russ', Robert's and Sean's discusses if not all.

-acbegen

> Sent: Tuesday, January 18, 2011 1:29 PM

---

From: "David Harrington" <[email-masked]>
Date: Tue, 18 Jan 2011 19:58:09 -0500

Hi Stephan,

The really sad part about this whole conversation is that what the
IESG has been pushing for is a documented consideration of the ops and
mgmt perspective, much like the one in your email, and Ali's emails,
and Dave's emails, and Mike's emails, but they want the discussion
captured **** in the document ****.

But what we get in the document is the assertion that the WG has
decided any such discussion is out of scope of the document (and
presumably the framework), rather than documenting the details of the
WG's considerations.

My #2 discuss is about whether we should expect some
mandatory-to-implement components or not, since without
mandatory-to-implement components, vendors ar elikely to not implement
common components, and operators cannot choose a consistent set of
components for their deployments in multi-vendor environments. 

This is a discuss-discuss, which means I am not pushing for any action
by the authors; I want a discussion among the IESG about the potential
impact of not having mandatory components, and whether fecframe is one
of the acceptable exceptions to the rule.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> From: Stephan Wenger [mailto:[email-masked]] 
> Sent: Tuesday, January 18, 2011 2:10 PM
> Subject: Re: [Fecframe] Revised security section for the framework
> 
> Hi David, IESG,
> >> > >    new security risks.  The goals of this section are to
state
> >> > >    o  They can try to corrupt the source flows (e.g., 
> to prevent
> >a
> >> > >    o  They can try to compromise the receiver's behavior
(e.g.,
> >> > >    o  They can try to compromise the network's behavior
(e.g.,
> >> > >    Repair FEC Payload ID or in the Explicit Source FEC
Payload
> >ID)
> >> > >    environment.  If encryption is applied after FEC
protection
> >at
> >> > >    MUST take place in the protected environment.  With
certain
> >use
> >> > >    provided at the packet level.  In this case, after
removing
> >all
> >> > >    Attacks on these FEC parameters can prevent the decoding
of
> >> > >    It is therefore RECOMMENDED that security measures are
taken
> >> > >    instance, modifying the Source Block Number of an FEC
source
> >> > >    It is therefore RECOMMENDED that security measures are
taken
> >> > >    There are also situations where the only insecure domain
is
> >> > >    flows.  For instance, if denial-of-service (DoS)
protection
> >is
> >> > >    the difference with respect to the first document relies
on

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 18 Jan 2011 17:37:14 -0800

While we're talking sad.. I find it very sad that the IESG had
previously approved our charter, and now after years of work we're
hearing that our charter is lacking. I also find it sad that these
persons having issues with our framework draft and our charter are not
responding to the list to engage in discussion but are working through
our AD as a proxy for their opinions. This makes it very hard to make
progress, though moving issues to DISCUSS may help.

Thanks,
Greg