We’re making these slides freely available to all (faculty, students, readers). Computer 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. Networking: A Top They obviously represent a lot of work on our part. In return for use, we only ask the following: Down Approach 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!) 6th edition If you post any slides on a www site, that you note that they are adapted Jim Kurose, Keith Ross from (or perhaps identical to) our slides, and note our copyright of this material. Addison-Wesley March 2012 Thanks and enjoy! JFK/KWR
All material copyright 1996-2012
J.F Kurose and K.W. Ross, All Rights Reserved
Application Layer 2-1
FTP: the file transfer protocol file transfer FTP FTP FTP user client server interface user at host remote file local file system system
transfer file to/from remote host
client/server model client: side that initiates transfer (either to/from remote) server: remote host ftp: RFC 959 ftp server: port 21 Application Layer 2-2 FTP: separate control, data connections
FTP client contacts FTP server TCP control connection,
server port 21 at port 21, using TCP client authorized over control TCP data connection, connection FTP server port 20 FTP client server client browses remote directory, sends commands over control connection server opens another TCP data connection to transfer when server receives file another file transfer command, server opens 2nd TCP data control connection: “out of connection (for file) to client band” after transferring one file, FTP server maintains server closes data connection “state”: current directory, earlier authentication
Application Layer 2-3
FTP commands, responses sample commands: sample return codes sent as ASCII text over status code and phrase (as control channel in HTTP) USER username 331 Username OK, PASS password password required LIST return list of file in 125 data current directory connection already open; RETR filename transfer starting retrieves (gets) file 425 Can’t open STOR filename stores data connection (puts) file onto remote 452 Error writing host file
Application Layer 2-4
Electronic mail outgoing message queue user mailbox Three major components: user agent user agents mail servers mail user server agent simple mail transfer protocol: SMTP SMTP mail user server agent
User Agent SMTP
a.k.a. “mail reader” SMTP user agent composing, editing, reading mail server mail messages user e.g., Outlook, Thunderbird, agent iPhone mail client user agent outgoing, incoming messages stored on server Application Layer 2-5 Electronic mail: mail servers mail servers: user agent mailbox contains incoming messages for user mail user server message queue of outgoing agent
(to be sent) mail messages SMTP mail user
SMTP protocol between server agent mail servers to send email SMTP messages user client: sending mail SMTP agent mail server server “server”: receiving mail user agent server user agent
Application Layer 2-6
Electronic Mail: SMTP [RFC 2821] uses TCP to reliably transfer email message from client to server, port 25 direct transfer: sending server to receiving server three phases of transfer handshaking (greeting) transfer of messages closure command/response interaction (like HTTP, FTP) commands: ASCII text response: status code and phrase messages must be in 7-bit ASCI Application Layer 2-7 Scenario: Alice sends message to Bob 1) Alice uses UA to compose 4) SMTP client sends Alice’s message “to” message over the TCP bob@someschool.edu connection 2) Alice’s UA sends message 5) Bob’s mail server places the to her mail server; message message in Bob’s mailbox placed in message queue 6) Bob invokes his user agent 3) client side of SMTP opens to read message TCP connection with Bob’s mail server
1 user mail user
mail agent agent server server 2 3 6 4 5 Alice’s mail server Bob’s mail server Application Layer 2-8 SMTP: final words SMTP uses persistent comparison with HTTP: connections HTTP: pull SMTP requires message (header & body) to be in SMTP: push 7-bit ASCII both have ASCII SMTP server uses command/response CRLF.CRLF to interaction, status codes determine end of message HTTP: each object encapsulated in its own response msg SMTP: multiple objects sent in multipart msg
Application Layer 2-9
Mail message format
SMTP: protocol for
exchanging email msgs header blank RFC 822: standard for text line message format: header lines, e.g., To: body From: Subject: different from SMTP MAIL FROM, RCPT TO: commands! Body: the “message” ASCII characters only
Application Layer 2-10
Mail access protocols user mail access user SMTP SMTP protocol agent agent (e.g., POP, IMAP)
sender’s mail receiver’s mail
server server
SMTP: delivery/storage to receiver’s server
mail access protocol: retrieval from server POP: Post Office Protocol [RFC 1939]: authorization, download IMAP: Internet Mail Access Protocol [RFC 1730]: more features, including manipulation of stored msgs on server HTTP: gmail, Hotmail, Yahoo! Mail, etc.
Application Layer 2-11
DNS: domain name system people: many identifiers: Domain Name System: SSN, name, passport # distributed database Internet hosts, routers: implemented in hierarchy of IP address (32 bit) - many name servers used for addressing application-layer protocol: hosts, datagrams name servers communicate to “name”, e.g., resolve names (address/name www.yahoo.com - translation) used by humans note: core Internet function, Q: how to map between IP implemented as application- layer protocol address and name, and vice versa ? complexity at network’s “edge”
Application Layer 2-12
DNS: services, structure DNS services why not centralize DNS? hostname to IP address single point of failure translation traffic volume host aliasing distant centralized database canonical, alias names maintenance mail server aliasing load distribution A: doesn’t scale! replicated Web servers: many IP addresses correspond to one name
Application Layer 2-13
DNS: a distributed, hierarchical database Root DNS Servers
… …
com DNS servers org DNS servers edu DNS servers
pbs.org poly.edu umass.edu
yahoo.com amazon.com DNS servers DNS serversDNS servers DNS servers DNS servers
client wants IP for www.amazon.com; 1st approx:
client queries root server to find com DNS server client queries .com DNS server to get amazon.com DNS server client queries amazon.com DNS server to get IP address for www.amazon.com
Application Layer 2-14
DNS: root name servers contacted by local name server that can not resolve name root name server: contacts authoritative name server if name mapping not known gets mapping returns mapping to local name server
c. Cogent, Herndon, VA (5 other sites)
d. U Maryland College Park, MD k. RIPE London (17 other sites) h. ARL Aberdeen, MD j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites)
e. NASA Mt View, CA m. WIDE Tokyo
f. Internet Software C. (5 other sites) Palo Alto, CA (and 48 other sites)
a. Verisign, Los Angeles CA 13 root name
(5 other sites) b. USC-ISI Marina del Rey, CA “servers” l. ICANN Los Angeles, CA worldwide (41 other sites) g. US DoD Columbus, OH (5 other sites)
Application Layer 2-15
TLD, authoritative servers top-level domain (TLD) servers: responsible for com, org, net, edu, aero, jobs, museums, and all top-level country domains, e.g.: uk, fr, ca, jp Network Solutions maintains servers for .com TLD Educause for .edu TLD authoritative DNS servers: organization’s own DNS server(s), providing authoritative hostname to IP mappings for organization’s named hosts can be maintained by organization or service provider
Application Layer 2-16
Local DNS name server does not strictly belong to hierarchy each ISP (residential ISP, company, university) has one also called “default name server” when host makes DNS query, query is sent to its local DNS server has local cache of recent name-to-address translation pairs (but may be out of date!) acts as proxy, forwards query into hierarchy
Application Layer 2-17
DNS name root DNS server resolution example 2 host at cis.poly.edu 3 TLD DNS server wants IP address for 4 gaia.cs.umass.edu 5
iterated query: local DNS server
dns.poly.edu contacted server 7 6 1 8 replies with name of server to contact authoritative DNS server “I don’t know this dns.cs.umass.edu name, but ask this requesting host server” cis.poly.edu
gaia.cs.umass.edu
Application Layer 2-18
DNS name root DNS server resolution example 2 3 recursive query: 7 6 puts burden of name TLD DNS server resolution on contacted name local DNS server server dns.poly.edu 5 4
heavy load at upper 1 8
levels of hierarchy? authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu
gaia.cs.umass.edu
Application Layer 2-19
DNS: caching, updating records once (any) name server learns mapping, it caches mapping cache entries timeout (disappear) after some time (TTL) TLD servers typically cached in local name servers • thus root name servers not often visited cached entries may be out-of-date (best effort name-to-address translation!) if name host changes IP address, may not be known Internet-wide until all TTLs expire update/notify mechanisms proposed IETF standard RFC 2136
Application Layer 2-20
DNS protocol, messages query and reply messages, both with same message format 2 bytes 2 bytes
msg header identification flags
identification: 16 bit # for # questions # answer RRs
query, reply to query uses # authority RRs # additional RRs same # flags: questions (variable # of questions) query or reply recursion desired answers (variable # of RRs) recursion available reply is authoritative authority (variable # of RRs)
additional info (variable # of RRs)
Application Layer 2-21
DNS protocol, messages
2 bytes 2 bytes
identification flags
# questions # answer RRs
# authority RRs # additional RRs
name, type fields
questions (variable # of questions) for a query RRs in response answers (variable # of RRs) to query records for authority (variable # of RRs) authoritative servers additional “helpful” additional info (variable # of RRs) info that may be used Application Layer 2-22 Attacking DNS DDoS attacks Redirect attacks Bombard root servers Man-in-middle with traffic Intercept queries Not successful to date DNS poisoning Traffic Filtering Send bogus relies to Local DNS servers DNS server, which cache IPs of TLD caches servers, allowing root Exploit DNS for DDoS server bypass Send queries with Bombard TLD servers spoofed source Potentially more dangerous address: target IP Requires amplification Application Layer 2-23