Shaping DNS Security with Curves a Comparative Security Analysis of DNSSEC and Dnscurve

Total Page:16

File Type:pdf, Size:1020Kb

Shaping DNS Security with Curves a Comparative Security Analysis of DNSSEC and Dnscurve Eindhoven University of Technology MASTER Shaping DNS security with curves a comparative security analysis of DNSSEC and DNSCurve van Tilborg, H.H.A. Award date: 2010 Link to publication Disclaimer This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain SHAPING DNS SECURITY WITH CURVES ACOMPARATIVE SECURITY ANALYSIS OF DNSSEC AND DNSCURVE Master Thesis Coding Theory and Cryptology Department of Mathematics and Computer Science Eindhoven University of Technology Author: Committee: ing. Harm H.A. VAN TILBORG dr. D.S. JARNIKOV drs. J. SCHEERDER dr. B. SˇKORIC´ Graduation tutor: dr. B.M.M. DE WEGER drs. J. SCHEERDER Graduation supervisor: dr. B.M.M. DE WEGER August 2010 ii Contents Glossary vii Acknowledgments xi List of Figures xiii List of Tables xv 1 Introduction1 1.1 Previous Work...........................2 1.2 Problem Statement........................2 1.3 Results...............................3 2 Domain Name System (DNS)5 2.1 Introduction............................5 2.1.1 Telephone Numbering System..............5 2.1.2 Hierarchical Distributed Database............7 2.2 History...............................8 2.3 Specification...........................9 2.3.1 Domain Names...................... 10 2.3.2 Separation of Duties................... 11 2.3.3 Traversal......................... 12 2.3.4 Topology......................... 13 2.3.5 Technical Details..................... 16 2.4 Security.............................. 24 2.4.1 Introduction....................... 24 2.4.2 Passive Attacks...................... 25 2.4.3 Active Attacks....................... 25 2.4.4 Passive Cache Poisoning................. 26 2.4.5 Identifier Guessing and Query Prediction........ 27 2.4.6 Active Cache Poisoning.................. 29 2.4.7 Amplification Attack................... 31 2.4.8 Hierarchical Trust.................... 32 iii 2.4.9 Other Attacks....................... 32 2.4.10 Summary......................... 33 3 DNS Security Extensions (DNSSEC) 35 3.1 Introduction............................ 35 3.1.1 Terminology........................ 36 3.2 History............................... 38 3.3 Objectives............................. 39 3.3.1 Origin Authentication of DNS data........... 39 3.3.2 Data Integrity....................... 40 3.3.3 Authenticated Denial of Existence............ 40 3.3.4 Backwards Compatibility with Regular DNS...... 40 3.3.5 Non-Objectives...................... 41 3.4 Specification........................... 41 3.4.1 Resource Records..................... 42 3.4.2 Cryptographic Primitives................. 46 3.4.3 Key Usage......................... 49 3.4.4 Traversal......................... 50 3.4.5 Topology......................... 55 3.4.6 Data Managers...................... 59 3.5 Security.............................. 61 3.5.1 Passive Attacks...................... 61 3.5.2 Active Attacks....................... 62 3.5.3 Passive Cache Poisoning................. 63 3.5.4 Identifier Guessing and Query Prediction........ 63 3.5.5 Active Cache Poisoning.................. 65 3.5.6 Amplification Attack................... 67 3.5.7 Hierarchical Trust.................... 68 3.5.8 Other Attacks....................... 69 3.5.9 Timing Attacks...................... 70 3.5.10 Replay Attacks...................... 70 3.5.11 NSEC Related Attacks.................. 72 3.5.12 Summary......................... 73 4 DNSCurve 75 4.1 Introduction............................ 75 4.2 History............................... 75 4.3 Objectives............................. 76 4.3.1 Confidentiality...................... 76 4.3.2 Integrity.......................... 76 4.3.3 Availability........................ 77 4.3.4 Non-Objectives...................... 77 4.4 Specification........................... 78 4.4.1 Protocol.......................... 78 iv 4.4.2 Cryptographic Primitives................. 85 4.4.3 Key Usage......................... 89 4.4.4 Traversal......................... 90 4.4.5 Topology......................... 93 4.4.6 Data Managers...................... 96 4.5 Security.............................. 98 4.5.1 Passive Attacks...................... 99 4.5.2 Active Attacks....................... 99 4.5.3 Passive Cache Poisoning................. 100 4.5.4 Identifier Guessing and Query Prediction........ 101 4.5.5 Active Cache Poisoning.................. 102 4.5.6 Amplification Attack................... 102 4.5.7 Hierarchical Trust.................... 103 4.5.8 Other Attacks....................... 103 4.5.9 Timing Attacks...................... 104 4.5.10 Replay Attacks...................... 104 4.5.11 NSEC Related Attacks.................. 105 4.5.12 CPU Exhaustion Attacks................. 106 4.5.13 Summary......................... 106 4.6 Comparison with DNSSEC.................... 108 4.7 Combining with DNSSEC.................... 111 4.7.1 DNSCurve Bottom-Up – DNSSEC Top-Down Approach 111 4.7.2 Merging of DNSSEC and DNSCurve........... 114 5 Curving in Practice 117 5.1 Introduction............................ 117 5.2 Implementation.......................... 118 5.2.1 Design........................... 118 5.2.2 Technology........................ 122 5.2.3 Implementation...................... 127 5.2.4 Testing........................... 129 5.3 Deployment............................ 130 5.3.1 Speeding up Deployment................ 130 5.3.2 Deployment Process................... 131 5.4 Performance............................ 132 5.4.1 Benchmark Tools..................... 132 5.4.2 Benchmark Setup..................... 137 5.5 Results............................... 141 5.5.1 Regular DNS Performance................ 141 5.5.2 Comparative DNS and DNSCurve Performance.... 142 5.5.3 Shared Secret Caching Performance.......... 147 5.5.4 CPU Usage Benchmark.................. 149 6 Conclusion 153 v A Performance Results 155 A.1 Comparative DNS and DNSCurve................ 155 A.2 Shared Secret Caching...................... 157 Bibliography 159 vi Glossary API Application Programming Interface. A defined interface that makes computer programs (or: applications) able to communicate with each other. Note this communication can also take place over a network, such as the Internet. byte To avoid ambiguity, a ‘byte’ stands for an ordered collection of 8 bits in this thesis. daemon A computer program that is constantly running in the background of a system. Usually waiting for input or requests to be handled and answered. DNSSEC Domain Name System Security Extensions and an extension to the regular Domain Name System to provide integrity. domain A domain represents a human readable identifying name on the Internet. If example.org is a domain, this means sub.example.org and www.sub.example.org are considered to be in the same domain. A do- main is the superset of a zone. DoS Denial of Service. Type of attack that influences the availability of a system. IETF Internet Engineering Task Force. Open standards organization of the Internet. The IETF facilitates the process of developing new RFCs, from drafting and reviewing, until testing and publishing. IP Internet Protocol. This is the layer between the Internet’s network layer and link layer. It also facilitates the addressing of networks and hosts around the Internet. There are two branches of IP: IPv4 and IPv6. The biggest difference between the two is the addressing space. IPv4 offers space for 232 hosts, while IPv6 can address 2128 hosts. ISP Internet Service Provider. Often a commercial company that facilitates connections towards the Internet for private persons or organizations. vii KSK Key Signing Key. Key that is used to authenticate other (usually zone signing) keys. Generally located in the same zone as the keys it au- thenticates. See also ZSKs. LAN Local Area Network. A network that connects hosts that are physically relatively close to each other, for example in one’s home, an office, or a group of buildings. Opposite of WAN. MAC Message Authentication Code. Also known as keyed cryptographic hash function. Hash function that together with a secret key can gen- erate a fixed size string that provides data integrity and authenticity of an arbitrary length piece of data. NaCl Networking and Cryptographic library, pronounced as ‘salt’. Library that implements all DNSCurve used cryptographic primitives used by DNSCurve. nonce Number used ONCE. An arbitrary number of cryptographically ran- dom bytes, used to guarantee freshness in (security) protocols, pre- venting replay attacks. POSIX Portable Operating System Interface for Unix. A family of stan- dards developed by the IEEE to accommodate a general application programming interface between user space and an operating system kernel. Originally focused
Recommended publications
  • Domain Name System 1 Domain Name System
    Domain Name System 1 Domain Name System The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. A Domain Name Service translates queries for domain names (which are easier to understand and utilize when accessing the internet) into IP addresses for the purpose of locating computer services and devices worldwide. An often-used analogy to explain the Domain Name System is that it serves as the phone book for the Internet by translating human-friendly computer hostnames into IP addresses. For example, the domain name www.example.com translates to the addresses 192.0.43.10 (IPv4) and 2620:0:2d0:200::10 (IPv6). The Domain Name System makes it possible to assign domain names to groups of Internet resources and users in a meaningful way, independent of each entity's physical location. Because of this, World Wide Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device. Internet domain names are easier to remember than IP addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). Users take advantage of this when they recite meaningful Uniform Resource Locators (URLs) and e-mail addresses without having to know how the computer actually locates them. The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain.
    [Show full text]
  • DNS Performance – a Study of Free, Public and Popular DNS Servers in 2019
    Linköping University | Department of Computer and Information Science Bachelor’s thesis, 16 ECTS | Informationsteknologi 2019 | LIU-IDA/LITH-EX-G--19/037--SE DNS Performance – A study of free, public and popular DNS servers in 2019 DNS prestanda – En studie av gratis, publika och populära DNS servrar år 2019 Filip Ström Felix Zedén Yverås Supervisor : Niklas Carlsson Examiner : Marcus Bendtsen Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se Upphovsrätt Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer- ingsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko- pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis- ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker- heten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dok- umentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för up- phovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/. Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.
    [Show full text]
  • NSA's MORECOWBELL
    NSA's MORECOWBELL: Knell for DNS Christian Grothoff Matthias Wachs Monika Ermert Jacob Appelbaum Inria TU Munich Heise Verlag Tor Project 1 Introduction On the net, close to everything starts with a request to the Domain Name System (DNS), a core Internet protocol to allow users to access Internet services by names, such as www.example.com, instead of using numeric IP addresses, like 2001:DB8:4145::4242. Developed in the \Internet good old times" the contemporary DNS is like a large network activity chart for the visually impaired. Consequently, it now attracts not only all sorts of commercially-motivated surveillance, but, as new documents of the NSA spy program MORECOWBELL confirm, also the National Security Agency. Given the design weaknesses of DNS, this begs the question if DNS be secured and saved, or if it has to be replaced | at least for some use cases. In the last two years, there has been a flurry of activity to address security and privacy in DNS at the Internet Engineering Task Force (IETF), the body that documents the DNS standards. The Internet Architecture Board, peer body of the IETF, just called on the engineers to use encryption everywhere, possibly including DNS. [4] A recent draft [6] by the IETF on DNS privacy starts by acknowledging that the DNS \... is one of the most important infrastructure components of the Internet and one of the most often ignored or misunderstood. Almost every activity on the Internet starts with a DNS query (and often several). Its use has many privacy implications ..." Despite seemingly quick consensus on this assessment, the IETF is not expecting that existing industry solutions will change the situation anytime soon: \It seems today that the possibility of massive encryption of DNS traffic is very remote." [5] From a surveillance perspective, DNS currently treats all information in the DNS database as public data.
    [Show full text]
  • Design of a Reactive DNS Measurement System
    Design of a Reactive DNS Measurement System Jochem Braakhuis 13-07-2021, University of Twente [email protected] Abstract—For speed, robustness and safety of the Internet, it is will then delegate the query to the appropriate top-level domain important that information on name servers in every level of the name server dependent on the entered domain (.com, .org, .nl). hierarchical DNS structure is accurate and consistent. OpenIN- Then, the top-level domain name server will in turn delegate TEL, designed in 2016, measures about half of the global names- the query to the authoritative name server for the entered pace every day, but lacks flexibility in reactive measurement. To domain, which finally returns the IP address of the domain’s provide an easily scalable framework for performing research server to the user, or delegate it to authoritative name servers in DNS inconsistencies, we designed and tested a reactive DNS measurement system compatible with OpenINTEL, supported by for further sub-domains. Section II further elaborates on this Apache Kafka message broker functionality. The software can process. query multiple levels in the DNS hierarchy and supports 10 query In addition to storing the IP addresses of name servers types. Initial high-volume testing of the resolver authoritative level shows the software is able to handle large volumes of and domains, name servers also contain other records about queries, but only gives a lower bound on the performance of the domains in their zone. For example, MX records contain the software. Testing of more authoritative levels, testing on purpose- domain names of the servers that handle email traffic for the built hardware and implementation of extended decoder logic and domain, and their priority.
    [Show full text]
  • How Linux Containers Have Evolved Daniel Walsh 11 Containers Have Come a Long Way in the Past Few Years
    . ........ .... ... .. .. .. ... .. OPENSOURCE.COM Opensource.com publishes stories about creating, adopting, and sharing open source solutions. Visit Opensource.com to learn more about how the open source way is improving technologies, education, business, government, health, law, entertainment, humanitarian efforts, and more. Submit a story idea: https://opensource.com/story Email us: [email protected] Chat with us in Freenode IRC: #opensource.com . OPEN SOURCE YEARBOOK 2017 . OPENSOURCE.COM 3 ............................. AUTOGRAPHS . .... ... .. .. .. ........ ... .. ............................. AUTOGRAPHS . .... ... .. .. .. ........ ... .. OPENSOURCE.COM............................. ........ WRITE FOR US ................... 7 big reasons to contribute to Opensource.com: Career benefits: “I probably would not have gotten my most recent job if it had not been for my articles on 1 Opensource.com.” Raise awareness: “The platform and publicity that is available through Opensource.com is extremely 2 valuable.” Grow your network: “I met a lot of interesting people after that, boosted my blog stats immediately, and 3 even got some business offers!” Contribute back to open source communities: “Writing for Opensource.com has allowed me to give 4 back to a community of users and developers from whom I have truly benefited for many years.” Receive free, professional editing services: “The team helps me, through feedback, on improving my 5 writing skills.” We’re loveable: “I love the Opensource.com team. I have known some of them for years and they are 6 good people.” 7 Writing for us is easy: “I couldn't have been more pleased with my writing experience.” Email us to learn more or to share your feedback about writing for us: https://opensource.com/story Visit our Participate page to more about joining in the Opensource.com community: https://opensource.com/participate Find our editorial team, moderators, authors, and readers on Freenode IRC at #opensource.com: https://opensource.com/irc .
    [Show full text]
  • CS 43: Computer Networks
    CS 43: Computer Networks 10: Naming and DNS September 24, 2018 Last class • Distributed systems architectures – Client-Server – Peer-to-Peer • Challenges in design – Partial failures – Event ordering Lecture 10 - Slide 2 Today • Identifiers and addressing • Domain Name System – History – Query sequences – Record types – Load balancing Lecture 10 - Slide 3 DNS: domain name system People: many identifiers: – SSN, name, passport # Internet hosts, routers: – IP address (32 bit) - used for addressing datagrams – “name”, e.g., www.google.com - used by humans How do we map between IP address and name, and vice versa ? Lecture 10 - Slide 4 DNS: domain name system • distributed database implemented in hierarchy of many name servers. • application-layer protocol: hosts, name servers communicate to resolve names à addresses – note: core Internet function, implemented as application-layer protocol – complexity at network’s “edge” Lecture 10 - Slide 5 Recall: TCP/IP Protocol Stack host host HTTP Application Layer HTTP TCP Transport Layer TCP router router IP IP Network Layer IP IP Ethernet Ethernet SONET SONET Ethernet Ethernet interface interface interface Link Layerinterface interface interface Lecture 10 - Slide 6 Recall: TCP/IP Protocol Stack host host HTTP Human-readable strings: www.example.com HTTP TCP (Not much addressing here, ports to ID socket) TCP router router IP IP addressesIP (32-bit IPv4, 128-bitIP IPv6) IP Ethernet Ethernet SONET SONET Ethernet Ethernet interface (Networkinterface dependent)interface Ethernet:interface 48-bit MACinterface address interface Lecture 10 - Slide 7 Why do we need to map names to IP addresses? Why not route on names at the network layer? A. Domain names are hierarchical, so we can route on domain names too.
    [Show full text]
  • DNS for Rocket Scientists Section 1 Overview
    DNS for Rocket Scientists This Open Source Guide is about DNS and (mostly) BIND 9.x on Linux (REDHAT Versions 6.x and 7.x) and the BSD's (FreeBSD, OpenBSD and NetBSD). It is meant for newbies, Rocket Scientist wannabees and anyone in between. This Guide was born out of our first attempts a number of years ago at trying to install a much needed DNS service on an early Redhat Linux system. We completed the DNS 'rite of passage' and found it a pretty unedifying and pointless experience. Health Warning: This is still a work-in-progress. If you have expertise in something - contribute some text. If you find errors don't grumble - tell us. Look at our to do list and if you want to contribute something please do so. And for all that hard work we promise only a warm sense of well-being and an acknowledgment of your work in the licence. Section 1 Overview What's new in Guide version 0.1.27 1. Boilerplate and Terminology 1.1 Objectives and Scope 1.2 How to read this Guide 1.3 Terminology and Conventions used 1.4 Acknowledgements 1.5 Copyright and License 2. DNS - Overview 2.1 A brief History of Name Servers 2.2 DNS Concepts & Implementation 2.2.1 DNS Overview 2.2.2 Domains and Delegation 2.2.3 DNS Organization and Structure 2.2.4 DNS System Components 2.2.5 Zones and Zone Files 2.2.6 DNS Queries 2.2.6.1 Recursive Queries 2.2.6.2 Iterative Queries 2.2.6.3 Inverse Queries 2.2.7 Zone Updates 2.2.7.1 Full Zone Transfer (AXFR) 2.2.7.2 Incremental Zone Transfer (IXFR) 2.2.7.3 Notify (NOTIFY) 2.2.7.4 Dynamic Zone Updates 2.2.7.5 Alternative Dynamic DNS Approaches 2.3 DNS Security Overview 2.3.1 Security Threats 2.3.2 Security Types 2.3.3 Local Security 2.3.4 Server-Server (TSIG Transactions) 2.3.5 Server-Client (DNSSEC) 3.
    [Show full text]
  • DNS-Sicherheit Am Beispiel Eines Mittelständischen Softwareunternehmens
    Bachelorarbeit Kevin Hüsgen DNS-Sicherheit am Beispiel eines mittelständischen Softwareunternehmens Fakultät Technik und Informatik Faculty of Computer Science and Engineering Department Informatik Department Computer Science Kevin Hüsgen DNS-Sicherheit am Beispiel eines mittelständischen Softwareunternehmens Bachelorarbeit eingereicht im Rahmen der Bachelorprüfung im Studiengang Bachelor of Science Angewandte Informatik am Department Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg Betreuender Prüfer: Prof. Dr.-Ing. Martin Hübner Zweitgutachter: Prof. Dr. Klaus-Peter Kossakowski Eingereicht am: 08.12.2020 Kevin Hüsgen Thema der Arbeit DNS-Sicherheit am Beispiel eines mittelständischen Softwareunternehmens Stichworte DNS, IT-Sicherheit, IT-Grundschutz, DNSSEC, DNS-over-TLS, DNS-over-HTTPS, Be- drohungsanalyse, Risikoanalyse, DNS-Sicherheit, DNSCurve, DNS-Cookies, TSIG, DoT, DoH Kurzzusammenfassung Das Ziel dieser Forschungsarbeit ist es, die Sicherheit von DNS anhand eines fiktiven, mit- telständischen Softwareunternehmens aus der Versicherungsbranche zu analysieren. Dazu werden die Schwachstellen, Bedrohungen und Angriffe beim Betrieb von DNS analysiert und die Risiken für das Unternehmen evaluiert. Es werden DNS-Sicherheitserweiterungen vorgestellt und die identifizierten Bedrohungen im Hinblick auf diese überprüft. Ein Maß- nahmenkatalog wurde erarbeitet, um die Risiken zu vermeiden oder zu reduzieren. Zum Schluss werden Empfehlungen ausgesprochen und im Bezug auf das Anwendungsszenario
    [Show full text]
  • DNS and BIND
    DNS and BIND David White DNS: Backbone of the Internet • Translates Domains into unique IP Addresses – i.e. “developcents.com” = “66.228.59.103” • Distributed Database of Host Information • Works seamlessly “behind the scenes” So what is a “Domain”? • RFC 920: Domains are Administrative entities • A unique name • Can contain subdomain names Basic Structure • Hierarchical, Tree-like structure • Made up of individual Nodes DNS: Series of Delegated Information A Silly Example… checkers.boardgames.games.fun.com checkers.boardgames.games.fun.com . (root) .games .boardgames .com .fun Domain Namespace: Another Picture This “tree” is also called a “domain namespace.” root (.) com edu google developcents taylor server1 server2 Components of DNS • Domain Name Space • Name Servers (Authoritative Name Servers) • Resolvers (Caching Name Servers) DNS Zones • A portion of a Domain Namespace defined by Zone Files (which contain Zone Records) • Portion of a Domain Namespace that has been administratively delegated • … Therefore, this information comes from an authoritative source (Master Name Server) • Can be loaded by Slave Name Servers (for backup and redundancy purposes) Components of Zone Files • TTL (Time to Live) – Tells caching nameservers how long they should cache information from an authoritative source • The domain administrator’s contact information • DNS Records Common DNS Records (Resource Records) • SOA Record (Start of Authority) – Indicates that the nameserver is the best source of info for data within a domain’s zone • A Record (Address) – Directly maps a name to an IP address • MX Record (Mail Exchanger) – Specifies which servers receive email for a domain (and in what order they should be tried) Common DNS Records (Resource Records) • NS Records (nameserver) – Required – Identify which servers are a particular zone’s nameservers – Does NOT have to be the same as the zone’s domain Glue Records: What and Why? • Solve a circular dependency problem: – The TLD delegates DNS requests for “example.com” to the particular authoritative name servers for example.com.
    [Show full text]
  • Naming and DNS
    CS 43: Computer Networks Naming and DNS Kevin Webb Swarthmore College September 21, 2017 Agenda • Identifiers and addressing • Domain Name System – History – Query sequences – Record types – Load balancing Recall: TCP/IP Protocol Stack host host HTTP Application Layer HTTP TCP Transport Layer TCP router router IP IP Network Layer IP IP Ethernet Ethernet SONET SONET Ethernet Ethernet interface interface interfaceLink Layerinterface interface interface Recall: TCP/IP Protocol Stack host host HTTP Human-readable strings: www.example.com HTTP TCP (Not much addressing here, ports to ID socket) TCP router router IP IP addressesIP (32-bit IPv4, 128-bitIP IPv6) IP Ethernet Ethernet SONET SONET Ethernet Ethernet interface (Networkinterface dependent)interface Ethernet:interface 48-bit MACinterface address interface Identifiers • Host name (e.g., www.swarthmore.edu) – Used by humans to specify host of interest – Unique, selected by host administrator – Hierarchical, variable-length string of alphanumeric characters • IP address (e.g., 130.58.68.164) – Used by routers to forward packets – Unique, topologically meaningful locator – Hierarchical namespace of 32 bits • MAC address (e.g., D8:D3:85:94:5F:1E) – Used by network adaptors to identify interesting frames – Unique, hard-coded identifier burned into network adaptor – Flat name space (of 48 bits in Ethernet) What’s in a name? • Host name: web.cs.swarthmore.edu – Domain: registrar for each top-level domain (e.g., .edu) – Host name: local administrator assigns to each host • IP addresses: 130.58.68.164
    [Show full text]
  • Securing Communication
    news from leading universities and research institutes in the Netherlands reSearcherS • Daniel J. Bernstein, Eindhoven University of Technology, the Netherlands, and University of Illinois at Chicago, USA • Tanja Lange, Eindhoven University of Technology, the Netherlands • Peter Schwabe, Academia Sinica, Taiwan. High-security and high-speed protection for computer networks Securing communication Internet and mobile communication has become a vital part of our lives in the past decade, but almost all of it is exposed to criminals. Researchers at the Eindhoven University of Technology have developed a new cryptographic library that is fast enough to allow universal deployment of high-security encryption. We often assume that communication downloading a game from an online These essential requirements over the internet is just as secure store. Users begin by accessing the of communication over computer as traditional forms of personal online store, and want to be sure that networks are ensured through communication. We assume that we they are in fact accessing the right cryptographic protection. Encryption know who we are communicating website and not a look-alike that will is what provides communication with; we assume our conversations are take their money but not let them with confidentiality, the assurance private, that only the person we talk download the software. Users then that transmitted information is only to can hear what we are saying; and submit their credit-card details or other read by the recipient and not by we assume that what we are saying banking information, and want to be an eavesdropper. Authentication will reach the recipient without being sure that this information is protected of users and data is provided by modified.
    [Show full text]
  • An Introduction to Computer Networks (Week 4) Stanford Univ CS144 Fall 2012
    An Introduction to Computer Networks (week 4) Stanford Univ CS144 Fall 2012 PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Thu, 11 Oct 2012 19:28:39 UTC Contents Articles Names and addresses 1 Address Resolution Protocol 1 Dynamic Host Configuration Protocol 6 Domain Name System 18 IPv4 31 IPv6 41 Network address translation 54 Ebooks Dedicated to Richard Beckett 64 References Article Sources and Contributors 65 Image Sources, Licenses and Contributors 67 Article Licenses License 68 1 Names and addresses Address Resolution Protocol Address Resolution Protocol (ARP) is a telecommunications protocol used for resolution of network layer addresses into link layer addresses, a critical function in multiple-access networks. ARP was defined by RFC 826 in 1982.[1] It is Internet Standard STD 37. It is also the name of the program for manipulating these addresses in most operating systems. ARP has been implemented in many combinations of network and overlaying internetwork technologies, such as IPv4, Chaosnet, DECnet and Xerox PARC Universal Packet (PUP) using IEEE 802 standards, FDDI, X.25, Frame Relay and Asynchronous Transfer Mode (ATM), IPv4 over IEEE 802.3 and IEEE 802.11 being the most common cases. In Internet Protocol Version 6 (IPv6) networks, the functionality of ARP is provided by the Neighbor Discovery Protocol (NDP). Operating scope The Address Resolution Protocol is a request and reply protocol that runs encapsulated by the line protocol. It is communicated within the boundaries of a single network, never routed across internetwork nodes. This property places ARP into the Link Layer of the Internet Protocol Suite, while in the Open Systems Interconnection (OSI) model, it is often described as residing between Layers 2 and 3, being encapsulated by Layer 2 protocols.
    [Show full text]