CS 5565 Network Architecture and Protocols Lecture 8 Godmar Back
Announcements Problem Set 1 due Feb 18 Project 1A due Feb 19 Problem Set 2 due Mar 18 Submission website open – test it! Next week: guest lectures: Monday: Dr. Butt on Distributed Storage Wednesday: Dr. Feng on High-Perf Networking Required Reading: research paper, see website CS 5565 Spring 2009 6/12/2018
Application Protocols Part 2: DNS
DNS: Summary so far Performs core network function, but implemented at application layer Not just name resolution, but generic database Example of distributed system: Partitions database hierarchically using domain suffixes; authoritative servers for each level Uses caching via local name servers Simple request/response protocol Only 1 message type for either query/reply CS 5565 Spring 2009 6/12/2018
Recursive vs. Iterative Queries root DNS server a.root-servers.net 2 TLD DNS server a3.nstld.com 3 Host at gback.cs.vt.edu wants IP address for godmar.stanford.edu Sends recursive query to voodoo Voodoo performs iterative queries 4 5 local DNS server voodoo.slo.cs.vt.edu 7 6 1 8 authoritative DNS server Argus.stanford.edu requesting host gback.cs.vt.edu godmar.stanford.edu CS 5565 Spring 2009 6/12/2018
RR format: (name, value, class, type, ttl) DNS Resource Records DNS: distributed DB storing resource records (RR) Example (dig output format) RR format: (name, value, class, type, ttl) a.root-servers.net. 79612 IN A 198.41.0.4 name ttl in secs class IN=Internet type value CS 5565 Spring 2009 6/12/2018
DNS Message Header DNS protocol : query and reply messages, both with same message format msg header identification: 16 bit # for query, reply to query uses same # flags: query or reply recursion desired recursion available reply is authoritative status code CS 5565 Spring 2009 6/12/2018
DNS Message Body Name, type fields for a query RRs in response to query records for authoritative servers additional “helpful” info that may be used CS 5565 Spring 2009 6/12/2018
The dig Command CS 5565 Spring 2009 6/12/2018 $ dig cs.vt.edu mx ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1535 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;cs.vt.edu. IN MX ;; ANSWER SECTION: cs.vt.edu. 14235 IN MX 10 stinger.cs.vt.edu. cs.vt.edu. 14235 IN MX 0 infernus.cs.vt.edu. ;; ADDITIONAL SECTION: stinger.cs.vt.edu. 14235 IN A 128.173.40.26 infernus.cs.vt.edu. 14235 IN A 128.173.40.25 ;; Query time: 1 msec ;; SERVER: 192.168.200.25#53(192.168.200.25) ;; WHEN: Mon Feb 7 10:59:08 2005 ;; MSG SIZE rcvd: 108 CS 5565 Spring 2009 6/12/2018
dig (2) $ dig @nomen.cns.vt.edu cs.vt.edu ns ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27887 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;cs.vt.edu. IN NS ;; AUTHORITY SECTION: vt.edu. 14400 IN SOA lacewing.cns.vt.edu. hostmaster.vt.edu. 200502032 3600 900 604800 14400 ;; Query time: 2 msec ;; SERVER: 198.82.247.37#53(nomen.cns.vt.edu) ;; WHEN: Mon Feb 7 15:24:57 2005 ;; MSG SIZE rcvd: 87 CS 5565 Spring 2009 6/12/2018
dig vt.edu ns (1) CS 5565 Spring 2009 6/12/2018 $ dig vt.edu ns ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59631 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5 ;; ANSWER SECTION: vt.edu. 13872 IN NS nomen.cns.vt.edu. vt.edu. 13872 IN NS milo.cns.vt.edu. vt.edu. 13872 IN NS ns1-auth.sprintlink.net. vt.edu. 13872 IN NS ns2-auth.sprintlink.net. vt.edu. 13872 IN NS ns3-auth.sprintlink.net. ;; ADDITIONAL SECTION: nomen.cns.vt.edu. 14394 IN A 198.82.247.37 milo.cns.vt.edu. 14394 IN A 198.82.247.98 ns1-auth.sprintlink.net. 86394 IN A 206.228.179.10 ns2-auth.sprintlink.net. 86394 IN A 144.228.254.10 ns3-auth.sprintlink.net. 86394 IN A 144.228.255.10 CS 5565 Spring 2009 6/12/2018
dig vt.edu ns (2) CS 5565 Spring 2009 6/12/2018 $ dig vt.edu ns ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20014 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5 ;; ANSWER SECTION: vt.edu. 13870 IN NS milo.cns.vt.edu. vt.edu. 13870 IN NS ns1-auth.sprintlink.net. vt.edu. 13870 IN NS ns2-auth.sprintlink.net. vt.edu. 13870 IN NS ns3-auth.sprintlink.net. vt.edu. 13870 IN NS nomen.cns.vt.edu. ;; ADDITIONAL SECTION: milo.cns.vt.edu. 14392 IN A 198.82.247.98 ns1-auth.sprintlink.net. 86392 IN A 206.228.179.10 ns2-auth.sprintlink.net. 86392 IN A 144.228.254.10 ns3-auth.sprintlink.net. 86392 IN A 144.228.255.10 nomen.cns.vt.edu. 14392 IN A 198.82.247.37 CS 5565 Spring 2009 6/12/2018
dig vt.edu ns (3) CS 5565 Spring 2009 6/12/2018 $ dig vt.edu ns ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54899 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5 ;; ANSWER SECTION: vt.edu. 13869 IN NS ns1-auth.sprintlink.net. vt.edu. 13869 IN NS ns2-auth.sprintlink.net. vt.edu. 13869 IN NS ns3-auth.sprintlink.net. vt.edu. 13869 IN NS nomen.cns.vt.edu. vt.edu. 13869 IN NS milo.cns.vt.edu. ;; ADDITIONAL SECTION: ns1-auth.sprintlink.net. 86391 IN A 206.228.179.10 ns2-auth.sprintlink.net. 86391 IN A 144.228.254.10 ns3-auth.sprintlink.net. 86391 IN A 144.228.255.10 nomen.cns.vt.edu. 14391 IN A 198.82.247.37 milo.cns.vt.edu. 14391 IN A 198.82.247.98 CS 5565 Spring 2009 6/12/2018
Security in DNS Discussion Why is DNS not secure? What vulnerabilities can you identify? CS 5565 Spring 2009 6/12/2018
DNS Poisoning Actual DNS entry (in 2005) $ dig @b.ns.ketil.froyn.name bad.ketil.froyn.name ns ; <<>> DiG 9.2.3 <<>> @b.ns.ketil.froyn.name bad.ketil.froyn.name ns ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23382 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;bad.ketil.froyn.name. IN NS ;; AUTHORITY SECTION: bad.ketil.froyn.name. 259200 IN NS www.example.com. ;; ADDITIONAL SECTION: www.example.com. 259200 IN A 217.144.230.27 ;; Query time: 128 msec ;; SERVER: 129.240.166.41#53(b.ns.ketil.froyn.name) CS 5565 Spring 2009 6/12/2018
Security in DNS No authentication of content (-> DNSSEC) Questions: When should you trust additional information sent? in- vs. out-of-bailiwick information: Trust vt.edu nameserver only for hosts that end in vt.edu How does client know reply comes from server? attacker must also know port number client used to send request to send answer id must match (theoretically: 1 in 65536 chance, but in practice had BIND implementations that were subject to “birthday attacks” [LURHQ]) CS 5565 Spring 2009 6/12/2018
Protocols & Security Many Internet protocols were designed assuming cooperating peers Guard only against implementation bugs Defense against security-related attacks often afterthought See also Clark’s 2006 article “The Internet Is Broken” Led to NSF-financed effort to “reinvent the Internet,” see, among others: http://cleanstate.stanford.edu CS 5565 Spring 2009 6/12/2018
Updating Records Currently done outside the protocol Manually or using server-specific or organization-specific facilities Update/notify mechanisms under design by IETF RFC 2136 See DNS Extensions working group dnsext (http://www.ietf.org/html.charters/dnsext-charter.html) CS 5565 Spring 2009 6/12/2018
DNS Redirection for CDNs Coral P2P Content Distribution Network Use DNS Redirection to find closest peer willing to serve request See [Freedman 2004]. Try out http://www.cs.vt.edu.nyud.net:8090/ Notice that www.cs.vt.edu.nyud.net -> CNAME’d to www.cs.vt.edu.http.L2.L1.L0.nyucd.net Redirection is also used by akamai.net CS 5565 Spring 2009 6/12/2018
Coral Example Source: [Freedman 2004]. CS 5565 Spring 2009 6/12/2018
CS 5565 Spring 2009 6/12/2018
Application Protocols Part 3: XMPP Slides by John Linford & Rahul Agarwal
XMPP Extensible Messaging and Presence Protocol A protocol for streaming XML elements in close to real time between any two network endpoints Provides a generalized, extensible framework for exchanging XML data Mainly used in instant messaging and presence applications (Jabber) RFC 3920: XMPP Core. http://xmpp.org/rfcs/rfc3920.html. CS 5565 Spring 2009 6/12/2018
openXMPP A modular, multi-platform standards-compliant XMPP library Provides required functionality listed in RFC 3920 and RFC 3921: XML streams XML stanzas TLS stream encryption SASL authentication Resource binding Roster and subscription management Internationalization (*) Conversation threads (*) Directed presence information (*) New account registration (*) Library: 3601 lines, 1379 statements Project: 5825 lines, 2304 statements C1----S1---S2---C3 | C2----+--G1===FN1===FC1 * Optional RFC functionality CS 5565 Spring 2009 6/12/2018
XMPP session establishment Offline Connected StartingTLS Connected StartingSASL StartingSession LoggedIn Client Server <stream:features> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> <required/> </starttls> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5</mechanism> <mechanism>PLAIN</mechanism> </mechanisms> </stream:features> <stream:features> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> <required/> </starttls> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5</mechanism> <mechanism>PLAIN</mechanism> </mechanisms> </stream:features> <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="PLAIN"> amNsLm9wZW5YTVBQQGdtYWlsLmNvbQBqY2wu b3BlblhNUFAAT3BFblhtUHA= </auth> <iq type="set" id="openXMPP_luxqnoei1"> <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"> <resource>openXMPP</resource> </bind> </iq> <iq id="openXMPP_luxqnoei1" type="result" xmlns="jabber:client"> <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"> <jid>somenode@example.com/openXMPP128A956D</jid> </bind> </iq> <iq type="set" id="openXMPP_luxqnoei2"> <session xmlns="urn:ietf:params:xml:ns:xmpp-session" /> </iq> <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> <iq type="result" id="openXMPP_luxqnoei2" xmlns="jabber:client" /> <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" /> CS 5565 Spring 2009 6/12/2018
State Diagram CS 5565 Spring 2009 6/12/2018
XMPP Subsequently exchange XML stanzas See Problem Set 2 For presence management For roster management For sending messages See Problem Set 2 CS 5565 Spring 2009 6/12/2018
Summary Application Protocols Request/Reply pattern pervasive Persistent vs. Nonpersistent Connections Simplicity! Few states, if any Stateless protocols are used where possible Human-readable message formats often preferred (despite overhead) Recent protocols sometimes use XML CS 5565 Spring 2009 6/12/2018