idnits 2.17.1 draft-patil-tram-alpn-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 22, 2014) is 3657 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) == Unused Reference: 'RFC5766' is defined on line 212, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.mbelshe-httpbis-spdy' -- Possible downref: Non-RFC (?) normative reference: ref. 'QUIC' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM P. Patil 3 Internet-Draft T. Reddy 4 Intended status: Standards Track G. Salgueiro 5 Expires: October 24, 2014 Cisco 6 M. Petit-Huguenin 7 Jive Communications 8 April 22, 2014 10 Application Layer Protocol Negotiation (ALPN) for Session Traversal 11 Utilities for NAT (STUN) 12 draft-patil-tram-alpn-00 14 Abstract 16 An Application Layer Protocol Negotiation (ALPN) label for the 17 Session Traversal Utilities for NAT (STUN) protocol is defined in 18 this document to allow the application layer to negotiate STUN within 19 the Transport Layer Security (TLS) connection. The STUN ALPN 20 protocol identifier applies to both TLS and Datagram Transport Layer 21 Security (DTLS). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 24, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 6.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 STUN can be securely transported using TLS-over-TCP (referred to as 70 TLS [RFC5246]), as specified in [RFC5389], or TLS-over-UDP (referred 71 to as DTLS [RFC6347]), as specified in 72 [I-D.petithuguenin-tram-turn-dtls]. 74 ALPN [I-D.ietf-tls-applayerprotoneg] enables an endpoint to 75 positively identify STUN protocol uses in TLS/DTLS and distinguish 76 them from other TLS/DTLS protocols. With ALPN, the client sends the 77 list of supported application protocols as part of the TLS/DTLS 78 ClientHello message. The server chooses a protocol and sends the 79 selected protocol as part of the TLS/DTLS ServerHello message. The 80 application protocol negotiation can thus be accomplished within the 81 TLS/DTLS handshake, without adding network round-trips, and allows 82 the server to associate a different certificate with each application 83 protocol, if desired. 85 For example, a firewall could block all outgoing traffic except for 86 TCP traffic to specific ports (e.g., 443 for HTTPS). A TURN server 87 listening on its default ports (3478 for TCP/UDP, 5349 for TLS) would 88 not be reachable in this case. However, despite the restrictions 89 imposed by the firewall, the TURN server can still be reached on the 90 allowed HTTPS port if an ALPN STUN protocol identifier is used to 91 establish the STUN application layer protocol as part of the TLS 92 handshake. In this case, the STUN ALPN identifier sent by the client 93 will be used by the server to identify that the client intends to 94 make a TURN request and it must act as a TURN server to relay the 95 traffic to and from the remote peer. Similarly, with Quick UDP 96 Internet Connections (QUIC) [QUIC], a UDP-based transport protocol 97 that operates under SPDY [I-D.mbelshe-httpbis-spdy], a TURN server 98 could be operated on the same ports as that of a SPDY server. 100 This document defines an entry ("stun") in the "Application Layer 101 Protocol Negotiation (ALPN) Protocol IDs" registry established by 102 [I-D.ietf-tls-applayerprotoneg] to identify the STUN protocol. 104 [[TODO: In various offline discussions some have expressed a desire 105 to add an additional ALPN protocol identifier for TURN (see IANA 106 Considerations below for example registration). ALPN can be used 107 more granularly to externally identify more of the protocol variants 108 and their different properties (i.e., STUN and TURN over TLS/DTLS). 109 The advantage in dividing it this way is that these different forms 110 can be externally identified (obviously, there isn't any inherent 111 value in the different identifiers from within the TLS 112 handshake).There are two main disadvantages. the first is that this 113 two application protocol approach may make implementations more 114 complicated/confusing. The second is that there may be difficulty in 115 differentiating the two with ALPN when TURN was specifically designed 116 to be able to run on the same port as STUN usage (in section 13 of 117 RFC 5389). Section 4.1.1.2 of RFC 5245 explicitly says that "If the 118 Allocate request is rejected because the server lacks resources to 119 fulfill it, the agent SHOULD instead send a Binding request to obtain 120 a server reflexive candidate." Does that prove there is no need to 121 differentiate TURN and STUN request on UDP/TCP or TLS and now DTLS? 122 Are there sufficiently meaningful differences between the usages to 123 warrant separate STUN and TURN ALPN identifiers?]] 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. IANA Considerations 133 The following entry is to be added to the "Application Layer Protocol 134 Negotiation (ALPN) Protocol IDs" registry established by 135 [I-D.ietf-tls-applayerprotoneg]. 137 The "stun" label identifies STUN over TLS/DTLS: 139 Protocol: Session Traversal Utilities for NAT (STUN) 141 Identification Sequence: 0x73 0x74 0x75 0x6E ("stun") 143 Specification: This document (RFCXXXX) 145 [[TODO: Shown only as an example. Remove the below registry entry if 146 open issue above dictates a single STUN ALPN identifier is 147 sufficient.]] 149 The "turn" label identifies TURN over TLS/DTLS: 151 Protocol: Traversal Using Relays around NAT (TURN) 153 Identification Sequence: 0x74 0x75 0x72 0x6E ("turn") 155 Specification: This document (RFCXXXX) 157 4. Security Considerations 159 The ALPN STUN protocol identifier does not introduce any specific 160 security considerations beyond those detailed in the TLS ALPN 161 Extension specification [I-D.ietf-tls-applayerprotoneg]. It also 162 does not impact the security of TLS/DTLS session establishment nor 163 the application data exchange. 165 5. Acknowledgements 167 This work benefited from the discussions and invaluable input by the 168 various members of the TRAM working group. These include Simon 169 Perrault, Paul Kyzivat, and Andrew Hutton. Special thanks to Martin 170 Thomson and Oleg Moskalenko for their constructive comments, 171 suggestions, and early reviews that were critical to the formulation 172 and refinement of this document. 174 6. References 176 6.1. Normative References 178 [I-D.ietf-tls-applayerprotoneg] 179 Friedl, S., Popov, A., Langley, A., and S. Emile, 180 "Transport Layer Security (TLS) Application Layer Protocol 181 Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 182 (work in progress), March 2014. 184 [I-D.mbelshe-httpbis-spdy] 185 Belshe, M. and R. Peon, "SPDY Protocol", draft-mbelshe- 186 httpbis-spdy-00 (work in progress), February 2012. 188 [I-D.petithuguenin-tram-turn-dtls] 189 Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 190 Layer Security (DTLS) as Transport for Traversal Using 191 Relays around NAT (TURN)", draft-petithuguenin-tram-turn- 192 dtls-00 (work in progress), January 2014. 194 [QUIC] http://www.ietf.org/proceedings/88/slides/ 195 slides-88-tsvarea-10.pdf, "QUIC Slide Deck at IETF88,", . 197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 198 Requirement Levels", BCP 14, RFC 2119, March 1997. 200 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 201 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 203 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 204 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 205 October 2008. 207 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 208 Security Version 1.2", RFC 6347, January 2012. 210 6.2. Informative References 212 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 213 Relays around NAT (TURN): Relay Extensions to Session 214 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 216 Authors' Addresses 218 Prashanth Patil 219 Cisco Systems, Inc. 220 Bangalore 221 India 223 Email: praspati@cisco.com 225 Tirumaleswar Reddy 226 Cisco Systems, Inc. 227 Cessna Business Park, Varthur Hobli 228 Sarjapur Marathalli Outer Ring Road 229 Bangalore, Karnataka 560103 230 India 232 Email: tireddy@cisco.com 233 Gonzalo Salgueiro 234 Cisco Systems, Inc. 235 7200-12 Kit Creek Road 236 Research Triangle Park, NC 27709 237 US 239 Email: gsalguei@cisco.com 241 Marc Petit-Huguenin 242 Jive Communications 243 1275 West 1600 North, Suite 100 244 Orem, UT 84057 245 USA 247 Email: marcph@getjive.com