idnits 2.17.1 draft-martinsen-ice-tls-candidates-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 20, 2017) is 2652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-ice-rfc5245bis-08 ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICE P. Martinsen 3 Internet-Draft N. Buckles 4 Intended status: Standards Track Cisco 5 Expires: July 24, 2017 January 20, 2017 7 TLS Candidates for ICE 8 draft-martinsen-ice-tls-candidates-00 10 Abstract 12 This document introduces TLS candidates to ICE. 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on July 24, 2017. 31 Copyright Notice 33 Copyright (c) 2017 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 50 3. Overview of Operations . . . . . . . . . . . . . . . . . . . 2 51 4. ICE-TLS-Candidates . . . . . . . . . . . . . . . . . . . . . 3 52 5. Sending Packets . . . . . . . . . . . . . . . . . . . . . . . 3 53 6. HTTP Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 7. RTCP Multiplexing . . . . . . . . . . . . . . . . . . . . . . 5 55 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 5 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 10. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 12. Normative References . . . . . . . . . . . . . . . . . . . . 5 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 In use-cases where media is terminated by a public reachable server 65 it is desirable to be able to negotiate a TLS connection in addition 66 to UDP as described in ICEbis [I-D.ietf-ice-rfc5245bis] and TCP as 67 described in ICE-TCP [RFC6544]. This will increase the chances of 68 successfully traversing any firewall between the client and the 69 public server. 71 Due to the problems associated with p2p connections and TCP 72 (Synchronously opening up the two necessary pinholes at two different 73 NAT/FWs), this specification focuses on the use case where one side 74 is publicly reachable and runs ICE-lite. 76 2. Notational Conventions 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 This specification uses terminology defined in ICEbis 83 [I-D.ietf-ice-rfc5245bis]. 85 3. Overview of Operations 87 ICE performs connectivity checks between clients and servers. ICE 88 candidates are usually exchanged via SDP and connectivity checks are 89 performed on each candidate pair. In the scenario where the client 90 implements a full ICE stack and the server implements a ICE lite 91 stack. The client is in the ICE controlling role, so the client has 92 ultimate control over which candidate pair is selected. 94 4. ICE-TLS-Candidates 96 The grammar for ICE candidates in SDP is described in ICEbis and ICE- 97 TCP. For TLS candidates, we update the grammar as follows: 99 transport = "UDP" / "TCP" / "TLS" / transport-extension 101 Candidate priority is calculated using the standard formula with UDP 102 having higher priority than TCP or TLS, and TCP having higher 103 priority than TLS. 105 Example ICE candidates from a client: 107 a=candidate:1 1 UDP 2113933823 10.19.1.236 20124 typ HOST 108 a=candidate:2 1 TCP 2113933567 10.19.1.236 20000 typ HOST 109 a=candidate:3 1 TLS 2113933322 10.19.1.236 20000 typ HOST \ 110 fingerprint sha-1;XX:YY:ZZ 111 52:A7:60:90:B2:3E:79:43:08:77:F0:80:C6:14:E2:1B:87:16:B3:B1 113 Example ICE candidates from a server: 115 a=candidate:0 1 UDP 2130706431 23.253.251.168 33434 typ host 116 a=candidate:8 1 TCP 1962934271 23.253.251.168 33434 typ host tcptype 117 passive a=candidate:16 1 TLS 1459376510 23.253.251.168 443 typ host 118 \ tcptype passive fingerprint sha-1;XX:YY:ZZ 120 Note that the server TCP and TLS candidates are always marked as 121 passive indicating that the client always initiates the TCP 122 connection. For TLS candidates both the client and server MUST 123 include the fingerprint attribute that has the following syntax 124 largely borrowed from Comedia over TLS in SDP [RFC4572]. 126 extension-att-name = "fingerprint" 127 extension-att-value = hash-func ";" fingerprint 128 hash-func = "sha-1" / "sha-224" / "sha-256" / token 129 fingerprint = 2UHEX *(":" 2UHEX) 131 The certificates exchanged as part of the TLS handshake should be 132 validated against the given fingerprint as a means of identifying the 133 remote TLS participant. 135 5. Sending Packets 137 Various types of packets (RTP, RTCP, SRTP, SRTCP, STUN, DTLS, BFCP) 138 are sent over the different transport types in different ways. 140 When using UDP transport all packets except BFCP are sent directly 141 over UDP as individual UDP datagrams. BFCP packets are sent directly 142 over UDP when the BFCP m-line is not DTLS enabled. BFCP packets are 143 sent as DTLS payload when the m-line is DTLS enabled. 145 When using TCP transport all packets except BFCP are sent directly 146 over the TCP connection using RTP and RTCP over Connection-Oriented 147 Transport [RFC4571] framing. BFCP packets are sent using this 148 framing when the BFCP m-line is not DTLS enabled. BFCP packets are 149 sent as DTLS payload when the m-line is DTLS enabled. 151 When using TLS transport all packets except BFCP are sent as TLS 152 payload using rfc4571 framing. BFCP packets are sent using rfc4571 153 framing when the BFCP m-line is not DTLS enabled. BFCP packets are 154 sent as DTLS payload when the m-line is DTLS enabled. 156 In the case of SRTP/SRTCP and TLS, each packet will be double 157 encrypted. On the encryption side the SRTP/SRTCP encryption and 158 authentication is done first and the TLS encryption is done second. 159 On the decryption side, the TLS decryption is done first and the 160 SRTP/SRTCP decryption is done second. 162 When a media or application m-line is negotiated (in SDP) as using 163 DTLS, a DTLS handshake will be performed regardless of the chosen 164 transport type. In the case of a TLS transport, the DTLS packets 165 will be sent as TLS payload. This creates a slightly strange end 166 result of DTLS over TLS but this allows the system as a whole to 167 operate in the same manner regardless of the chosen transport type. 169 6. HTTP Proxy 171 Some firewalls will block arbitrary UDP, TCP, or TLS traffic, but 172 will allow TLS traffic via an HTTP proxy. When an HTTP proxy is 173 configured on the client (or host operating system) and TLS ICE 174 candidates have been exchanged between the client and server, then 175 the client should initiate an HTTP CONNECT to the proxy server before 176 sending TLS traffic. 178 The client provides the IP and TLS port of the server to the HTTP 179 proxy (in the form of a generated HTTP URL). It is quite likely that 180 the TLS port of the server must be 443 (standard HTTPS port) for this 181 operation to work. After the proxy server returns 200 the client may 182 send the TLS along the established TCP connection with the proxy 183 server and the TLS will be forwarded (intact) to the server. (There 184 is a wiki page at https://en.wikipedia.org/wiki/HTTP_tunnel, but no 185 real standards to point to). 187 The use of an HTTP proxy is largely invisible to the server. The 188 server will see the IP address port used by the HTTP proxy instead of 189 the client, but this will be handled normally as part of ICE 190 processing. 192 7. RTCP Multiplexing 194 It is desirable (and in some cases required) that RTCP and RTP be 195 transmitted over the same port. This behavior is negotiated in SDP 196 as described in Multiplexing RTP and RTCP [RFC5761]. It is highly 197 recommended that all clients support rtcp-mux. Clients that do not 198 support rtcp-mux may not be able to use TLS and HTTP proxies for 199 connectivity. 201 8. Compatibility 203 TODO: How will this affect old clients? 205 9. IANA Considerations 207 SDP? 209 10. Security Considerations 211 The security considerations described in [I-D.ietf-ice-rfc5245bis] 212 are still valid. TODO: ANY TLS attacs we should care about? TODO: 213 SRTP? Do we need it even if we use TLS, yes probably. (Changing 214 paths and so on?) 216 11. Acknowledgements 218 12. Normative References 220 [I-D.ietf-ice-rfc5245bis] 221 Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 222 Connectivity Establishment (ICE): A Protocol for Network 223 Address Translator (NAT) Traversal", draft-ietf-ice- 224 rfc5245bis-08 (work in progress), December 2016. 226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 227 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 228 RFC2119, March 1997, 229 . 231 [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) 232 and RTP Control Protocol (RTCP) Packets over Connection- 233 Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 234 2006, . 236 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 237 Transport Layer Security (TLS) Protocol in the Session 238 Description Protocol (SDP)", RFC 4572, DOI 10.17487/ 239 RFC4572, July 2006, 240 . 242 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 243 Control Packets on a Single Port", RFC 5761, DOI 10.17487/ 244 RFC5761, April 2010, 245 . 247 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 248 "TCP Candidates with Interactive Connectivity 249 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 250 March 2012, . 252 Authors' Addresses 254 Paal-Erik Martinsen 255 Cisco Systems, Inc. 256 Philip Pedersens Vei 22 257 Lysaker, Akershus 1325 258 Norway 260 Email: palmarti@cisco.com 262 Nathan Buckles 263 Cisco Systems, Inc. 264 2250 East President George Bush Highway 265 Richardson, Texas 75082-3550 266 USA 268 Email: nbuckles@cisco.com