DOCSLIB.ORG

The Transport Layer: Tutorial and Survey SAMI IREN and PAUL D

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

The Transport Layer: Tutorial and Survey SAMI IREN and PAUL D. AMER University of Delaware AND PHILLIP T. CONRAD Temple University Transport layer protocols provide for end-to-end communication between two or more hosts. This paper presents a tutorial on transport layer concepts and terminology, and a survey of transport layer services and protocols. The transport layer protocol TCP is used as a reference point, and compared and contrasted with nineteen other protocols designed over the past two decades. The service and protocol features of twelve of the most important protocols are summarized in both text and tables. Categories and Subject Descriptors: C.2.0 [Computer-Communication Networks]: General—Data communications; Open System Interconnection Reference Model (OSI); C.2.1 [Computer-Communication Networks]: Network Architecture and Design—Network communications; Packet-switching networks; Store and forward networks; C.2.2 [Computer-Communication Networks]: Network Protocols; Protocol architecture (OSI model); C.2.5 [Computer- Communication Networks]: Local and Wide-Area Networks General Terms: Networks Additional Key Words and Phrases: Congestion control, flow control, transport protocol, transport service, TCP/IP 1. INTRODUCTION work of routers, bridges, and communi- cation links that moves information be- In the OSI 7-layer Reference Model, the tween hosts. A good transport layer transport layer is the lowest layer that service (or simply, transport service) al- operates on an end-to-end basis be- lows applications to use a standard set tween two or more communicating of primitives and run on a variety of hosts. This layer lies at the boundary networks without worrying about differ- between these hosts and an internet- ent network interfaces and reliabilities. This work was supported, in part, by the National Science Foundation (NCR 9314056), the U.S. Army Research Office (DAAL04-94-G-0093), and the Adv Telecomm/Info Dist’n Research Program (ATIRP) Consortium sponsored by ARL under Fed Lab Program, Cooperative Agreement DAAL01-96-2-0002. Authors’ addresses: S. Iren and P. D. Amer, Department of Computer and Information Sciences, University of Delaware, Newark, DE 19716; P. T. Conrad, Department of Computer and Information Sciences, Temple University, Philadelphia, PA 19122. Permission to make digital/hard copy of part or all of this work for personal or classroom use is granted without fee provided that the copies are not made or distributed for profit or commercial advantage, the copyright notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. © 2000 ACM 0360-0300/99/1200–0360 $5.00 ACM Computing Surveys, Vol. 31, No. 4, December 1999 Transport Layer • 361 CONTENTS (TCP) — and then contrast TCP with many alternative designs. 1. Introduction 2. Transport Layer Concepts and Terminology Section 2 introduces the basic con- 2.1 Introduction to TCP cepts and terminology of the transport 2.2 General Role of the Transport Layer layer through a simple example illus- 2.3 Terminology: SDUs, PDUs, and the like trating a TCP connection. Section 3 sur- 2.4 Example TCP Connection, Step-by-Step 2.5 What this example shows. and does not show veys the range of different services that 3. Transport Service can be provided by a transport layer. 3.1 CO-message vs. CO-byte vs. CL Similarly, Section 4 surveys the range 3.2 Reliability of protocol designs that provide these 3.3 Blocking vs. Non-Blocking 3.4 Multicast vs. Unicast services. (The important distinction be- 3.5 Priority vs. No-priority tween service and protocol is a major 3.6 Security vs. No-security theme throughout this paper.) Section 5 3.7 Status-reporting vs. No-status-reporting briefly surveys nine widely imple- 3.8 Quality-of-service vs. No-quality-of-service 4. Transport Protocol Features mented transport protocols other than 4.1 Connection-oriented vs. Connectionless TCP (UDP, TP0, TP4, SNA-APPN, 4.2 Transaction-oriented DECnet-NSP, ATM, XTP, T/TCP and 4.3 CO Protocol Features RTP) and two others that, although not 4.4 Error Control: Sequence Numbers, Acks, and Retransmissions widely implemented, have been particu- 4.5 Flow/Congestion Control larly influential (VMTP and NETBLT). 4.6 Multiplexing/Demultiplexing This section also includes briefer de- 4.7 Splitting/Recombining scriptions of eight experimental proto- 4.8 Concatenation/Separation cols that appear in the research litera- 4.9 Blocking/Unblocking 4.10 Segmentation/Reassembly ture (Delta-t, MSP, SNR, DTP, k-XP, 5. Transport Protocol Examples TRUMP, POC, and TP11). Section 6 5.1 UDP concludes the paper with an overview of 5.2 TP4 past, current, and future trends that 5.3 TP0 5.4 NETBLT have influenced transport layer design 5.5 VMTP including the impact of wireless net- 5.6 T/TCP works. This section also presents a few 5.7 RTP of the debates concerning transport pro- 5.8 APPN (SNA) 5.9 NSP (DECnet) tocol design. As an appendix, tables are 5.10 XTP provided summarizing TCP and eleven 5.11 SSCOP/AAL5 (ATM) of the transport protocols discussed in 5.12 Miscellaneous Transport Protocols Section 5. Similar tables for the experi- 6. Future Directions and Conclusion 6.1 Impacts of Trends and New Technologies mental protocols are omitted for reasons 6.2 Wireless Networks of space, but are available on the au- 6.3 Debates thors’ Web site: www.eecis.udel.edu/ 6.4 Final Observations ˜amer/PEL/survey/. APPENDIX This survey concentrates on unicast service and protocols — that is, commu- nication between exactly two hosts (or Essentially, the transport layer isolates two host processes). Multicast protocols applications from the technology, de- [Armstrong et al. 1992; Bormann et al. sign, and idiosyncracies of the network. 1994; Braudes and Zabele 1993; Deer- Dozens of transport protocols have ing 1989; Floyd et al. 1995; McCanne et been developed or proposed over the last al. 1996; Smith and Koifman 1996] pro- two decades. To put this research in vide communication among n $ 2 perspective, we focus first on the fea- hosts. Multicast represents an impor- tures of probably the most well-known tant research area currently undergoing transport protocol — namely the Inter- significant change and development, net’s Transmission Control Protocol and is worthy of a separate survey. ACM Computing Surveys, Vol. 31, No. 4, December 1999 362 • S. Iren et al. A previous study surveying eight years of thought about transport proto- transport protocols can be found in Do- col design. eringer et al. [1990]. A final reason that TCP provides a good starting point for study, is that the 2. TRANSPORT LAYER CONCEPTS AND history of research and development on TERMINOLOGY TCP can be traced in publicly available documents. Ongoing research and de- From an application programmer’s per- velopment of transport protocols, partic- spective, the transport layer provides ularly TCP, is the focus of two working interprocess communication between groups of the Internet Society. The two processes that most often are run- end2end working group of the Internet ning on different hosts. This section in- Research Task Force (IRTF, www.irtf. troduces some basic transport layer con- org) discusses ongoing long-term re- cepts and terminology through an search on transport protocols in general example: a simple document retrieval (including TCP), while the tcp-impl over the World Wide Web (herein Web) group of the Internet Engineering Task utilizing the TCP transport protocol. Force (IETF, www.ietf.org) focuses on short-term TCP implementation issues. 2.1 Introduction to TCP Both groups maintain active mailing lists where ideas are discussed and de- Although we provide a broad survey of bated openly. The work of these groups the transport layer, the service and pro- can be found in journal articles, confer- tocol features of TCP are used through- ence proceedings, and documents out this paper as a point of reference. known as Internet Drafts and Requests Over the last two decades the Inter- for Comments (RFCs). RFCs contain not net protocol suite (also called the only all the Internet Standards, but also TCP/IP protocol suite) has come to be other information of historical and tech- the most ubiquitous form of computer nical interest. It is much more difficult networking. Hence, the most widely for researchers to obtain similar infor- used transport protocols today are TCP mation concerning proprietary proto- and its companion transport protocol, cols. the User Datagram Protocol (UDP). A few other protocols are widely used, 2.2 General Role of the Transport Layer mainly because of their connection to the proprietary protocol suites of partic- To illustrate the role that the transport ular vendors. Examples include the layer plays in a familiar application, the transport protocols from IBM’s SNA, remainder of Section 2 examines the and Digital’s DECnet. However, the role of TCP in a simple interaction over success of the Internet has led nearly all the Web. vendors in the direction of TCP/IP as The Web is an example of a client/ the future of networking. server application. A human interacts The Internet’s marked success would with a Web browser (client) running on not alone be sufficient justification for a “local” machine. The Web browser organizing a survey around a single pro- communicates with a server on some tocol. Also important is that TCP pro- “remote” machine. The Web uses an ap- vides examples of many significant is- plication layer protocol called the Hy- sues that arise in transport protocol pertext Transfer Protocol (HTTP) [Bern- design. The design choices made in TCP ers-Lee et al.
Recommended publications
  • Solutions to Chapter 2

    Solutions to Chapter 2

    CS413 Computer Networks ASN 4 Solutions Solutions to Assignment #4 3. What difference does it make to the network layer if the underlying data link layer provides a connection-oriented service versus a connectionless service? [4 marks] Solution: If the data link layer provides a connection-oriented service to the network layer, then the network layer must precede all transfer of information with a connection setup procedure (2). If the connection-oriented service includes assurances that frames of information are transferred correctly and in sequence by the data link layer, the network layer can then assume that the packets it sends to its neighbor traverse an error-free pipe. On the other hand, if the data link layer is connectionless, then each frame is sent independently through the data link, probably in unconfirmed manner (without acknowledgments or retransmissions). In this case the network layer cannot make assumptions about the sequencing or correctness of the packets it exchanges with its neighbors (2). The Ethernet local area network provides an example of connectionless transfer of data link frames. The transfer of frames using "Type 2" service in Logical Link Control (discussed in Chapter 6) provides a connection-oriented data link control example. 4. Suppose transmission channels become virtually error-free. Is the data link layer still needed? [2 marks – 1 for the answer and 1 for explanation] Solution: The data link layer is still needed(1) for framing the data and for flow control over the transmission channel. In a multiple access medium such as a LAN, the data link layer is required to coordinate access to the shared medium among the multiple users (1).
  • Moving to Ipv6(PDF)

    Moving to Ipv6(PDF)

    1 Chicago, IL 9/1/15 2 Moving to IPv6 Mark Kosters, Chief Technology Officer With some help from Geoff Huston 3 The Amazing Success of the Internet • 2.92 billion users! • 4.5 online hours per day per user! • 5.5% of GDP for G-20 countries Just about anything about the Internet Time 3 4 Success-Disaster 5 The Original IPv6 Plan - 1995 Size of the Internet IPv6 Deployment IPv6 Transition – Dual Stack IPv4 Pool Size Time 6 The Revised IPv6 Plan - 2005 IPv4 Pool Size Size of the Internet IPv6 Transition – Dual Stack IPv6 Deployment 2004 2006 2008 2010 2012 Date 7 Oops! We were meant to have completed the transition to IPv6 BEFORE we completely exhausted the supply channels of IPv4 addresses! 8 Today’s Plan IPv4 Pool Size Today Size of the Internet ? IPv6 Transition IPv6 Deployment 0.8% Time 9 Transition... The downside of an end-to-end architecture: – There is no backwards compatibility across protocol families – A V6-only host cannot communicate with a V4-only host We have been forced to undertake a Dual Stack transition: – Provision the entire network with both IPv4 AND IPv6 – In Dual Stack, hosts configure the hosts’ applications to prefer IPv6 to IPv4 – When the traffic volumes of IPv4 dwindle to insignificant levels, then it’s possible to shut down support for IPv4 10 Dual Stack Transition ... We did not appreciate the operational problems with this dual stack plan while it was just a paper exercise: • The combination of an end host preference for IPv6 and a disconnected set of IPv6 “islands” created operational problems – Protocol
  • Routing Loop Attacks Using Ipv6 Tunnels

    Routing Loop Attacks Using Ipv6 Tunnels

    Routing Loop Attacks using IPv6 Tunnels Gabi Nakibly Michael Arov National EW Research & Simulation Center Rafael – Advanced Defense Systems Haifa, Israel {gabin,marov}@rafael.co.il Abstract—IPv6 is the future network layer protocol for A tunnel in which the end points’ routing tables need the Internet. Since it is not compatible with its prede- to be explicitly configured is called a configured tunnel. cessor, some interoperability mechanisms were designed. Tunnels of this type do not scale well, since every end An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 point must be reconfigured as peers join or leave the tun- network without prior configuration. This category includes nel. To alleviate this scalability problem, another type of ISATAP, 6to4 and Teredo. We present a novel class of tunnels was introduced – automatic tunnels. In automatic attacks that exploit vulnerabilities in these tunnels. These tunnels the egress entity’s IPv4 address is computationally attacks take advantage of inconsistencies between a tunnel’s derived from the destination IPv6 address. This feature overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a eliminates the need to keep an explicit routing table at vehicle for traffic amplification to facilitate DoS attacks. the tunnel’s end points. In particular, the end points do We exhibit five attacks of this class. One of the presented not have to be updated as peers join and leave the tunnel. attacks can DoS a Teredo server using a single packet. The In fact, the end points of an automatic tunnel do not exploited vulnerabilities are embedded in the design of the know which other end points are currently part of the tunnels; hence any implementation of these tunnels may be vulnerable.
  • Is QUIC a Better Choice Than TCP in the 5G Core Network Service Based Architecture?

    Is QUIC a Better Choice Than TCP in the 5G Core Network Service Based Architecture?

    DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2020 Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN Master in Communication Systems Date: November 22, 2020 Supervisor at KTH: Marco Chiesa Supervisor at Ericsson: Zaheduzzaman Sarker Examiner: Peter Sjödin School of Electrical Engineering and Computer Science Host company: Ericsson AB Swedish title: Är QUIC ett bättre val än TCP i 5G Core Network Service Based Architecture? iii Abstract The development of the 5G Cellular Network required a new 5G Core Network and has put higher requirements on its protocol stack. For decades, TCP has been the transport protocol of choice on the Internet. In recent years, major Internet players such as Google, Facebook and CloudFlare have opted to use the new QUIC transport protocol. The design assumptions of the Internet (best-effort delivery) differs from those of the Core Network. The aim of this study is to investigate whether QUIC’s benefits on the Internet will translate to the 5G Core Network Service Based Architecture. A testbed was set up to emulate traffic patterns between Network Functions. The results show that QUIC reduces average request latency to half of that of TCP, for a majority of cases, and doubles the throughput even under optimal network conditions with no packet loss and low (20 ms) RTT. Additionally, by measuring request start and end times “on the wire”, without taking into account QUIC’s shorter connection establishment, we believe the results indicate QUIC’s suitability also under the long-lived (standing) connection model.
  • Medium Access Control Layer

    Medium Access Control Layer

    Telematics Chapter 5: Medium Access Control Sublayer User Server watching with video Beispielbildvideo clip clips Application Layer Application Layer Presentation Layer Presentation Layer Session Layer Session Layer Transport Layer Transport Layer Network Layer Network Layer Network Layer Univ.-Prof. Dr.-Ing. Jochen H. Schiller Data Link Layer Data Link Layer Data Link Layer Computer Systems and Telematics (CST) Physical Layer Physical Layer Physical Layer Institute of Computer Science Freie Universität Berlin http://cst.mi.fu-berlin.de Contents ● Design Issues ● Metropolitan Area Networks ● Network Topologies (MAN) ● The Channel Allocation Problem ● Wide Area Networks (WAN) ● Multiple Access Protocols ● Frame Relay (historical) ● Ethernet ● ATM ● IEEE 802.2 – Logical Link Control ● SDH ● Token Bus (historical) ● Network Infrastructure ● Token Ring (historical) ● Virtual LANs ● Fiber Distributed Data Interface ● Structured Cabling Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 5: Medium Access Control Sublayer 5.2 Design Issues Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 5: Medium Access Control Sublayer 5.3 Design Issues ● Two kinds of connections in networks ● Point-to-point connections OSI Reference Model ● Broadcast (Multi-access channel, Application Layer Random access channel) Presentation Layer ● In a network with broadcast Session Layer connections ● Who gets the channel? Transport Layer Network Layer ● Protocols used to determine who gets next access to the channel Data Link Layer ● Medium Access Control (MAC) sublayer Physical Layer Univ.-Prof. Dr.-Ing. Jochen H. Schiller ▪ cst.mi.fu-berlin.de ▪ Telematics ▪ Chapter 5: Medium Access Control Sublayer 5.4 Network Types for the Local Range ● LLC layer: uniform interface and same frame format to upper layers ● MAC layer: defines medium access ..
  • Lecture 11: PKI, SSL and VPN Information Security – Theory Vs

    Lecture 11: PKI, SSL and VPN Information Security – Theory Vs

    Lecture 11: PKI, SSL and VPN Information Security – Theory vs. Reality 0368-4474-01, Winter 2011 Yoav Nir ©2011 Check Point Software Technologies Ltd. | [Restricted] ONLY for designated groups and individuals What is VPN ° VPN stands for Virtual Private Network ° A private network is pretty obvious – An Ethernet LAN running in my building – Wifi with access control – A locked door and thick walls can be access control – An optical fiber running between two buildings ©2011 Check Point Software Technologies Ltd. 2 What is a VPN ° What is a non-private network? – Obviously, someone else’s network. ° Obvious example: the Internet. ° The Internet is pretty fast, and really cheap. ° What do I do if I have offices in several cities – And people working from home – And sales people working from who knows where ° We could use the Internet, but… – People could see my data – People could modify my messsages – People could pretend to be other people ©2011 Check Point Software Technologies Ltd. 3 What is a VPN ° I could run my own cables around the world. ° I could buy an MPLS connection from a local telco – Bezeq would love to sell me one. They call it IPVPN, and it’s pretty much a switched link just for my company – But I can’t get that to the home or mobile users – And it’s mediocre (but consistent) speed – And Bezeq can still do whatever it wants – And it’s really expensive – The incremental cost of using the Internet is zero ° A virtual private network combines the relative low-cost of using the Internet with the privacy of a leased line.
  • Chapter 3 Transport Layer

    Chapter 3 Transport Layer

    Chapter 3 Transport Layer A note on the use of these Powerpoint slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you see the animations; and can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: Computer § If you use these slides (e.g., in a class) that you mention their source (after all, we’d like people to use our book!) Networking: A Top § If you post any slides on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this Down Approach material. 7th edition Thanks and enjoy! JFK/KWR Jim Kurose, Keith Ross All material copyright 1996-2016 Pearson/Addison Wesley J.F Kurose and K.W. Ross, All Rights Reserved April 2016 Transport Layer 2-1 Chapter 3: Transport Layer our goals: § understand principles § learn about Internet behind transport transport layer protocols: layer services: • UDP: connectionless • multiplexing, transport demultiplexing • TCP: connection-oriented • reliable data transfer reliable transport • flow control • TCP congestion control • congestion control Transport Layer 3-2 Chapter 3 outline 3.1 transport-layer 3.5 connection-oriented services transport: TCP 3.2 multiplexing and • segment structure demultiplexing • reliable data transfer 3.3 connectionless • flow control transport: UDP • connection management 3.4 principles of reliable 3.6 principles
  • Guidelines for the Secure Deployment of Ipv6

    Guidelines for the Secure Deployment of Ipv6

    Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
  • Ipsec and IKE Administration Guide

    Ipsec and IKE Administration Guide

    IPsec and IKE Administration Guide Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A. Part No: 816–7264–10 April 2003 Copyright 2003 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, docs.sun.com, AnswerBook, AnswerBook2, SunOS, Sun ONE Certificate Server, and Solaris are trademarks, registered trademarks, or service marks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and Sun™ Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements.
  • QUIC Record Layer

    QUIC Record Layer

    A Security Model and Fully Verified Implementation for the IETF QUIC Record Layer Antoine Delignat-Lavaud∗, Cédric Fournet∗, Bryan Parnoy, Jonathan Protzenko∗, Tahina Ramananandro∗, Jay Bosamiyay, Joseph Lallemandz, Itsaka Rakotonirinaz, Yi Zhouy ∗Microsoft Research yCarnegie Mellon University zINRIA Nancy Grand-Est, LORIA Abstract—Drawing on earlier protocol-verification work, we investigate the security of the QUIC record layer, as standardized Application Application by the IETF in draft version 30. This version features major HTTP/2 HTTP/3 differences compared to Google’s original protocol and early IETF drafts. It serves as a useful test case for our verification TLS QUIC methodology and toolchain, while also, hopefully, drawing atten- tion to a little studied yet crucially important emerging standard. TCP UDP We model QUIC packet and header encryption, which uses IP IP a custom construction for privacy. To capture its goals, we propose a security definition for authenticated encryption with Fig. 1: Modularity of current networking stack vs. QUIC semi-implicit nonces. We show that QUIC uses an instance of a generic construction parameterized by a standard AEAD-secure scheme and a PRF-secure cipher. We formalize and verify the it is possible to combine both features in a single message, security of this construction in F?. The proof uncovers interesting saving a full network round-trip. limitations of nonce confidentiality, due to the malleability of short From a security standpoint, a fully-integrated secure trans- headers and the ability to choose the number of least significant port protocol offers the potential for a single, clean security bits included in the packet counter.
  • An Introduction to the Identifier-Locator Network Protocol (ILNP)

    An Introduction to the Identifier-Locator Network Protocol (ILNP)

    An Introduction to the Identifier-Locator Network Protocol (ILNP) Presented by Joel Halpern Material prepared by Saleem N. Bhatti & Ran Atkinson https://ilnp.cs.st-andrews.ac.uk/ IETF102, Montreal, CA. (C) Saleem Bhatti, 21 June 2018. 1 Thanks! • Joel Halpern: presenting today! • Ran Atkinson: co-conspirator. • Students at the University of St Andrews: • Dr Ditchaphong Phoomikiatissak (Linux) • Dr Bruce Simpson (FreeBSD, Cisco) • Khawar Shezhad (DNS/Linux, Verisign) • Ryo Yanagida (Linux, Time Warner) • … many other students on sub-projects … • IRTF (Routing RG, now concluded) • Discussions on various email lists. IETF102, Montreal, CA. (C) Saleem Bhatti, 21 June 2018. 2 Background to Identifier-Locator IETF102, Montreal, CA. (C) Saleem Bhatti, 21 June 2018. 3 “IP addresses considered harmful” • “IP addresses considered harmful” Brian E. Carpenter ACM SIGCOMM CCR, vol. 44, issue 2, Apr 2014 http://dl.acm.org/citation.cfm?id=2602215 http://dx.doi.org/10.1145/2602204.2602215 • Abstract This note describes how the Internet has got itself into deep trouble by over-reliance on IP addresses and discusses some possible ways forward. IETF102, Montreal, CA. (C) Saleem Bhatti, 21 June 2018. 4 RFC2104 (I), IAB, Feb 1997 • RFC2104, “IPv4 Address Behaviour Today”. • Ideal behaviour of Identifiers and Locators: Identifiers should be assigned at birth, never change, and never be re-used. Locators should describe the host's position in the network's topology, and should change whenever the topology changes. Unfortunately neither of the these ideals are met by IPv4 addresses. IETF102, Montreal, CA. (C) Saleem Bhatti, 21 June 2018. 5 RFC6115 (I), Feb 2011 • RFC6115, “Recommendation for a Routing Architecture”.
  • Secure Socket Layer Transport Layer Security

    Secure Socket Layer Transport Layer Security

    VPN Secure Socket Layer Transport Layer Security Mureed HUSSAIN, Ahmed MEHAOUA, Dominique SERET Technologies VPN Communication layers Security protocols Application layer ssh, S/MIME, PGP Transport layer SSL, TLS, WTLS Network layer IPsec MPLS Data Link layer PPTP, L2TP Physical layer Scrambling, Hopping, Quantum Communications 1 Agenda • Introduction – Motivation, evolution, standardization – Applications • SSL Protocol – SSL phases and services – Sessions and connections – SSL protocols and layers • SSL Handshake protocol • SSL Record protocol / layer • SSL solutions and products • Conclusion Sécurisation des échanges • Pour sécuriser les échanges ayant lieu sur le réseau Internet, il existe plusieurs approches : - niveau applicatif (PGP) - niveau réseau (protocole IPsec) - niveau physique (boîtiers chiffrant). • TLS/SSL vise à sécuriser les échanges au niveau de la couche Transport. • Application typique : sécurisation du Web 2 Transport Layer Security • Advantages – Does not require enhancement to each application – NAT friendly – Firewall Friendly • Disadvantages – Embedded in the application stack (some mis-implementation) – Protocol specific --> need to duplicated for each transport protocol – Need to maintain context for connection (not currently implemented for UDP) – Doesn’t protect IP adresses & headers Security-Sensitive Web Applications • Online banking • Online purchases, auctions, payments • Restricted website access • Software download • Web-based Email • Requirements – Authentication: Of server, of client, or (usually)