[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

ICE                                                         P. Martinsen
Internet-Draft                                                N. Buckles
Intended status: Standards Track                                   Cisco
Expires: July 24, 2017                                  January 20, 2017


                         TLS Candidates for ICE
                 draft-martinsen-ice-tls-candidates-00

Abstract

   This document introduces TLS candidates to ICE.

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 July 24, 2017.

Copyright Notice

   Copyright (c) 2017 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
   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.







Martinsen & Buckles       Expires July 24, 2017                 [Page 1]


Internet-Draft                   ICE TLS                    January 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   2
   3.  Overview of Operations  . . . . . . . . . . . . . . . . . . .   2
   4.  ICE-TLS-Candidates  . . . . . . . . . . . . . . . . . . . . .   3
   5.  Sending Packets . . . . . . . . . . . . . . . . . . . . . . .   3
   6.  HTTP Proxy  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  RTCP Multiplexing . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . .   5
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   5
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   12. Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In use-cases where media is terminated by a public reachable server
   it is desirable to be able to negotiate a TLS connection in addition
   to UDP as described in ICEbis [I-D.ietf-ice-rfc5245bis] and TCP as
   described in ICE-TCP [RFC6544].  This will increase the chances of
   successfully traversing any firewall between the client and the
   public server.

   Due to the problems associated with p2p connections and TCP
   (Synchronously opening up the two necessary pinholes at two different
   NAT/FWs), this specification focuses on the use case where one side
   is publicly reachable and runs ICE-lite.

2.  Notational Conventions

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

   This specification uses terminology defined in ICEbis
   [I-D.ietf-ice-rfc5245bis].

3.  Overview of Operations

   ICE performs connectivity checks between clients and servers.  ICE
   candidates are usually exchanged via SDP and connectivity checks are
   performed on each candidate pair.  In the scenario where the client
   implements a full ICE stack and the server implements a ICE lite
   stack.  The client is in the ICE controlling role, so the client has
   ultimate control over which candidate pair is selected.




Martinsen & Buckles       Expires July 24, 2017                 [Page 2]


Internet-Draft                   ICE TLS                    January 2017


4.  ICE-TLS-Candidates

   The grammar for ICE candidates in SDP is described in ICEbis and ICE-
   TCP.  For TLS candidates, we update the grammar as follows:

             transport = "UDP" / "TCP" / "TLS" / transport-extension

   Candidate priority is calculated using the standard formula with UDP
   having higher priority than TCP or TLS, and TCP having higher
   priority than TLS.

   Example ICE candidates from a client:


      a=candidate:1 1 UDP 2113933823 10.19.1.236 20124 typ HOST
      a=candidate:2 1 TCP 2113933567 10.19.1.236 20000 typ HOST
      a=candidate:3 1 TLS 2113933322 10.19.1.236 20000 typ HOST \
      fingerprint sha-1;XX:YY:ZZ
      52:A7:60:90:B2:3E:79:43:08:77:F0:80:C6:14:E2:1B:87:16:B3:B1

   Example ICE candidates from a server:


    a=candidate:0 1 UDP 2130706431 23.253.251.168 33434 typ host
    a=candidate:8 1 TCP 1962934271 23.253.251.168 33434 typ host tcptype
    passive a=candidate:16 1 TLS 1459376510 23.253.251.168 443 typ host
    \ tcptype passive fingerprint sha-1;XX:YY:ZZ

   Note that the server TCP and TLS candidates are always marked as
   passive indicating that the client always initiates the TCP
   connection.  For TLS candidates both the client and server MUST
   include the fingerprint attribute that has the following syntax
   largely borrowed from Comedia over TLS in SDP [RFC4572].

             extension-att-name = "fingerprint"
             extension-att-value = hash-func ";" fingerprint
             hash-func =  "sha-1" / "sha-224" / "sha-256" / token
             fingerprint =  2UHEX *(":" 2UHEX)

   The certificates exchanged as part of the TLS handshake should be
   validated against the given fingerprint as a means of identifying the
   remote TLS participant.

5.  Sending Packets

   Various types of packets (RTP, RTCP, SRTP, SRTCP, STUN, DTLS, BFCP)
   are sent over the different transport types in different ways.




Martinsen & Buckles       Expires July 24, 2017                 [Page 3]


Internet-Draft                   ICE TLS                    January 2017


   When using UDP transport all packets except BFCP are sent directly
   over UDP as individual UDP datagrams.  BFCP packets are sent directly
   over UDP when the BFCP m-line is not DTLS enabled.  BFCP packets are
   sent as DTLS payload when the m-line is DTLS enabled.

   When using TCP transport all packets except BFCP are sent directly
   over the TCP connection using RTP and RTCP over Connection-Oriented
   Transport [RFC4571] framing.  BFCP packets are sent using this
   framing when the BFCP m-line is not DTLS enabled.  BFCP packets are
   sent as DTLS payload when the m-line is DTLS enabled.

   When using TLS transport all packets except BFCP are sent as TLS
   payload using rfc4571 framing.  BFCP packets are sent using rfc4571
   framing when the BFCP m-line is not DTLS enabled.  BFCP packets are
   sent as DTLS payload when the m-line is DTLS enabled.

   In the case of SRTP/SRTCP and TLS, each packet will be double
   encrypted.  On the encryption side the SRTP/SRTCP encryption and
   authentication is done first and the TLS encryption is done second.
   On the decryption side, the TLS decryption is done first and the
   SRTP/SRTCP decryption is done second.

   When a media or application m-line is negotiated (in SDP) as using
   DTLS, a DTLS handshake will be performed regardless of the chosen
   transport type.  In the case of a TLS transport, the DTLS packets
   will be sent as TLS payload.  This creates a slightly strange end
   result of DTLS over TLS but this allows the system as a whole to
   operate in the same manner regardless of the chosen transport type.

6.  HTTP Proxy

   Some firewalls will block arbitrary UDP, TCP, or TLS traffic, but
   will allow TLS traffic via an HTTP proxy.  When an HTTP proxy is
   configured on the client (or host operating system) and TLS ICE
   candidates have been exchanged between the client and server, then
   the client should initiate an HTTP CONNECT to the proxy server before
   sending TLS traffic.

   The client provides the IP and TLS port of the server to the HTTP
   proxy (in the form of a generated HTTP URL).  It is quite likely that
   the TLS port of the server must be 443 (standard HTTPS port) for this
   operation to work.  After the proxy server returns 200 the client may
   send the TLS along the established TCP connection with the proxy
   server and the TLS will be forwarded (intact) to the server.  (There
   is a wiki page at https://en.wikipedia.org/wiki/HTTP_tunnel, but no
   real standards to point to).





Martinsen & Buckles       Expires July 24, 2017                 [Page 4]


Internet-Draft                   ICE TLS                    January 2017


   The use of an HTTP proxy is largely invisible to the server.  The
   server will see the IP address port used by the HTTP proxy instead of
   the client, but this will be handled normally as part of ICE
   processing.

7.  RTCP Multiplexing

   It is desirable (and in some cases required) that RTCP and RTP be
   transmitted over the same port.  This behavior is negotiated in SDP
   as described in Multiplexing RTP and RTCP [RFC5761].  It is highly
   recommended that all clients support rtcp-mux.  Clients that do not
   support rtcp-mux may not be able to use TLS and HTTP proxies for
   connectivity.

8.  Compatibility

   TODO: How will this affect old clients?

9.  IANA Considerations

   SDP?

10.  Security Considerations

   The security considerations described in [I-D.ietf-ice-rfc5245bis]
   are still valid.  TODO: ANY TLS attacs we should care about?  TODO:
   SRTP?  Do we need it even if we use TLS, yes probably.  (Changing
   paths and so on?)

11.  Acknowledgements

12.  Normative References

   [I-D.ietf-ice-rfc5245bis]
              Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
              Connectivity Establishment (ICE): A Protocol for Network
              Address Translator (NAT) Traversal", draft-ietf-ice-
              rfc5245bis-08 (work in progress), December 2016.

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

   [RFC4571]  Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
              and RTP Control Protocol (RTCP) Packets over Connection-
              Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July
              2006, <http://www.rfc-editor.org/info/rfc4571>.



Martinsen & Buckles       Expires July 24, 2017                 [Page 5]


Internet-Draft                   ICE TLS                    January 2017


   [RFC4572]  Lennox, J., "Connection-Oriented Media Transport over the
              Transport Layer Security (TLS) Protocol in the Session
              Description Protocol (SDP)", RFC 4572, DOI 10.17487/
              RFC4572, July 2006,
              <http://www.rfc-editor.org/info/rfc4572>.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761, DOI 10.17487/
              RFC5761, April 2010,
              <http://www.rfc-editor.org/info/rfc5761>.

   [RFC6544]  Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
              "TCP Candidates with Interactive Connectivity
              Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
              March 2012, <http://www.rfc-editor.org/info/rfc6544>.

Authors' Addresses

   Paal-Erik Martinsen
   Cisco Systems, Inc.
   Philip Pedersens Vei 22
   Lysaker, Akershus  1325
   Norway

   Email: palmarti@cisco.com


   Nathan Buckles
   Cisco Systems, Inc.
   2250 East President George Bush Highway
   Richardson, Texas  75082-3550
   USA

   Email: nbuckles@cisco.com

















Martinsen & Buckles       Expires July 24, 2017                 [Page 6]


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