* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download October 1, 2003
Survey
Document related concepts
Wake-on-LAN wikipedia , lookup
Wireless security wikipedia , lookup
Network tap wikipedia , lookup
Computer network wikipedia , lookup
Deep packet inspection wikipedia , lookup
Internet protocol suite wikipedia , lookup
Airborne Networking wikipedia , lookup
Distributed firewall wikipedia , lookup
Zero-configuration networking wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Peer-to-peer wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Transcript
Outline for this lecture • Design Philosophy of Internet Protocols • “End to end” argument CS219/Fall 2002 10/02 Architectural Principles of the Internet: RFC 1958 & Clark’s Paper • Internet has grown by factors of 1000 (backbone speed) to 10^6 (# of hosts) in 1996. • The principle of constant change is perhaps the only principle of the Internet • The purpose is to find guidelines that had been useful in the past: a small “spanning set” of rules • Reflects our current understanding of the Internet: avoid statements like “Heavier-than-air flying machines are impossible” by Lord Kelvin in 1895 • If there are several ways of doing the same thing, choose the previous design unless you have a very good reason not to. CS219/Fall 2002 10/02 Is there an Internet Architecture? • Architecture or tradition? The community believes: – The goal is connectivity – The tool is the IP protocol – The intelligence is end to end rather than hidden in the network • Revolution versus evolution for Internet technology CS219/Fall 2002 10/02 Design Philosophy of TCP/IP • Network characteristics • Prioritized design goals • Architecture and implementation CS219/Fall 2002 10/02 Network Characteristics • Network heterogeneity: varieties of networks • Diverse application requirements: throughput, delay, loss, etc. • Large number of subnetworks, nodes • Decentralized management and control CS219/Fall 2002 10/02 Prioritized Design Goals Effectiveness is more important than efficiency: • Connectivity: interconnection of distinguishable networks • Robustness and survivability: communication continues in the presence of various degree of failures • Flexible service: meet diverse application requirements • Distributed management • Cost effectiveness • Ease for Plug-in: Easy to attach for new hosts • Accounting issue CS219/Fall 2002 10/02 Fundamental Goal • Multiplexed utilization of existing interconnected networks – “Network of networks” or “multi-media network:” Multiplexing versus integrating/unifying – Packet switching versus circuit switching: bursty traffic versus regular traffic – Store and forward packet forwarding – Internet level protocol must be independent of the hardware medium and hardware addressing CS219/Fall 2002 10/02 Robust Connectivity: how IP achieves • Issues and solutions in IP – Heterogeneous networks: IP address and IP router – Node and network failures: • “connectionless” within the network: no connection state management for IP routers • Fate-sharing with end hosts • ICMP error report messages – Scalability: no per-connection/group state within the network, push such states to the edge (end hosts) of the network CS219/Fall 2002 10/02 Flexible Service • Built on top of basic IP best-effort service • Discard the approach of unified transport service design: – UDP, TCP, RTP, … … • Remember: no performance assurances CS219/Fall 2002 10/02 Decentralized control • No centralized management • Two-tier routing: inter-domain, intradomain • Each domain can specify its own routing policies/preferences • Exchanging routing table information among border gateways CS219/Fall 2002 10/02 Cost-effectiveness • Header contributes overhead – Small packets • Recovery from lost packets: – End-to-end retransmissions – Not link-by-link retransmissions CS219/Fall 2002 10/02 Architecture and implementation • Packet-switching system that allows for different realizations • Live with failures: Not to prevent failures but how to react to them properly • How to evaluate your design – Prototyping – Simulation – Compatiability issue: incremental deployment CS219/Fall 2002 10/02 A Few More Guidelines • Heterogeneity is inevitable and must be supported by design – Hardware; application protocols • Duplication of the same protocol functionality should be avoided as far as possible • All designs must scale • Keep the solution simple: choose the simplest solution if possible • Modularity is good. • Do not wait until a perfect solution is found CS219/Fall 2002 10/02 More guidelines • Avoid options and parameters whenever possible. They should be configured/negotiated dynamically rather than manually • Be strict when sending, and tolerant when receiving. You may silently drop faulty input when in doubt without returning an error message. • Be parsimonious with unsolicited (multicast or broadcast) packets • Circular dependencies must be avoided CS219/Fall 2002 10/02 Name and Address Issues • Avoid any design that requires addresses to be hard coded or stored on non-volatile storage • User applications should use names rather than addresses in general • A single naming structure is used • Public names (e.g. DNS names) are in caseindependent ASCII. • Addresses must be unambiguous • Upper layer protocols must be able to identify end-points unambiguously CS219/Fall 2002 10/02 Confidentiality and Authentication • All designs must fit into the IP security architecture ?? • Authentication and confidentiality are the responsibility of end users, not the network • Security protocols should allow different cryptographic algorithms. • Choose a well-known/studied cryptographic algorithm, do NOT invent a new one unless no existing one works CS219/Fall 2002 10/02 Implementations • Objects should be self describing (including type and size). Other type codes and magic numbers assigned by IANA may be used. • Any implementation which does not include all of the required components cannot claim conformance with the standard • Designs must be international, with support for localization • Prefer unpatented technology CS219/Fall 2002 10/02 End-to-end arguments in system design Problem statement: given the freedom to implement a few functionalities in multiple “places” of the system (physical devices, or layers of protocols), where to implement them? Goal: correctness, completeness, and performance tradeoff Approach: end-to-end arguments CS219/Fall 2002 10/02 What is end-to-end argument? • System: application, communication subsystem and the rest • End-to-end: – the function can completely and correctly be implemented ONLY with the knowledge and help of the application standing at the endpoints of the communication system. – Providing the function as a feature of the communication system is not feasible – appeals to application requirement – Move a function upward in a layered system closer to the application that uses the function CS219/Fall 2002 10/02 Example: file transfer • Problem: transfer a file from host A to B • Steps: – At A, file system reads and passes the file to ftp – At A, ftp passes it to data comm. System – Packets of the file are transferred from A to B – At B, ftp retrieves the file – At B, file system writes the data to the disk CS219/Fall 2002 10/02 Example (continued) • Threats: – Read error from the disk at A – Software errors in buffering and copying data by file system, ftp, or network, at A or B – Hardware errors at A or B – Transfer error in the network part – Host crashes at A or B CS219/Fall 2002 10/02 Approach to handle threats • Approach 1: reinforce EVERY step – Using duplicate copies, timeout and retry, error detection, crash recovery, etc. – Maybe Not feasible – Uneconomical • Approach 2: end-to-end check and retry – Implement “end-to-end” error checking at Steps 1 and 5 – Retry if checking fails CS219/Fall 2002 10/02 end-to-end approach in the example • Guarantee correctness and completeness of reliable file transfer • Reliability is the composite effects of all the components • Reliability in the network alone is not sufficient for end-to-end reliability • Application requirement is the key • Works if the error is not frequent CS219/Fall 2002 10/02 End-to-end versus low-layer implementation • Correctness and completeness – Provided by end-to-end – Not by lower-layer implementations – Conclusion: end-to-end is a must • Performance perspective – End-to-end may suffer without lower-layer collaboration – Placing functions in lower layer is justified only if performance benefits outweighs the cost of additional complexity at the lower layer. • Redundancy perspective CS219/Fall 2002 10/02 When to use the end-to-end approach • A functionality should be pushed to higher layers if possible, motivated by – – – – Correctness and completeness Reduced redundancy Incremental deployment More flexibility exposed to applications • Unless implementing it at lower layers can achieve large performance gains that outweigh the cost of additional complexity at lower layers CS219/Fall 2002 10/02 More discussions and examples • End-to-end versus hop-by-hop reliability • Multicast: IP versus end-system – Case against IP multicast • Stateful multicast architecture: Requires IP routers to maintain group state • Vulnerable to flooding attack • Multicast address is needed for each group • Calls for infrastructure-level changes • Slow deployment • Implementing multicast congestion control at higher layers? – Case against end-system multicast • Performance penalty CS219/Fall 2002 10/02 Another example: security • Security in a networking system • Bruce Schneier wrote in “Secrets and Lies: Digital security in a networked world” (John Wiley & Sons, Inc; 2000) – Cryptography is not the Answer. – Cryptography is not sufficient from the system perspective – “Security is a chain; it is only as secure as the weakest link” – “Security is a process, not a product” CS219/Fall 2002 10/02 What has changed since then? • Operations in an untrustworthy world – Untrusted end-points (imply more mechanisms in the core to enforce good behaviors) • More demanding applications – e.g., streaming media (intermediate servers) • ISP service differentiation • The rise of third-party involvement • Less sophisticated users CS219/Fall 2002 10/02 New Requirements • Security-related – Users communicate but do not totally trust each other – Anonymity in communications – End parties do not trust their software/hardware • The ends vs the middle – Third party involvement • Multiway communication • One party tries to force interaction on another CS219/Fall 2002 10/02 Different forms of e2e arguments • network side – Avoid putting application-specific functions in the network – Push application-specific functions up and out to the edges • Application side – Decide where application-level services should be attached CS219/Fall 2002 10/02 Network side: Modify the endnode • Placement of function at the edge may – compromise performance, but the functional objective is met – Represent an imperfect but acceptable solution – Not solve the problem CS219/Fall 2002 10/02 Network side: the network core • Add functions to the network core – Enable more functionalities and applications – Prevent certain malicious applications • Design issues – Imposing a control element into the path of communication (e.g. by using the topology information/characteristics) – Revealing or hiding the message content (e.g. by using labels on information/keyword) CS219/Fall 2002 10/02 Application side • Insert servers into the data path of an application – mail servers, anonymous message forwarders (e.g. nym) • Use of additional components away from the e2e design – Using trusted third party (e.g. via public key certificate) CS219/Fall 2002 10/02 Some examples in wireless • Wireless proxy (I.e., transcoding,web) – Handle end devices with different capabilities – Different client requirements – No change on the application server – Main complexity on the proxy • Wireless security • Reliability over the wireless link CS219/Fall 2002 10/02