View
214
Download
0
Tags:
Embed Size (px)
Citation preview
CS219/Fall 2002 10/02
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,
intra-domain• 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 case-
independent 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 end-node• 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)