Encapsulation End-to-End Argument Source Transport Saltzer, Reed & Clark, 1981 src & dst ports + Network src & dst IP addresses + message M Application src & dst MAC addresses Link segment H T M Transport datagram H N H T M Network If a function can be completely and correctly implemented frame H N H T M H L Link only with the knowledge and help of the application Physical standing at the endpoints of the communication system, H N H T M Network H N H T M then providing that function as a feature of the H N H T M H L Link H N H T M H L communication system itself is not possible Physical Destination Sometimes providing an incomplete version as a feature of Router Application M the communication system itself may be useful as a H T M Transport performance enhancement H N H T M Network M H L H N H T Link Physical � 14 � 15 An Application EtE Argument’ s Impact of the Argument Occam’ s Razor for Internet architecture Should the network guarantee packet delivery? End-to-end properties are best provided by applications, Consider transferring a file not by the network Guaranteed packet delivery, ordered packet delivery, duplicate Sender reads file from disk & sends it; Receiver reads packets suppression, security, etc. and writes them to disk Wouldn’ t it be simpler if network guaranteed delivery? Internet performs simplest packet routing and delivery service No! Application still needs to check file was written to disk Packets are sent on a best-effort basis It needs to implement anyway its own retransmits � 16 � 17
Application Layer Application Protocols Transport Network Link HTTP Physical persistent/non persistent; stateless, hence cookies Application Layer Electronic Mail SMTP; POP3; IMAP DNS Manages naming of internet hosts � 18 Domain Name System Naming (DNS) Mockapetris ‘87 People Root DNS Servers SSN, NetId, Passport Number .com DNS servers .org DNS servers .edu DNS servers Internet Hosts, Routers yahoo.com amazon.com pbs.org cornell.edu utexas.edu IP Address (32 bit) Ex: 128.84.96.12 DNS servers DNS servers DNS servers DNS servers DNS servers Assigned to hosts by their internet service providers (ISPs) A name service built above a hierarchical, distributed, Not a unique id, can be reused for a different machine autonomous, reliable database Determines how packets reach its holder Application level protocol: hosts & name servers communicate to resolve names A virtual “name” Ex: www.cs.cornell.edu Introduced to replace the original Internet naming scheme Human friendly a single central master file downloaded everywhere by FTP How are human friendly names translated into IP addresses? Components separated by dot and resolved from right to left All names are global: they mean the same everywhere in the DNS � 20 � 21
DNS Name Resolution: DNS Lookup Iterative root DNS server To find the IP address of www.cs.cornell.edu (basic protocol) 2 TLD DNS server (.edu in this case) Query root server to find IP of DNS server for edu… 3 4 which, when queried next, will provide IP of DNS server for cornell.edu local 5 DNS which, when queried next, will provide IP of server Authoritative 6 cs.cornell.edu DNS server (bigred.cit.cornell.edu) 7 which, when queried next, will provide IP of 1 8 www.cs.cornell.edu www.cs.cornell.edu � 22 irnerio.cs.utexas.edu � 23 DNS Name Resolution: Caching Recursive root DNS server Cache entries may be out of date 2 3 bindings are forgotten after TTL TLD DNS server (.edu in this case) TLD servers typically cached in local name servers 7 6 Servers cache new bindings they learn local 4 DNS 5 server only eventual consistency Authoritative DNS server (bigred.cit.cornell.edu) if binding changes, it may not be learned until TTL 1 8 update notify proposed IETF standard www.cs.cornell.edu irnerio.cs.utexas.edu � 24
Leveraging DNS Attacking DNS for DDoS DDos attacks on DNS target: root servers DDOS Amplification to date, unsuccessful traffic filtering / root server bypass via TLD, cashed at local asymmetric attack servers send query with spoofed target: TLD servers source address potentially more dangerous IP of the victim Redirect attacks Man-in-the-middle DNS poisoning � 27 The Client Server Application Paradigm Transport Network Link Physical Server: Program(s) that provide some service Client: Program that uses the service Remote Procedure Calls Typical pattern: Client connects to the server locates it in the network and establishes a connection Client sends requests messages that indicate desired service and necessary parameters Server returns response � 28 � 29
Pros and Cons Procedure Calls of Messages to the Rescue Very flexible communication A more natural way to communicate Programmers can choose message’ s format as they see supported by every language fit with well-defined semantics But… The idea Now programmer must worry about message formats Server exports a set of procedures, that clients can Messages must be packed and unpacked invoke, as if they were co-located Messages must be decoded by server to determine The rub requested service Messages may require special error handling functions They are not colocated! How do we make this transparent to the programmer? � 30 � 31 Remote Procedure Call Building a Server (RPC) Birrell & Nelson @ Xerox PARC “Implementing Remote Procedure Calls” (1984) Goal: design RPC to look like a local Interface defined using an Interface Definition Language (IDL) procedure call specifies the names, parameters, and types for all Client and server each implement three components server procedures that clients can call user program Stub compiler reads IDL and produces two stub a set of stop procedures procedures for each server procedure RPC runtime support stubs manage all details of communication between client and server server-side stub is linked to server’ s code client-side stub is linked to client’ s � 32 � 33
RPC Stubs RPC Call Structure proc foo(a,b) proc foo(a,b) Server Server Client Client (1) Calls local (6) Does call foo(x,y) begin foo... call foo(x,y) begin foo... program program program program stub function the work! end foo end foo Stubs send each other messages to call foo call foo call foo call foo make RPC happen Client Server (5) Unpacks proc foo(a,b) call foo(x,y) stub stub Client Server (2) Builds msg, params, proc foo(a,b) call foo(x,y) stub stub calls OS makes call send msg receive msg Server-side stub: Client-side stub: RPC (3) Sends msg (4) Receives RPC Server program thinks it is Looks (to client) like a runtime to remote node msg, calls stub runtime called by the client callable server procedure Client program thinks it is foo actually called by the Call calling the server server stub � 34 � 35 RPC Return Structure proc foo(a,b) Server (1) Returns Client (6) Client call foo(x,y) begin foo... program result to stub program continues end foo call foo call foo Client (2) Packs results Server (5) Unpacks msg, proc foo(a,b) call foo(x,y) stub in msg, calls OS stub returns to client send msg receive msg RPC (4) Receives (3) Responds RPC runtime msg, calls stub to original msg runtime Return � 36
Recommend
More recommend
