DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
draft-ram-straw-b2bua-dtls-srtp-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Ram R  , Tirumaleswar Reddy.K  , Gonzalo Salgueiro  , Victor Pascual 
Last updated 2014-06-20
Stream (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
STRAW                                                    R. Ravindranath
Internet-Draft                                                  T. Reddy
Intended status: Standards Track                            G. Salgueiro
Expires: December 22, 2014                                         Cisco
                                                              V. Pascual
                                                                  Quobis
                                                           June 20, 2014

  DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back
                          User Agents (B2BUAs)
                   draft-ram-straw-b2bua-dtls-srtp-00

Abstract

   Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
   often function on the media plane, rather than just on the signaling
   path.  This document describes the behavior B2BUAs should follow when
   acting on the media plane that use Secure Real-time Transport
   Protocol (SRTP) security context setup with Datagram Transport Layer
   Security (DTLS) protocol.

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 December 22, 2014.

Copyright Notice

   Copyright (c) 2014 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Ravindranath, et al.    Expires December 22, 2014               [Page 1]
Internet-Draft       DTLS-SRTP handling in SIP B2BUA           June 2014

   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Media Plane B2BUAs  . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Media Relay . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Media Aware or Media Termination  . . . . . . . . . . . .   6
     3.3.  Media Plane B2BUA with NAT handling . . . . . . . . . . .   8
   4.  DTLS-SRTP Handling in B2BUA with Forked Signaling . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [RFC5763] describes how Session Initiation Protocol (SIP) [RFC3261]
   can be used to establish a Secure Real-time Transport Protocol (SRTP)
   [RFC3711] security context with Datagram Transport Layer Security
   (DTLS) [RFC4347] protocol.  It describes a mechanism of transporting
   a certificate fingerprint in the Session Description Protocol (SDP)
   [RFC4566], which identifies the certificate that will be presented
   during the DTLS handshake.  DTLS-SRTP is defined for point-to-point
   media sessions, in which there are exactly two participants.  Each
   DTLS-SRTP session contains a single DTLS association, and either two
   SRTP contexts (if media traffic is flowing in both directions on the
   same host/port quartet) or one SRTP context (if media traffic is only
   flowing in one direction).

   In many SIP deployments, SIP entities exist in the SIP signaling path
   between the originating and final terminating endpoints.  These SIP
   entities, as described in [RFC7092], modify SIP and SDP bodies and
   also are likely to be on the media path.  Such entities, when present
   in the signaling/media path, are likely to do several things.  For
   example, some B2BUAs modify parts of the SDP body (like IP address,
   port) and subsequently modify the RTP headers as well.  There are
   other types of B2BUAs that completely modify the RTP packet,
   including the payload (e.g., a transcoder).  In all these cases a

Ravindranath, et al.    Expires December 22, 2014               [Page 2]
Internet-Draft       DTLS-SRTP handling in SIP B2BUA           June 2014

   DTLS association would break unless the B2BUA participates in the
   DTLS setup and ensures the contexts are setup properly.  B2BUA that
   are in media path MUST support DTLS stack and SRTP extensions needed
   for DTLS as described in [RFC5763] so that it can function as DTLS
   proxy.

   [RFC7092] describes three different categories of such B2BUAs,
   according to the level of activities performed on the media plane:

      A B2BUA that act as a simple media relay effectively unaware of
      anything that is transported and only modifies the UDP/IP header
      of the packets.

      A B2BUA that performs a media-aware role.  It inspects and
      potentially modifies RTP or RTP Control Protocol (RTCP) headers;
      but it does not modify the payload of RTP/RTCP.

      A B2BUA that performs a media-termination role and operates at the
      media payload layer, such as RTP/RTCP payload (e.g., a
      transcoder).

   The following sections will describe the behaviour B2BUAs should
   follow in order to avoid any impact on end-to-end DTLS-SRTP streams.

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

   The following generalized terms are defined in [RFC3261], Section 6.

      B2BUA: a SIP Back-to-Back User Agent, which is the logical
      combination of a User Agent Server (UAS) and User Agent Client
      (UAC).

      UAS: a SIP User Agent Server.

      UAC: a SIP User Agent Client.

   All of the pertinent B2BUA terminology and taxonomy used in this
   document is based on [RFC7092].

   It is assumed the reader is already familiar with the fundamental
   concepts of the RTP protocol [RFC3550] and its taxonomy
   [I-D.ietf-avtext-rtp-grouping-taxonomy], as well as those of SRTP
   [RFC3711], and DTLS [RFC4347].

Ravindranath, et al.    Expires December 22, 2014               [Page 3]
Internet-Draft       DTLS-SRTP handling in SIP B2BUA           June 2014

3.  Media Plane B2BUAs

3.1.  Media Relay

   A media relay as identified in section 3.2.1 of [RFC7092] basically
   just forwards, from an application layer point-of-view, all packets
   it receives on a negotiated UDP connection, without either inspecting
   or modifying them.  They just forward the UDP payload as-is by
   changing only the UDP/IP header.

   A media relay B2BUA MUST forward the certificate fingerprint and
   setup attribute it receives in the SDP from the originating endpoint
   as-is to the remote side and vice-versa.  The below example shows a
   "INVITE with SDP" SIP call flow with both SIP user agents doing DTLS-
   SRTP with a media relay B2BUA that changes the UDP/IP address/port.

Ravindranath, et al.    Expires December 22, 2014               [Page 4]
Internet-Draft       DTLS-SRTP handling in SIP B2BUA           June 2014

       +-------+            +------------------+              +-----+
       | Alice |            | MediaRelay B2BUA |              | Bob |
       +-------+            +------------------+              +-----+
           |(1) INVITE               |  (3)INVITE                |
           |   a=setup:actpass       |   a=setup:actpass         |
           |   a=fingerprint1        |   a= fingerprint1         |
           |   (alice's IP/port)     |   (B2BUA's IP, port)      |
           |------------------------>|-------------------------->|
           |                         |                           |
           |    (2)  100 trying      |                           |
           |<------------------------|                           |
           |                         | (4) 100 trying            |
           |                         |<--------------------------|
           |                         |                           |
           |                         |  (5)200 OK                |
           |                         |   a=setup:active          |
           |                         |    a=fingerprint2         |
           |                         |  (Bob's IP, port)         |
           |<------------------------|<--------------------------|
           |    (6) 200 OK           |                           |
           |    a=setup:active       |                           |
           |    a=fingerprint2       |                           |
           |    B2BUA's address,port |                           |
           |               (7, 8)ClientHello + use_srtp          |
           |<------------------------|<--------------------------|
           |                         |                           |
           |                         |                           |
           |           (9,10)ServerHello + use_srtp              |
           |------------------------>|-------------------------->|
           |                 (11)    |                           |
           |  [Certificate exchange between Alice and Bob over   |
           |   DTLS ]                |                           |
           |                         |                           |
           |         (12)            |                           |
           |<---------SRTP/SRTCP---->|<----SRTP/SRTCP----------->|
           |   [B2BUA just changes UDP/IP header]                |

         Figure 1: INVITE with SDP callflow for Media Relay B2BUA

   NOTE: For the sake of brevity the entire fingerprint attribute is not
   shown.

   For each RTP or RTCP flow the peers do a DTLS handshake on the same
   source and destination port pair to establish a DTLS association.  In
   this case, Bob, after he receives an INVITE triggers a DTLS
   connection.  Note the DTLS handshake and the response to the INVITE
   may happen in parallel, thus, the B2BUA SHOULD be prepared to receive
   media on the ports it advertised to Bob in the OFFER.  Since a media

Ravindranath, et al.    Expires December 22, 2014               [Page 5]
Internet-Draft       DTLS-SRTP handling in SIP B2BUA           June 2014

   relay B2BUA does not differentiate between a DTLS, RTP or any packet
   sent it just changes the UDP/IP addresses and forwards the packet on
   either leg.

   [[TODO: ICE handling w.r.t media relay B2BUA will be discussed in
   STUN passthrough STRAW WG item and the reference will be added in
   this section]]

3.2.  Media Aware or Media Termination

   A media-aware relay, unlike the the media relay discussed in the
   previous section, is actually aware of the media traffic it is
   handling.  A media-aware relay inspects SRTP and SRTCP packets
   flowing through it, and may even be able to modify the headers in any
   of them before forwarding them.  A B2BUA performing such a media-
   aware role de-crypts the payload and re-encrypt it, but it does not
   modify the contents of the payload itself.  Note that when such a
   media-aware B2BUA modifies SRTP headers it MUST act as a DTLS
   intermediary and terminate the DTLS connection so it can decrypt/re-
   encrypt in order to properly update the compound SRTCP packet to make
   them consistent.  This DTLS proxy functionality of media-aware B2BUAs
   is discussed in greater detail in Section X of
   [I-D.ietf-straw-b2bua-rtcp].

   [[TODO: Update reference to STRAW RTCP document once this new section
   appears in the next version (in progress).]]

   In addition to modifying the headers, a B2BUA performing a media
   termination role can modify parts of the payload as well.  For
   example, a transcoder is a type of media terminator that modifies the
   payload before it forwards the packet.  These B2BUA's SHOULD have the
   capability to distinguish between DTLS, SRTP, SRTCP or other packets
   (e.g., STUN) received on the same UDP port by using the algorithm
   mentioned in section 5.1.2 of [RFC5764] and takes care of handling
   them separately.

   Below example shows how a DTLS-SRTP session is setup for these B2BUA

Ravindranath, et al.    Expires December 22, 2014               [Page 6]
Internet-Draft       DTLS-SRTP handling in SIP B2BUA           June 2014

       +-------+           +------------------+               +-----+
       | Alice |           | MediaAware B2BUA |               | Bob |
       +-------+           +------------------+               +-----+
           |(1) INVITE               |  (3)INVITE                |
           |   a=setup:actpass       |   a=setup:actpass         |
           |   a=fingerprint1        |   a= fingerprint2         |
           |   (alice's IP/port)     |   (B2BUA's IP, port)      |
           |------------------------>|-------------------------->|
           |                         |                           |
           |    (2)  100 trying      |                           |
           |<------------------------|                           |
           |                         | (4) 100 trying            |
           |                         |<--------------------------|
           |                         |                           |
           |                         |  (5)200 OK                |
           |                         |   a=setup:active          |
           |                         |    a=fingerprint3         |
           |                         |  (Bob's IP, port)         |
           |                         |<--------------------------|
           |                         |(6)ClientHello + use_srtp  |
           |                         |<--------------------------|
           |    (7) 200 OK           |                           |
           |    a=setup:active       | ServerHello + use_srtp (8)|
           |    a=fingerprint4       |-------------------------->|
           |    B2BUA's address,port |             (9,10)        |
           |<------------------------|   [Cert Exchange between] |
           |  (11)ClientHello+       |      Bob and B2BUA over   |
           |     use_srtp            |              DTLS         |
           |<------------------------|                           |
           |  (12)ServerHello+       |                           |
           |   use_srtp              |                           |
           |------------------------>|                           |
           |                 (13,14  |                           |
           |  [Cert exchange between |                           |
           |   Alice and B2BUA       |                           |
           |   DTLS ]                |                           |
           |                         |                           |
           |         (15)            |          (16)             |
           |<---------SRTP/SRTCP---->|<----SRTP/SRTCP----------->|
           |   [B2BUA modifies SRTP/SRTCP header and/or payload]  |

         Figure 2: INVITE with SDP callflow with Media-aware B2BUA

   NOTE: For the sake of brevity the entire fingerprint attribute is not
   shown.

   NOTE: The same call flow would be applicable to "INVITE without SDP"
   Offer calls.

Ravindranath, et al.    Expires December 22, 2014               [Page 7]
Internet-Draft       DTLS-SRTP handling in SIP B2BUA           June 2014

   NOTE: Steps 5,6 may be parallel and so the B2BUA MAY receive
   ClientHello before it sees a 200OK.  Steps 7,8 can happen in any
   order.  Also steps 9,10, 11 may be parallel.  B2BUA should be
   prepared to handle these responses on each leg independently.

   A media termination B2BUA MUST change the certificate fingerprint
   from both the endpoints so that it can signal its own certificate
   fingerprint in the SDP.  This allows the B2BUA to act as a DTLS-SRTP
   proxy and modify the payload.

3.3.  Media Plane B2BUA with NAT handling

   It is possible that DTLS exchange and offer/answer exchange happens
   in parallel.  In case of NAT exists between B2BUA and UA, ClientHello
   message in DTLS will be lost in case the answer is not received in
   UA.  To overcome this issue, retransmission of ClientHello of DTLS as
   mentioned in Sec 4.2.4.1 of [RFC6347] SHALL be followed or
   ClientHello MAY be started only after offer/answer exchange is
   complete.

4.  DTLS-SRTP Handling in B2BUA with Forked Signaling

   B2BUA's may receive multiple answers for an outbound INVITE due to a
   downstream proxy forking the INVITE to multiple targets.  It is
   possible that each of these responses have different certificate
   fingerprints.  The B2BUA SHOULD take care of setting separate DTLS-
   SRTP associations with each of the forked targets.

5.  Security Considerations

   This document simply describes the behavior B2BUAs should follow when
   acting on the media plane that use SRTP security context setup with
   the DTLS protocol.  It does not introduce any specific security
   considerations beyond those detailed in [RFC5763].  The B2BUA
   behaviors outlined here also do not impact the security and integrity
   of the DTLS-SRTP session nor the data exchanged over it.

6.  IANA Considerations

   This document makes no request of IANA.

7.  Acknowledgments

   Special thanks to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan,
   Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes and Brett Tate for their
   constructive comments, suggestions, and early reviews that were
   critical to the formulation and refinement of this document.

Ravindranath, et al.    Expires December 22, 2014               [Page 8]
Internet-Draft       DTLS-SRTP handling in SIP B2BUA           June 2014

8.  Contributors

   Rajeev Seth provided substantial contributions to this document.

9.  References

9.1.  Normative References

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

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC5763]  Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
              for Establishing a Secure Real-time Transport Protocol
              (SRTP) Security Context Using Datagram Transport Layer
              Security (DTLS)", RFC 5763, May 2010.

   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
              Security (DTLS) Extension to Establish Keys for the Secure
              Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

9.2.  Informative References

   [I-D.ietf-avtext-rtp-grouping-taxonomy]
              Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro,
              "A Taxonomy of Grouping Semantics and Mechanisms for Real-
              Time Transport Protocol (RTP) Sources", draft-ietf-avtext-
              rtp-grouping-taxonomy-01 (work in progress), February
              2014.

   [I-D.ietf-straw-b2bua-rtcp]
              Miniero, L., Murillo, S., and V. Pascual, "Guidelines to
              support RTCP end-to-end in Back-to-Back User Agents
              (B2BUAs)", draft-ietf-straw-b2bua-rtcp-01 (work in
              progress), June 2014.

Ravindranath, et al.    Expires December 22, 2014               [Page 9]
Internet-Draft       DTLS-SRTP handling in SIP B2BUA           June 2014

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC7092]  Kaplan, H. and V. Pascual, "A Taxonomy of Session
              Initiation Protocol (SIP) Back-to-Back User Agents", RFC
              7092, December 2013.

Authors' Addresses

   Ram Mohan Ravindranath
   Cisco
   Cessna Business Park
   Sarjapur-Marathahalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: rmohanr@cisco.com

   Tirumaleswar Reddy
   Cisco
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103
   India

   Email: tireddy@cisco.com

   Gonzalo Salgueiro
   Cisco Systems, Inc.
   7200-12 Kit Creek Road
   Research Triangle Park, NC  27709
   US

   Email: gsalguei@cisco.com

   Victor Pascual
   Quobis
   Spain

   Email: victor.pascual@quobis.com

Ravindranath, et al.    Expires December 22, 2014              [Page 10]