DOCSLIB.ORG

Middleboxes Firewalls

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Middleboxes Firewalls Internet Ideal: Simple Network Model • Globally unique idenPfiers – Each node has a unique, fixed IP address – … reachable from everyone and everywhere Middleboxes • Simple packet forwarding – Network nodes simply forward packets Jennifer Rexford – … rather than modifying or filtering them COS 461: Computer Networks source destination Lectures: MW 10-10:50am in Architecture N101 IP network hGp://www.cs.princeton.edu/courses/archive/spr12/cos461/ 2 Internet Reality Middleboxes • Host mobility • Replicated services • Middleboxes are intermediaries – Host changing address – Load balancing over – Interposed between communicang hosts as it moves server replicas – OZen without knowledge of one or both parPes • IP address deplePon • Performance concerns • Myriad uses “An abomina*on!” – MulPple hosts using – Allocang bandwidth, – Address translators – Violaon of layering the same address caching content, … – Firewalls – Hard to reason about • Security concerns • Incremental deployment – Traffic shapers – Responsible for subtle bugs – DetecPng and blocking – New technology – Intrusion detecPon “A prac*cal necessity!” unwanted traffic deployed in stages – Transparent proxies – Solve real/pressing problems – Applicaon accelerators 3 – Needs not likely to go away 4 Firewalls Should arriving packet be allowed in? Departing packet let out? Firewalls administered public network Internet firewall • Firewall filters packet-by-packet, based on: – Source and desPnaon IP addresses and port numbers – TCP SYN and ACK bits; ICMP message type – Deep packet inspecPon on packet contents (DPI) 5 6 1 Packet Filtering Examples Firewall Configuraon • block all packets with IP protocol field = 17 and • Firewall applies a set of rules to each packet with either source or dest port = 23. – To decide whether to permit or deny the packet – All incoming and outgoing UDP flows blocked • Each rule is a test on the packet – All Telnet connecPons are blocked – Comparing IP and TCP/UDP header fields • block inbound TCP packets with SYN but no ACK – … and deciding whether to permit or deny – Prevents external clients from making TCP • Order maers connecPons with internal clients – Once packet matches a rule, the decision is done – but allows internal clients to connect to outside • block all packets with TCP port of Quake 7 8 Firewall Configuraon Example Firewall Configuraon Rules • Alice runs a network in 222.22.0.0/16 • #1: Don’t let Trudy’s machines in • Wants to let bob’s school access certain hosts – Deny (src = 111.11.11.0/24, dst = 222.22.0.0/16) – Bob is on 111.11.0.0/16 • #2: Let rest of bob’s network in to special dsts – Alice’s special hosts on 222.22.22.0/24 – Permit (src=111.11.0.0/16, dst = 222.22.22.0/24) • Alice doesn’t trust Trudy, inside bob’s network • #3: block the rest of the world – Trudy is on 111.11.11.0/24 – Deny (src = 0.0.0.0/0, dst = 0.0.0.0/0) • Alice doesn’t want any other Internet traffic 9 10 Stateful Firewall A Variaon: Traffic Management • Stateless firewall: • Permit vs. deny is too binary a decision – Treats each packet independently – Classify the traffic based on rules • Stateful firewall – … and handle each class differently – Remembers connecPon-level informaon • Traffic shaping (rate limiPng) – E.g., client iniPang connecPon with a server – Limit the amount of bandwidth for certain traffic – … allows the server to send return traffic • Separate queues – Use rules to group related packets SYN SYN – And then do weighted fair scheduling across groups SYN-ACK SYN-ACK 11 12 2 Clever Users Subvert Firewalls • Example: filtering dorm access to a server – Firewall rule based on IP addresses of dorms – … and the server IP address and port number – Problem: users may log in to another machine Network Address Translaon • Example: filtering P2P based on port #s – Firewall rule based on TCP/UDP port numbers • E.g., allow only port 80 (e.g., Web) traffic – Problem: soZware using non-tradiPonal ports • E.g., write P2P client to use port 80 instead 13 14 History of NATs Network Address Translaon • IP address space deplePon – Clear in early 90s that 232 addresses not enough Outbound: Rewrite the src IP addr – Work began on a successor to IPv4 • In the meanPme… Inbound: Rewrite the 138.76.29.7dest IP addr 10.0.0.1 – Share addresses among numerous devices – … without requiring changes to exisPng hosts Problem: Local address not globally addressable outside • Meant as a short-term remedy NAT – Now: NAT is widely deployed, much more than IPv6 NAT rewrites the IP addresses • Make “inside” look like single IP addr • Change header checksums accordingly 10.0.0.2 inside 15 16 Port-Translang NAT Network Address Translaon Example • Two hosts communicate with same desPnaon NAT translation table WAN side addr LAN side addr – DesPnaon needs to differenPate the two 138.76.29.7, 5001 10.0.0.1, 3345 • Map outgoing packets …… – Change source address and source port S: 10.0.0.1, 3345 D: 128.119.40.186, 80 • Maintain a translaon table 10.0.0.1 1 S: 138.76.29.7, 5001 – Map of (src addr, port #) to (NAT addr, new port #) 2 D: 128.119.40.186, 80 10.0.0.2 • 138.76.29.7 Map incoming packets S: 128.119.40.186, 80 S: 128.119.40.186, 80 D: 10.0.0.1, 3345 4 D: 138.76.29.7, 5001 3 – Map the desPnaon address/port to the local host 10.0.0.3 17 18 3 Maintaining the Mapping Table Where is NAT Implemented? • Create an entry upon seeing an outgoing packet • Home router (e.g., Linksys box) – Packet with new (source addr, source port) pair – Integrates router, DHCP server, NAT, etc. – Use single IP address from the service provider • Eventually, need to delete entries to free up #’s – When? If no packets arrive before a Pmeout • Campus or corporate network – (At risk of disrupPng a temporarily idle connecPon) – NAT at the connecPon to the Internet – Share a collecPon of public IP addresses • Yet another example of “soZ state” – Avoid complexity of renumbering hosts/routers – I.e., removing state if not refreshed for a while when changing ISP (w/ provider-allocated IP prefix) 19 20 PracPcal ObjecPons Against NAT Principled ObjecPons Against NAT • Port #s are meant to idenPfy sockets • Routers are not supposed to look at port #s – Yet, NAT uses them to idenPfy end hosts – Network layer should care only about IP header – Makes it hard to run a server behind a NAT – … and not be looking at the port numbers at all • NAT violates the end-to-end argument 138.76.29.7 – Network nodes should not modify the packets Requests to 10.0.0.1 • IPv6 is a cleaner soluPon 138.76.29.7 on port 80 – beGer to migrate than to limp along with a hack NAT That’s what happens when network Which host should get the request??? puts power in hands of end users! 10.0.0.2 • Explicit config at NAT for incoming conn’s 21 22 Replicated Servers • One site, many servers – www.youtube.com Load balancers 23 24 4 Load balancer Dedicated IP • Splits load over server replicas addresses 10.0.0.1 – At the connecPon level Virtual IP address 12.1.11.3 10.0.0.2 Wide-Area Accelerators 10.0.0.3 • Apply load balancing policies 25 26 At ConnecPon Point to the Internet Example: Improve TCP Throughput ACK Appliance Internet Appliance Appliance Internet Appliance • Improve end-to-end performance • Appliance with a lot of local memory – Through buffering, compression, caching, … • Sends ACK packets quickly to the sender • Incrementally deployable • Overwrites receive window with a large value – No changes to end hosts or the rest of the Internet • Or, even run a new and improved version of TCP 27 28 Example: Compression Example: Caching Appliance Internet Appliance Appliance Internet Appliance • Compress the packet • Cache copies of the outgoing packets • Send the compressed packet • Check for sequences of bytes that match past data • Uncompress at the other end • Just send a pointer to the past data • Maybe compress across successive packets • And have the receiving appliance reconstruct 29 30 5 Example: EncrypPon Appliance Internet Appliance Tunneling • Two sites share keys for encrypPng traffic • Sending appliance encrypts the data • Receiving appliance decrypts the data • Protects the sites from snoopers on the Internet 31 32 IP Tunneling 6bone: Deploying IPv6 over IP4 • A B tunnel E F IP tunnel is a virtual point-to-point link Logical view: – Illusion of a direct link between two nodes IPv6 IPv6 IPv6 IPv6 A B tunnel E F A B C D E F Logical view: Physical view: IPv6 IPv6 IPv4 IPv4 IPv6 IPv6 A B E F Flow: X Src:B Src:B Flow: X Physical view: Src: A Src: A Dest: F Dest: E Dest: E Dest: F Flow: X Flow: X Src: A Src: A • Encapsulaon of the packet inside IP datagram data Dest: F Dest: F data – Node b sends a packet to node E data data – … containing another packet as the payload A-to-B: E-to-F: B-to-C: B-to-C: IPv6 IPv6 IPv6 inside IPv6 inside 33 IPv4 IPv4 34 Remote Access Virtual Private Network Conclusions VPN server • 12.1.1.73 Middleboxes address important problems – Geng by with fewer IP addresses Internet – blocking unwanted traffic 12.1.1.0/24 12.1.1.1 1.2.3.4 – Making fair use of network resources • Tunnel from user machine to VPN server – Improving end-to-end performance – A “link” across the Internet to the local network • Middleboxes cause problems of their own • Encapsulates packets to/from the user – No longer globally unique IP addresses – – Packet from 12.1.1.73 to 12.1.1.100 Cannot assume network simply delivers packets – Inside a packet from 1.2.3.4 to 12.1.1.1 35 36 6 Midterm Exam • 10:00-10:50am Wednesday March 14 – In Frist 302 (not the lecture room!) • Open books, notes, slides, etc.
Load more

Recommended publications
  • Automated Verification of Customizable Middlebox Properties
    Automated Verification of Customizable Middlebox Properties with Gravel Kaiyuan Zhang Danyang Zhuo† Aditya Akella# Arvind Krishnamurthy Xi Wang University of Washington † Duke University # University of Wisconsin-Madison Abstract (e.g., free of crashes, memory safety) [14] or on proving equiv- alence to pseudocode-like low-level specifications [39, 40]. Building a formally-verified software middlebox is attractive In this paper, we ask whether it is possible to make soft- for network reliability. In this paper, we explore the feasibil- ware middlebox verification completely automated with mini- ity of verifying “almost unmodified” software middleboxes. mal proof effort. In particular, our goal is two-fold. First, we Our key observation is that software middleboxes are already want verification to work on real-world “almost unmodified” designed and implemented in a modular way (e.g., Click). Fur- middlebox implementations without requiring manual proofs. ther, to achieve high performance, the number of operations Second, we want developers to be able to express and ver- each element or module performs is finite and small. These ify high-level properties directly translated from RFCs (e.g., two characteristics place them within reach of automated RFC5382 [29] for NAT) without writing manual proofs to- verification through symbolic execution. wards each of these properties. To deliver on these goals, we We perform a systematic study to test how many existing seek to replicate the automated reasoning approach used in Click elements can be automatically verified using symbolic some recent verification projects that focus on file systems execution. We show that 45% of the elements can be auto- and OS system calls [30,34].
    [Show full text]
  • Etsi Ts 103 523-1 V1.1.1 (2020-12)
    ETSI TS 103 523-1 V1.1.1 (2020-12) TECHNICAL SPECIFICATION CYBER; Middlebox Security Protocol; Part 1: MSP Framework and Template Requirements 2 ETSI TS 103 523-1 V1.1.1 (2020-12) Reference DTS/CYBER-0027-1 Keywords cyber security ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice The present document can be downloaded from: http://www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI deliverable is the one made publicly available in PDF format at www.etsi.org/deliver. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https://portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.
    [Show full text]
  • Openbox: Enabling Innovation in Middlebox Applications
    OpenBox: Enabling Innovation in Middlebox Applications Anat Bremler-Barr Yotam Harchol David Hay School of Computer Science School of Computer Science School of Computer Science The Interdisciplinary Center and Engineering and Engineering Herzliya, Israel The Hebrew University The Hebrew University [email protected] Jerusalem, Israel Jerusalem, Israel [email protected] [email protected] ABSTRACT Contemporary networks contain many different kind of mid- dleboxes that perform variety of advanced network func- tions. Currently, a special box is tailored to provide each such function. These special boxes are usually proprietary, and operators control over them is limited to the set of ca- pabilities defined by the provider of each box. Nonetheless, many middleboxes perform very similar tasks. In this paper we present OpenBox: a logically-centralized framework that makes advanced packet processing and mon- itoring easier, faster, more scalable, flexible, and innovative. OpenBox decouples the control plane of middleboxes from their data plane, and unifies the data plane of multiple mid- dlebox applications using entities called service instances. On top of the centralized control plane everyone can de- Figure 1: The general architecture of the OpenBox velop OpenBox applications. An OpenBox application, for- framework. OpenBox applications are programmed merly implemented as a separate middlebox, instructs the over the OpenBox controller, which sets the actual data plane how to process packets in order to achieve its classification and monitoring rules in data plane's intended function. OpenBox service instances reside in data service instances. OpenBox controller communi- plane and process packets according to policies defined by cates with an OpenFlow controller, if such exists, the control plane.
    [Show full text]
  • Middleboxes As a Cloud Service
    UC Berkeley UC Berkeley Electronic Theses and Dissertations Title Middleboxes as a Cloud Service Permalink https://escholarship.org/uc/item/4kj7g8dz Author Sherry, Justine Marie Publication Date 2016 Peer reviewed|Thesis/dissertation eScholarship.org Powered by the California Digital Library University of California Middleboxes as a Cloud Service By Justine Marie Sherry A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor Sylvia Ratnasamy, Chair Professor Scott Shenker Professor John Chuang Professor Arvind Krishnamurthy Fall 2016 Middleboxes as a Cloud Service Copyright 2016 by Justine Marie Sherry 1 Abstract Middleboxes as a Cloud Service by Justine Marie Sherry Doctor of Philosophy in Computer Science University of California, Berkeley Professor Sylvia Ratnasamy, Chair Today’s networks do much more than merely deliver packets. Through the deployment of middleboxes, enterprise networks today provide improved security – e.g., filtering malicious content – and performance capabilities – e.g., caching frequently accessed content. Although middleboxes are deployed widely in enterprises, they bring with them many challenges: they are complicated to manage, expensive, prone to failures, and challenge privacy expectations. In this thesis, we aim to bring the benefits of cloud computing to networking. We argue that middlebox services can be outsourced to cloud providers in a similar fashion to how mail, compute, and storage are today outsourced. We begin by presenting APLOMB, a system that allows enterprises to outsource middlebox processing to a third party cloud or ISP. For en- terprise networks, APLOMB can reduce costs, ease management, and provide resources for scalability and failover.
    [Show full text]
  • Ipv6 Address Obfuscation by Intermediate Middlebox in Coordination with Connected Devices
    IPv6 address obfuscation by intermediate middlebox in coordination with connected devices Florent Fourcot12, Laurent Toutain14, Stefan K¨opsell2, Fr´ed´ericCuppens13, and Nora Cuppens-Boulahia13 1 Institut Mines-T´el´ecom; T´el´ecomBretagne {first.last}@telecom-bretagne.eu 2 TU Dresden; Faculty of Computer Science [email protected] 3 Lab-STICC - Laboratoire en sciences et technologies de l'information, de la communication et de la connaissance 4 IRISA - Institut de recherche en informatique et syst`emesal´eatoires The original publication is available at www.springerlink.com. Abstract. Privacy is a major concern on the current Internet, but trans- port mechanisms like IPv4 and more specifically IPv6 do not offer the necessary protection to users. However, the IPv6 address size allows de- signing privacy mechanisms impossible in IPv4. Nevertheless existing so- lutions like Privacy Extensions [20] are not optimal, still only one address is in use for several communications over time. And it does not offer con- trol of the network by the administrator (end devices use randomly gen- erated addresses). Our IPv6 privacy proposal uses ephemeral addresses outside the trusted network but stable addresses inside the local network, allowing the control of the local network security by the administrator. Our solution is based on new opportunities of IPv6: a large address space and a new flow label field. In combination with Cryptographically Gen- erated Addresses, we can provide protection against spoofing on the local network and enhanced privacy for Internet communication. Keywords: IPv6, Privacy, Security, Address Management 1 Introduction If IPv4 is still the most popular IP stack, IPv6 leaves the laboratory to be de- ployed on the Internet.
    [Show full text]
  • Reflections on Middlebox Detection Mechanisms in Ipv6 Transition
    Reflections on Middlebox Detection Mechanisms in IPv6 Transition Aaron Yi Ding∗y, Jouni Korhonenz, Teemu Savolainenx, Yanhe Liu∗, Markku Kojo∗, Sasu Tarkoma∗, Henning Schulzrinney ∗University of Helsinki yColumbia University zBroadcom xNokia Abstract. Middleboxes performing Network Address Translation (NAT) have gained a positive role in the IPv6 transition by enabling interoperabi- lity of different IP versions, i.e., IPv4 and IPv6. Although the NAT-based mechanisms pave the way for a smooth adoption of IPv6 in the transi- tion, we shall be prudent towards such middlebox-oriented approach due to its complexity and overhead for end users and network services. In this position paper, we discuss the middlebox detection mechanisms de- signed for IPv6 transition, focusing on NAT64 in specific, and share our hands-on experience in protocol design and standardization. Based on our experimental findings, we identify issues in the existing approaches and offer suggestions to protocol designers and researchers. The goal is to improve our understanding of the middleboxes and hence leading to a more robust design of protocols for the evolving IPv6 Internet. 1 Introduction In the transitional phase to IPv6, ensuring the interoperability between IPv4 and IPv6 is the key to a smooth adoption of IPv6 in the Internet [1]. Among various proposals, the once criticized Network Address Translation (NAT) mechanism, typically deployed on middleboxes, has made a positive impact to bridge the gap between those two incompatible IP versions. As indicated in recent studies [2, 3], the IPv6 adoption has grown steady on a global scale. A lot of this growth can be accredited to the transitional technologies deployed by network operators, such as NAT64 [4] combined with DNS64 [5].
    [Show full text]
  • Lost in Network Address Translation: Lessons from Scaling the World's
    Lost in Network Address Translation: Lessons from Scaling the World’s Simplest Middlebox Vladimir Olteanu Felipe Huici Costin Raiciu U. Politehnica of Bucharest NEC Europe Ltd. U. Politehnica of Bucharest Abstract work Function Virtualisation (NFV) and is more than just To understand whether the promise of Network Function hype: all of the major network operators have gotten to- Virtualization can be accomplished in practice, we set out gether to specify an architecture for Network Function Vir- to create a software version of the simplest middlebox that tualization [20] and to allow chaining different functions on keeps per flow state: the NAT. the same traffic flow [10]. While there is a lot of literature in the wide area of SDN in There is already a growing body of research on how we general and in scaling middleboxes, we find that by aiming should approach NFV: the basic recipe is to use hardware to create a NAT good enough to compete with hardware ap- load balancing (e.g. OpenFlow) to split traffic to a number pliances requires a lot more care than we had thought when of commodity servers, as proposed by Flowstream [7]. To we started our work. In particular, limitations of OpenFlow implement middlebox functionality, the simplest choice is to switches force us to rethink load balancing in a way that use existing apps running over Linux; however major gains does not involve the centralized controller at all. The result can be made in both performance and ease of deployment is a solution that can sustain, on six low-end commodity if we restrict the programming language for middleboxes as boxes, a throughput of 40Gbps with 64B packets, on par proposed by ClickOS [12] and FlowOS [3].
    [Show full text]
  • Secure Session Establishment with SIP in Environments Containing Middleboxes
    Secure Session Establishment with SIP in Environments containing Middleboxes KLAUS UMSCHADEN1,2, IGOR MILADINOVIC1,2,, JOHANNES STADLER1,2 1) Institute of Communication Networks Technical University of Vienna Favoritenstrasse 9 / 388, 1040 Vienna AUSTRIA 2) Forschungszentrum Telekommunikation Wien Donau-City-Str. 1, 1220, Vienna AUSTRIA Abstract: - The Session Initiation Protocol (SIP) is an application layer protocol for session establishment, modification and teardown. For end-to-end security of the session information, SIP uses the Secure Multipurpose Internet Mail Extension (S/MIME). However, in many environments SIP has to traverse middleboxes with firewall or NAT service, which breaks either end-to-end confidentiality or end-to-end significance of SIP messages and therefore the end-to-end security. This paper describes this problematic and two potential solutions. Especially one of them, the MIDCOM aware SIP proxy, which can be authorized to apply S/MIME to SIP, is an interesting approach that offers end-to-end security services without increasing existing firewall and middlebox security risks. Key-Words: - SIP, Security, VoIP, Middlebox, Firewall, NAT, MIDCOM 1 Introduction approach where the user can authorize its SIP proxy to Session Initiation Protocol (SIP) [1, 2] is a protocol for apply Secure Multipurpose Internet Mail Extension session control over packet based networks. The 3GPP (S/MIME) [10] on SIP after the middlebox has been uses SIP for the signaling in Universal Mobile prepared for the media streams via MIDCOM. This Telecommunications System (UMTS) [3] networks. It is enables end-to-end security and centralizes the evident that end-to-end security is essential for next middlebox control in the SIP proxy.
    [Show full text]
  • Experiences Deploying a Transparent Split TCP Middlebox and the Implications for NFV
    Experiences Deploying a Transparent Split TCP Middlebox and the Implications for NFV Franck Le, Erich Nahum, Vasilis Pappas, Maroun Touma, Dinesh Verma IBM T.J. Watson Research Center Yorktown Heights, NY, USA {fle|nahum|vpappas|maroun|dverma}@us.ibm.com ABSTRACT tion, poor connectivity, and range limitations all con- This paper summarizes our experiences deploying a trans- tribute to poor wireless experience. parent Split TCP middlebox for WiFi networks in En- Split TCP: One solution to this problem is Split terprise customer environments. Since Split TCP is TCP [1, 6, 25]. The concept is simple: Split a TCP nearly two decades old, we believed this would be a connection between a fixed server and wireless client straightforward application of well-known technology. into two separate connections at the middlebox { one Reality, however, would teach us otherwise. connection between the server and the middlebox, and While we began our deployment in our own office one between the middlebox and the client. This allows with 3,000 users, we encountered several challenges in packet loss recovery to occur independently over either deploying this technology at customer sites. Each cus- leg, minimizing unnecessary congestion window reduc- tomer had different network architectures, security poli- tions and improving TCP performance. cies, and non-negotiable requirements. In particular, Routing TCP Streams: Of course, this requires modifying the network architecture was frequently im- that the middlebox be able to intercept all packets of a possible. Deployment challenges tended to fall into two flow in both directions. Many network functions (e.g., related but distinct categories. First, making the box firewall, intrusion detection system, deep packet inspec- transparent to both clients and servers required extend- tion, split TCP proxy) have the requirement that they ing the notion of transparency from beyond just layer observe and even intercept full TCP streams.
    [Show full text]
  • Detecting Middlebox Interference on Applications
    Detecting Middlebox Interference on Applications Shan Huang Felix´ Cuadrado, Steve Uhlig School of Electronic Engineering and Computer Science Submitted for the degree of Master of Philosophy to the University of London July 2017 Abstract Middleboxes are widely used in today’s Internet, especially for security and performance. Mid- dleboxes classify, filter and shape traffic, therefore interfering with application behaviour and performing new network functions for end hosts. Recent studies have uncovered and studied middleboxes in different types of networks. In order to understand the middlebox interference on traffic flows and explore the involved ASes, our methodology relies on a client-server architecture, to be able to observe both directions of the middlebox interaction. Meanwhile, probing with increasing TTL values provides us chances to inspect behaviour of middleboxes hop by hop. Implementing our methodologies, we exploit a large-scale proxy infrastructure Luminati, to de- tect HTTP-interacting middleboxes across the Internet. We collect a large-scale dataset from van- tage points distributed in nearly 10,000 ASes across 196 countries. Our results provide abundant evidence for middleboxes deployed across more than 1000 ASes. We observe various middle- box interference in both directions of traffic flows, and across a wide range networks, including mobile operators and data center networks. i Contents 1 Introduction3 1.1 Introduction.....................................3 1.2 Motivation......................................4 1.3 Contribution.....................................5 2 Literature Study6 2.1 Middleboxes Taxonomy..............................6 2.2 Middleboxes Today.................................7 2.2.1 Middleboxes in Enterprise Networks....................7 2.2.2 Middleboxes in ISP Networks.......................8 2.2.3 Middleboxes and Internet Censorship...................9 2.3 Detecting Method.................................
    [Show full text]
  • Revealing Middlebox Interference with Tracebox
    Revealing Middlebox Interference with Tracebox Gregory Detal, Benjamin Hesmans, Yves Vanaubel, Benoit Donnet Olivier Bonaventure Université de Liège Université catholique de Louvain Liège – Belgium Louvain-la-Neuve – Belgium fi[email protected] fi[email protected] ABSTRACT description does not apply anymore to a wide range of net- Middleboxes such as firewalls, NAT, proxies, or Deep Pack- works. Enterprise networks, WiFi hotspots, and cellular net- et Inspection play an increasingly important role in various works often include various types of middleboxes in addition types of IP networks, including enterprise and cellular net- to traditional routers and switches [1]. A middlebox, defined works. Recent studies have shed the light on their impact on as “any intermediary box performing functions apart from real traffic and the complexity of managing them. Network normal, standard functions of an IP router on the data path operators and researchers have few tools to understand the between a source host and destination host”[2], manipulates impact of those boxes on any path. In this paper, we pro- traffic for purposes other than simple packet forwarding. pose tracebox, an extension to the widely used traceroute Middleboxes are often deployed for performance or secu- tool, that is capable of detecting various types of middle- rity reasons. Typical middleboxes include Network Address box interference over almost any path. tracebox sends IP Translators, firewalls, Deep Packet Inspection boxes, trans- packets containing TCP segments with different TTL values parent proxies, Intrusion Prevention/Detection Systems, etc. and analyses the packet encapsulated in the returned ICMP Recent papers have shed the light on the deployment of messages.
    [Show full text]
  • Are TCP Extensions Middlebox-Proof?
    Are TCP Extensions Middlebox-proof? Benjamin Hesmans, Fabien Duchene, Christoph Paasch, Gregory Detal and Olivier Bonaventure ICTEAM, Université Catholique de Louvain Louvain-La-Neuve – Belgium fi[email protected] ABSTRACT During the last decade, a wide variety of middleboxes have Besides the traditional routers and switches, middleboxes been proposed, implemented and deployed [14]. These mid- such as NATs, firewalls, IDS or proxies have a growing im- dleboxes are frequently found in enterprise and cellular net- portance in many networks, notably in entreprise and wire- works [15]. A first analysis was carried out by Medina et less access networks. Many of these middleboxes modify al [9], using TBIT [10]. This study showed that middle- the packets that they process. For this, they to implement boxes interfere with TCP extensions, effectively decreasing (a subset of) protocols like TCP. Despite the deployment of TCP's performance. Honda et al. [6] took another approach, these middleboxes, TCP continues to evolve on the endhosts trying to detect the behavior of the Internet's middleboxes and little is known about the interactions between TCP ex- by sending and recording specially crafted TCP segments. tensions and the middleboxes. They conclude that any extension to TCP must be designed In this paper, we experimentally evaluate the interference with middleboxes in mind. Despite the widespread utiliza- between middleboxes and the Linux TCP stack. For this, tion of these middleboxes, there are few detailed documents we first propose MBtest, a set of Click elements that model or tools that model their behavior. Such tools could be used middlebox behavior. We use it to experimentally evaluate by designers of new protocols or TCP extensions to verify if how three TCP extensions interact with middleboxes.
    [Show full text]