Transcript October 1, 2003

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