[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

RMT                                                           B. Adamson
Internet-Draft                                 Naval Research Laboratory
Intended status: Informational                                   V. Roca
Expires: November 11, 2010                                         INRIA
                                                               H. Asaeda
                                                         Keio University
                                                            May 10, 2010


  Security and Reliable Multicast Transport Protocols: Discussions and
                               Guidelines
                    draft-ietf-rmt-sec-discussion-05

Abstract

   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 discussions and
   potential resolution of any significant security issues that may
   exist in the current set of RMT standards.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 11, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the



Adamson, et al.         Expires November 11, 2010               [Page 1]


Internet-Draft         Security and RMT Protocols               May 2010


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.




























Adamson, et al.         Expires November 11, 2010               [Page 2]


Internet-Draft         Security and RMT Protocols               May 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Conventions Used in this Document  . . . . . . . . . . . .  6
   2.  Quick Introduction to RMT Protocols and their Use  . . . . . .  6
     2.1.  The Two Families of CDP  . . . . . . . . . . . . . . . . .  6
     2.2.  RMT Protocol Characteristics . . . . . . . . . . . . . . .  7
     2.3.  Target Use Case Characteristics  . . . . . . . . . . . . .  7
   3.  Some Security Threats  . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Control-Plane Attacks  . . . . . . . . . . . . . . . . . .  9
       3.1.1.  Control Plane Monitoring . . . . . . . . . . . . . . .  9
       3.1.2.  Unauthorized (or Malicious) Group Membership . . . . . 10
     3.2.  Data-Plane Attacks . . . . . . . . . . . . . . . . . . . . 10
       3.2.1.  Rogue Traffic Generation . . . . . . . . . . . . . . . 11
       3.2.2.  Sender Message Spoofing  . . . . . . . . . . . . . . . 11
       3.2.3.  Receiver Message Spoofing  . . . . . . . . . . . . . . 12
       3.2.4.  Replay Attacks . . . . . . . . . . . . . . . . . . . . 12
   4.  General Security Goals . . . . . . . . . . . . . . . . . . . . 13
     4.1.  Network Protection . . . . . . . . . . . . . . . . . . . . 14
     4.2.  Protocol Protection  . . . . . . . . . . . . . . . . . . . 14
     4.3.  Content Protection . . . . . . . . . . . . . . . . . . . . 14
     4.4.  Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . 15
   5.  Elementary Security Techniques . . . . . . . . . . . . . . . . 15
   6.  Technological Building Blocks  . . . . . . . . . . . . . . . . 17
     6.1.  IPsec  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
       6.1.1.  Benefits . . . . . . . . . . . . . . . . . . . . . . . 17
       6.1.2.  Requirements . . . . . . . . . . . . . . . . . . . . . 18
       6.1.3.  Limitations  . . . . . . . . . . . . . . . . . . . . . 18
     6.2.  Group MAC  . . . . . . . . . . . . . . . . . . . . . . . . 19
       6.2.1.  Benefits . . . . . . . . . . . . . . . . . . . . . . . 19
       6.2.2.  Requirements . . . . . . . . . . . . . . . . . . . . . 19
       6.2.3.  Limitations  . . . . . . . . . . . . . . . . . . . . . 19
     6.3.  Digital Signatures . . . . . . . . . . . . . . . . . . . . 19
       6.3.1.  Benefits . . . . . . . . . . . . . . . . . . . . . . . 19
       6.3.2.  Requirements . . . . . . . . . . . . . . . . . . . . . 20
       6.3.3.  Limitations  . . . . . . . . . . . . . . . . . . . . . 20
     6.4.  TESLA  . . . . . . . . . . . . . . . . . . . . . . . . . . 20
       6.4.1.  Benefits . . . . . . . . . . . . . . . . . . . . . . . 20
       6.4.2.  Requirements . . . . . . . . . . . . . . . . . . . . . 21
       6.4.3.  Limitations  . . . . . . . . . . . . . . . . . . . . . 21
     6.5.  Source-Specific Multicast  . . . . . . . . . . . . . . . . 21
       6.5.1.  Requirements . . . . . . . . . . . . . . . . . . . . . 22
       6.5.2.  Limitations  . . . . . . . . . . . . . . . . . . . . . 22
       6.5.3.  Source-Based and Receiver-Based Attacks  . . . . . . . 22
     6.6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . 23
   7.  Security Infrastructure  . . . . . . . . . . . . . . . . . . . 23
   8.  New Threats Introduced by the Security Scheme Itself . . . . . 24
   9.  Consequences for the RMT and MSEC Working Group  . . . . . . . 24



Adamson, et al.         Expires November 11, 2010               [Page 3]


Internet-Draft         Security and RMT Protocols               May 2010


     9.1.  RMT Transport Message Security Encapsulation Header  . . . 24
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     13.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27











































Adamson, et al.         Expires November 11, 2010               [Page 4]


Internet-Draft         Security and RMT Protocols               May 2010


1.  Introduction

   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 Asynchronous Layered
   Coding (ALC) [RFC5775], NACK-Oriented Reliable Multicast (NORM)
   [RFC5740], and the File Delivery over Unidirectional Transport
   (FLUTE) [I-D.ietf-rmt-flute-revised] application that is built on top
   of ALC.  These can be considered "Content Delivery Protocols" (CDP)
   as described in [Neumann05].  In this document, the term CDP will
   refer indifferently to either ALC or NORM, with their associated BBs.

   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) [RFC1112] 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 Source-Specific Multicast (SSM)
   [RFC3569], [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.

   The goals of this document are therefore to:

   1.  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);

   2.  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),



Adamson, et al.         Expires November 11, 2010               [Page 5]


Internet-Draft         Security and RMT Protocols               May 2010


       while others are specific to RMT protocols (e.g., congestion
       control specific security schemes);

   3.  List some technological building blocks and solutions that can
       provide the desired security services;

   4.  Highlight the CDP 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;

   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.

1.1.  Conventions Used in this Document

   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 [RFC2119].


2.  Quick Introduction to RMT Protocols and their Use

2.1.  The Two Families of CDP

   The ALC and NORM classes of CDP 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.

   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.

   The appropriate choice of a CDP depends upon application needs,
   deployment constraints, and network connectivity considerations.  And



Adamson, et al.         Expires November 11, 2010               [Page 6]


Internet-Draft         Security and RMT Protocols               May 2010


   while there are many common security considerations for these two
   classes of CDP, there are also some unique considerations for each.

2.2.  RMT Protocol Characteristics

   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.

   The ALC and NORM protocols also differ in the communication paths:

   o  sender to receivers: ALC and NORM, for bulk data transfer and
      signaling messages;

   o  receivers to sender: NORM only, for feedback messages;

   o  receivers to receivers: NORM only for control messages;

   Note that the fact ALC is capable of working on top of purely
   unidirectional networks does not mean that no back-channel is
   available (Section 2.3).

   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.

2.3.  Target Use Case Characteristics

   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:

   o  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;

   o  Massively scalable versus moderately scalable session.  Here we do
      not define precisely what the terms "massively scalable" and
      "moderately scalable" mean.



Adamson, et al.         Expires November 11, 2010               [Page 7]


Internet-Draft         Security and RMT Protocols               May 2010


   o  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;

   o  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?

   o  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).

   o  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;

   o  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.

   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.


3.  Some Security Threats

   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.





Adamson, et al.         Expires November 11, 2010               [Page 8]


Internet-Draft         Security and RMT Protocols               May 2010


3.1.  Control-Plane Attacks

   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
   multicast routing protocol messaging.  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.

   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 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.

3.1.1.  Control Plane Monitoring

   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 Section 4.4.



Adamson, et al.         Expires November 11, 2010               [Page 9]


Internet-Draft         Security and RMT Protocols               May 2010


3.1.2.  Unauthorized (or Malicious) Group Membership

   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.

   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).  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 sufficient protocol security mechanisms are not enabled in the
   routing infrastructure.  [RFC4609] describes security threats to the
   PIM-SM multicast routing infrastructures.

3.2.  Data-Plane Attacks

   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 Section 3.2.4], as it can be applied
   across these different categories.



Adamson, et al.         Expires November 11, 2010              [Page 10]


Internet-Draft         Security and RMT Protocols               May 2010


3.2.1.  Rogue Traffic Generation

   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 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.

3.2.2.  Sender Message Spoofing

   Sender message spoofing attacks are applicable to both CDP: ALC
   (sender-only transmission) and NORM (sender-receiver exchanges).
   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[RFC5052] 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.
   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.

   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.  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 TCP-Friendly Multicast
   Congestion Control (TFMCC) [RFC4654] approach proposed for NORM
   operation with spoofing of sender messages carrying congestion
   control state to receivers.






Adamson, et al.         Expires November 11, 2010              [Page 11]


Internet-Draft         Security and RMT Protocols               May 2010


3.2.3.  Receiver Message Spoofing

   These attacks are limited to CDP 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.

   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.

   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.

3.2.4.  Replay Attacks

   The infamous "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.

3.2.4.1.  Replay of Sender Messages

   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



Adamson, et al.         Expires November 11, 2010              [Page 12]


Internet-Draft         Security and RMT Protocols               May 2010


   that replay of old messages could corrupt data of a current transfer.

3.2.4.2.  Replay of Receiver Messages

   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.


4.  General Security Goals

   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 CDP defined in the IETF RMT working group.
   However, the scope can also encompass additional applications, like
   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.

   The possible final goals include, in decreasing order of importance:

   o  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);

   o  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;

   o  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;

   o  and user protection: the goal is often to protect the user
      privacy.






Adamson, et al.         Expires November 11, 2010              [Page 13]


Internet-Draft         Security and RMT Protocols               May 2010


4.1.  Network Protection

   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 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.

4.2.  Protocol Protection

   Protecting 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 CDP.  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.

4.3.  Content Protection

   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.

   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



Adamson, et al.         Expires November 11, 2010              [Page 14]


Internet-Draft         Security and RMT Protocols               May 2010


   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.

4.4.  Privacy

   Finally the user should be protected, and more specifically its
   privacy.  In general, there is no privacy issue for data sender: 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 address should not be disclosed publicly.

   Data receivers use IGMP or MLD protocols to notify their upstream
   routers to join or leave IP multicast session.  The recent IGMPv3
   [RFC3376] and MLDv2 [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 keep track of host membership
   status on a link.  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.

   As described in Section 3.1.2, unauthorized users may spoof IGMP/MLD
   query messages and trace receivers' addresses on the same 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.


5.  Elementary Security Techniques

   The goals defined in Section 4 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:








Adamson, et al.         Expires November 11, 2010              [Page 15]


Internet-Draft         Security and RMT Protocols               May 2010


   +-----------------+-------------------------------------------------+
   | Technique       | Goal                                            |
   +-----------------+-------------------------------------------------+
   | packet          | Enable session participants to verify that a    |
   | integrity       | packet has not been inappropriately modified in |
   |                 | transit.                                        |
   | packet source   | Enable a receiver to verify the source of a     |
   | authentication  | packet.                                         |
   | packet group    | Enable a receiver to verify that a packet       |
   | authentication  | 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.                                |
   | packet          | Enable any third party to verify the source of  |
   | non-repudiation | a packet such that the source cannot repudiate  |
   |                 | having sent the packet.                         |
   | packet          | Enable a receiver to detect that a packet is    |
   | anti-replay     | the same as a previously-received packet        |
   | object          | Enable a receiver to verify the integrity of a  |
   | integrity       | 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.                               |
   | object source   | Enable a receiver to verify the source of an    |
   | authentication  | object.                                         |
   | object          | Enable a source to guarantee that only          |
   | confidentiality | authorized receivers can access the object      |
   |                 | data.                                           |
   +-----------------+-------------------------------------------------+

                        General Security Techniques

   Some additional techniques are specific to the RMT protocols:

   +---------------+---------------------------------------------------+
   | Technique     | Goal                                              |
   +---------------+---------------------------------------------------+
   | congestion    | Prevent an attacker from modifying the congestion |
   | control       | control protocol normal behavior (e.g., by        |
   | security      | reducing the transmission (NORM) or reception     |
   |               | (ALC) rate, or on the opposite increasing this    |
   |               | rate up to a point where congestion occurs)       |
   | group         | Ensure that only authorized receivers (as defined |
   | management    | by a certain group management policy) join the    |
   |               | RMT session and possibly inform the source        |



Adamson, et al.         Expires November 11, 2010              [Page 16]


Internet-Draft         Security and RMT Protocols               May 2010


   | backward      | Prevent a new group member to access the          |
   | group secrecy | information in clear sent to the group before he  |
   |               | joined the group                                  |
   | forward group | Prevent a former group member to access the       |
   | secrecy       | information in clear sent to the group after he   |
   |               | left the group                                    |
   +---------------+---------------------------------------------------+

                     RMT-Specific Security Techniques

   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 Section 2.3.


6.  Technological Building Blocks

   Here is a list of techniques and building blocks that are likely to
   fulfill one or several of the goals listed above:

   o  IPsec;

   o  Group MAC;

   o  Digital signatures;

   o  TESLA;

   o  SSM communication model;

   Each of them is now quickly discussed.  In particular we identify
   what service it can offer, its limitations, and its field of
   application (adequacy with respect to the CDP and the target use
   case).

6.1.  IPsec

6.1.1.  Benefits

   One direct approach using existing standards is to apply IPsec
   [RFC4301] to achieve the following properties:

   o  source authentication and packet integrity (IPsec AH or ESP)

   o  confidentiality by means of encryption (IPsec ESP)




Adamson, et al.         Expires November 11, 2010              [Page 17]


Internet-Draft         Security and RMT Protocols               May 2010


6.1.2.  Requirements

   It is expected that the approach to apply IPsec for reliable
   multicast transport sessions is similar to that described for OSPFv3
   security[RFC4552].  The following list proposes the IPsec
   capabilities needed to support a similar approach to RMT protocol
   security:

   o  Mode - Transport mode IPsec security is required;

   o  Selectors - source and destination addresses and ports, protocol.

   o  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 [RFC4535] may be
      used to emplace the keys for IPsec operation.

   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 CDP provide robustness to any
   message loss that might occur due to ANY timing discrepancies among
   the participants in the reliable multicast session.

6.1.3.  Limitations

   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.






Adamson, et al.         Expires November 11, 2010              [Page 18]


Internet-Draft         Security and RMT Protocols               May 2010


6.2.  Group MAC

6.2.1.  Benefits

   The use of Group MAC (Message Authentication Codes) within the CDP
   [SimpleAuth] 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.

6.2.2.  Requirements

   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).

6.2.3.  Limitations

   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
   [SimpleAuth].

6.3.  Digital Signatures

6.3.1.  Benefits

   The use of Digital Signatures within the CDP [SimpleAuth] 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.







Adamson, et al.         Expires November 11, 2010              [Page 19]


Internet-Draft         Security and RMT Protocols               May 2010


6.3.2.  Requirements

   This scheme is easy 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.

6.3.3.  Limitations

   When RSA [RsaPaper] asymmetric cryptography is used, the digital
   signatures approach has two major shortcomings:

   o  it is limited by high computational costs, especially at the
      sender, and

   o  it is limited by high transmission overheads.

   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:

           +--------------------+--------------+--------------+
           | Symmetric Key Size | RSA Key Size | ECC Key Size |
           +--------------------+--------------+--------------+
           |       80 bits      |   1024 bits  |   160 bits   |
           |      112 bits      |   2048 bits  |   224 bits   |
           +--------------------+--------------+--------------+

   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 [SimpleAuth].

6.4.  TESLA

6.4.1.  Benefits

   The use of TESLA [RFC5776] within the CDP 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



Adamson, et al.         Expires November 11, 2010              [Page 20]


Internet-Draft         Security and RMT Protocols               May 2010


   suitable for high data rate transmissions, and/or lightweight
   terminals.  Finally, the transmission overhead remains limited.

6.4.2.  Requirements

   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 Network Time
   Protocol (NTP) [RFC1305] infrastructure (which also requires a
   bidirectional transport channel), or a Global Positioning System
   (GPS) device, or a clock with a time-drift that is negligible in
   front of the TESLA time accuracy requirements.

   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.

6.4.3.  Limitations

   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.

   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.

6.5.  Source-Specific Multicast

   Source-Specific Multicast (SSM) [RFC3569], [RFC4607] amends the
   classical Any-Source Multicast (ASM) model by creating logical IP
   multicast "channels" that are defined by the multicast destination
   address _and_ 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.






Adamson, et al.         Expires November 11, 2010              [Page 21]


Internet-Draft         Security and RMT Protocols               May 2010


6.5.1.  Requirements

   Use of SSM requires that the network intermediate systems explicitly
   support it.  Additionally, hosts operating systems are required to
   support the IGMPv3/MLDv2 extensions for SSM, and the CDP
   implementations need to support the IGMPv3/MLDv2 API, including
   management of the <srcAddr; dstMcastAddr> "channel" identifiers.

6.5.2.  Limitations

   CDP 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.

6.5.3.  Source-Based and Receiver-Based Attacks

   The security threats are categorized into "source-based" and
   "receiver-based" attacks [RFC4609].  In short, the former is a DoS
   attack against the multicast networks, in which data is sent to
   numerous and random group addresses, and the latter is a DoS attack
   against multicast routers, in which innumerable IGMP/MLD joins are
   sent from a client.

   Regarding source-based attack, there are some security benefits in
   SSM.  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 mechanism 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.

   On the contrary, SSM is not robust against receiver-based attack.  An
   SSM capable router constructs a Shortest-Path Tree (SPT) with no
   shared tree coordination.  Therefore, even if a host triggers invalid
   or unavailable channel subscriptions, the upstream router starts
   establishing all SPTs with no intellectual decision.  What is worse
   is that these multicast routers cannot recognize the original router
   that is attacked and cannot stop the attack itself.




Adamson, et al.         Expires November 11, 2010              [Page 22]


Internet-Draft         Security and RMT Protocols               May 2010


6.6.  Summary

   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):

   +------------------+-------------+-------------+------------+-------+
   |                  | RSA Digital | ECC Digital |  Group MAC | TESLA |
   |                  |  Signature  |  Signature  |            |       |
   +------------------+-------------+-------------+------------+-------+
   | True             |     Yes     |     Yes     |  No (group |  Yes  |
   | authentication   |             |             |  security) |       |
   | and integrity    |             |             |            |       |
   | Immediate        |     Yes     |     Yes     |     Yes    |   No  |
   | authentication   |             |             |            |       |
   | Processing load  |      -      |      0      |      +     |   +   |
   | Transmission     |      -      |      0      |      +     |   +   |
   | overhead         |             |             |            |       |
   | Complexity       |      +      |      +      |      +     |   -   |
   +------------------+-------------+-------------+------------+-------+


7.  Security Infrastructure

   Deploying the elementary technological building blocks often requires
   that a security infrastructure exists.  Such security infrastructure
   can provide:

   o  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.

   o  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)

   It is expected that some CDP 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



Adamson, et al.         Expires November 11, 2010              [Page 23]


Internet-Draft         Security and RMT Protocols               May 2010


   reliable multicast transfer.  The IETF Multicast Security (MSEC)
   Working Group has developed some protocols that can be applied to
   achieve more scalable and effective group communication security
   infrastructure[RFC4046].  It is encouraged that these mechanisms be
   considered in the development of security for CDP.


8.  New Threats Introduced by the Security Scheme Itself

   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.


9.  Consequences for the RMT and MSEC Working Group

   To meet the goals outlined in this document, it is expected that the
   RMT and MSEC Working Groups may need to develop some supporting
   protocol security mechanisms.  It is also possible to cooperate with
   the Multicast Backbone (MBONE) Deployment (MBONED) Working Group for
   defining operational considerations.

9.1.  RMT Transport Message Security Encapsulation Header

   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 "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 GSAKMP [RFC4535] or a similar approach for
   automated key management.







Adamson, et al.         Expires November 11, 2010              [Page 24]


Internet-Draft         Security and RMT Protocols               May 2010


10.  IANA Considerations

   This document has no actions for IANA.


11.  Security Considerations

   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.


12.  Acknowledgments

   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.


13.  References

13.1.  Normative References

   [I-D.ietf-rmt-flute-revised]
              Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
              "FLUTE - File Delivery over Unidirectional Transport",
              draft-ietf-rmt-flute-revised-11 (work in progress),
              March 2010.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3569]  Bhattacharyya, S., "An Overview of Source-Specific
              Multicast (SSM)", RFC 3569, July 2003.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC4046]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
              "Multicast Security (MSEC) Group Key Management
              Architecture", RFC 4046, April 2005.



Adamson, et al.         Expires November 11, 2010              [Page 25]


Internet-Draft         Security and RMT Protocols               May 2010


   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4535]  Harney, H., Meth, U., Colegrove, A., and G. Gross,
              "GSAKMP: Group Secure Association Key Management
              Protocol", RFC 4535, June 2006.

   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
              for OSPFv3", RFC 4552, June 2006.

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4609]  Savola, P., Lehtonen, R., and D. Meyer, "Protocol
              Independent Multicast - Sparse Mode (PIM-SM) Multicast
              Routing Security Issues and Enhancements", RFC 4609,
              October 2006.

   [RFC4654]  Widmer, J. and M. Handley, "TCP-Friendly Multicast
              Congestion Control (TFMCC): Protocol Specification",
              RFC 4654, August 2006.

   [RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
              Correction (FEC) Building Block", RFC 5052, August 2007.

   [RFC5740]  Adamson, B., Bormann, C., Handley, M., and J. Macker,
              "NACK-Oriented Reliable Multicast (NORM) Transport
              Protocol", RFC 5740, November 2009.

   [RFC5775]  Luby, M., Watson, M., and L. Vicisano, "Asynchronous
              Layered Coding (ALC) Protocol Instantiation", RFC 5775,
              April 2010.

   [RFC5776]  Roca, V., Francillon, A., and S. Faurite, "Use of Timed
              Efficient Stream Loss-Tolerant Authentication (TESLA) in
              the Asynchronous Layered Coding (ALC) and NACK-Oriented
              Reliable Multicast (NORM) Protocols", RFC 5776,
              April 2010.

   [SimpleAuth]
              Roca, V., "Simple Authentication Schemes for the ALC and
              NORM Protocols", Internet
              Draft draft-ietf-rmt-simple_auth-for-alc-norm-02.txt (work
              in progress), October 2009.







Adamson, et al.         Expires November 11, 2010              [Page 26]


Internet-Draft         Security and RMT Protocols               May 2010


13.2.  Informative References

   [Neumann05]
              Neumann, C., Roca, V., and R. Walsh, "Large Scale Content
              Distribution Protocols", ACM Computer Communications
              Review (CCR) Vol. 35 No. 5, October 2005.

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation", RFC 1305, March 1992.

   [RsaPaper]
              Rivest, R., Shamir, A., and L. Adleman, "A Method for
              Obtaining Digital Signatures and Public-Key
              Cryptosystems", Communications of the ACM 21, pp. 120-126,
              1978.


Authors' Addresses

   Brian Adamson
   Naval Research Laboratory
   Washington, DC  20375
   USA

   Email: adamson@itd.nrl.navy.mil
   URI:   http://cs.itd.nrl.navy.mil


   Vincent Roca
   INRIA
   Montbonnot  38334
   France

   Email: vincent.roca@inria.fr
   URI:   http://planete.inrialpes.fr/~roca/


   Hitoshi Asaeda
   Keio University
   5322 Endo
   Fujisawa, Kanagawa  252-8520
   Japan

   Email: asaeda@wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~asaeda/






Adamson, et al.         Expires November 11, 2010              [Page 27]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/