| 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
This document introduces TLS candidates to ICE.
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 (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.
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.
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].
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.
transport = “UDP” / “TCP” / “TLS” / transport-extension
The grammar for ICE candidates in SDP is described in ICEbis and ICE-TCP. For TLS candidates, we update the grammar as follows:
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
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
extension-att-name = “fingerprint”
extension-att-value = hash-func “;” fingerprint
hash-func = "sha-1" / "sha-224" / "sha-256" / token
fingerprint = 2UHEX *(":" 2UHEX)
Example ICE candidates from a client: [RFC4572].
Various types of packets (RTP, RTCP, SRTP, SRTCP, STUN, DTLS, BFCP) are sent over the different transport types in different ways.
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.
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).
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.
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.
TODO: How will this affect old clients?
SDP?
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?)