idnits 2.17.00 (12 Aug 2021) /tmp/idnits36506/draft-tschofenig-hourglass-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 (July 9, 2012) is 3596 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: 'RFC2119' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC3724' is defined on line 507, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mmusic-media-path-middleboxes-04 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: draft-ietf-tsvwg-sctp-udp-encaps has been published as RFC 6951 -- No information found for draft-tschofenig-http-design-guidance - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track July 9, 2012 5 Expires: January 10, 2013 7 The New Waist of the Hourglass 8 draft-tschofenig-hourglass-00.txt 10 Abstract 12 When developing a new application layer protocol the question about 13 its foundation arises. The decision will be impacted by various 14 factors but the ability for the solution to be deployable in today's 15 Internet will certainly play a big role since various intermediaries 16 may lead to a brittle communication architecture. 18 The waist of the hourglass has changed over time: new applications 19 have to run on top of UDP or TCP. Protocol designs that use other 20 transport protocols have turned out to be undeployable on the public 21 Internet. Running protocols on bare IP is also doomed to fail. This 22 change is not theoretic in nature but has real-world implications for 23 protocol designers. 25 There is also a trend to run applications on top of HTTP/HTTPS. The 26 author seeks more input from the wider IETF community about the 27 deployment situation of protocol filtering by intermediaries and on 28 the impact for protocol designers. 30 This document is being discussed at 31 https://www.ietf.org/mailman/listinfo/architecture-discuss 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 10, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Network Address Translators . . . . . . . . . . . . . . . . . 4 69 3. New Transport Protocols . . . . . . . . . . . . . . . . . . . 6 70 4. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Will IPv6 reverse the shift? . . . . . . . . . . . . . . . . . 9 72 6. The Rise of the Web . . . . . . . . . . . . . . . . . . . . . 10 73 7. Community Input Needed . . . . . . . . . . . . . . . . . . . . 11 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 79 11.2. Informative References . . . . . . . . . . . . . . . . . 15 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 The Internet protocol stack is organized in layers and text books 85 typically talk about the data link layer, network layer, transport 86 layer, and the application layer. 88 IP evolved in a core part of protocol stack that represents a common 89 intermediate protocol layer. This intermediate layer is designed to 90 support a variety of link layers and new link layer technologies can 91 be added in the future, without affecting IP itself. 93 In addition, IP supports a broad set of applications on top of it, 94 ranging from email to instant messaging to voice over IP. All of 95 those applications do not require changes to IP itself. As with link 96 layers, new applications can be added at any time. 98 The "Everything over IP, and IP over everything" theme, as it is 99 often described, is shown graphically in Figure 1. 101 +------+------+------+------+------+ 102 |Email | Web | VoIP | P2P | RTSP | 103 +------+------+------+------+------+ 104 | TCP | UDP | ICMP | 105 +------+------+------+ 106 | IP | 107 +------+------+------+ 108 |Ether |Sonet | ATM | 109 +------+------+------+------+------+ 110 |Fiber | TP | CAT5 | WiFi | GSM | 111 +------+------+------+------+------+ 113 Figure 1: The Original IP Hourglass 115 This diagram is, of course, simplified but illustrates the level of 116 interoperability needed to communication between different IP hosts. 117 Combined with the end-to-end principle the hour glass indicates the 118 level of protocol understanding intermediaries need to have in order 119 to exchange forward IP packets between a sender and a receiver 120 (absent any specific application layer entities, like proxies or 121 caches). Having IP as the waist meant that anyone could extend the 122 layers above the network layer in the way they wanted to communicate 123 end-to-end, including defining new transport layer protocols (as it 124 was done with SCTP, and DCCP). 126 Unfortunately, the various developments over the last years have 127 changed this model. We will describe the developments below. 129 2. Network Address Translators 131 Originally, NAT was designed to operate strictly at the IP layer - 132 translating internal to external addresses 1-for-1. This was done 133 primarily to avoid network renumbering when there was a change in 134 provider. However, NAT-P - NAT with port translation - quickly 135 emerged. In NAT-P, a large number of hosts can utilize a single 136 external IP address by using the UDP and TCP port numbers as a 137 demultiplexing point. 139 In essence, the UDP or TCP port number became an extended version of 140 the IP address - adding another 16 bits to the total amount of space, 141 providing for 48 overall. 143 NAT-P in particular, often just called NAT, has seem extremely 144 widespread deployment. Needless to say that this is a common 145 deployment in residence with broadband Internet but with the work on 146 Carrier Grade NAT it has also become a solution for dealing with IPv4 147 shortage in their effort to migrate to IPv6. 149 When put together, the implication is that basic packet transport 150 between point A and point B is, these days, frequently possible only 151 if the transport is UDP or TCP. This is because NAT-P requires one 152 of these two in order to utilize the 16 bit ports as as a 153 demultiplexing point. NATs, which are part of the network, have 154 become not just TCP and UDP-aware, they have become TCP and UDP 155 *dependent*. Almost every NAT in deployment today will simply 156 discard a packet above IP that is not TCP or UDP. The primary 157 exception is ICMP. Some NATs will pass ICMP packets, but it is 158 filtered by many. Consequently, it only sometimes works on the 159 Internet. This is also making it difficult to rely on. Indeed, it's 160 success rate is sufficiently poor that new mechanisms for path MTU 161 discovery have been designed which work without ICMP [RFC4821]. 163 This means that the operation of the public Internet is dependent on 164 the existence of UDP and TCP traffic. 166 Consequently, if new protocols have to ever actually work on the 167 public Internet, they need to run on top of the only available packet 168 transport on the Internet - UDP/IP. UDP has replaced IP as the 'raw' 169 point to point packet transport on the Internet. If congestion 170 control or signaling or other features are desired, they must be 171 layered on top of UDP, rather than in a new protocol beside it. 173 The IAB had published a number of publications to make the community 174 aware of the implications. In RFC 3724 the IAB examines the 175 development of the end-to-end principle as it has been applied to the 176 Internet architecture. In RFC 3424 [RFC3424] the IAB specifically 177 addressed the problems created with NATs. 179 3. New Transport Protocols 181 Does this mean that it is impossible to define new transport 182 protocols? Fortunately, the answer is no. New transport protocols 183 can be defined but the have to build on top of UDP or TCP. The 184 considerations for running them on top of UDP/TCP from Section 2 185 apply. 187 It is tempting to design a protocol on top of IP in such a way that 188 it is "NAT friendly". In this context, "NAT friendly" means that the 189 protocol has been designed to make ALGs for that protocol easy to 190 implement. However, there is a vicious cycle that prevents such ALG 191 functionality from ever being built. New features get added to 192 products, such as NATs, when the market demands them. The market 193 demands them when there is enough usage to create such a demand. 194 However, if the protocol will fail utterly to work in the face of 195 existing NAT, there will never be enough usage to create such demand. 196 Even if there was, the amount of time it would take to upgrade all of 197 the NATs on the Internet to support this ALG functionality is 198 astoundingly large. Thus, the protocol will continue to be 199 unreliable on the Internet, since there is always a chance that it 200 hits a NAT which does not support the necessary ALG functionality. 202 Consequently, designing protocols to be "NAT friendly" in this way 203 does not work in practice. New applications and protocols must be 204 designed to run on top of either UDP or TCP. 206 Examples of where this has been done after the fact is 207 [I-D.ietf-tsvwg-sctp-udp-encaps] for SCTP and [RFC3948] for IPSec. 208 However, it is far better to define this at the beginning, and 209 furthermore, have it as the one and only mode of operation. This 210 avoid protocol choices, and therefore simplifies design and improves 211 interoperability. 213 4. Firewalls 215 Unfortunately, it is not just NATs that cause problems for end-to-end 216 communication. Firewalls are also TCP and UDP aware, and are often 217 configured to discard non-UDP or non-TCP traffic. The degree of 218 filtering depends on the type of network; enterprise networks have 219 traditionally been more aggressive in filtering even outgoing 220 traffic. 222 Many firewalls are stateful, i.e., they create state information when 223 they see an packet from the internal network towards the Internet. 224 An unpleasant property of stateful packet filtering firewalls is that 225 they may lead to dropped packets when an arriving packet does not 226 match the previously allocated state information or when they drop 227 packets as part of their policy (as it is often the case when non- 228 UDP/non-TCP packets are seen). Furthermore, the firewall (as well as 229 NATs) decide locally when to time-out state information without 230 informing any other network entities leaving end hosts guessing about 231 the rate at which they need to send keep-alive messages. Time-out 232 intervalls typically varry between TCP and UDP but vary considerable 233 between different deployments and between products from different 234 vendors. 236 IETF protocol designers have already revised some protocols to handle 237 stateful packet filtering firewalls. Examples can be found with RFC 238 4487 [RFC4487] and RFC 5207 [RFC5207]. 240 Clever protocol designers started to invent algorithms to test paths 241 between address pairs for reachability. These patch tests are time 242 consuming and need to be re-run regularly when the network conditions 243 change. The more address pairs are available (IPv4, IPv6, tunnels, 244 etc.) the longer the tests need. 246 One such path test mechanism is the Interactive Connectivity 247 Establishment (ICE) protocol, described in RFC 5245 [RFC5245], and it 248 has been successfully used with the Extensible Messaging and Presence 249 Protocol (XMPP) and the Session Initiation Protocol (SIP). Similar 250 mechanisms may also be re-used with the efforts around the Real-Time 251 Communication in WEB-browsers, which is currently work in progress in 252 the IETF and the W3C. 254 For those cases where a protocol aims to exchange traffic between 255 hosts where both sides are behind NATs or firewalls then a rendezvous 256 mechanism and a mechanism for patch tests is needed. Such a 257 mechanism, however, also allows to determine when fewer protocol 258 encapsulations can be used. 260 To combat the ever increasing number of path candidates that have to 261 be tested for real-time applications a new protocol design practice 262 had emerged: Instead of using separate port pairs for different media 263 streams (e.g., streams for voice and video RTP traffic, feedback for 264 RTP via RTCP, separate channel for signaling communication and inband 265 communication, e.g., instant messaging, key exchange protocols) 266 protocol architects design their protocols in such a way that they 267 only use a small set of UDP/TCP port pairs and multiplex/demultiplex 268 the application traffic at a higher layer. This reduces the number 269 of path candidates that have to be tested for e2e connectivity. 271 This design trend can already be observed since a few years with 272 examples being found with DTLS / SRTP. RFC 5764 [RFC5764] and RFC 273 5763 [RFC5763] describe the design and how to demultiplex arriving 274 packets. The level of multiplexing is astonishing: 276 o Symmetric RTP [RFC4961] is the case in which there are two RTP 277 sessions that have their source and destination ports and 278 addresses reversed. 280 o RTP and RTCP traffic is usually sent on two separate UDP ports. 281 Two bidirectional DTLS-SRTP sessions are needed when symmetric RTP 282 [RFC4961] is used: one for the RTP port, one for the RTCP port. 284 o RTP and RTCP traffic may also be multiplexed on a single UDP port 285 [RFC5761]. 287 o Finally, the DTLS, and the connectivity check packets using STUN 288 also need to be multiplexed over the same port pair to accomplish 289 best possible optimization. 291 This improves the cryptographic performance of DTLS, but may cause 292 problems when RTCP and RTP are subject to different network treatment 293 (e.g., for bandwidth reservation). Some organizations using SIP as 294 part of their communication architecture have made assumptions about 295 what network intermediaries can do in order to perform firewall 296 pinholing and QoS treatment that may consequently not be compatible 297 with this type of design anymore. See 298 [I-D.ietf-mmusic-media-path-middleboxes] for a discussion about 299 middlebox behavior with SIP in context of media path security. 301 5. Will IPv6 reverse the shift? 303 Will the IPv6 Internet share the same fate as the IPv4 Internet, and 304 work only with UDP and TCP? It seems likely that the answer will be 305 yes. 307 The primary reason is that the IPv6 Internet is not something that 308 will appear overnight to replace the IPv4 Internet, as everyone had 309 noticed by now already. It will run alongside it for a very long 310 time, if not forever. Hosts that have connection to the IPv6 311 Internet will find themselves frequently using IPv4 (in a dual- stack 312 deployment), because the target host is available only on IPv4, or 313 will find themselves communicating with via IPv6 to a v4-only host 314 through NAT. In both cases, any protocols except for UDP and TCP 315 based protocols will not work. And thus, the v6 host will need to 316 utilize protocols that do work in all cases - ones based on UDP and 317 TCP - rather than ones that work only in a few cases. And so, when 318 we eventually do cutover to IPv6 only, it will be with hosts which 319 have, all along, only been running protocols that run on top of UDP 320 or TCP. 322 Another reason is that the IPv6 Internet will certainly be filled 323 with firewalls, and if history is any guide for the future, only TCP 324 and UDP are likely to work through such firewalls. 326 Examples of such firewall guidance for IPv6 to mimic the security 327 functionality of a NAT in IPv6 is given in RFC 4864 [RFC4864]. 329 Furthermore, (too) many efforts are currently ongoing to deal with 330 the long transition period from IPv4 to IPv6 and these migration 331 techniques introduce additional layers of NATs and tunneling that 332 will lead to problems with bi-directional reachability. 334 Finally, the IPv6 Internet is filled with NATs already anyway, 335 despite attempts to provide ample address space. 337 Consequently, for an application designers perspective, why build an 338 application on top of a protocol which doesn't work on the IPv4 339 Internet, and won't work on anything but a pure IPv6 network, when an 340 application running on top of UDP or TCP will work everywhere? 342 6. The Rise of the Web 344 The Web had enjoyed incredible success over the last 20 years and so 345 it is not suprising that many application developers have used HTTP 346 and HTTPS as the foundation for their application protocol design. 347 The properties offered by HTTP, HTML, and JavaScript are often a good 348 fit for many designs, and the familiarity of HTTP appeals to many 349 developers. With the intensive standardization efforts that happened 350 over the last few years and the improvement in browser peformance Web 351 applications today offer the same capabilities as native applications 352 in almost all areas. More guidance when HTTP usage is appropriate 353 can be found in [I-D.tschofenig-http-design-guidance]. 355 Sometimes, however, the choice of HTTP is not entirely voluntarily. 356 Certain networks, specifically enterprise networks, deploy aggressive 357 packet filtering technology such that barely any traffic other than 358 HTTP/HTTPS is allowed to bypass. Whether this policy decision is 359 based on a careful security evaluation, lack of awareness of other 360 protocols, or too complex company-internal processes for interacting 361 with the network administrator for updating packet filtering rules to 362 allow new applications to traverse is difficult to say. 364 In any case, for applications that are intented to be used in such 365 environments any protocol other than HTTP (or even HTTPS) is less 366 likely to function. It is therefore not suprising that protocol 367 designers are not willing to take the risk or put the additional 368 complexity of supporting multiple transport mechanisms. 369 Consequently, the perceived firewall traversal capability of HTTP/ 370 HTTPS has "convinced" many developers to use HTTP/HTTP as their 371 protocol of choice. As proxies that perform their policy at the HTTP 372 layer become more common application developers will have to react 373 again: an classical arms race. Consequently, HTTPS becomes the only 374 choice to prevent intermediaries from inspecting (and potentially 375 modifying) application layer content. 377 While many protocol designs use HTTP/HTTPS the Web is, however, much 378 more. In [I-D.tschofenig-post-standardization] we argue that the 379 features provided by JavaScript, as used by many Web developments, 380 have created another degree of sophistication that has helped to 381 build a convenient platform for application development. Especially 382 for end-user facing applications the JavaScript-based Web platform 383 has changed the standardization landscape and the work of protocol 384 architects. 386 7. Community Input Needed 388 The developments in the area of transport protocols have been 389 recognized by the community for a couple of years now and NAT and 390 firewall traversal techniques are taken into consideration in 391 protocol designs.. 393 The author is, however, struggling with the question whether there is 394 enough evidence to conclude that every protocol design today shall 395 build on HTTP/HTTPS (rather than voluntarily using to use HTTP/HTTPS 396 because of its properties). This would lead to another shift in the 397 IP hourglass model with HTTP/HTTPS being the new waist. 399 At this point in time it may be premature to conclude that a 400 mandatory HTTP/HTTPS based protocol design is indeed appropriate. 402 Firewalling behavior certainly differs from environment to 403 environment and not every Internet protocol is supposed to be 404 deployed everywhere. Some protocols are specifically focused on 405 server-to-server communication or have historically been using a non- 406 HTTP/HTTPS based design (e.g., routing protocols). 408 The author is therefore seeking input and further research on this 409 issue from the wider IETF and Internet community. 411 A few publications exist, such as [IPoptions], [TCPextensions], and 412 [HomeGateway], that illustrate the degree of filtering in networks 413 used by end customers (e.g., home networks, hotspots, and ISP 414 networks). Note that enterprise networks are explicitly excluded 415 since they are known to be challenging from filtering point of view 416 and cannot serve as the basis for protocol design. There are also 417 projects ongoing that may build the foundation for additional 418 insight, such as the 'Open Observatory for Network Interference' 419 [OONI] or the Neubot project [Neubot]. 421 In any case, more data points are needed to offer a better snapshot 422 of the current Internet deployment status. It will help protocol 423 developers to make informed decisions for their designs. 425 8. Security Considerations 427 This document focuses on implications for protocol design and 428 security protocols themselves are also impacted by the developments 429 on the Internet caused by evolving behavior of network 430 intermediaries. 432 9. IANA Considerations 434 This document does not require action by IANA. 436 10. Acknowledgements 438 The author would like to thank Jonathan Rosenberg for his work on 439 [I-D.rosenberg-internet-waist-hourglass]. This document re-uses text 440 from his earlier work. 442 11. References 444 11.1. Normative References 446 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 447 Requirement Levels", March 1997. 449 11.2. Informative References 451 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile 452 IPv6 and Firewalls: Problem Statement", RFC 4487, 453 May 2006. 455 [I-D.tschofenig-post-standardization] 456 Tschofenig, H., Aboba, B., Peterson, J., and D. McPherson, 457 "Trends in Web Applications and the Implications on 458 Standardization", draft-tschofenig-post-standardization-02 459 (work in progress), May 2012. 461 [I-D.rosenberg-internet-waist-hourglass] 462 Rosenberg, J., "UDP and TCP as the New Waist of the 463 Internet Hourglass", 464 draft-rosenberg-internet-waist-hourglass-00 (work in 465 progress), February 2008. 467 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 468 E. Klein, "Local Network Protection for IPv6", RFC 4864, 469 May 2007. 471 [I-D.ietf-mmusic-media-path-middleboxes] 472 Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis 473 of Middlebox Interactions for Signaling Protocol 474 Communication along the Media Path", 475 draft-ietf-mmusic-media-path-middleboxes-04 (work in 476 progress), January 2012. 478 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 479 Control Packets on a Single Port", RFC 5761, April 2010. 481 [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", 482 BCP 131, RFC 4961, July 2007. 484 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 485 Security (DTLS) Extension to Establish Keys for the Secure 486 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 488 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 489 for Establishing a Secure Real-time Transport Protocol 490 (SRTP) Security Context Using Datagram Transport Layer 491 Security (DTLS)", RFC 5763, May 2010. 493 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 494 (ICE): A Protocol for Network Address Translator (NAT) 495 Traversal for Offer/Answer Protocols", RFC 5245, 496 April 2010. 498 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 499 Firewall Traversal Issues of Host Identity Protocol (HIP) 500 Communication", RFC 5207, April 2008. 502 [I-D.ietf-tsvwg-sctp-udp-encaps] 503 Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP 504 Packets", draft-ietf-tsvwg-sctp-udp-encaps-04 (work in 505 progress), July 2012. 507 [RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle 508 and the Future of End-to-End: Reflections on the Evolution 509 of the Internet Architecture", RFC 3724, March 2004. 511 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 512 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 513 RFC 3948, January 2005. 515 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 516 Self-Address Fixing (UNSAF) Across Network Address 517 Translation", RFC 3424, November 2002. 519 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 520 Discovery", RFC 4821, March 2007. 522 [I-D.tschofenig-http-design-guidance] 523 Tschofenig, H., Dusseault, L., Reschke, J., and M. 524 Nottingham, "HTTP Protocol Design Guidelines", status: 525 not yet published, July 2012. 527 [Neubot] Nexa Center for Internet & Society, "The Neubot Project", 528 available at: http://nexa.polito.it/neubot, 2012. 530 [OONI] The Tor Project, "OONI : Open Observatory of Network 531 Interference", available at: http://ooni.nu/, 2012. 533 [HomeGateway] 534 Eggert, L., "An experimental study of home gateway 535 characteristics, In Proceedings of the '10th annual 536 conference on Internet measurement'", 2010. 538 [TCPextensions] 539 Honda, M., Nishida, Y., Greenhalgh, A., Handley, M., and 540 H. Tokuda, "Is it Still Possible to Extend TCP? In Proc. 541 ACM Internet Measurement Conference (IMC), Berlin, 542 Germany", Nov 2011. 544 [IPoptions] 545 Fonseca, R., Porter, G., Katz, R., Shenker, S., and I. 546 Stoica, "IP options are not an option, Technical Report 547 UCB/EECS", 2005. 549 Author's Address 551 Hannes Tschofenig 552 Nokia Siemens Networks 553 Linnoitustie 6 554 Espoo 02600 555 Finland 557 Phone: +358 (50) 4871445 558 Email: Hannes.Tschofenig@gmx.net 559 URI: http://www.tschofenig.priv.at