One document matched: draft-ietf-rmt-sec-discussion-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="info" docName="draft-ietf-rmt-sec-discussion-02" ipr="full3978">
<!--
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
-->
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Security and RMT Protocols">Security and Reliable Multicast
Transport Protocols: Discussions and Guidelines</title>
<author fullname="Brian Adamson" initials="B." surname="Adamson">
<organization>Naval Research Laboratory</organization>
<address>
<postal>
<street></street>
<city>Washington, DC</city>
<code>20375</code>
<country>USA</country>
</postal>
<email>adamson@itd.nrl.navy.mil</email>
<uri>http://cs.itd.nrl.navy.mil</uri>
</address>
</author>
<author fullname="Vincent Roca" initials="V." surname="Roca">
<organization>INRIA</organization>
<address>
<postal>
<street>655, av. de l'Europe</street>
<street>Zirst; Montbonnot</street>
<city>ST ISMIER cedex</city>
<code>38334</code>
<country>France</country>
</postal>
<email>vincent.roca@inria.fr</email>
<uri>http://planete.inrialpes.fr/~roca/</uri>
</address>
</author>
<date day="14" month="July" year="2008" />
<area>Transport</area>
<workgroup>RMT</workgroup>
<keyword>security analysis</keyword>
<abstract>
<t>This document describes general security considerations for the
Reliable Multicast Transport (RMT) Working Group set of building blocks
and protocols. An emphasis is placed on risks that might be resolved in
the scope of transport protocol design. However, relevant security
issues related to IP Multicast control-plane and other concerns not
strictly within the scope of reliable transport protocol design are also
discussed. The document also begins an exploration of approaches that
could be embraced to mitigate these risks. The purpose of this document
is to provide a consolidated security discussion and provide a basis for
further discussion and potential resolution of any significant security
issues that may exist in the current set of RMT standards.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Reliable Multicast Transport (RMT) Working Group has produced a
set of building block (BB) and protocol instantiation (PI)
specifications for reliable multicast data transport. Some present PIs
defined within the scope of RMT include <xref
target="RFC3450">ALC</xref><xref
target="draft-ietf-rmt-pi-alc-revised"></xref> , <xref
target="RFC3940">NORM</xref>, and the <xref
target="RFC3926">FLUTE</xref> application that is built on top of ALC.
These can be considered "Content Delivery Protocols" (CDP) as described
in<xref target="Neumann05"> </xref>. In this document, the term CDP will
refer indifferently to either ALC or NORM, with their associated
BBs.</t>
<t>The use of these BBs and PIs raises some new security risks. For
instance, these protocols share a novel set of Forward Error Correction
(FEC) and congestion control building blocks that present some new
capabilities for Internet transport, but may also pose some new security
risks. Yet some security risks are not related to the particular BBs
used by the PIs, but are more general. Reliable multicast transport
sessions are expected to involve at least one sender and multiple
receivers. Thus, the risk of and avenues to attack are implicitly
greater than that of point-to-point (unicast) transport sessions. Also
the nature of IP multicast can expose other coexistent network flows and
services to risk if malicious users exploit it. The classic any-source
multicast (ASM) model of multicast routing allows any host to join an IP
multicast group and send traffic to that group. This poses many
potential security challenges. And, while the emerging single-source
multicast (SSM) model that allows only a single sender to send traffic
to a group simplifies some challenges, there remain some specific
issues. For instance, possible areas of attack include those against the
control plane where malicious hosts join IP multicast groups to cause
multicast traffic to be directed to parts of the network where it is not
needed or desired. This can indirectly cause denial-of-service (DoS) to
other network flows. Also, attackers may transmit erroneous or corrupt
messages to the group or employ strategies such as replay attack within
the "data plane" of protocol operation.</t>
<t>The goals of this document are therefore to: <list style="numbers">
<t>Define the possible general security goals; i.e., define what we
want to protect, i.e. the network itself, and/or the protocol,
and/or the content.</t>
<t>List the possible elementary security services that will make it
possible to fullfil the general security goals. Some of these
services are generic (e.g. object and/or packet integrity), while
others are specific to RMT protocols (e.g. congestion control
specific security schemes).</t>
<t>List some technological building blocks and solutions that can
provide the desired security services.</t>
<t>Highlight the CDP specificities that will impact security and
define some use-cases. Indeed, the set of solutions proposed to
fulfill the security goals will greatly be impacted by the target
use case.</t>
</list> In some cases, the existing RMT documents already discuss the
risks and outline approaches to solve them, at least partially. The
purpose of this document is to consolidate this content and provide a
basis for further discussion and potential resolution of any significant
security issues that may exist.</t>
<section title="Conventions Used in this Document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section title="Quick Introduction to RMT Protocols and their Use">
<section title="The Two Families of CDP">
<t>The ALC/LCT and NORM classes of CDP are designed to reliably
deliver nncontent to a group of multicast receivers, but each with a
different set of features and limitations. The ALC/LCT class supports
a unidirectional delivery model where there is no feedback from the
receivers to senders, relying upon transmission redundant FEC coding
capable of recovering missing packet content for reliability. With
appropriate FEC encoding techniques, the transmission stream can
deliver data at different rates to different receivers, thus offering
the potential for multirate congestion control. This allows
scalability for delivery of bulk content to potentially very large
group sizes. While NORM supports the same use of FEC as ALC/LCT, it
leverages Negative Acknowledgement techniques to control the senders'
transmission of content. The advantage of NORM is that the sender need
not transmit any more information than necessary to satisfy the
receivers' need to achive reliable transfer. But, while NORM specifies
feedback control techniques to allow it to scale to considerably large
group sizes, it is not as massively scalable as the ALC/LCT approach
when feedback is used. Additionally, the NORM feedback control
mechanisms add some additional header content and protocol
implementation complexity as compared ALC/LCT. The appropriate choice
of CDP depends upon application needs, deployment constraints, and
network connectivity considerations. And while there are many common
security considerations for these two classes of CDP, there are also
some unique considerations for each.</t>
</section>
<section anchor="protocolCharacteristics"
title="RMT Protocol Characteristics">
<t>This section focuses on the RMT protocol characteristics that will
impact the choice of the technological building blocks, and the way
they can be applied. Both ALC and NORM have been designed with
receiver group size scalability. While ALC targets massively scalable
sessions (e.g. with millions of receivers), NORM is less ambitious,
essentially because of the use of feedback messages to the source.
Ideally, the use of security mechanisms should not break these
scalability features.</t>
<t>The ALC and NORM protocols differ in the communication paths: <list
style="symbols">
<t>sender to receivers: ALC and NORM, for bulk data transfer and
signaling messages;</t>
<t>receivers to sender: NORM only, for feedback messages;</t>
<t>receivers to receivers: NORM only for control messages;</t>
</list> But the fact that ALC is capable of working on top of purely
unidirectional networks does not mean that no back-channel will be
available (see <xref target="useCaseCharacteristics"></xref>). The
NORM and ALC protocols support a variety of content delivery models
where transport may be carefully coordinated among the sender and
receivers or with looser coordination and interaction. This leads to a
number of different use cases for these protocols.</t>
</section>
<section anchor="useCaseCharacteristics"
title="Target Use Case Characteristics">
<t>This section focuses on the target use cases and their special
characteristics. These details will impact both the choice of the
technological building blocks and the way they can be applied. One can
distinguish the following use case features: <list style="symbols">
<t>Purely unidirectional transport versus symmetric bidirectional
transport versus asymmetric bidirectional transport. Most of the
time, the amount of traffic flowing to the source is limited, and
one can overlook whether the transport channel is symmetric or
not. The nature of the underlying transport channel is of
paramount importance, since many security building blocks will
require a bidirectional communication;</t>
<t>Massively scalable versus moderately scalable session. Here we
do not define precisely what the terms "massively scalable" and
"moderately scalable" mean.</t>
<t>Known set of receivers versus unknown set of receivers: I.e.,
does the source know at any point of time the set of receivers or
not? Of course, knowing the set of receivers is usually not
compatible with massively scalable sessions;</t>
<t>Dynamic set of receivers versus fixed set of receivers: I.e.,
does the source know at some point of time the maximum set of
receivers or will it evolve dynamically?</t>
<t>High rate data flow versus small rate data flow: Some security
building blocks are CPU-intensive and are therefore incompatible
with high data rate sessions (e.g. solutions that digitally sign
all packets sent).</t>
<t>Protocol stack available at both ends: A solution that requires
some unusual features within the protocol stack will not always be
usable. Some target environments (e.g. embedded systems) provide a
minimum set of features and extending them (e.g. to add IPsec) is
not necessarily realistic;</t>
<t>Multicast routing and other layer-3 protocols in use: E.g., SSM
routing is often seen as one of the key service to improve the
security within multicast sessions, and some security building
blocks require specialized versions of layer-3 protocols (e.g.
IGMP/MLD with security extensions). In some cases these
assumptions might not be realistic.</t>
</list>Depending on the target goal and the associated security
building block used, other features might be of importance. For
instance TESLA requires a loose time synchronization between the
source and the receivers. Several possible techniques are available to
provide this, but some of them may be feasible only if the target use
case has the appropriate characteristics.</t>
</section>
</section>
<section title="Known Security Threats">
<t>The IP architecture provides common access to notional control and
data planes to both end and intermediate systems. For the purposes of
discussion here, the "control plane" mechanisms are considered those
with message exchanges between end systems (typically computers) and
intermediate systems (typically routers) (or among intermediate systems)
while the "data plane" encompasses messages exchanged among end systems,
usually pertaining to the transfer of application data. The security
threats described here are introduced within the taxonomy of control
plane and data plane IP mechanisms.</t>
<section title="Control-Plane Attacks">
<t>In this discussion, "control-plane" in the context of Internet
Protocol systems refers to signaling among end systems and
intermediate systems to facilitate routing and forwarding of packets.
For IP multicast, this notably includes Internet Group Management
Protocol (IGMP) and multicast routing protocol messaging. While
control-plane attacks may be considered outside of the scope of the
transport protocol specfications discussed here, it is important to
understand the potential impact of such attacks with respect to the
deployment and operation of these protocols. For example, awareness of
possible IP Multicast control-plane manipulation that can lead to
unauthorized (or unexpected) monitoring of data plane traffic by
malicious users may lead a transport application or protocol
implementation to support encryption to ensure data confidentiality
and/or privacy. Also, these types of attack also have bearing on
assessing the real risks of potentially more complex attacks against
the transport mechanisms themselves. In some cases, the solutions to
these control-plane risk areas may reduce the impact or possibility of
some data-plane attacks that are discussed in this document.</t>
<t>The presence of these types of attack may necessitate that
policy-based controls be emplaced in routers to limit the distribution
(including transmission and reception) of multicast traffic (on a
group-wise and/or traffic volume basis) to different parts of the
network. Such policy-based controls are beyond the scope of the RMT
protocol specifications. However, such network protection mechanisms
may reduce the opportunities for or effectiveness of of some of the
data-plane attacks discussed later. For example, reverse-path checks
can significantly limit opportunities for attackers to conduct replay
attacks when hosts actually do use IPSec. Also, future IP Multicast
control protocols may wish to consider providing security mechanism to
prevent unauthorized monitoring or manipulation of messages related to
group membership, routing, and activity. The sections below describe
some variants of control-plane attacks.</t>
<section title="Control Plane Monitoring">
<t>While this may not be a direct attack on the transport system, it
may be possible for an attacker to gain useful information in
advancing attack goals by monitoring IP Multicast control plane
traffic including group membership and multicast routing
information. Indentification of hosts and/or routers participating
in specific multicast groups may readily identify systems vulnerable
to protocol-specific exploitation. And, with regards to user privacy
concerns, such "side information" may be relevant to this emerging
aspect of network security.</t>
</section>
<section title="Unauthorized (or Malicious) Group Membership">
<t>One of the simplest attacks is that where a malicious host joins
an IP multicast group so that potentially unwanted traffic is routed
to the host's network interface. This type of attack can turn a
legitimate source of IP traffic into a "attacker" without requiring
any access privileges to the source host or routers involved. This
type of attack can be used for denial-of-service purposes or for the
real attacker (the malicious joiner) to gain access to the
information content being sent. Similarly, some routing protocols
may permit any sender (whether joined to the specific group or not)
to transmit messages to a multicast group.</t>
<t>It is possible that malicious hosts could also spoof IGMP
messages, joining groups posing as legitimate hosts (or spoof source
traffic from legitimate hosts). This may be done at intermediate
locations in the network or by hosts co-resident with the authorized
hosts on local area networks. Such spoofing could be done by raw
packet generation or with replay of previously-recorded control
messages. For the sake of completeness, it should be noted that
multicast routing protocol control messaging may be subject to
similar threats if insufficient protocol security mechanisms are
enabled in the routing infrastructure.</t>
</section>
</section>
<section title="Data-Plane Attacks">
<t>This section discusses some types of active attacks that might be
conducted "in-band" with respect to the reliable multicast transport
protocol operating within the data plane of network data transfer.
I.e., the "data-plane" here refers to IP packets containing end-to-end
transport content to support the reliable multicast transfer. The
passive attack of unauthorized data-plan monitoring is discussed above
since such activity might be made possible by the vulnerabilities of
the IP Multicast control plane. To cover the two classes of RMT
protocols, the active data-plane attacks are categorized as 1) those
where the attacker generates messages posing as a data sender, and 2)
those where the attacker generates messages posing as a receiver
providing feedback to the sender(s) or group. Additionally, a common
threat to protocol operation is that of brute-force, rogue packet
generation. This is discussed briefly below, but the more subtle
attacks that might be conducted are given more attention as those fall
within the scope of the RMT transport protocol design. Additionally,
special consideration is given to that of the "replay attack" [see
<xref target="ReplayAttacks"></xref>], as it can be applied across
these different categories.</t>
<section title="Rogue Traffic Generation">
<t>If an attacker is able to successfully inject packets into the
multicast distribution tree, one obvious denial-of-service attack is
for the attacker to generate a large volume of apparently
authenticate (and when authentication mechanisms are used, a
"replay" attack strategy might be used) traffic. The impact of this
type of attack can be significant since the potential for routers to
relay the traffic to multiple portions of a networks (as compared to
a single unicast routing path). However, other than the amplified
negative impact to the network, this type of attack is no different
than what is possible with rogue unicast packet generation and
similar measures used to protect the network from such attacks could
be used to contain this type of brute-force attack. Of course, the
pragmatic question of whether current implementations of such
protection mechanisms support IP Multicast SHOULD be considered.</t>
</section>
<section title="Sender Message Spoofing">
<t>These types of attacks are applicable to both general types of
RMT protocols: ALC (sender-only transmission) and NORM
(sender-receiver exhanges). Without an authentication mechanism, an
attacker can easily generate sender messages that could disrupt a
reliable multicast transfer session. And with FEC-based transport
mechanisms, a single packet with an apparently-correct FEC payload
identifier <xref target="RFC3452"></xref> but a corrupted FEC
payload could potentially render an entire block of transported data
invalid. Thus, a modest injection rate of corrupt traffic could
cause severe impairment of data transport. Additionallly, such
invalid sender packets could convey out-of-bound indices (e.g. bad
symbol or block identifiers) that can lead to buffer overflow
exploits or similar issues in implementations that insufficient
check for invalid data.</t>
<t>An indirect use of sender message spoofing would be to generate
messages that would cause receivers to take inappropriate
congestion-control action. In the case of the layered congestion
control mechanisms proposed for ALC use, this could lead to the
receivers erroneusly leaving groups associated with higher bandwidth
transport layers and suffering unnecessarily low transport rates.
Similarly, receivers may be misled to join inappropriate groups
directing unwanted traffic to their part of the network. Attacks
with similar effect could be conducted against the TFMCC approach
proposed for NORM operation with spoofing of sender messages
carrying congestion control state to receivers.</t>
</section>
<section title="Receiver Message Spoofing">
<t>These atacks are limited to RMT protocols that use feedback from
receivers in the group to influence sender and other receiver
operation. In the NORM protocol, this includes
negative-acknowledgement (NACK) messages fed back to the sender to
achieve reliable transfer, congestion control feedback content, and
the optional positive acknowledgement features of the specification.
It is also important to note that for ASM operation, NORM receivers
pay attention to the messages of other receivers for the purpose of
suppression to avoid feedback implosion as group size grows
large.</t>
<t>An attacker that can generate false feedback can manipulate the
NORM sender to unnecessarily transmit repair information and reduce
the goodput of the reliable transfer regardless of the sender's
transmit rate. Contrived congestion control feedback could also
cause the sender to transmit at an unfairly low rate.</t>
<t>As mentioned, spoofed receiver messaging may not be directed only
at senders, but also at receivers participating in the session. For
example, an attacker may direct phony receiver feedback messages to
selected receivers in the group causing those receivers to suppress
feedback that might have otherwise been transmitted. This attack
could compromise the ability of those receivers to achieve reliable
transfer. Also, suppressed congestion control feedback could cause
the sender to perhaps transmit at a rate unfair to those attacked
receivers if their fair congestion control rate were lower than
other receivers in the group.</t>
</section>
<section anchor="ReplayAttacks" title="Replay Attacks">
<t>The infamous "replay attack" (injection of a previously
transmitted packet (or at least its payload) into the reliable
transport group or directly to one or more of its participants) is
given special attention here because of the special consequences it
can have on RMT protocol operation. Without specific protection
mechanisms against replay (e.g. duplicate message detection), it is
possible for these attacks to be successful even when security
mechanisms such as packet authentication and/or encryption are
employed.</t>
<section title="Replay of Sender Messages">
<t>Generally, replay of recent protocol messages from the sender
will not harm transport, and could potentially assist it, unless
it is of sufficient volume to result in the same type of impact as
the "rogue traffic generation" described above. However, it is
possible that replay of sufficiently old messages may cause
receivers to think they are "out of sync" with the sender and
reset state, compromising the transfer. Also, if sender transport
data identifiers are reused (object identifiers, FEC payload
identifiers, etc), it is possible that replay of old messages
could corrupt data of a current transfer.</t>
</section>
<section title="Replay of Receiver Messages">
<t>Replay of receiver messages are problematic for the NORM
protocol, because replay of NACK messages could cause the sender
unnecessarily transmit repair information for an FEC coding block.
Similarly, the sender transmission rate might be manipulated by
replay of congestion control feedback messages from receivers in
the group. And the way that NORM senders estimate group round-trip
timing (GRTT) could allow a replay attack to manipulate the
senders' GRTT estimate to an unnecessarily large value, adding
latency to the reliable transport process.</t>
</section>
</section>
</section>
</section>
<section anchor="generalGoals" title="General Security Goals">
<t>The term "security" is extremely vast and encompasses many different
meanings. The goal of this section is to clarify what "security" means
when considering the reliable multicast transport (RMT) protocols being
defined in the IETF RMT working group. The scope can also encompass
additional group communication applications, for instance streaming
applications. This section only focuses on the desired general goals.
The following sections will then discuss the possible elementary
services that will be required to fulfill these general goals, as well
as the underlying technological building blocks.</t>
<t>The possible final goals include, in decreasing order of importance:
<list style="symbols">
<t>network protection: the goal is to protect the network from
attacks, no matter whether these attacks are voluntary (i.e.
launched by one or several attackers) or non voluntary (i.e. caused
by a misbehaving system, where "system" can designate a building
block, a protocol, an application, or a user);</t>
<t>protocol protection: the goal is to protect the RMT protocol
itself, e.g. to avoid that a misbehaving receiver prevents other
receivers to get the content, no matter whether this is done
intentionally or not;</t>
<t>and content protection: to goal is to protect the content itself,
for instance to guaranty the integrity of the content, or to make
sure that only authorized clients can access the content.</t>
</list></t>
<section title="Network Protection">
<t>Protecting the network is of course of primary importance. An
attacker should not be able to damage the whole infrastructure by
exploiting some features of the RMT protocol. Unfortunately, recent
past has shown that the multicast routing infrastructure is relatively
fragile, as well as the applications built on top of it. Since the RMT
protocols may use congestion control mechanisms to regulate sender
transmission rate, the protocol security features should ensure that
the sender may not be manipulated to transmit at incorrect rates (most
importantly not at an excessive rate) to any parts of the the receiver
group. In the case of NORM, the security mechanisms should ensure that
the feedback suppression mechanisms are protected to prevent
badly-behaving network nodes from purposefully causing feedback
implosion. In the case of ALC, where layered congestion control may be
used via dynamic grou/layer membership, this extends to considerations
of excessive manipulation of the multicast router control plane.</t>
</section>
<section title="Protocol Protection">
<t>Protecting the protocols is also importance, since the higher the
number of clients, the more serious the consequences of an attack.
This is all the more true as scalability is often one of the desired
goals of RMT protocols. Ideally, receivers should be sufficiently
isolated from one another, so that a single misbehaving receiver does
not affect others. Similarly, an external attacker should not be able
to break the system, i.e. resulting in unreliable operation or
delivery of incorrect content.</t>
</section>
<section title="Content Protection">
<t>Finally, the content itself should be protected when meaningful.
This level of security is often the concern of the content provider
(and its responsibility). For instance, in case of confidential (or
non-free) content, the typical solution consists in encrypting the
content. It can be done within the upper application, i.e. above the
RMT protocol, or within the transport system.</t>
<t>But other requirements may exist, like verifying the integrity of a
received object, or authenticating the sender of the received packets.
To that goal, one can rely on the use of building blocks integrated
within, or above, or beneath the RMT protocol.</t>
<t>One may also consider that offering the packet sender
authentication and content integrity services are basic requirements
that should fulfill any RMT system that operates within an open
network, where any attacker can easily inject spurious traffic in an
ongoing NORM or ALC session. In that case this goal is not the
responsibility of the content provider but the responsibility of the
administrator who deploys the RMT system itself.</t>
</section>
</section>
<section title="Elementary Security Techniques">
<t>The goals defined in <xref target="generalGoals"></xref> will be
fulfilled by means of underlying security techniques, provided by one or
several technological building blocks. This section only focuses on
these elementary security techniques. Some general techniques
traditionally available are: </t>
<texttable title="General Security Techniques">
<ttcol width="20%">Technique</ttcol>
<ttcol>Goal</ttcol>
<c>packet integrity</c>
<c>Enable session participants to verify that a packet has not been
inappropriately modified in transit.</c>
<c>packet source authentication</c>
<c>Enable a receiver to verify the source of a packet.</c>
<c>packet group authentication</c>
<c>Enable a receiver to verify that a packet originated or was
modified only within the group and has not been modified by nonmembers
in transit; Additionally, if attribution of any modifications by the
group is required, certain group authentication mechanisms may provide
this capability.</c>
<c>packet non-repudiation</c>
<c>Enable any third party to verify the source of a packet such that
the source cannot repudiate having sent the packet.</c>
<c>packet anti-replay</c>
<c>Enable a receiver to detect that a packet is the same as a
previously-received packet</c>
<c>object integrity</c>
<c>Enable a receiver to verify the integrity of a whole object. Such
bject integrity verification should be possible for any singular
object or any composition of sub-objects which together constitute a
larger object structure.</c>
<c>object source authentication</c>
<c>Enable a receiver to verify the source of an object.</c>
<c>object confidentiality</c>
<c>Enable a source to guarantee that only authorized receivers can
access the object data.</c>
</texttable>
<t>Some additional techniques are specific to the RMT protocols:</t>
<texttable title="RMT-Specific Security Techniques">
<ttcol width="20%">Technique</ttcol>
<ttcol>Goal</ttcol>
<c>congestion control security</c>
<c>Prevent an attacker from modifying the congestion control protocol
normal behavior (e.g. by reducing the transmission (NORM) or reception
(ALC) rate, or on the opposite increasing this rate up to a point
where congestion occurs)</c>
<c>group management</c>
<c>Ensure that only authorized receivers (as defined by a certain
group management policy) join the RMT session and possibly inform the
source</c>
<c>backward group secrecy</c>
<c>Prevent a new group member to access the information in clear sent
to the group before he joined the group</c>
<c>forward group secrecy</c>
<c>Prevent a former group member to access the information in clear
sent to the group after he left the group</c>
</texttable>
<t>These technques are usually achieved by means of one or several
technological building blocks. The target use case where the RMT system
will be deployed will greatly impact the choice of the technological
building block(s) used to provide these services, as explained in <xref
target="useCaseCharacteristics"></xref>.</t>
</section>
<section title="Technological Building Blocks">
<t>Here is a list of techniques and building blocks that are likely to
fulfill one or several of the goals listed above: <list style="symbols">
<t>IPsec;</t>
<t>Use of TESLA within RMT;</t>
<t>Use of Group MAC within RMT;</t>
<t>Use of Digital signatures within RMT;</t>
<t>use of SSM (Source Specific Multicast) multicast routing;</t>
<t>Digital Signature;</t>
<t>(TBD) add other BBs</t>
</list> Each of them is now quickly discussed. In particular we
identify what service it can offer, its limitations, and its field of
application (adequacy W.R.T. the CDP and the target use case).</t>
<section title="IPsec">
<section title="Benefits">
<t>One direct approach using existing standards is to apply IPSec
<xref target="RFC2401"></xref> to achieve the following properties
for message transmission: <list style="numbers">
<t>Authentication (IPSec AH or ESP)</t>
<t>Confidentiality (IPSec ESP)</t>
</list></t>
</section>
<section title="Requirements">
<t>It is expected that the approach to apply IPSec for reliable
multicast transport sessions is similar to that described for OSPFv3
security<xref target="RFC4552"></xref>. The following list proposes
the IPSec capabilities needed to support a similar approach to RMT
protocol security: <list style="numbers">
<t>Mode - Transport mode IPSec security is required;</t>
<t>Selectors - source and destination addresses and ports,
protocol.</t>
<t>For some uses, preplaced manual key support may be required
to support application deployment and operation. For automated
key management for group communication the Group Secure
Association Key Management Protocol (GSAKMP) described in <xref
target="RFC4535"></xref> may be used to emplace the keys for
IPSec operation.</t>
</list> Note that a periodic rekeying procedure similar to that
described in RFC 4552 can also be applied with the additional
benefit that the reliable transport aspects of the RMT protocols
provide robustness to any message loss that might occur due to ANY
timing discrepencies among the participants in the reliable
multicast session.</t>
</section>
<section title="Limitations">
<t>It should be noted that current IPSec implementations may not
provide the capability for anti-replay protection for multicast
operation. In the case of the NORM protocol, a sequence number is
provided for packet loss measurement to support congestion control
operation. This sequence number can also be used within a NORM
implementation for detecting duplicate (replayed) messages from
sources (senders or receivers) within the transport session group.
In this way, protection against replay attack can be achieved in
conjunction with the authentication and possibly confidentiality
properties provided by an IPSec encapsulation of NORM messages. NORM
receivers generate a very low volume of feedback traffic and it is
expected that the 16-bit sequence space provided by NORM will be
sufficient for replay attack protection. When a NORM session is
long-lived, the limits of the sender repair window are expected to
provide protection from replayed NACKs as they would typically be
outside of the sender's current repair window. It is suggested that
IPSec implementations that can provide anti-replay protection for IP
Multicast traffic, even when there are multiple senders within a
group, be adopted. The GSAKMP document has some discussion in this
area.</t>
</section>
</section>
<section title="Use of TESLA within RMT">
<section title="Benefits">
<t>The use of <xref target="TESLA_4_ALC_NORM">TESLA</xref> within
the RMT protocols offers a loss tolerant, lightweight,
authentication/integrity service for the packets generated by the
session's sender. Depending on the time synchronization method and
bootstrap method used, TESLA is compatible with massively scalable
sessions. Because TESLA eavily relies on fast symmetric
cryptographic building blocks, CPU processing remains limited both
at the sender and receiver sides, which makes it suitable for high
data rate transmissions, and/or lightweight terminals. Finally, the
transmission overhead remains limited.</t>
</section>
<section title="Requirements">
<t>The security offered by TESLA relies heavily on time. Therefore
the session's sender and each receiver need to be loosely
synchronized in a secure way. To that purpose, several methods
exist, depending on the use case: direct time synchronization (which
requires a bidirectional transport channel), using a secure NTP
infrastructure (which also requires a bidirectional transport
channel), or a GPS device, or a clock with a time-drift that is
negligible in front of the TESLA time accuracy requirements.</t>
<t>The various bootstrap parameters must also be communicated to the
receivers, using either an in-band or out-of-band mechanism,
sometimes requiring bidirectional communications.</t>
<t>So, depending on the time synchronization scheme and the
bootstrap mechanism method, TESLA can be used with either
bidirectional or unidirectional transport channels.</t>
</section>
<section title="Limitations">
<t>A first limitation is that TESLA does not protect the packets
that are generated by receivers, for instance the feedback packets
of NORM. These packets must be protected by other means.</t>
<t>Another limitation is that TESLA requires some buffering
capabilities at the receivers in order to enable the delayed
authentication feature. This is not considered though as a major
issue in the general case (e.g. FEC decoding of objects within an
ALC session already requires some buffering capabilities, that often
exceed that of TESLA), but it might be one in case of embedded
environments.</t>
</section>
</section>
<section title="Use of Group MAC within CDP">
<section title="Benefits">
<t>The use of Group MAC (Message Authentication Codes) within the
CDP <xref target="SIMPLE_AUTH_4_ALC_NORM"></xref> is a simple
solution to provide a loss tolerant group authentication/integrity
service for all the packets exchanged within a session (i.e. the
packets generated by the session's sender and the session's
receivers). This scheme is easy to deploy since it only requires
that all the group members share a common secret key. Because Group
MAC heavily relies on fast symmetric cryptographic building blocks,
CPU processing remains limited both at the sender and receiver
sides, which makes it suitable for high data rate transmissions,
and/or lightweight terminals. Finally, the transmission overhead
remains limited.</t>
</section>
<section title="Requirements">
<t>This scheme only requires that all the group members share a
common secret key, possibly associated to a re-keying mechanism
(e.g. each time the group membership changes, or on a periodic
basis).</t>
</section>
<section title="Limitations">
<t>This scheme cannot protect against attacks coming from inside the
group, where a group member impersonates the sender and sends forged
messages to other receivers. It only provides a group-level
authentication/integrity service, unlike the TESLA and Digital
Signature schemes.</t>
<t>Note that the Group MAC and Digital Signature schemes can be
advantageously used together, as explained in <xref
target="SIMPLE_AUTH_4_ALC_NORM"></xref>.</t>
</section>
</section>
<section title="Use of Digital Signatures within CDP">
<section title="Benefits">
<t>The use of Digital Signatures within the CDP <xref
target="SIMPLE_AUTH_4_ALC_NORM"></xref> is a simple solution to
provide a loss tolerant authentication/integrity service for all the
packets exchanged within a session (i.e. the packets generated by
the session's sender and the session's receivers). This scheme is
easy to deploy since it only requires that the participants know the
packet sender's public key, which can be achieved with either Public
Key Infrastructre (PKI) or by pre-deploying these keys.</t>
</section>
<section title="Requirements">
<t>This scheme is easy to deploy since it only requires that the
participants know the packet sender's public key, which can be
achieved either thanks to a PKI or by pre-deploying these keys.</t>
</section>
<section title="Limitations">
<t>When RSA asymmetric cryptography is used, digital signatures has
two major shortcommings: <list style="symbols">
<t>it is limited by high computational costs, especially at the
sender, and</t>
<t>it is limited by high transmission overheads.</t>
</list>This scheme is well suited to low data rate flows, when
transmission overheads are not a major issue. For instance it can be
used as a complement to TESLA for the feedback traffic coming from
the session's receivers.</t>
<t>The use of ECC ("Eliptic Curve Cryptography") significantly
relaxes these constraints, especially when seeking for higher
security levels. For instance, the following key size provide
equivalent security:</t>
<texttable>
<ttcol align="center">Symmetric Key Size</ttcol>
<ttcol align="center">RSA Key Size</ttcol>
<ttcol align="center">ECC Key Size</ttcol>
<c>80 bits</c>
<c>1024 bits</c>
<c>160 bits</c>
<c>112 bits</c>
<c>2048 bits</c>
<c>224 bits</c>
</texttable>
<t>However in some cases, the Intellectual Property Rights (IPR)
considerations for ECC may limit its use, so the other techniques
are presented here as well.</t>
<t>Note that the Group MAC and Digital Signature schemes can be
advantageously used together, as explained in <xref
target="SIMPLE_AUTH_4_ALC_NORM"></xref>.</t>
</section>
</section>
<section title="SSM Multicast Routing">
<t> <xref target="RFC3569">Source-specific Multicast (SSM)</xref>
amends the classical Any-source Multicast (ASM) model creating logical
IP multicast "channels" that are defined by the multicast destination
address <spanx style="emph">and</spanx> the specific source address.
Thus for a given "channel", only one specific source can inject
packets that are distributed to receivers that have joined. This form
of multicast has group management benefits since a source can
independently control the "channels" it creates. Additionally, there
are some security benefits of this multicast paradigm.</t>
<section title="Benefits">
<t>Since data-plane traffic for an SSM "channel" is limited to that
of a single, specific source address, it is possible that network
intermediate systems may impose mechanims that prevent injection of
traffic to the group from inappropriate (perhaps malicious) nodes.
This can reduce the risk for denial-of-service and some of the other
attacks described in this document. While SSM alone is not a
complete security solution, it can simplify secure RMT
operation.</t>
</section>
<section title="Requirements">
<t>Use of SSM requires that the network intermediate systems
explicitly support it. Additionally, hosts are required to support
the IGMPv3 extensions for SSM and applications and RMT
implementations will need to support use of IGMPv3 including
management of the <sourceAddr:dstMcastAdd> "channel"
identifier.</t>
</section>
<section title="Limitations">
<t>RMT protocols such as NORM that use signaling from receivers to
multicast senders will need to use unicast addressing for feedback
messages. In the case of NORM, its timer-based feedback suppression
requires support of the sender NORM_CMD(REPAIR_ADV) message to
control receiver feedback. In some topologies, use of unicast
feedback may require some additional latency (increased backoff
factor) for safe operation. The security of the unicast feedback
from the receivers to sender will need to be addressed separately
since the IP multicast model, including SSM, does not provide the
sender knowledge of authorized group members.</t>
</section>
</section>
<section title="Summary">
<t>The following table summarizes the pros/cons of each
authentication/integrity scheme used at application/transport
level:</t>
<texttable>
<ttcol align="left"></ttcol>
<ttcol align="center">RSA Digital Signature</ttcol>
<ttcol align="center">ECC Digital Signature</ttcol>
<ttcol align="center">Group MAC</ttcol>
<ttcol align="center">TESLA</ttcol>
<c>True auth and integrity</c>
<c>Yes</c>
<c>Yes</c>
<c>No (group security)</c>
<c>Yes</c>
<c>Immediate auth</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<c>No</c>
<c>Processing load</c>
<c>--</c>
<c>+</c>
<c>++</c>
<c>+</c>
<c>Transmission overhead</c>
<c>--</c>
<c>+</c>
<c>++</c>
<c>+</c>
<c>Complexity</c>
<c>++</c>
<c>++</c>
<c>++</c>
<c>--</c>
</texttable>
</section>
</section>
<section title="Security Infrastructure">
<t>Deploying the elementary technological building blocks often requires
that a security infrastructure exists. Such security infrastructure can
provide: <list style="symbols">
<t>Public Key Infrastructure (PKI) for trusted third party vetting
of, and vouching for, user identities. PKI also allows the binding
of public keys to users, usually by means of certificates.</t>
<t>Group Key Management with rekeying schemes that are either
periodic or triggered by some higher level event. It is required in
particular when the group is dynamic and forward/backward secrecy
are important. This is also required to improve the scalability of
the CDP (since key management is done automatically, using a key
server topology), or the security provided by the CDP (since the
underlying cryptographic keys will be changed frequently)</t>
</list></t>
<t>It is expected that some RMT protocol deployments may use existing
client-server security infrastructure models so that receivers may
acquire any necessary session keys, etc and be authenticated or
validated as needed for group participation. Then, the reliable delivery
of session data content will be provided via the applicable RMT
protocols. Note that in this case the security infrastructure itself may
limit the scalability of the group size or other aspects of reliable
multicast transfer. </t>
<t>The IETF MSEC Working Group has developed some protocols that can be
applied to achieve more scalable and effective group communication
security infrastructure<xref target="RFC4046"></xref>. It is encouraged
that these mechanisms be considered in the development of security for
RMT protocols.</t>
</section>
<section title="New Threats Introduced by the Security Scheme Itself">
<t>Introducing a security scheme, as a side effect, can sometimes
introduce new security threats. For instance, signing all packets with
asymmetric cryptographic schemes (to provide a source
authentication/content integrity/anti-replay service) opens the door to
DoS attacks. Indeed, verifying asymmetric-based cryptographic signatures
is a CPU intensive task. Therefore an attacker can easily overload a
receiver (or a sender in case of NORM) by injecting a significant number
of faked packets.</t>
</section>
<section title="Consequences for the RMT and MSEC Working Group">
<t>To meet the goals outlined in this document, it is expected that the
RMT and Multicast Security (MSEC) WG may need to develop some supporting
protocol security mechanisms.</t>
<section title="RMT Transport Message Security Encapsulation Header">
<t>An alternative approach to using IPSec to provide the necessary
properties to protect RMT protocol operation from the application
attacks described earlier, is to extend the RMT protocol message set
to include a message encapsulation option. This encapsulation header
could be used to provide authentication, confidientiality, and
anti-replay protection as needed. Since this would be independent of
the IP layer, the header might need to provide a source identifier to
be used as a "selector" for recalling security state (including
authentication certificate(s), sequence state, etc) for a given
message. In the case of the NORM protocol, a NormNodeId field exists
that could be used for this purpose. In the case of ALC, the security
encapsulation mechanism would need to add this function. The security
encapsulation mechanism, although resident "above" the IP layer, could
use <xref target="RFC4535">GSAKMP</xref> or a similar approach for
automated key managment.</t>
</section>
<!--
FROM THE JULY 2006 RMT MINUTES:
2- RMT BBs to Standard Track and Security
(point raised by Magnus Westerlund on the ML)
Magnus explains that having specifications (BBs, PIs) on the STD track
without any detailed guidelines on how to implement security services is
not reasonable. Hence this discussion...
Lorenzo answers there are many possible goals which makes this discussion
(and recommendations) difficult. The highest security goal is probably
to protect the network, a lower goal is to protect the protocol itself,
and an even lower goal is to protect the objects being transported.
Magnus agrees that there is a hierarchy of possible goals, but it does
not mean that we can ignore them altogether.
Lorenzo reminds that one initial RMT's goal was scalability, and therefore
it was decided that the source should not know the identity of the
receivers. As a consequence, it makes some security requirements more
complex to achieve.
George Gross: Scalability was one of the goals also for MSEC too
(e.g. for key management). Many BBs developed in MSEC will come for free.
Lorenzo: Do we need any modification to the protocols defined in MSEC
to use them in RMT?
George reminds the group that IPsec has been redesigned recently in order
to support multicast.
Lorenzo: We are not standardizing the application, but the transport.
As RMT is providing transport solutions, is there any need to bother
with application topics?
George: IPsec is one solution, but the question is whether we want to
use it (there are limitations) or want provide security in the
application layer?
Magnus: If we want to do that on a lower layer (i.e. with IPsec) we
need to specify a profile for it here.
The discussion now focuses on the above three goals (content, network
and protocol protection):
1) Content protection:
Magnus: The provider of the content has its own opinion on how to protect
the content.
Lorenzo: It's not the problem of RMT to provide content protection.
We can say we need a WG in the application level to address this problem.
Magnus agrees with Lorenzo.
Mark: Yet but we must keep in mind that there's an urgent need to make
progress. Many people are using FLUTE/ALC now...
Magnus: Confidentiality issue is the last problem to solve. There are
more important problems to solve first.
2) Network protection:
Lorenzo: Network protection in our case means protecting the network
from congestion. What is the situation ?
Brian: There is a potential attack to TFMCC (used by NORM). The sender
can slow down because of a malicious receivers who says to be a bad
node.
George explains that against this kind of receiver feedback attack, the
only solution is to provide group key management and to use digital
signatures. This technique can enable the sender to decide whether
a receiver who sends feedback is an authorized member of the group or
not. But a requirement is to use a key management infrastructure...
3) Protocol protection:
One possible goal is to protect the transport protocol against nodes
that want to stop the protocol.
Lorenzo: Can we mandate the use of SSM to protect NORM?
Magnus answers that an attacker having control over the network can
easily spoof the source, so using SSM does not really solve the problem.
George: Using public keys, a certificate authority and digital signature
can help... The new version of IPsec, that features multicast extensions,
is another way to achieve that goal.
Lorenzo suggests to ask the MSEC WG to have it a WG item. He also
suggests to add in the security requirement of NORM a note explaining
that this scheme can be used.
Gorry: Why do we go to SSM?
Lorenzo explains there's a potential solution for TFMCC if we mandate the
use of SSM. It seems a realistic assumption.
Brian explains that with SSM, a receiver can still slow down the sender
but cannot break the network.
Lorenzo: A possible solution, for TFMCC, is to say that if the sender
receives contradicting feedback, then he should trust the worst one.
Gorry explains that in case of the ALC layer congestion control
scheme, there's an incentive to receive at a higher rate even if it
breaks the network (i.e. by not being fair with other TCP flows).
Lorenzo: Is there any work in unicast to address the problem?
What about a TCP receiver that acknowledges each packet even if
he didn't receive them? It can happen in NORM and ALC but also in TCP.
It seems to be a very tough problem since it needs to involve the routers.
Somebody explains that the problem is that we trust the host to do
the congestion control. In TCP, if a receiver misbehaves, he will
probably be the only one to be hurt.
Lorenzo: So we have a very big problem here... But we are only
opening issues, we are not solving them!
-->
</section>
<section title="Security Considerations">
<t>This document is a general discussion of security for the RMT
protocol family. But specific security considerations are not applicable
as this document does not introduce any new techniques.</t>
</section>
<section title="Acknowledgments">
<t>The authors would like acknowledge Magnus Westerlund for stimulating
the working group activity in this area. Additionally George Gross and
Ran Atkinson contributed many ideas to the discussion here.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.2401'?>
<?rfc include='reference.RFC.3450'?>
<!--
<?rfc include='reference.RFC.3451'?>
-->
<?rfc include='reference.RFC.3452'?>
<?rfc include='reference.RFC.3926'?>
<?rfc include='reference.RFC.3940'?>
<?rfc include='reference.RFC.4535'?>
<?rfc include='reference.RFC.4552'?>
<?rfc include='reference.RFC.4654'?>
<?rfc include='reference.RFC.4046'?>
<reference anchor="draft-ietf-rmt-pi-alc-revised">
<front>
<title>Asynchronous Layered Coding (ALC) Protocol
Instantiation</title>
<author initials="M." surname="Luby">
<organization></organization>
</author>
<author initials="M." surname="Watson">
<organization></organization>
</author>
<author initials="L." surname="Vicisano">
<organization></organization>
</author>
<date month="February" year="2007" />
</front>
<seriesInfo name=""
value="draft-ietf-rmt-pi-alc-revised-04.txt (work in progress)" />
</reference>
<reference anchor="TESLA_4_ALC_NORM">
<front>
<title>The Use of TESLA in the ALC and NORM Protocols</title>
<author fullname="Vincent Roca" initials="V." surname="Roca">
<organization></organization>
</author>
<author fullname="Aurelien Francillon" initials="A."
surname="Francillon">
<organization></organization>
</author>
<author fullname="Sebastien Faurite" initials="S." surname="Faurite">
<organization></organization>
</author>
<date month="July" year="2007" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-msec-tesla-for-alc-norm-02.txt" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-for-alc-norm-02.txt"
type="TXT" />
</reference>
<reference anchor="SIMPLE_AUTH_4_ALC_NORM">
<front>
<title>Simple Authentication Schemes for the ALC and NORM
Protocols</title>
<author fullname="Vincent Roca" initials="V." surname="Roca">
<organization></organization>
</author>
<date month="June" year="2007" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-roca-rmt-simple_auth-for-alc-norm-00.txt" />
<format target="http://www.ietf.org/internet-drafts/draft-roca-rmt-simple_auth-for-alc-norm-00.txt"
type="TXT" />
</reference>
<reference anchor="RFC3569">
<front>
<title>An Overview of Source-Specific Multicast (SSM)</title>
<author fullname="S. Bhattacharyya" initials="S."
surname="Bhattacharyya">
<organization></organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="IETF" value="RFC 3569" />
</reference>
</references>
<references title="Informative References">
<reference anchor="Neumann05">
<front>
<title>Large Scale Content Distribution Protocols</title>
<author fullname="Christoph Neumann" initials="C." surname="Neumann">
<organization>CN2005</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Vincent Roca" initials="V." surname="Roca">
<organization>V</organization>
</author>
<author fullname="Rod Walsh" initials="R." surname="Walsh">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="October" year="2005" />
<abstract>
<t></t>
</abstract>
</front>
<seriesInfo name="ACM Computer Communications Review (CCR)"
value="Vol. 35 No. 5" />
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 10:57:55 |