DOCSLIB.ORG

Vmware NSX® Automation Fundamentals

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Vmware NSX® Automation Fundamentals VMware NSX® Automation Fundamentals Caio Oliveira, VMware Thiago Koga, VMware Foreword by Martin Casado II | VMware NSX® Automation Fundamentals Caio Oliveira, VMware Thiago Koga, VMware Foreword by Martin Casado | III VMWARE PRESS Program Managers Katie Holms Shinie Shaw Technical Writer Rob Greanias Reviewers and Content Contributors Marcos Hernandez Anderson Duboc Gustavo Santana Angel Villar Garea Andrew Voltmer Scott Goodman Designer and Production Manager Michaela Loeffler Sappington Warning & Disclaimer Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an “as is” basis. The authors, VMware Press, VMware, and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book. The opinions expressed in this book belong to the author and are not necessarily those of VMware. VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www.vmware.com. Copyright © 2018 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. and its subsidiaries in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. IV | Table of Contents About the Reviewers and Content Contributors ...........................................XII Preface ............................................................................................................................ XV Foreword ....................................................................................................................... XVI Chapter 1 - Introduction ................................................................................................1 Intended Audience ............................................................................................................2 What it will teach .............................................................................................................. 3 Why this subject is important .................................................................................... 3 How to proceed ................................................................................................................. 3 Disclaimer ............................................................................................................................. 4 Concept Definitions ......................................................................................................... 5 Programmability ................................................................................................................ 5 Automation ...........................................................................................................................7 Orchestration ...................................................................................................................... 9 Chapter 2 - Data Center Automation Challenges ........................................... 13 Network Automation Challenges ............................................................................16 Security Automation Challenges .............................................................................19 Tales from the Field – Gustavo Santana..............................................................23 Tales from the Field – Marcos Hernandez ..........................................................27 Chapter 3 - Automation Concepts ....................................................................... 29 What is an API? ................................................................................................................32 API Documentation ...................................................................................................... 34 What to look for in a good API ................................................................................35 REST Definitions ..............................................................................................................36 Consuming NSX REST API thought different methods ..............................37 XML Definitions ................................................................................................................38 Myth Buster – Automation is for Cloud Only ..................................................40 Physical and Virtual Workloads Paradigm .......................................................40 Chapter 4 - NSX and vRealize Automation ...................................................... 45 Current Product Interoperability (January 2018) .......................................... 46 vRealize Automation Definitions ............................................................................ 48 vRealize Automation Main Components ........................................................... 50 Life Cycle Extensibility ................................................................................................52 Key Features ......................................................................................................................52 Common Use Cases for vRealize Automation .................................................53 NSX and vRealize Automation Benefits ............................................................. 54 NSX and vRealize Automation Integration ........................................................58 Why this integration is helping organizations? ..............................................59 What enterprise are looking for out of this integration? ...........................60 vRealize Automation Network Profiles .................................................................61 Use Cases for vRealize Automation with NSX ................................................ 66 Day Two Operations with vRealize Automation and NSX .........................73 | V Chapter 5 - NSX and OpenStack ...........................................................................77 OpenStack Definitions ................................................................................................ 80 Neutron Concepts and NSX Integration .............................................................82 NSX and OpenStack Benefits .................................................................................. 88 Benefits of NSX .................................................................................................................91 NSX and OpenStack Integration .............................................................................93 NSX and VMware Integrated OpenStack ........................................................ 106 Tales from the Field – Marcos Hernandez ......................................................... 115 Chapter 6 - VMware vRealize Automation, OpenStack, or Both? ..........117 Tales From The Field – Angel Villar Garea ....................................................... 122 Chapter 7 - VMware NSX and Other Automations Tools...........................125 Chapter 8 - Conclusion ............................................................................................137 Bibliography .................................................................................................................139 Index ................................................................................................................................143 VI | List of Figures Figure 1.1 Programmability Workflow ................................................................... 6 Figure 1.2 Different Automation Solutions .......................................................... 8 Figure 1.3 Infrastructure Conductor (Maestro) ............................................... 10 Figure 2.1 Cars substitution of Horse-Drawn Vehicles .................................14 Figure 2.2 Car Industrialization .................................................................................15 Figure 2.3 SDN - Hardware Approach...................................................................18 Figure 2.4 Network Virtualization - Software Approach .............................18 Figure 2.5 Anatomy of a modern Cyber-Attack ..............................................19 Figure 2.6 Security Data Center Expenses and Losses .............................. 20 Figure 2.7 East-West and North-South Traffic in the Data Center.........21 Figure 2.8 Automation with a Preconfigured Network ...............................24 Figure 2.9 Physical Network Automation ...........................................................25 Figure 3.1 Automation may be Different for Each Person/Organization.............................................................................. 30 Figure 3.2 API Interactions .........................................................................................33 Figure 3.3 VMware NSX RESTful API ....................................................................35 Figure 3.4 HTTP verbs/methods and CRUD Operations............................36 Figure 3.5 VMware NSX® API™ Structure (example) .....................................37 Figure 3.6 Postman within Chrome to GET Syslog Information .............39 Figure 3.7 People, Process and Technology ...................................................
Load more

Recommended publications
  • Arguments for an End-Middle-End Internet
    CHASING EME: ARGUMENTS FOR AN END-MIDDLE-END INTERNET A Dissertation Presented to the Faculty of the Graduate School of Cornell University in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy by Saikat Guha August 2009 c 2009 Saikat Guha ALL RIGHTS RESERVED CHASING EME: ARGUMENTS FOR AN END-MIDDLE-END INTERNET Saikat Guha, Ph.D. Cornell University 2009 Connection establishment in the Internet has remained unchanged from its orig- inal design in the 1970s: first, the path between the communicating endpoints is assumed to always be open. It is assumed that an endpoint can reach any other endpoint by simply sending a packet addressed to the destination. This assumption is no longer borne out in practice: Network Address Translators (NATs) prevent all hosts from being addressed, firewalls prevent all packets from being delivered, and middleboxes transparently intercept packets with- out endpoint knowledge. Second, the Internet strives to deliver all packets ad- dressed to a destination regardless of whether the packet is ultimately desired by the destination or not. Denial of Service (DoS) attacks are therefore common- place, and the Internet remains vulnerable to flash worms. This thesis presents the End-Middle-End (EME) requirements for connec- tion establishment that the modern Internet should satisfy, and explores the de- sign space of a signaling-based architecture that meets these requirements with minimal changes to the existing Internet. In so doing, this thesis proposes so- lutions to three real-world problems. First, it focuses on the problem of TCP NAT Traversal, where endpoints behind their respective NATs today cannot es- tablish a direct TCP connection with each other due to default NAT behavior.
    [Show full text]
  • API Providers Guideанаapi Design
    API Providers Guide ­ API Design Prepared By Kin Lane June 2014 Table of Contents Overview of The API Design Space A New Generation Of API Design Developing The Language We Need To Communicate Leading API Definition Formats Building Blocks of API Design Companies Who Provide API Design Services API Design Tools API Design Editors API Definitions Providing A Central Truth For The API Lifecycle Contributing To The Deployment Lifecycle Contributing To The Management Lifecycle Contributing To The Testing & Monitoring Lifecycle Contributing To The Discovery Lifecycle An Evolutionary Period For API Design Overview of The API Design Space In the early days of APIs, everything was just about deploying and consuming—you were doing one or the other. Then by 2006 we saw the stabilization of common API management practices emerge from providers like Mashery, and then 3Scale. Now in 2014 we are stabilizing again, and the API universe is expanding around the area of API design, with new approaches, tools and entire companies emerging to provide services that are dedicated to helping companies design the best APIs they can. I define the world of API design as everything that goes into planning and designing your API, as well as the definition of your API that will eventually be deployed as your production endpoints, drive your documentation, generate the code samples your developers will use to integrate, test, monitor, and allow your API to be found­­through this lens, API design is fast becoming the driver for all areas of the API lifecycle. Depending on our needs, API design may begin with understanding HTTP, and REST, or may learning more about applying hypermedia as part of your design constraints, or API design might simply be about generating a Swagger definition, so you can generate interactive API documentation.
    [Show full text]
  • Democratizing Content Distribution
    Democratizing content distribution Michael J. Freedman New York University Primary work in collaboration with: Martin Casado, Eric Freudenthal, Karthik Lakshminarayanan, David Mazières Additional work in collaboration with: Siddhartha Annapureddy, Hari Balakrishnan, Dan Boneh, Nick Feamster, Scott Garriss, Yuval Ishai, Michael Kaminsky, Brad Karp, Max Krohn, Nick McKeown, Kobbi Nissim, Benny Pinkas, Omer Reingold, Kevin Shanahan, Scott Shenker, Ion Stoica, and Mythili Vutukuru Overloading content publishers Feb 3, 2004: Google linked banner to “julia fractals” Users clicked onto University of Western Australia web site …University’s network link overloaded, web server taken down temporarily… Adding insult to injury… Next day: Slashdot story about Google overloading site …UWA site goes down again Insufficient server resources Browser Browser Origin Server Browser Browser Browser Browser Browser Browser Many clients want content Server has insufficient resources Solving the problem requires more resources Serving large audiences possible… Where do their resources come from? Must consider two types of content separately • Static • Dynamic Static content uses most bandwidth Dynamic HTML: 19.6 KB Static content: 6.2 MB 1 flash movie 5 style sheets 18 images 3 scripts Serving large audiences possible… How do they serve static content? Content distribution networks (CDNs) Centralized CDNs Static, manual deployment Centrally managed Implications: Trusted infrastructure Costs scale linearly Not solved for little guy Browser Browser Origin Server Browser Browser Browser Browser Browser Browser Problem: Didn’t anticipate sudden load spike (flash crowd) Wouldn’t want to pay / couldn’t afford costs Leveraging cooperative resources Many people want content Many willing to mirror content e.g., software mirrors, file sharing, open proxies, etc.
    [Show full text]
  • Enterprise Tech 30—The 2021 List
    Enterprise Tech 30—The 2021 List Rajeev Chand Partner Head of Research The Enterprise Tech 30 is an exclusive list of the most promising private Peter Wagner companies in enterprise technology. The list, which is in its third year, is Founding Partner based on an institutional research and survey process with 103 leading venture capitalists, who are identified and invited based on their track Jake Flomenberg Partner record, expertise, and reputation for discernment. Olivia Rodberg The Enterprise Tech 30 is now a platform for the startup community: a Research Associate watershed recognition for the 30 companies and a practical and February 24, 2021 invaluable resource for customers, partners, journalists, prospective team members, service providers, and deal makers, among others. We are pleased to present the Enterprise Tech 30 for 2021. Wing Venture Capital 480 Lytton Avenue Palo Alto, CA 94301 Early Mid Late 1. Modern Treasury 1. Zapier 1. HashiCorp 2. Privacera 2. Fishtown Analytics 2. Stripe 3. Roam Research 3. Retool 3. Databricks 4. Panther Labs 4. Netlify 4. GitLab 5. Snorkel AI 5. Notion 5. Airtable 6. Linear 6. Grafana Labs 6. Figma 7. ChartHop 7. Abnormal Security 7. Confluent 8. Substack 8. Gatsby 8. Canva 9. Monte Carlo 9. Superhuman 9. LaunchDarkly 10. Census 10. Miro 10. Auth0 Special Calendly 1 2021 The Curious Case of Calendly This year’s Enterprise Tech 30 has 31 companies rather than 30 due to the “curious case” of Calendly. Calendly, a meeting scheduling company, was categorized as Early-Stage when the ET30 voting process started on January 11 as the company had raised $550,000.
    [Show full text]
  • Next Gen Integration and API Economy
    WHITE PAPER NEXT GEN INTEGRATION AND API ECONOMY Executive Summary Industry leaders say that Integration is where developers are designing innovative All such ecosystems emerged slowly in the key to Digital Economy. APIs are the applications, reaching new customers and last few years, and monetized transactions foundation of Next Gen Integration, be it exploring new markets, all around APIs. on the APIs, which created new digital Cloud integration, Application integration, revenue streams, which in turn, led to API In an Enterprise Integration ecosystem, B2B integration or Enterprise Integration. economy. APIs help in exposing an enterprise’s In current context, APIs are simple backend-as-a-service so that new Businesses, both large and small, both B2C to understand interfaces focused on applications can quickly be built on top of and B2B, all participate in the API economy. business’ recognizable assets, that facilitate that. Why this works is because a significant This paper brings connectivity and integration with peer applications or useful data is almost locked inside big and integration into spotlight, showcasing the systems in an Agile manner. complex legacy enterprise systems, and entire journey that has taken place and the data warehouses, and APIs unlock that A new Developer Ecosystem is emerging pace it’s moving ahead in. data, that precious data. External Document © 2019 Infosys Limited External Document © 2019 Infosys Limited Introduction Traditional integration We live in an economy powered by digital Traditional integration methods are: 2. Hub and Spoke (H&S) computing technologies, cushioned by 1. Point to Point (P2P) 3. Enterprise Service Bus (ESB) the Internet and the World Wide Web.
    [Show full text]
  • Community-Based API Builder to Manage Apis and Their Connections with Cloud-Based Services
    Community-based API Builder to manage APIs and their connections with Cloud-based Services Romanos Tsouroplis1, Michael Petychakis1, Iosif Alvertis1, Evmorfia Biliri1, Fenareti Lampathaki1, Dimitris Askounis1 1 National Technical University of Athens, School of Electrical and Computer Engineering, Athens, Greece { rtsouroplis, mpetyx, alvertisjo, ebiliri, flamp, askous} @epu.ntua.gr Abstract. Creating added value, innovative applications and services in the web is hindered by the prevailing different formats and models of information retrieved by the various Cloud-based Services (CBS). Additionally, CBS tend to change their Application Programming Interface (API) versions very often, not sufficiently helping the interested enterprises with their adoption as they need to be up-to-date and always functional. The API Builder is a community- based platform that aims to facilitate developers in adopting a Graph API that unifies the experience of multiple cloud-based services APIs and personal cloudlets, building and maintaining their software applications easily, despite any changes made in the CBS APIs. Keywords: APIs, Cloud-based Services, Evolving APIs, Graph API, Community-based platform, Social Enterprise 1. Introduction These days, more and more users tend to share their data through the World Wide Web. Social Networks have gathered large silos of information for each of their users and their interconnections. The Web APIs (Application Programming Interface) provide all the endpoints needed for a developer to request access into this plethora of information. All the major social networks like Facebook, Twitter, etc., have an API, providing most of their core services to third parties for several reasons [1]. Currently, on the site Programmable Web, which indexes, categorizes and makes mashups of APIs, 12,987 public APIs are listed and this number is continuously growing [2].
    [Show full text]
  • Managing Large-Scale, Distributed Systems Research Experiments with Control-Flows Tomasz Buchert
    Managing large-scale, distributed systems research experiments with control-flows Tomasz Buchert To cite this version: Tomasz Buchert. Managing large-scale, distributed systems research experiments with control-flows. Distributed, Parallel, and Cluster Computing [cs.DC]. Université de Lorraine, 2016. English. tel- 01273964 HAL Id: tel-01273964 https://tel.archives-ouvertes.fr/tel-01273964 Submitted on 15 Feb 2016 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. École doctorale IAEM Lorraine MANAGINGLARGE-SCALE,DISTRIBUTED SYSTEMSRESEARCHEXPERIMENTSWITH CONTROL-FLOWS THÈSE présentée et soutenue publiquement le 6 janvier 2016 pour l’obtention du DOCTORATDEL’UNIVERSITÉDELORRAINE (mention informatique) par TOMASZBUCHERT Composition du jury : Rapporteurs Christian Pérez, Directeur de recherche Inria, LIP, Lyon Eric Eide, Research assistant professor, Univ. of Utah Examinateurs François Charoy, Professeur, Université de Lorraine Olivier Richard, Maître de conférences, Univ. Joseph Fourier, Grenoble Directeurs de thèse Lucas Nussbaum, Maître de conférences, Université de Lorraine Jens Gustedt, Directeur de recherche Inria, ICUBE, Strasbourg Laboratoire Lorrain de Recherche en Informatique et ses Applications – UMR 7503 ABSTRACT(ENGLISH) Keywords: distributed systems, large-scale experiments, experiment control, busi- ness processes, experiment provenance Running experiments on modern systems such as supercomputers, cloud infrastructures or P2P networks became very complex, both technically and methodologically.
    [Show full text]
  • Software-Defined Networking: Improving Security for Enterprise
    Software-defined Networking: Improving Security for Enterprise and Home Networks by Curtis R. Taylor A Dissertation Submitted to the Faculty of the WORCESTER POLYTECHNIC INSTITUTE In partial fulfillment of the requirements for the Degree of Doctor of Philosophy in Computer Science by May 2017 APPROVED: Professor Craig A. Shue, Dissertation Advisor Professor Craig E. Wills, Head of Department Professor Mark Claypool, Committee Member Professor Thomas Eisenbarth, Committee Member Doctor Nathanael Paul, External Committee Member Abstract In enterprise networks, all aspects of the network, such as placement of security devices and performance, must be carefully considered. Even with forethought, networks operators are ulti- mately unaware of intra-subnet traffic. The inability to monitor intra-subnet traffic leads to blind spots in the network where compromised hosts have unfettered access to the network for spreading and reconnaissance. While network security middleboxes help to address compromises, they are limited in only seeing a subset of all network traffic that traverses routed infrastructure, which is where middleboxes are frequently deployed. Furthermore, traditional middleboxes are inherently limited to network-level information when making security decisions. Software-defined networking (SDN) is a networking paradigm that allows logically centralized control of network switches and routers. SDN can help address visibility concerns while providing the benefits of a centralized network control platform, but traditional switch-based SDN leads to concerns of scalability and is ultimately limited in that only network-level information is available to the controller. This dissertation addresses these SDN limitations in the enterprise by pushing the SDN functionality to the end-hosts. In doing so, we address scalability concerns and provide network operators with better situational awareness by incorporating system-level and graphical user interface (GUI) context into network information handled by the controller.
    [Show full text]
  • Downloads On-Demand from the Cessing) Description of Each Endpoint, Which Server
    Моделі та засоби систем баз даних і знань UDC 004.724, 004.62 https://doi.org/10.15407/pp2018.04.059 Kyrylo Malakhov, Aleksandr Kurgaev, Vitalii Velychko MODERN RESTFUL API DLS AND FRAMEWORKS FOR RESTFUL WEB SERVICES API SCHEMA MODELING, DOCUMENTING, VISUALIZING The given paper presents an overview of modern RESTful API description languages (belongs to interface description languages set) – OpenAPI, RAML, WADL, Slate – designed to provide a structured description of a RESTful web APIs (that is useful both to a human and for automated machine processing), with related RESTful web API modelling frameworks. We propose an example of the schema model of web API of the service for pre-trained distributional semantic models (word embedding’s) processing. This service is a part of the “Personal Research Information System” services ecosystem – the “Research and Development Workstation Environment” class system for supporting research in the field of ontology engineering: the au- tomated building of applied ontology in an arbitrary domain area as a main feature; scientific and technical creativity: the automated preparation of application documents for patenting inventions in Ukraine. It also presents a quick look at the relationship of Service-Oriented Architecture and Web services as well as REST fundamentals and RESTful web services; RESTful API creation process. Key words: Service-Oriented Architecture, Web service, REST, RESTful API, OpenAPI, RAML, WADL, Slate. Introduction Databases, web sites, business applica- tivity: the automated preparation of applica- tions and services need to exchange data. This tion documents for patenting inventions in is accomplished by defining standard data Ukraine) with related RESTful web API formats such as Extensible Markup Language modelling frameworks.
    [Show full text]
  • Comparing Description Languages for REST Apis in Industry and Academia
    Institute of Architecture of Application Systems University of Stuttgart Universitätsstraße 38 D–70569 Stuttgart Masterarbeit Nr. 50 Description Languages for REST APIs - State of the Art, Comparison, and Transformation Anton Scherer Course of Study: Softwaretechnik Examiner: Prof. Dr. Dr. h.c. Frank Leymann Supervisor: Dipl.-Inf. Florian Haupt Dipl.-Inf. Karolina Vukojevic-Haupt Commenced: July 21, 2015 Completed: January 20, 2016 CR-Classification: D.2.2, D.2.11 Abstract In recent years, the architectural style for building Web Services called "Representational State Transfer" (REST) gained a lot of popularity in industry and academia. Since designing complex, distributed hypermedia systems still meeting all the REST constraints is a difficult task, an academic, model-driven approach based on a multi-layered metamodel was developed in order to enforce REST compliance. Apart from that, multiple REST API description languages emerged in industry, providing means to formally define the structure of an API for human (e.g. API documentation) and machine (e.g. automated creation of client/server stubs) consumption. This work aims to compare the academic metamodel with API description languages widely used in industry. As a comparison methodology, bidirectional model transformations were designed and implemented between the academic metamodel and each of the two leading API description languages, Swagger and RAML. The model transformations were evaluated with a quantitative method by applying them on real world API descriptions as well as manually evaluating the quality of the transformed models. The model transformations show that indeed various mappings can be established between model elements of different metamodels. However, there are also crucial differences which are also examined in this thesis.
    [Show full text]
  • A Defense Framework Against Denial-Of-Service in Computer Networks
    A DEFENSE FRAMEWORK AGAINST DENIAL-OF-SERVICE IN COMPUTER NETWORKS by Sherif Khattab M.Sc. Computer Science, University of Pittsburgh, USA, 2004 B.Sc. Computer Engineering, Cairo University, Egypt, 1998 Submitted to the Graduate Faculty of the Department of Computer Science in partial fulfillment of the requirements for the degree of Doctor of Philosophy University of Pittsburgh 2008 UNIVERSITY OF PITTSBURGH DEPARTMENT OF COMPUTER SCIENCE This dissertation was presented by Sherif Khattab It was defended on June 25th, 2008 and approved by Prof. Rami Melhem, Department of Computer Science Prof. Daniel Moss´e,Department of Computer Science Prof. Taieb Znati, Department of Computer Science Prof. Prashant Krishnamurthy, School of Information Sciences Dissertation Advisors: Prof. Rami Melhem, Department of Computer Science, Prof. Daniel Moss´e,Department of Computer Science ii A DEFENSE FRAMEWORK AGAINST DENIAL-OF-SERVICE IN COMPUTER NETWORKS Sherif Khattab, PhD University of Pittsburgh, 2008 Denial-of-Service (DoS) is a computer security problem that poses a serious challenge to trustworthiness of services deployed over computer networks. The aim of DoS attacks is to make services unavailable to legitimate users, and current network architectures allow easy-to-launch, hard-to-stop DoS attacks. Particularly challenging are the service-level DoS attacks, whereby the victim service is flooded with legitimate-like requests, and the jamming attack, in which wireless communication is blocked by malicious radio interference. These attacks are overwhelming even for massively-resourced services, and effective and efficient defenses are highly needed. This work contributes a novel defense framework, which I call dodging, against service- level DoS and wireless jamming.
    [Show full text]
  • DISSERTATION DOCTEUR DE L UNIVERSITÉ DU LUXEMBOURG EN INFORMATIQUE Diego KREUTZ Dissertation Defence Committee
    PhD-FSTM-2020-52 The Faculty of Sciences, Technology and Medicine DISSERTATION Defence held on 15/09/2020 in Luxembourg to obtain the degree of DOCTEUR DE L’UNIVERSITÉ DU LUXEMBOURG EN INFORMATIQUE by Diego KREUTZ Born on 29 November 1979 in Santa Rosa (Brazil) LOGICALLY CENTRALIZED SECURITY FOR ​ ​ ​ ​ ​ ​ ​ SOFTWARE-DEFINED NETWORKING ​ ​ ​ ​ ​ Dissertation defence committee Dr Paulo Esteves-Veríssimo, dissertation supervisor Professor, Université du Luxembo​urg Dr Björn Ottersten, Chairman Professor, Université du Luxembourg Dr Radu State, Vice Chairman ​ Associate Professor, Université du Luxembourg Dr Jennifer Rexford Professor, Princeton University Dr Sandra Scott-Hayward, Lecturer, Queen’s University Be​ lfast Acknowledgements I am very proud of and grateful to my supervisors Paulo Esteves-Veríssimo and Fernando M. V. Ramos because I have learned so much with them. One of the few things I am sure of is my eternal debt with them. I am (arguably) sure I am a better researcher now because of them. In fact, I am still learning everyday something new with them. Paulo was also an awesome sort of coach in my personal life as well. He is an impressively smart and knowledgeable person. I have to say, in some ways, he is indeed better than a regular doctor. I know that (probably) just me and him will truly understand the meaning of this statement. IhadoneofthemostinterestingandproductivetimesafterImetJiangshan Yu. He is a very smart, easy going and inspiring researcher and person. Because of him, I started to better understand and to have joy in designing security protocols. JY inspired me in different ways. I consider myself lucky to have met him.
    [Show full text]