One document matched: draft-ietf-rmt-sec-discussion-08.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?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 category="info" docName="draft-ietf-rmt-sec-discussion-08"
ipr="trust200902">
<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 abbrev="NRL">Naval Research Laboratory</organization>
<address>
<postal>
<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/>
<city>Montbonnot</city>
<code>38334</code>
<country>France</country>
</postal>
<email>vincent.roca@inria.fr</email>
<uri>http://planete.inrialpes.fr/~roca/</uri>
</address>
</author>
<author fullname="Hitoshi Asaeda" initials="H." surname="Asaeda">
<organization abbrev="NICT">National Institute of Information and
Communications Technology</organization>
<address>
<postal>
<street>Network Research Headquarters</street>
<street>4-2-1 Nukui-Kitamachi</street>
<city>Koganei</city>
<region>Tokyo</region>
<code>184-8795</code>
<country>Japan</country>
</postal>
<email>asaeda@nict.go.jp</email>
</address>
</author>
<date day="17" month="May" year="2013"/>
<area>Transport</area>
<workgroup>RMT</workgroup>
<keyword>security analysis</keyword>
<abstract>
<t>This document describes general security considerations for Reliable
Multicast Transport (RMT) 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
discussions 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 IETF has produces a set of Reliable Multicast Transport (RMT)
protocol 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="RFC5775">Asynchronous Layered Coding (ALC)</xref>, <xref
target="RFC5740">NACK-Oriented Reliable Multicast (NORM)</xref>, and the
<xref target="RFC6726">File Delivery over Unidirectional Transport
(FLUTE)</xref> application that is built on top of ALC. These can be
considered "Content Delivery Protocols" as described in <xref
target="Neumann05"/>.</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 <xref
target="RFC1112">Any-Source Multicast (ASM)</xref> 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 <xref target="RFC3569">Source-Specific Multicast
(SSM)</xref>, <xref target="RFC4607"/> model that enables users to
receive multicast data sent only from specified sender(s) simplifies
some challenges, there are still 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 may
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: protecting the
network infrastructure, and/or the protocol, and/or the content,
and/or the user (e.g., its privacy);</t>
<t>List the possible elementary security services that will make it
possible to fulfill 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 reliable multicast protocol and the use-case
specificities that will impact security. Indeed, the set of
solutions proposed to fulfill the security goals will greatly be
impacted by these considerations;</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>
<section title="Quick Introduction to RMT Protocols and their Use">
<section title="ALC and NORM Overview">
<t>The ALC and NORM classes of reliable multicast transport are
designed to reliably deliver content to a group of multicast
receivers. However, ALC and NORM have a different set of features and
limitations. ALC supports a unidirectional delivery model where there
is no feedback from the receivers to senders. Reliability is achieved
by the joint use of carousel-based transmission techniques associated
to FEC encoding to recover from missing (erased) packets.</t>
<!--
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.
-->
<t>On the opposite, NORM achieves reliability by means of FEC encoding
(as with ALC) and feedback from the receivers. More specifically, NORM
leverages Negative Acknowledgement techniques to control the senders'
transmission of content. The advantage is that the sender need not
transmit any more information than necessary to satisfy the receivers'
need for fully reliable transfers. However, while NORM specifies
feedback control techniques to allow it to scale to large group sizes,
it is not as massively scalable as ALC. Additionally, the NORM
feedback control mechanisms add some header content and protocol
implementation complexity.</t>
<t>The appropriate choice of a reliable multicast transport protocol
depends upon application needs, deployment constraints, and network
connectivity considerations. And while there are many common security
considerations for these two types of protocols, 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
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., millions of receivers), NORM is less ambitious,
essentially because of the use of feedback messages.<!--Ideally, the use of security mechanisms should not break these scalability features.--></t>
<t>The ALC and NORM protocols also 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> Note that the fact ALC is capable of working on top of
purely unidirectional networks does not mean that no back-channel is
available (<xref target="useCaseCharacteristics"/>).</t>
<t>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 specific 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 <xref target="RFC4607"/> is often seen as one of the key
ways to improve security within multicast sessions, and some
security building blocks require specialized versions of layer-3
protocols (e.g., Internet Group Management Protocol (IGMP) or
Multicast Listener Discovery (MLD) protocol 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, the Timed Efficient Stream Loss-Tolerant Authentication
(TESLA) security protocol as described in <xref target="RFC4082"/>
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="Some 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), Multicast Listener Discovery protocol (MLD), and
routing protocol messaging<xref target="Baltatu00"/>. While
control-plane attacks may be considered outside of the scope of the
transport protocol specifications 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 embedded 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 some of the
data-plane attacks discussed later. For example, reverse-path checks
can significantly limit opportunities for attackers to conduct replay
attacks as described in <xref target="ReplayAttacks"/>. Also, future
IP Multicast control protocols may wish to consider providing a
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. Identification 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 as described in <xref
target="sec.privacy"/>. Use of multicast security extensions such as
those as described in <xref target="RFC5374"/> can help prevent
control plane monitoring.</t>
<!-- [HA] Pointed a privacy section -->
</section>
<section anchor="sec.unauthorized_group_membership"
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/MLD
messages, joining groups posing as legitimate hosts (or spoof source
traffic from legitimate hosts). For example, this may be done 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.</t>
<t>For the sake of completeness, it should be noted that multicast
routing protocol control messaging may be subject to similar threats
if sufficient protocol security mechanisms are not enabled in the
routing infrastructure. <xref target="RFC4609"/> describes security
threats to the PIM-SM multicast routing infrastructures.</t>
<!-- [HA] Added text and pointed mroutesec RFC -->
</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"/>], 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 traffic (and if authentication mechanisms are used, a
"replay" attack strategy might be used). 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 to that possible with rogue unicast packet generation and
similar measures (e.g., as described in <xref target="RFC4732"/>)
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>Sender message spoofing attacks are relevant for both of the
current reliable multicast transport protocols: ALC (sender-only
transmission) and NORM (sender-receiver exchanges). Without an
authentication mechanism, an attacker can generate sender messages
that could disrupt a reliable multicast transfer session. With
FEC-based transport mechanisms, a single packet with an
apparently-correct FEC payload identifier<xref target="RFC5052"/>
but a corrupted FEC payload would render an entire block of
transported data invalid. Thus, a modest injection rate of corrupt
traffic could cause severe impairment of data transport.
Additionally, 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
insufficiently 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 erroneously leaving groups associated with higher
bandwidth transport layers and suffering unnecessarily low transport
rates although this would be safe from a network operation
perspective. Similarly, receivers may be misled to join
inappropriate groups and cause unwanted traffic to be directed to
their part of the network. Attacks with similar effect could be
conducted against the <xref target="RFC4654">TCP-Friendly Multicast
Congestion Control (TFMCC)</xref> approach proposed for NORM
operation with spoofing of sender messages carrying congestion
control state to receivers. Packet source authentication techniques
such as those described in <xref target="BuildingBlocks"/> can be
used to mitigate sender message spoofing.</t>
</section>
<section title="Receiver Message Spoofing">
<t>These attacks are limited to reliable multicast 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 transmit at a rate unfair to those attacked receivers
if their fair congestion control rate were lower.</t>
</section>
<section anchor="ReplayAttacks" title="Replay Attacks">
<t>The "replay attack" (injection of a previously transmitted packet
to one or more 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
to 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 protocols defined by the IETF for reliable
multicast transport. However, the scope can also encompass additional
applications, like streaming applications. This section only focuses on
the desired general goals. It should be noted that many of these goals
also apply to IP unicast and/or IP multicast infrastructure and not
necessarily specific to RMT protocols. 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 operation of 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>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>
<t>and user protection: the goal is often to protect the user
privacy.</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 infrastructure by exploiting
some features of the RMT protocol. Since the RMT protocols 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 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 operation of the protocols is also of 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 reliable multicast transport.
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. As the RMT protocols often use UDP encapsulation,
much of the guidance described in <xref target="RFC5405"/>
applies.</t>
</section>
<section title="Content Protection">
<t>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. 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. For example, packet sender authentication
and content integrity services can be used for RMT systems that are
deployed within an open network, where any attacker can inject
spurious traffic in an ongoing NORM or ALC session.</t>
</section>
<section anchor="sec.privacy" title="Privacy">
<t>Finally the user should be protected, and more specifically their
privacy. In general, there is not a privacy issue for the data sender.
I.e., the data sender's address is announced to all prospective
receivers prior to their joins. Moreover receivers need to specify the
source address(es) as well as the IP multicast address in SSM
communication upon their subscription. The situation is different if
we consider receivers since their addresses do not need to be
disclosed publicly.</t>
<t>Data receivers use IGMP or MLD protocols to notify their upstream
routers to join or leave an IP multicast session. The recent IGMPv3
<xref target="RFC3376"/> and MLDv2 <xref target="RFC3810"/> do not
adopt the "report suppression mechanism". Report suppression makes the
receiver host withdraw its own report when the host hears a report
scheduled to be sent from other host joining the same group.
Eliminating the report suppression mechanism does not contribute to
minimizing the number of responses, but enables the router to
explicitly track of host membership status on a local network. Due to
this specification, operators who maintain upstream routers that
attach multicast data receiver can recognize data receivers' addresses
by tracing IGMP/MLD report messages. Although such traced data may be
useful for capacity planning or accounting from operator's
perspective, the detail information including receivers' IP addresses
should be carefully treated.</t>
<t>As described in <xref target="sec.unauthorized_group_membership"/>,
unauthorized users may spoof IGMP/MLD query messages and trace
receivers' addresses that are shared by the same Layer 2
infrastructure (e.g., LAN). Currently, IGMP/MLD protocols do not
protect this attack. It is desired for these protocols to ignore
invalid query messages and provide receiver's privacy by some
means.</t>
</section>
</section>
<section title="Elementary Security Techniques">
<t>The goals defined in <xref target="generalGoals"/> 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
object 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 techniques 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"/>.</t>
</section>
<section anchor="BuildingBlocks" 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>Group MAC;</t>
<t>Digital signatures;</t>
<t>TESLA;</t>
<t>SSM communication model;</t>
<!-- [HA] wording -->
</list> Each of them is briefly discussed below. In particular we
identify the services it offers, its limitations, and its field of
application (adequacy with respect to the RMT protocol 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="RFC4301"/> to achieve the following properties: <list
style="symbols">
<t>source authentication and packet integrity (IPsec AH or
ESP)</t>
<t>confidentiality by means of encryption (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"/>. The following list proposes the
IPsec capabilities needed to support a similar approach to RMT
protocol security: <list style="symbols">
<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"/> 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 multicast transport provides robustness to
any message loss that might occur due to ANY timing discrepancies
among the session participants.</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="Group MAC">
<section title="Benefits">
<t>The use of Group MAC (Message Authentication Codes) within <xref
target="RFC6584">Simple Authentication Schemes for the ALC and NORM
Protocols</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. Note that the Group MAC and Digital Signature
schemes can be advantageously used together, as explained in <xref
target="RFC6584">Simple Authentication Schemes for the ALC and NORM
Protocols</xref>.</t>
</section>
</section>
<section title="Digital Signatures">
<section title="Benefits">
<t>The use of Digital Signatures within <xref
target="RFC6584">Simple Authentication Schemes for the ALC and NORM
Protocols</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
Infrastructure (PKI) or by preplacement of these keys.</t>
</section>
<section title="Requirements">
<t>This scheme is simple to deploy since it requires only that the
participants know the packet sender's public key, which can be
achieved with either PKI or by preplacement of these keys.</t>
</section>
<section title="Limitations">
<t>When RSA <xref target="RsaPaper"/> asymmetric cryptography is
used, the digital signatures approach has two major shortcomings:
<list style="symbols">
<t>high computational costs, especially at the sender, and</t>
<t>high transmission overhead.</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. The use of ECC ("Elliptic 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. Note that the Group MAC and Digital
Signature schemes can be advantageously used together, as explained
in <xref target="RFC6584">Simple Authentication Schemes for the ALC
and NORM Protocols</xref>.</t>
</section>
</section>
<section title="TESLA">
<t>The Timed Efficient Stream Loss-tolerant Authentication (TESLA)
protocol allows multicast receivers to check the integrity and
authenticate the source of each packet in multicast or broadcast data
streams with low-cost computational operations. TESLA is also tolerant
of packet loss, thus making it suitable as an underlying security
mechanism for RMT protocols.</t>
<section title="Benefits">
<t>The use of <xref target="RFC5776">TESLA</xref> within reliable
multicast transport offers a loss tolerant, lightweight,
authentication/integrity service for the packets generated by the
session's sender. Depending on the time synchronization and
bootstrap methods used, TESLA can be compatible with massively
scalable sessions. Because TESLA 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>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 <xref
target="RFC5905">Network Time Protocol (NTP)</xref> infrastructure
(which also requires a bidirectional transport channel), a common,
central time reference (e.g., Global Positioning System (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. 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>One 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="Source-Specific Multicast">
<!-- [HA] Changed -->
<t><xref target="RFC3569">Source-Specific Multicast (SSM)</xref>,
<xref target="RFC4607"/> amends the classical Any-Source Multicast
(ASM) model by creating logical IP multicast "channels" that are
defined by the multicast destination address <spanx style="emph">and</spanx>
the specific source address(es). Thus for a given "channel", only the
specific source(s) can inject packets that are distributed to the
receivers. This form of multicast has group management benefits since
a source can independently control the "channels" it creates and the
need for globally coordinated group address management is reduced. The
security considerations for SSM multicast are described in <xref
target="RFC4609"/>.</t>
<section title="Requirements">
<t>Use of SSM requires that the network intermediate systems
explicitly support it. For RMT protocol participants, it is
necessary that the source address as well as the group address is
available as part of session description information. Additionally,
hosts operating systems are required to support the IGMPv3/MLDv2
extensions for SSM, and the reliable multicast transport
implementations need to support the IGMPv3/MLDv2 API, including
management of the <srcAddr; dstMcastAddr> "channel"
identifiers. It should be noted that the SSM paradigm can also be
logically implemented where receivers explicitly filter data
transfer packets to be only allowed from the expected source.</t>
</section>
<section title="Limitations">
<t>Reliable multicast transport 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>
<!-- [HA] Modified with source-based and receiver-based attacks, and merged "Benefits" section -->
</section>
<section title="Summary">
<t>The following table summarizes the pros/cons of each
authentication/integrity scheme used at application/transport level
(where "-" means bad, "0" means neutral, and "+" means good):</t>
<texttable>
<ttcol align="left"/>
<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 authentication and integrity</c>
<c>Yes</c>
<c>Yes</c>
<c>No (group security)</c>
<c>Yes</c>
<c>Immediate authentication</c>
<c>Yes</c>
<c>Yes</c>
<c>Yes</c>
<c>No</c>
<c>Processing load</c>
<c>-</c>
<c>0</c>
<c>+</c>
<c>+</c>
<c>Transmission overhead</c>
<c>-</c>
<c>0</c>
<c>+</c>
<c>+</c>
<c>Complexity</c>
<c>+</c>
<c>+</c>
<c>+</c>
<c>-</c>
</texttable>
<!--
<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 reliable multicast transport protocol (since key management is
done automatically, using a key server topology), or the security
provided (since the underlying cryptographic keys will be changed
frequently)</t>
</list></t>
<t>It is expected that some reliable multicast deployments may use
existing client-server security infrastructure models so that receivers
may acquire any necessary security material 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. The IETF has developed some Multicast Security
(MSEC) protocols that can be applied to achieve more scalable and
effective group communication security infrastructure<xref
target="RFC4046"/>. It is encouraged that these mechanisms be considered
in the development of security for reliable multicast transport
protocol.</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 overload a receiver
(or a sender in case of NORM) by injecting a significant number of faked
packets.</t>
</section>
<section title="Future IETF Considerations">
<t>To meet all of the goals outlined in this document, it is expected
that the IETF may need to develop some additional supporting protocol
security mechanisms. This can include some extensions to the existing
RMT protocols that feature extensible header fields. As an example, some
considerations for an RMT security encapsulation extension are described
below.</t>
<!-- [HA] Added MBONED WG statement -->
<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, confidentiality, 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 <spanx style="verb">NormNodeId</spanx>
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 management.</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="IANA Considerations">
<t>This document has no actions for IANA.</t>
</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="Informative References">
<?rfc include='reference.RFC.4301'?>
<?rfc include='reference.RFC.5052'?>
<?rfc include="reference.RFC.6726"?>
<?rfc include="reference.RFC.5740"?>
<?rfc include='reference.RFC.4535'?>
<?rfc include='reference.RFC.4552'?>
<?rfc include='reference.RFC.4082'?>
<?rfc include='reference.RFC.4046'?>
<?rfc include='reference.RFC.4609'?>
<?rfc include="reference.RFC.5775"?>
<?rfc include="reference.RFC.5776"?>
<?rfc include='reference.RFC.6584'?>
<?rfc include='reference.RFC.3376'?>
<?rfc include='reference.RFC.3810'?>
<?rfc include='reference.RFC.1112'?>
<?rfc include='reference.RFC.3569'?>
<?rfc include='reference.RFC.4732'?>
<?rfc include='reference.RFC.4607'?>
<?rfc include='reference.RFC.4654'?>
<?rfc include='reference.RFC.5405'?>
<reference anchor="Neumann05">
<front>
<title>Large Scale Content Distribution Protocols</title>
<author fullname="Christoph Neumann" initials="C." surname="Neumann">
<organization/>
</author>
<author fullname="Vincent Roca" initials="V." surname="Roca">
<organization/>
</author>
<author fullname="Rod Walsh" initials="R." surname="Walsh">
<organization/>
</author>
<date month="October" year="2005"/>
<abstract>
<t/>
</abstract>
</front>
<seriesInfo name="ACM Computer Communications Review (CCR)"
value="Vol. 35 No. 5"/>
</reference>
<reference anchor="RsaPaper">
<front>
<title>A Method for Obtaining Digital Signatures and Public-Key
Cryptosystems</title>
<author fullname="R.L. Rivest" initials="R.L." surname="Rivest">
<organization/>
</author>
<author fullname="A. Shamir" initials="A." surname="Shamir">
<organization/>
</author>
<author fullname="L. Adleman" initials="L." surname="Adleman">
<organization/>
</author>
<date year="1978"/>
</front>
<seriesInfo name="Communications of the ACM 21," value="pp. 120-126"/>
<format target="http://people.csail.mit.edu/rivest/Rsapaper.pdf"
type="HTML"/>
</reference>
<reference anchor="Baltatu00">
<front>
<title>Security Issues in Control, Management and Routing
Protocols</title>
<author fullname="M. Baltatu" initials="M." surname="Baltatu">
<organization/>
</author>
<author fullname="A. Loy" initials="A." surname="Loy">
<organization/>
</author>
<author fullname="F. Maino" initials="F." surname="Maino">
<organization/>
</author>
<author fullname="D. Mazzocchi" initials="D." surname="Mazzocchi">
<organization/>
</author>
<date month="May" year="2000"/>
</front>
<seriesInfo name="Elsevier Computer Networks" value="pp. 881-894"/>
</reference>
<?rfc include='reference.RFC.5905'?>
<?rfc include='reference.RFC.5374'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:54:17 |