idnits 2.17.1 draft-blanchet-iab-internetoverport443-01.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 (October 22, 2012) is 4203 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Informational October 22, 2012 5 Expires: April 25, 2013 7 Implications of Blocking Outgoing Ports Except Ports 80 and 443 8 draft-blanchet-iab-internetoverport443-01.txt 10 Abstract 12 Users are often connected to Internet with very few outgoing ports 13 available, such as only port 80 and 443 over TCP. This situation has 14 many implications on designing, deploying and using IETF protocols, 15 such as encaspulating protocols within HTTP, difficulty to do traffic 16 engineering, quality of service, peer-to-peer, multi-channel 17 protocols or deploying new transport protocols. This document 18 describes the situation and its implications. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 25, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. IETF Guidance . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Trafic Policing . . . . . . . . . . . . . . . . . . . . . . 4 59 3.3. Deploying New Protocols . . . . . . . . . . . . . . . . . . 4 60 3.4. Overloading HTTP . . . . . . . . . . . . . . . . . . . . . 4 61 3.5. Increasing the rate of usage of IP addresses . . . . . . . 4 62 3.6. More Complex Operations . . . . . . . . . . . . . . . . . . 5 63 3.7. Inability to Deploy Applications and Protocols . . . . . . 5 64 3.8. Applications Become Only HTTP-based . . . . . . . . . . . . 5 65 3.9. Applications Need to Become Very Smart for Opening 66 Connection . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.10. Internet Transport . . . . . . . . . . . . . . . . . . . . 6 68 3.11. Should IETF Protocols Only Use HTTP Encapsulation . . . . . 6 69 4. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 74 9. Informative References . . . . . . . . . . . . . . . . . . . . 7 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 A trend started many years ago has been to provide Internet access to 80 end-users with limited outgoing ports. The most constraint but 81 common case is to only have outgoing TCP port 80 and port 443 opened. 82 Port 80 is expected to carry HTTP and some middleboxes in the network 83 may block non-HTTP traffic on that port. Port 443 is often less 84 policed than port 80 based on the assumption that it is carrying 85 encrypted traffic. However, enterprise firewalls sometimes verify 86 the use of TLS/SSL on port 443. 88 A consequence of this trend is that Internet statistics show 89 [Labovitz] that a majority of the Internet traffic is over port 80 90 and 443. And the concentration on these ports are further increasing 91 every year. 93 While the purpose of this document is not to find or judge the 94 reasons why providers (in the large sense of providing) are blocking 95 all outgoing ports except very few, a few known reasons can be 96 listed, while no opinion on the validity is expressed: 97 o Users only need HTTP anyway. Now email and chat is over HTTP. 98 o Less number of ports means easier control over shadow traffic. 99 o Provider wants to control, verify, police all outgoing traffic. 101 A consequence for the enterprise or non-HTTP application service 102 provider is that there are very few ways to offer a service to its 103 end-users. For example, an application (VoIP, ssh, jabber, ftp, ...) 104 provider need to use an additional IP address and to bind its 105 application server to the port 443 to make sure its users can reach 106 it whatever the characteristics of the access network the nomadic 107 users are attaching to. The other way is to build a tunnel such as 108 VPN to the service infrastructure and then tunnel all application 109 traffic to that tunnel. Obviously for the same reason, the tunnel 110 server itself has to be bound on port 443. 112 From the application developer point of view, HTTP framework is often 113 chosenfor its own benefits with or without the limited outgoing ports 114 deployment considerations, as discussed in 115 [I-D.tschofenig-post-standardization]. 117 2. Terminology 119 This document uses the term provider in a large sense of some 120 organization offering the Internet access to users. For example, a 121 provider in this document includes coffee shop wifi access, guest 122 access in various public places and networks, hotel networks, 123 enterprise guest access networks, as well as traditional providers 124 such as broadband, mobile and wifi network established large 125 providers. 127 3. Implications 129 3.1. IETF Guidance 131 IETF provided guidance about the use of HTTP and port 80. For 132 example, [RFC3205] recommended to use different ports than 80 for new 133 services, even when HTTP encapsulation was used. This guidance may 134 need to be revisited. 136 This situation further complicates the Internet transparency, end-to- 137 end and hourglass model, as discussed in [RFC2775],[RFC3234] and 138 [RFC4924]. 140 3.2. Trafic Policing 142 If all traffic goes over one or two ports, then it is more difficult 143 to differentiate delay sensitive traffic to bulk traffic while 144 applying policies on forwarding engines at the transport level. The 145 policing nodes on the network haveto open the application payload. 146 For example, for Motion-JPEG over http, parsing the HTTP headers is 147 needed to discover that this data is streaming. 149 3.3. Deploying New Protocols 151 If port 80 and 443 are the only ports opened, then given that 152 middleboxes in networks are inspecting packets and validate HTTP 153 traffic, then a new protocol not based on HTTP and requiring a 154 different transport port or protocol is difficult, while impossible, 155 to deploy as is. 157 3.4. Overloading HTTP 159 Another consequence of this situation is that protocols and data go 160 over HTTP. HTTP is defined with a specific set of requirements and 161 is implemented in a solution set that is far from the IP layer. It 162 uses TCP transport, has multiple ascii headers in the payload to be 163 parsed, has state, etc. However, the HTTP protocol is being revised 164 [RFC6455][httpbis] related to some of these new requirements. 166 3.5. Increasing the rate of usage of IP addresses 168 If an organization has N different services where each one takes a 169 different port, then, in the context of its users only able to use 170 outgoing port 80/443, the organization has to use N IP addresses, one 171 for each service and bind the service on port 443 (or 80) on that IP 172 address. Therefore, the organization increases the rate of its usage 173 of IP addresses. Since IPv4 addresses are almost exhausted, this 174 situation adds pain to the IPv4 address exhaustion. IPv6 addresses 175 are almost limitless to this issue, but having too many IPv6 176 addresses on the same server to support the services add complexity 177 to the operations. 179 3.6. More Complex Operations 181 As a network operator likes to monitor traffic to engineer and 182 troubleshoot the network, it cannot do anymore by only looking at the 183 ports used by the traffic. For example, a peak traffic from a source 184 node that always uses a single outgoing port for all its traffic, may 185 be a video call or video streaming or file copy or a virus related 186 traffic or torrent or ... Therefore, the network operations is blind 187 to what the traffic is, unless the monitoring is at done within the 188 application payload. 190 3.7. Inability to Deploy Applications and Protocols 192 A good example of limitations to deploy applications and protocols 193 are IP cameras. These devices send video streams to outside. While 194 a typical protocol stack would use RTP/RTSP for this purpose, often 195 the only way to successfully send the stream in all cases is to 196 encapsulate it over HTTP using Motion JPEG or other coding over HTTP. 197 Similar issues also happen for interactive applications. The 198 constraint of the transport protocol to use may have an important 199 impact on the application design and behavior. 201 3.8. Applications Become Only HTTP-based 203 From the application developer point of view, the most garanteed way 204 to get its outgoing traffic from the client host to the Internet 205 (servers) is to carry its application data and protocols over HTTP 206 over port 80 and/or 443. This is, whatever the type of traffic, such 207 as gaming, voice, video, file transfer, augmented reality, 3D, ..., 208 with a wide set of different characteristics. Within the HTTP 209 framework, the Websocket Protocol[RFC6455] is one way to support the 210 variety of applications over HTTP. 212 3.9. Applications Need to Become Very Smart for Opening Connection 214 Skype is a good illustration of a deployable application that works 215 in most cases. Analysis of Skype behavior [ColumbiaSkype] shows 216 Skype is trying to open outgoing ports, and when not possible, 217 defaults to port 80 or 443 as last resort. Therefore, this 218 illustrates that a successful deployable application should use 219 similar techniques with the last resort being port 80 or 443. That 220 also means the other peer of the communication must be bound to the 221 same 80 or 443 port. This application behavior may require to have 222 standardized ways of handling encapsulation over 80/443 for realtime 223 applications. 225 3.10. Internet Transport 227 Written differently, this situation can be described as the Internet 228 can only run with a single transport protocol(TCP) and two transport 229 ports(80,443). Given that some deployments have HTTP-aware 230 middleboxes on those ports, then the Internet can only run "reliably" 231 over a single transport protocol (HTTP) and a single transport port 232 (443). 234 3.11. Should IETF Protocols Only Use HTTP Encapsulation 236 Given above, should the IETF only design protocols over HTTP? Should 237 all current protocols be redesigned to be carried over HTTP? (more a 238 question to debate than an affirmation...) 240 For example, 3GPP and MPEG produced the Dynamic Adaptive Streaming 241 over HTTP(DASH) protocol[DASH] where one of the reasons is related to 242 firewalls and NAT traversal. This new protocol is intended to 243 replace the RTSP [RFC2326] protocol. 245 Websockets[RFC6455] is a standardized way to encapsulate subprotocols 246 within HTTP and therefore multiplexing the various application 247 protocols within HTTP. 249 [I-D.tschofenig-post-standardization] also discuss about this issue. 251 4. Mitigation 253 IPv6 could be seen as a way to mitigate that problem. As discussed 254 above, the reasons why access providers or enterprises are limiting 255 outgoing ports are not related to IPv4 address exhaustion or IPv4 256 itself. 258 However, on the server side of the connections, given the large IPv6 259 address space available per server, IPv6 could be used to partly 260 mitigate the problem by having, on a single server, each service 261 bound to a different IPv6 address while using the same transport port 262 80. 264 It should be noted that some IPv6 access providers are not blocking 265 any port, helping restoring the Internet transparency. 267 5. Recommendations 269 A new network protocol that would likely be used and deployed in an 270 environment described above, should: 271 o consider the issues listed and identify how the protocol 272 specification will mitigate the issues. For example, what happens 273 if only port 80 and/or 443 over TCP are available for the end user 274 to start its connection with that protocol? What happens if HTTP 275 protocol inspection is done on those ports by an intermediate 276 node? 277 o consider, for the "transport" of the protocol, using the HTTP 278 protocol, or enhancements of HTTP such as the RESTFUL or 279 Websockets[RFC6455] methods. 281 The access network providers, including small organisations such as 282 Internet cafes, should consider opening their outbound ports to 283 mitigate the issues raised above and to enable a full Internet user 284 experience. There is an opportunity to implement these no-outgoing- 285 ports blocking policies for the new IPv6 deployments. 287 6. Security Considerations 289 This document does not specify a new protocol. However, it does 290 highlight security impacts of the current Internet access. 292 7. IANA Considerations 294 This document has no actions for IANA. 296 8. Acknowledgements 298 Dave Thaler, Hannes Tschofenig, Brian Carpenter, Bernard Adoba, Joel 299 Halpern, Cameron Byrne have provided input and suggestions to this 300 document. 302 9. Informative References 304 [ColumbiaSkype] 305 Baset, S. and H. Schulzrinne, "An Analysis of the Skype 306 Peer-to-Peer Internet Telephony Protocol", . 309 [DASH] "ISO/IEC 23009-1:2012 Information technology -- Dynamic 310 adaptive streaming over HTTP (DASH) -- Part 1: Media 311 presentation description and segment formats", . 315 [I-D.tschofenig-post-standardization] 316 Tschofenig, H., Aboba, B., Peterson, J., and D. McPherson, 317 "Trends in Web Applications and the Implications on 318 Standardization", draft-tschofenig-post-standardization-02 319 (work in progress), May 2012. 321 [Labovitz] 322 Labovitz, C., "Internet Traffic and Content 323 Consolidation", March 2010, 324 . 327 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 328 Streaming Protocol (RTSP)", RFC 2326, April 1998. 330 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 331 February 2000. 333 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 334 RFC 3205, February 2002. 336 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 337 Issues", RFC 3234, February 2002. 339 [RFC4924] Aboba, B. and E. Davies, "Reflections on Internet 340 Transparency", RFC 4924, July 2007. 342 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 343 RFC 6455, December 2011. 345 [httpbis] "Hypertext Transfer Protocol Bis (httpbis)", 346 . 348 Author's Address 350 Marc Blanchet 351 Viagenie 352 246 Aberdeen 353 Quebec, QC G1R 2E1 354 Canada 356 Email: Marc.Blanchet@viagenie.ca 357 URI: http://viagenie.ca