[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
PERC                                                         J. Mattsson
Internet-Draft                                                M. Naslund
Intended status: Standards Track                           M. Westerlund
Expires: April 21, 2016                                         Ericsson
                                                        October 19, 2015


     Secure Real-time Transport Protocol (SRTP) for Cloud Services
                   draft-mattsson-perc-srtp-cloud-01

Abstract

   In order to support use cases when two or more end-points communicate
   via one (or more) cloud service (e.g. virtualized cloud-based
   conferencing) that are not trusted to access the media content, this
   document describes the use of so called end-to-end (inner) and hop-
   by-hop (outer) cryptographic transforms within the Secure Real-time
   Transport Protocol (SRTP).  One of the main aspects of the transforms
   is to make the confidentiality and message authentication independent
   of the RTP header.  Another central aspect is to enable
   identification of the cryptographic contexts (keys etc.).  Besides
   the security of the end-points, also trust assumptions regarding the
   cloud services are addressed.

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 April 21, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Mattsson, et al.         Expires April 21, 2016                 [Page 1]


Internet-Draft                 SRTP Cloud                   October 2015


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  End-To-End Security . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  End-to-End Payload  . . . . . . . . . . . . . . . . . . .   4
     3.2.  RTP Header Extensions . . . . . . . . . . . . . . . . . .   6
     3.3.  Replay Protection++ . . . . . . . . . . . . . . . . . . .   7
     3.4.  RTCP  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.4.1.  End-to-End Authenticated RTCP . . . . . . . . . . . .   9
       3.4.2.  End-to-End Confidential RTCP  . . . . . . . . . . . .   9
   4.  Hop-by-Hop Security . . . . . . . . . . . . . . . . . . . . .   9
   5.  Inband Key-Distribution . . . . . . . . . . . . . . . . . . .  10
   6.  Group Key-Management  . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     7.1.  Third Party Attacks . . . . . . . . . . . . . . . . . . .  11
     7.2.  MDD Attacks . . . . . . . . . . . . . . . . . . . . . . .  12
       7.2.1.  Denial of service . . . . . . . . . . . . . . . . . .  12
       7.2.2.  Replay Attack . . . . . . . . . . . . . . . . . . . .  12
       7.2.3.  Delayed Playout Attack  . . . . . . . . . . . . . . .  13
       7.2.4.  Splicing Attack . . . . . . . . . . . . . . . . . . .  13
       7.2.5.  Wrong Meta Data Attack  . . . . . . . . . . . . . . .  14
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   This document proposes a solution to achieve End-to-End Security for
   an RTP media streams and its meta data within the context of PERC.
   However, the document focuses on the RTP e2e protection mechanism.
   It only puts requirements on the key-management, not proposing a
   solution for that part.  This draft is a complete rewrite, and the
   proposal is based on what was sent to the PERC mailing list, but
   substantially updated based on feedback and discussion.





Mattsson, et al.         Expires April 21, 2016                 [Page 2]


Internet-Draft                 SRTP Cloud                   October 2015


   The discussion in this document is be based on the analysis of the
   RTP fields and how they needs to be handled written up in
   [I-D.westerlund-perc-rtp-field-considerations].  We will assume that
   the reader is familiar with that discussion.

   This document assumes a basic model for protection of the data that
   consists of the following high level functions.  A end-to-end media
   data protection mechanism as defined below in Section 3.  An inband
   key-distribution mechanism to provide endpoints with RTP stream
   specific keys, assumed to be EKT based, whose requirements are
   discussed in Section 5.  An key-management function that provides
   authorized endpoints with a EKT master key (Group key) (Section 6).
   In addition an hop-by-hop security mechanism (Section 4) are in use
   to protect that not possible to cover end-to-end with protection as
   necessary between the endpoints and middlboxes (MDD) in the system.

2.  Definitions

   This section provides a set of definitions.

2.1.  Terminology

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

   This document uses the following terms:

   Endpoint:  An RTP stream sending and/or receiving entity that is part
      of the end-to-end security context.

   MDD:  Media Delivery Device - An RTP middlebox that operates
      according to any of the three possible RTP topologies
      [I-D.ietf-avtcore-rtp-topologies-update] that is possible in the
      PERC system:

         Transport Translator - Relay

         Switching RTP Mixer

         Selective Forwarding Middlebox (SFM)

   Third Party:  An entity that is neither an endpoint nor an MDD.








Mattsson, et al.         Expires April 21, 2016                 [Page 3]


Internet-Draft                 SRTP Cloud                   October 2015


3.  End-To-End Security

   This section discusses the various components of the end-to-end
   security for the media data, the RTP header fields, RTP header
   extensions, and media related RTCP messages and information.

3.1.  End-to-End Payload

   The end-to-end payload consist of a couple of destinct parts that all
   needs to be considered:

   Media Payload:  The Media Payload containing the information packed
      according to the RTP payload format in use.

   Padding:  0 to 256 bytes of padding octets.  Used to obfuscate the
      RTP payload length when necessary.

   RTP Header Fields:  A number of RTP header fields are closely
      associated with the media payload.  They will be discussed below.

   The RTP header fields can be classified into several different
   categoriezes:

      E2E related, non-changable by MDD:

         P

         M

         Header Extensions

      E2E related, changable by MDD:

         PT

         Sequence number:

         Timestamp:

         SSRC/CSRC: Identifying the RTP Stream

         Header Extensions:

      Hop-by-hop:

         V:

         X:



Mattsson, et al.         Expires April 21, 2016                 [Page 4]


Internet-Draft                 SRTP Cloud                   October 2015


         CC:

         Header Extensions:

   As can be seen there are some fields that can be closely tied with
   the payload and which MUST be forwarded by the MDD unaltered.  We
   have other fields that needs to be possible to change by the MDD.
   For some of these it is critical that a receiving endpoint can learn
   the original value to verify that the MDD's actions as acceptable.
   Then there are some fields that are fixed in the protocol like V or
   otherwise needs to be handled on a hop-by-hop basis.  For the X and
   CC field their value is dependent on the need to carry some field in
   their corresponding data fields the Extension header and CSRC list
   respectively.

   The most problematic fields are the ones that have to be rewritten,
   but still have important indicator purposes, like PT, SSRC/CSRC,
   Timestamp and Header Extension IDs.  Sequence number is not included,
   just because we know it is so critical to know the relative order of
   transmitted packets that this MUST be preserved end-to-end.  Original
   Timestamp we will discuss below in Replay Protection (Section 3.3).

   Our proposal for the end-to-end media payload is the following:

   The SSRC is assigned uniquely by a higher management function.  For
   media switching mixers, that original value is preserved using the
   CSRC field.  Any MDD that receives a RTP stream that is a switched
   one, i.e. the SSRC belongs to the MDD, rather than originating
   endpoint, and thus contain an CSRC field, will have to copy forward
   the CSRC value, not the MDD's SSRC value into the produced outgoing
   packet's CSRC field.

      Note: We can support MDD that makes SSRC/CSRC translations, but
      for that to work we strongly recommend to mirror the original SSRC
      into the inband key-management protocol.  This to ensure that the
      unqiue stream identifier is preserved and can be verified and tied
      to other functions and verifications.

   The SSRC/CSRC field will be used by the receiving endpoint as a
   reference to the security context established by the combination of
   the RTP packets received and the information from the inband key-
   management protocol.  Any on-path SSRC/CSRC translation will be
   possible as the receiving endpoint will only use the received value
   as a reference to the context, not part of the protection operation.
   The important is that the originating SSRC is consistently handled by
   the system.





Mattsson, et al.         Expires April 21, 2016                 [Page 5]


Internet-Draft                 SRTP Cloud                   October 2015


   Each sent RTP packet from the originating endpoint will have in place
   of the regular RTP payload an security protected end-to-end payload.
   This payload will consist of 32-bit of end-to-end sequence number
   followed by a variable number of bytes of security payload.  The
   security payload is created by applying the cipher (AES-GCM
   [I-D.ietf-avtcore-srtp-aes-gcm] assumed) with as plaintext: RTP
   payload format, Padding, and as associated data: P, M, PT (Original),
   Timestamp (Original), End-to-end header extensions (both
   confidentiality and only authenticated one in plain text).

   As Initialization vector (IV) to the cipher the following data is
   used: HeaderExtFlag (1 bit) : NullFlags(7 bits) : NullPadding (24
   bits) : Stream Specific Key Sequence Nr (32 bits) : End-to-End
   Sequence number (32-bit).  These values are first concatenated and
   then XORed with the e2e session salt to form the e2e IV.  The stream
   specific key sequence number combined with the E2E sequence number
   forms an always increasing value for this particular RTP stream as
   identified by the unique stream ID (Orignal SSRC).  The HeaderExtFlag
   is set to 0 for protection of the end-to-end payload (this section)
   and set to 1 for the confidentiality and integrity operation of any
   RTP header Extensions (Section 3.2).

3.2.  RTP Header Extensions

   There exist RTP header extensions that needs to be end-to-end
   authenticated.  For these we want to ensure two important properties.
   A MDD shall not be able to remove it without detecting the removal,
   secondly, the integrity of the content of the header extension must
   be verified.  This is proposed by including the header extensions
   that are marked as requiring end-to-end authentication in the e2e
   associated data for the packet.

   This both the advantage and downside of being closely tied to the
   payload of the packet.  This is advantageous as it prevents the MDD
   from interfeering with the information and when it is provided.
   However, it prevents the MDD to include relevant meta data in header
   extensions at its own descretion.  One use case for this is Source
   description information like CNAME and MID that can be included with
   a stream when a new endpoint joins the conference.

   A complicating factor is that like the PT (payload type) the ID field
   for header extensions are dynamically assigned, and the mapping can
   be endpoint specific.  Which requires that the MDD can translate them
   as needed.  This makes it difficult for the receiving endpoint to
   verify which format the source truly indicated.  Preferably one
   should have a mechanism to indicate the original ID, so that the
   original value can be included in the associated data.




Mattsson, et al.         Expires April 21, 2016                 [Page 6]


Internet-Draft                 SRTP Cloud                   October 2015


   For RTP header extensions that requires confidentiality each header
   extension's data part is individually encrypted using a stream
   cipher.  AES-GCM is not recommended to use due to the expansion that
   the internal integrity tag.  The key will be the one associated with
   the source stream ID crypto context.  The IV needs to contain:
   HeaderExtFlag (1 bit = 1) : in packet order : Padding : Stream
   Specific Key Sequence Nr (32 bits) : End-to-End Sequence number
   (32-bit).  The "in packet order" number is a counter for each header
   extension included in the packet.  So the first header extension gets
   zero (0), the next one (1), and so on.  This results in that an MDD
   MUST retain the individual order of the header extensions when
   forwarding them.  We also note that by individually protecting each
   header extension, any header extension where the ID is the
   information, i.e. without any data there will be no confidentiality.

      Note: The reason to initially consider this strucutre is that is
      can avoid forcing a move to 2-byte header extension headers.  If
      one defines a new header extension that wraps all the header
      extensions including their ID and Lengths then it is likely that
      this becomes longer than 15 bytes.  It also locks in the IDs which
      forces the receiving endpoint to know how the IDs at the
      originating source maps to specific extensions.

   The authentication process for header extension is performed by
   taking each header extension in the order it was received and
   concatenate them togehter with the ID and length values in the field
   form used by two-bytes header extensions, independently which form
   they where received in.  This avoids authentication errors if an MDD
   needs to switch between one and two bytes header extension format.
   The ID field is replaced with a null value.  Having the original IDs
   would be preferable, as it would like for the PT enable verification
   of the intended format.  This block of data is included as Associated
   data in the decryption.

3.3.  Replay Protection++

   This section is called Replay Protection++ as it is not only replay
   protection that is needed.  Yes, replay protection is needed against
   replay attacks (Section 7.2.2), but also protection against a delayed
   playout attack (Section 7.2.3).  In addition the mechanism needs to
   be robust against splicing attacks (Section 7.2.4) where the attacker
   attempts to provide another stream as this source's one.

   The protection mechanism against these attacks works as follows.
   First the receiver tracks the source ID associated with a crypto
   context.  Every time a new key is provided by an EKT message the
   receiver needs to verify that the source ID matches with the one in




Mattsson, et al.         Expires April 21, 2016                 [Page 7]


Internet-Draft                 SRTP Cloud                   October 2015


   the context.  Next the key sequence number must be larger than stored
   otherwise the key in the context is kept.

   When an RTP packet is received the crypto context is retrieved.  The
   context stores the highest end-to-end sequence number received, and a
   vector indicating which of the last N packets that has been received,
   this to accept re-ordered packets that is only slightly delayed.  It
   also stores the reception time and corresponding original timestamp
   value.  First it forms the extended e2e sequence number concatinating
   the key sequence number (from EKT message if included and verified,
   or from context) with the e2e sequence number.  If that is greater
   than the stored highest seen extended sequence number or within the
   window of acceptable older packets and not previously received, then
   the processing continues.

   Then the time based checks are performed.  The reception time delta
   is compared with the RTP timestamp difference.  That difference must
   be within a error of margin equal to network jitter boundaries and an
   allowed fudge factor for media switching mixers to align content when
   switching.  The margin of error is no larger than one or two seconds.
   If the difference is bigger than this MUST be indicated to the user
   if played out, discarding media is recommended.

   For this method to be robust clock drift between sender and receiver
   needs to be tracked, as the RTP timestamp is based on the originating
   endpoint's clock and the reception time uses the receivers clock.
   Clock drift is only expected to be a significant issue if there is
   very long periods when no RTP packets are received with media from a
   particular sender.  Using RTCP SR the receiver can track sample clock
   versus senders general clock.  Every time a timestamped packet is
   received, SR or RTP they can be used to estimate the relative clock
   speed difference between endpoints.

   Next the decryption including authentication is performed.  If the
   received data is validated, then the crypto context is updated with
   the new highest extended sequence number as well as the time
   parameters.

3.4.  RTCP

   There exist a need for both end-to-end authenticated RTCP messages,
   as well as end-to-end confidentiality protected ones.  When it comes
   to confidentiality protected ones, these includes end-to-end codec
   control [RFC5104], such as region of interest [3GPP TS 26.114,
   version 13.1.0].  The ROI feedback message is used by a receiver to
   request to view a particular region of the total captured frame.
   There exist no reason for the MDD to know what region that is
   requested by which users.  If some of the defined RTCP SDES items was



Mattsson, et al.         Expires April 21, 2016                 [Page 8]


Internet-Draft                 SRTP Cloud                   October 2015


   to be used, like name, phone, location, and tool, there is
   significant privacy concerns around those, and they should be
   transported such that the MDD can't get access to them.  Other SDES
   items like CNAME, MID are meta data related to the session.  They can
   be generated in such a way that there are no privacy concerns with
   them.  However, one would like to ensure that they are integrity
   protected to prevent any modification on the path from the sender to
   any receiver.

   There also appears to be need for end-to-end messages providing vital
   information about each end-points actions, that can't be modified by
   the MDD.  This is to enable auditing of the MDDs and prevent that
   they attempt to fool the users of them.  For each unique e2e stream
   id each receiver should know how much packets actually was
   transmitted, what the current timestamp value, and corresponding wall
   clock time, preferably in a time base that can be tracked.

   Below we propose how to address these cases.

3.4.1.  End-to-End Authenticated RTCP

   The end-to-end authenticated RTCP is a new RTCP packet type used as
   authentication wrapper.  The new RTCP wrapper packet has the RTCP
   basic header identifying the packet type, the originating SSRC, the
   original SSRC (Source ID), a sequence number and an transmission
   timestamp (NTP format) and includes one or more regular RTCP packets
   with the information that needs to be end-to-end authenticated.  This
   may lead to that what before would have been multiple items in on
   RTCP packet, now becomes divided on multiple RTCP packets types based
   on its security classification.  The whole packet with the exception
   of the originating SSRC field is authenticated (associated data), and
   the tag (AES-GCM output) located last in the wrapper RTCP packet.

3.4.2.  End-to-End Confidential RTCP

   Similar to the e2e authenticated RTCP this packet is also a wrapper
   for one or more RTCP packets that need to handled confidential end-
   to-end.  The 64 byte common RTPC packet header is not encrypted.
   This is followed by a original SSRC (Source ID) field, a sequence
   number used to build the IV for the packet.  The part that is
   confidentiality protected is the transmission timestamp, the RTCP
   packets (in fully), and any RTCP padding.

4.  Hop-by-Hop Security

   We have considered that two different Hop-by-Hop security protocols
   may be used between an end-point and the MDD, as well as between one
   MDD and another MDD.  Those two protocols are SRTP [RFC3711] and DTLS



Mattsson, et al.         Expires April 21, 2016                 [Page 9]


Internet-Draft                 SRTP Cloud                   October 2015


   [RFC6347].  DTLS is included as our analysis
   [I-D.westerlund-perc-rtp-field-considerations] puts SRTP's design of
   leaving the RTP header fields in the clear into question in regards
   to use media confidentiality.  To make third party attacks more
   difficult we would recommend using DTLS over SRTP for the hop-by-hop
   security.

5.  Inband Key-Distribution

   An EKT like inband key-distribution mechanism is assumed.  This
   section discusses information that appear necessary to include in
   this security layer.

   The unique source ID MUST be provied in EKT to prevent both denial of
   service attacks (Section 7.2.1) as well as splicing attacks
   (Section 7.2.4).  The source ID also scopes the key sequence number.
   The key sequence number is monontionically increased each time the
   key distributed is changed.  This is to prevent replay attacks
   including the EKT, that would update and replace the current key with
   an old key.

   EKT could be used to provide other original field values that are
   assumed to have static mappings in MDD.  Thus, original PT, Header
   Extension IDs could be provided.

   While the current EKT mechanism is included in the RTP body of every
   packet, with a full EKT field sent periodically (e.g. every 100 ms),
   this may not be the optimal solution for PERC.  The MDD will likely
   have a much better understanding of when an endpoint needs the full
   EKT field and may store and forward EKT when needed (new key sequence
   number or new receiving endpoint).  This would not only save some
   bandwidth, but also minimize the time endpoints cannot decrypt
   because they have not got the latest key.  Further optimizations
   could be to let the endpoint ack the reception of full EKT fields.
   Letting the control the delivery of full EKT fields can be done with
   the current EKT model where the full EKT fields are not bound to a
   specific SRTP packet, but only to a specific stream.

   When the 32 bits Stream Specific End-to-End Sequence Nr is about to
   wrap, the sending end-point will have to rekey its transport key by
   sending a new full EKT field with a new transport key and a bumped up
   key sequence number.  With easy rekeying, we note that 32-bits are
   sufficient also for really high bit-rates.  At 3 Gbps using 1200
   bytes of payload one need to rekey approximately every 3 hours.







Mattsson, et al.         Expires April 21, 2016                [Page 10]


Internet-Draft                 SRTP Cloud                   October 2015


6.  Group Key-Management

   In many cases the party controlling the PERC conference will want to
   limit the ability of participants to decrypt (and modify or inject)
   media produced before the participant joined or after the participant
   left.  While some conferences will offer recording and allow all
   participants to decrypt the whole conference, participants modifying
   or injecting media after they have officially left the conference is
   not acceptable and must be mitigated.  The known solution to this is
   to change the group EKT key.  Either periodically or in conjunction
   with participants joining or leaving.  After each change of the group
   EKT key, each sending endpoint needs to rekey also the transport key
   and deliver that to all remaining participants encrypted by the new
   group key.

7.  Security Considerations

   This section discusses various security considerations, especially a
   number of attacks.

7.1.  Third Party Attacks

   While an on-path third party attacker is always able to perform
   Denial of Service (DoS) Attacks by blocking all or selected packages,
   the PERC solution should be take measures to mitigate more serious
   DoS attacks form on-path and off-path attackers.  On-path attacks are
   mitigated by hbh integrity protection and encryption.  The integrity
   protection mitigates packet modification and encryption makes
   selective blocking of packets harder, but not impossible.

   Off-path attackers may perform DoS attacks by connecting to different
   PERC entities and deliver Specificly crafted packets.  One potential
   attack is if an attacker is able to get packets forwarded by the MDD,
   replacing a legitimate stream from one of the trusted endpoints.  If
   hbh authentication Is not used, such an attack would only be detected
   in the receiving endpoints where the forged packets would be dropped.
   It is therefore essential that the MDD (or the call processing node)
   authenticates the endpoints as being invited members of the
   conference.

   Another potential attack is a third party claiming to be an MDD,
   fooling endpoints points to send packets to the false MDD instead of
   the correct one.  The deceived sending endpoint would then think the
   packets have been delivered to endpoints when they in fact have not
   been.  If the false MDD can trick several endpoints to connect (or
   connect as an cascading MDD to another legitimate MDD) it may create
   a false version of the real conference, giving the connected
   endpoints a completely distorted view of the conference.  To prevent



Mattsson, et al.         Expires April 21, 2016                [Page 11]


Internet-Draft                 SRTP Cloud                   October 2015


   this attack all endpoints and MDDs MUST authenticate other MDDs to
   ensure that They are legitimate semi-trusted MDDs.

7.2.  MDD Attacks

   The MDD can attack the session in a number of possible ways.

7.2.1.  Denial of service

   Any modification of the end-to-end authenticated data will result in
   the receiving endpoint to get an integrity failure when performing
   authentication on the received packet.

   The MDD can also attempt perform resource consumption attacks on the
   receiving endpoint.  One such attack would be to provide random SSRC/
   CSRC value to any RTP packet with an inband key-distribution message
   (EKT) attached.  As the EKT message enables the receiver to form a
   new crypto context, the MDD can attempt to consume the receiving
   endpoints resources.  This attack will be possible to detect and
   mitigate if the EKT messages contains the unique e2e stream id.

   An denial of service attack is that the MDD rewrites the PT field to
   another codec.  The MDD will usually know which PT corresponds to
   which codec.  The effect of this attack is that an payload packetized
   and encoded according to one RTP payload format is then processed
   using another payload format and codec.  Assuming that the
   implementation is robust to random input it is unlikely to cause
   crashes in the receiving software/hardware.  However, it is not
   unlikely that such rewriting will cause severe media degradations.
   For audio formats, especially sample based, this attack is likely to
   cause highly disturbing audio, that can be damaging to hearing and
   the playout equipment.  This draft proposes that the original PT is
   provided end-to-end.  However, without knowledge about the stream
   source's original media format MIME paraemters for each PT one can't
   verify correct mapping.  Only detect attempts of remapping during the
   session.

7.2.2.  Replay Attack

   Replay attack is when an already received packets from a previous
   point in the RTP Stream is replayed as new packets.  This could for
   example allow an MDD to transmit a sequence of packets identified as
   a user saying "yes", instead of the "no" the user actually said.

   The mitigation for a replay attack is to prevent old packets beyond a
   small jitter and network re-ordering window to be rejected.  The end-
   to-end replay protection must be provided for the whole duration of
   the conference and must therefore based on a single monotonically



Mattsson, et al.         Expires April 21, 2016                [Page 12]


Internet-Draft                 SRTP Cloud                   October 2015


   increasing number.  The proposal in this document combines an end-to-
   end sequence number that is incremented with a key-sequence number,
   thus preventing that the reseting of the end-to-end sequence number
   when a re-keying occurs to allow old packets from being replayed.

7.2.3.  Delayed Playout Attack

   The delayed playout attack is an variant of the replay attack.  This
   attack is possible even if e2e replay protection is in place.
   However, due to that the MDD is allowed to select a sub-set of
   streams and not forward the rest to a receiver the receiver has to
   accept gaps in the e2e packet sequence.  The issue with this is that
   an MDD can select to not deliver a particular stream for a while.
   Within the window from last packet forward to the receiver and the
   latest received by the MDD, the MDD can select an arbitrary starting
   point when resuming forwarding packets.  Thus what the media source
   said, can be substantially delayed at the receiver with the receiver
   believing that it is what was said just now and only delayed by the
   transport delay.

   To prevent this attack, we force the MDD to provide the receiver with
   the original RTP timestamp authenticated.  Thus a receiver can
   compare the previously received sample's original timesamp with the
   original timestamp of the recently received sample.  The timestamp
   difference should correspond to the difference in reception times
   with a maximum allowed variation corresponding to network jitter and
   a short fudge factor to enable the MDD to align different sources
   when acting as media switching mixer.  Note this calculation will not
   function if the used RTP payload format switches and the different
   formats has different RTP timestamp rates.  Thus the rules in
   [RFC7160] MUST be followed.

7.2.4.  Splicing Attack

   The splicing attack is an attack where a MDD receiving multiple media
   sources splices one media stream into the other.  If the MDD would be
   able to change the SSRC without the receiver having any method for
   verifying the orignal source ID, then the MDD could first deliver
   stream A.  And if the sequence numbers and other information allows
   it, the MDD can forward stream B under the same SSRC as stream A was
   previously forwarded.

   This attack is mitigated by requiring each rtp stream to have unique
   source IDs that are provided to the receiver.  That way the receiver
   would detect when the source ID switches for these streams.






Mattsson, et al.         Expires April 21, 2016                [Page 13]


Internet-Draft                 SRTP Cloud                   October 2015


7.2.5.  Wrong Meta Data Attack

   In case of several cascading MDDs, a malicious MDD may send forged
   meta data to another MDD, either giving the endpoints connected to
   the second MDD a modified view of what is happening in the conference
   (like who is speaking) or just degrading the quality of experience
   for endpoints connected to the second MDD.  The false meta data could
   be any other hbh-protected fields.  Especially in cases where two
   different conference providers or two different vendors of MDDs is
   involved in the conference, subtle forgeries meant to lower the
   experience for users of the competing service/MDD might be done.

   Similar effect could result from honest MDDs having different
   algorithms, e.g. for selecting active speaker.  Minor differences
   must likely be accepted as long as endpoints connected to different
   MDDs do not get very different view of what happened in the
   conference.

8.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

9.  References

9.1.  Normative References

   [I-D.ietf-avtcore-rtp-topologies-update]
              Westerlund, M. and S. Wenger, "RTP Topologies", draft-
              ietf-avtcore-rtp-topologies-update-10 (work in progress),
              July 2015.

   [I-D.ietf-avtcore-srtp-aes-gcm]
              McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption
              in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-aes-gcm-17
              (work in progress), June 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <http://www.rfc-editor.org/info/rfc3711>.



Mattsson, et al.         Expires April 21, 2016                [Page 14]


Internet-Draft                 SRTP Cloud                   October 2015


   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC7160]  Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
              Clock Rates in an RTP Session", RFC 7160,
              DOI 10.17487/RFC7160, April 2014,
              <http://www.rfc-editor.org/info/rfc7160>.

9.2.  Informative References

   [I-D.westerlund-perc-rtp-field-considerations]
              Westerlund, M., "Handling Considerations for the RTP
              fields in PERC", draft-westerlund-perc-rtp-field-
              considerations-00 (work in progress), October 2015.

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
              February 2008, <http://www.rfc-editor.org/info/rfc5104>.

Authors' Addresses

   John Mattsson
   Ericsson AB
   SE-164 80 Stockholm
   Sweden

   Phone: +46 10 71 43 501
   Email: john.mattsson@ericsson.com


   Mats Naslund
   Ericsson AB
   SE-164 80 Stockholm
   Sweden

   Phone: +46 10 71 33 739
   Email: mats.naslund@ericsson.com












Mattsson, et al.         Expires April 21, 2016                [Page 15]


Internet-Draft                 SRTP Cloud                   October 2015


   Magnus Westerlund
   Ericsson
   Farogatan 2
   SE-164 80 Stockholm
   Sweden

   Phone: +46 10 714 82 87
   Email: magnus.westerlund@ericsson.com











































Mattsson, et al.         Expires April 21, 2016                [Page 16]