Outline for this lecture

1
Outline for this lecture

• Design Philosophy of Internet Protocols
• End to end argument

2
Architectural Principles of the Internet RFC
1958 Clarks Paper

• Internet has grown by factors of 1000 (backbone
  speed) to 106 ( 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.

3
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

4
Design Philosophy of TCP/IP

• Network characteristics
• Prioritized design goals
• Architecture and implementation

5
Network Characteristics

• Network heterogeneity varieties of networks
• Diverse application requirements throughput,
  delay, loss, etc.
• Large number of subnetworks, nodes
• Decentralized management and control

6
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

7
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

8
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

9
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

10
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

11
Cost-effectiveness

• Header contributes overhead
• Small packets
• Recovery from lost packets
• End-to-end retransmissions
• Not link-by-link retransmissions

12
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

13
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

14
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

15
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

16
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

17
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

18
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
19
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

20
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

21
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

22
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

23
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

24
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

25
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

26
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

27
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

28
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

29
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

30
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

31
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

32
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)

33
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)

34
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