15-441 computer networking lecture 29 – final review
TRANSCRIPT
15-441 Computer Networking
Lecture 29 – Final Review
12-05-06 Lecture 27: Research Directions 2
Fun
• TCP/IP drinking game• (http://infohost.nmt.edu/~val/tcpip.html)
• Internet map • (http://xkcd.com/c195.html)
12-05-06 Lecture 27: Research Directions 3
Outline – Lec 14
• The recurring IP address space problem• IPv6.• NAT.• Tunneling / Overlays• Network Management
• Autoconfiguration• SNMP (notes only)
12-05-06 Lecture 27: Research Directions 4
• “Next generation” IP.• Most urgent issue: increasing
address space.• 128 bit addresses
• Simplified header for faster processing:
• No checksum (why not?)• No fragmentation (?)
• Support for guaranteed services: priority and flow id
• Options handled as “next header”
• reduces overhead of handling options
V/PrV/Pr Flow labelFlow label
LengthLength NextNext Hop LHop L
Source IP addressSource IP address
Destination IP addressDestination IP address
IP v6
12-05-06 Lecture 27: Research Directions 5
B IPB IP
Network Address Translation
Publ A IPPubl A IP
B IPB IP
A Port’A Port’ B PortB Port
Priv A IPPriv A IP
B IPB IP
A PortA Port B PortB Port
Publ A IPPubl A IP
B PortB Port
B IPB IP
Priv A IPPriv A IP
B PortB Port A PortA Port
A Port’A Port’
A
B
• NAT maps (private source IP, source port) onto (public source IP, unique source port)
• reverse mapping on the way back• destination host does not know that this process is happening
• Very simple working solution.• NAT functionality fits well with firewalls
12-05-06 Lecture 27: Research Directions 6
Tunneling
• Force a packet to go to a specific point in the network.
• Path taken is different from the regular routing
• Achieved by adding an extra IP header to the packet with a new destination address.
• Similar to putting a letter in another envelope
• preferable to using IP source routing option
• Used increasingly to deal with special routing requirements or new features.
• Mobile IP,..• Multicast, IPv6, research, ..
Data IP1 IP2
IP2
IP1
12-05-06 Lecture 27: Research Directions 7
DHCP
• DHCPOFFER• IP addressing information• Boot file/server information (for network booting)• DNS name servers• Lots of other stuff - protocol is extensible; half of the options reserved for local
site definition and use.
DHCPDISCOVER - broadcast
DHCPOFFER
DHCPREQUEST
DHCPACK
12-05-06 Lecture 27: Research Directions 8
Outline – Lec 15
• Exam discussion• Layering review (bridges, routers, etc.)
• Exam section C.
• Circuit switching refresher• Virtual Circuits - general
• Why virtual circuits?• How virtual circuits? -- tag switching!
• Two modern implementations• ATM - teleco-style virtual circuits• MPLS - IP-style virtual circuits
12-05-06 Lecture 27: Research Directions 9
• Global VC ID allocation -- ICK! Solution: Per-link uniqueness. Change VCI each hop.
Input Port Input VCI Output Port Output VCI R1: 1 5 3 9 R2: 2 9 4 2
R4: 1 2 3 5
A
B
R2
R1
R3
R4 Dst
1
2
3
4
3
3
3
1
1
1
2
2
4
4
4
2
Virtual Circuit Switching:Label (“tag”) Swapping
12-05-06 Lecture 27: Research Directions 10
Multi Protocol Label Switching - MPLS
• Selective combination of VCs + IP• Today: MPLS useful for traffic engineering, reducing core
complexity, and VPNs
• Core idea: Layer 2 carries VC label• Could be ATM (which has its own tag)• Could be a “shim” on top of Ethernet/etc.:• Existing routers could act as MPLS switches just by examining
that shim -- no radical re-design. Gets flexibility benefits, though not cell switching advantages
Layer 2 header
Layer 3 (IP) header
Layer 2 header
Layer 3 (IP) header
MPLS label
12-05-06 Lecture 27: Research Directions 11
MPLS + IP
• Map packet onto Forward Equivalence Class (FEC)• Simple case: longest prefix match of destination address• More complex if QoS of policy routing is used
• In MPLS, a label is associated with the packet when it enters the network and forwarding is based on the label in the network core.
• Label is swapped (as ATM VCIs)
• Potential advantages.• Packet forwarding can be faster• Routing can be based on ingress router and port• Can use more complex routing decisions• Can force packets to followed a pinned route
12-05-06 Lecture 27: Research Directions 12
Take Home Points
• Costs/benefits/goals of virtual circuits• Cell switching (ATM)
• Fixed-size pkts: Fast hardware• Packet size picked for low voice jitter. Understand
trade-offs.• Beware packet shredder effect (drop entire pkt)
• Tag/label swapping• Basis for most VCs. • Makes label assignment link-local. Understand
mechanism.• MPLS - IP meets virtual circuits
• MPLS tunnels used for VPNs, traffic engineering, reduced core routing table sizes
12-05-06 Lecture 27: Research Directions 13
Outline – Lec 16
• Transport introduction
• Error recovery & flow control
12-05-06 Lecture 27: Research Directions 14
Important Lessons
• Transport service• UDP mostly just IP service• TCP congestion controlled, reliable, byte stream
• Types of ARQ protocols• Stop-and-wait slow, simple• Go-back-n can keep link utilized (except w/ losses)• Selective repeat efficient loss recovery
• Sliding window flow control• Addresses buffering issues and keeps link utilized
12-05-06 Lecture 27: Research Directions 15
ReceiverReceiverSenderSender
Sender/Receiver State
… …
Sent & Acked Sent Not Acked
OK to Send Not Usable
… …
Max acceptable
Receiver window
Max ACK received Next seqnum
Received & Acked Acceptable Packet
Not Usable
Sender window
Next expected
12-05-06 Lecture 27: Research Directions 16
Outline – Lec 17
• TCP flow control
• Congestion sources and collapse
• Congestion control basics
12-05-06 Lecture 27: Research Directions 17
Important Lessons
• Why is congestion control needed?
• How to evaluate congestion control algorithms?• Why is AIMD the right choice for congestion control?
• TCP flow control• Sliding window mapping to packet headers• 32bit sequence numbers (bytes)
12-05-06 Lecture 27: Research Directions 18
acknowledged sent to be sent outside window
Source PortSource Port Dest. PortDest. Port
Sequence NumberSequence Number
AcknowledgmentAcknowledgment
HL/FlagsHL/Flags WindowWindow
D. ChecksumD. Checksum Urgent PointerUrgent Pointer
Options…Options…
Source PortSource Port Dest. PortDest. Port
Sequence NumberSequence Number
AcknowledgmentAcknowledgment
HL/FlagsHL/Flags WindowWindow
D. ChecksumD. Checksum Urgent PointerUrgent Pointer
Options...Options...
Packet Sent Packet Received
App write
Window Flow Control: Send Side
12-05-06 Lecture 27: Research Directions 19
Causes & Costs of Congestion
• When packet dropped, any “upstream transmission capacity used for that packet was wasted!
12-05-06 Lecture 27: Research Directions 20
Phase Plots
• Simple way to visualize behavior of competing connections over time
User 1’s Allocation x1
User 2’s Allocation
x2
12-05-06 Lecture 27: Research Directions 21
Phase Plots
• What are desirable properties?
• What if flows are not equal?
Efficiency Line
Fairness Line
User 1’s Allocation x1
User 2’s Allocation
x2Optimal point
Overload
Underutilization
12-05-06 Lecture 27: Research Directions 22
Outline – Lec 18
• TCP connection setup/data transfer
• TCP reliability
12-05-06 Lecture 27: Research Directions 23
Establishing Connection:Three-Way handshake
• Each side notifies other of starting sequence number it will use for sending
• Why not simply chose 0?• Must avoid overlap with earlier
incarnation• Security issues
• Each side acknowledges other’s sequence number
• SYN-ACK: Acknowledge sequence number + 1
• Can combine second SYN with first ACK
SYN: SeqC
ACK: SeqC+1SYN: SeqS
ACK: SeqS+1
Client Server
12-05-06 Lecture 27: Research Directions 24
Tearing Down Connection
• Either side can initiate tear down
• Send FIN signal• “I’m not going to send any more
data”
• Other side can continue sending data
• Half open connection• Must continue to acknowledge
• Acknowledging FIN• Acknowledge last sequence
number + 1
A BFIN, SeqA
ACK, SeqA+1
ACK
Data
ACK, SeqB+1
FIN, SeqB
12-05-06 Lecture 27: Research Directions 25
Fast Retransmit
Time
Sequence No Duplicate Acks
RetransmissionX
Packets
Acks
12-05-06 Lecture 27: Research Directions 26
TCP (Reno variant)
Time
Sequence NoX
X
XX
Now what? - timeout
Packets
Acks
12-05-06 Lecture 27: Research Directions 27
Important Lessons
• TCP state diagram setup/teardown
• TCP timeout calculation how is RTT estimated
• Modern TCP loss recovery• Why are timeouts bad?• How to avoid them? e.g. fast retransmit
12-05-06 Lecture 27: Research Directions 28
Outline – Lec 20
• TCP congestion avoidance
• TCP slow start
• TCP modeling
12-05-06 Lecture 27: Research Directions 29
TCP Congestion Control
• Changes to TCP motivated by ARPANET congestion collapse
• Basic principles• AIMD• Packet conservation• Reaching steady state quickly• ACK clocking
12-05-06 Lecture 27: Research Directions 30
Congestion Avoidance Sequence Plot
Time
Sequence No
Packets
Acks
12-05-06 Lecture 27: Research Directions 31
TCP Packet Pacing
• Congestion window helps to “pace” the transmission of data packets
• In steady state, a packet is sent when an ack is received• Data transmission remains smooth, once it is smooth• Self-clocking behavior
Pr
Pb
ArAb
ReceiverSender
As
12-05-06 Lecture 27: Research Directions 32
Slow Start Packet Pacing
• How do we get this clocking behavior to start?
• Initialize cwnd = 1• Upon receipt of every ack,
cwnd = cwnd + 1
• Implications• Window actually increases to
W in RTT * log2(W)• Can overshoot window and
cause packet loss
12-05-06 Lecture 27: Research Directions 33
Slow Start Sequence Plot
Time
Sequence No
.
.
.
Packets
Acks
12-05-06 Lecture 27: Research Directions 34
TCP Saw Tooth Behavior
Time
CongestionWindow
InitialSlowstart
Fast Retransmit
and Recovery
Slowstartto pacepackets
Timeoutsmay still
occur
12-05-06 Lecture 27: Research Directions 35
TCP Performance
• Can TCP saturate a link?• Congestion control
• Increase utilization until… link becomes congested• React by decreasing window by 50%• Window is proportional to rate * RTT
• Doesn’t this mean that the network oscillates between 50 and 100% utilization?
• Average utilization = 75%??• No…this is *not* right!
12-05-06 Lecture 27: Research Directions 36
TCP Performance
• If we have a large router queue can get 100% utilization
• But, router queues can cause large delays
• How big does the queue need to be?• Windows vary from W W/2
• Must make sure that link is always full• W/2 > RTT * BW• W = RTT * BW + Qsize• Therefore, Qsize > RTT * BW
• Ensures 100% utilization• Delay?
• Varies between RTT and 2 * RTT
12-05-06 Lecture 27: Research Directions 37
Single TCP FlowRouter with large enough buffers for full link utilization
12-05-06 Lecture 27: Research Directions 38
TCP (Summary)
• General loss recovery• Stop and wait• Selective repeat
• TCP sliding window flow control• TCP state machine• TCP loss recovery
• Timeout-based• RTT estimation
• Fast retransmit • Selective acknowledgements
12-05-06 Lecture 27: Research Directions 39
TCP (Summary)
• Congestion collapse• Definition & causes
• Congestion control• Why AIMD?• Slow start & congestion avoidance modes• ACK clocking
• Packet conservation
• TCP performance modeling• How does TCP fully utilize a link?
• Role of router buffers
12-05-06 Lecture 27: Research Directions 40
Outline – Lec 19
• HTTP review and details (more in notes)
• Persistent HTTP review
• HTTP caching
• Content distribution networks
12-05-06 Lecture 27: Research Directions 41
Persistent HTTP (review)
Nonpersistent HTTP issues:• Requires 2 RTTs per object• OS must work and allocate
host resources for each TCP connection
• But browsers often open parallel TCP connections to fetch referenced objects
Persistent HTTP• Server leaves connection
open after sending response• Subsequent HTTP messages
between same client/server are sent over connection
Persistent without pipelining:• Client issues new request
only when previous response has been received
• One RTT for each referenced object
Persistent with pipelining:• Default in HTTP/1.1• Client sends requests as
soon as it encounters a referenced object
• As little as one RTT for all the referenced objects
12-05-06 Lecture 27: Research Directions 42
Web Proxy Caches
• User configures browser: Web accesses via cache
• Browser sends all HTTP requests to cache
• Object in cache: cache returns object
• Else cache requests object from origin server, then returns object to client
client
Proxyserver
client
HTTP request
HTTP request
HTTP response
HTTP response
HTTP request
HTTP response
origin server
origin server
12-05-06 Lecture 27: Research Directions 43
Content Distribution Networks (CDNs)
• The content providers are the CDN customers.
Content replication• CDN company installs hundreds
of CDN servers throughout Internet
• Close to users• CDN replicates its customers’
content in CDN servers. When provider updates content, CDN updates servers
origin server
in North America
CDN distribution node
CDN server
in S. America CDN server
in Europe
CDN server
in Asia
12-05-06 Lecture 27: Research Directions 44
Consistent Hash – Example
• Smoothness addition of bucket does not cause movement between existing buckets
• Spread & Load small set of buckets that lie near object• Balance no bucket is responsible for large number of
objects
• Construction• Assign each of C hash buckets to
random points on mod 2n circle, where, hash key size = n.
• Map object to random position on circle
• Hash of object = closest clockwise bucket
0
4
8
12Bucket
14
12-05-06 Lecture 27: Research Directions 45
How Akamai Works
End-user
cnn.com (content provider) DNS root server Akamai server
1 2 3
4
Akamai high-level DNS server
Akamai low-level DNS server
Nearby matchingAkamai server
11
67
8
9
10
Get index.html
Get /cnn.com/foo.jpg
12
Get foo.jpg
5
12-05-06 Lecture 27: Research Directions 46
HTTP (Summary)
• Simple text-based file exchange protocol • Support for status/error responses, authentication, client-side state
maintenance, cache maintenance
• Workloads• Typical documents structure, popularity• Server workload
• Interactions with TCP• Connection setup, reliability, state maintenance• Persistent connections
• How to improve performance• Persistent connections• Caching• Replication
12-05-06 Lecture 27: Research Directions 47
Outline
• p2p file sharing techniques• Downloading: Whole-file vs. chunks• Searching
• Centralized index (Napster, etc.)• Flooding (Gnutella, etc.)• Smarter flooding (KaZaA, …)• Routing (Freenet, etc.)
• Uses of p2p - what works well, what doesn’t?• servers vs. arbitrary nodes• Hard state (backups!) vs soft-state (caches)
• Challenges• Fairness, freeloading, security, …
12-05-06 Lecture 27: Research Directions 48
Next Topic...
• Centralized Database• Napster
• Query Flooding• Gnutella
• Intelligent Query Flooding• KaZaA
• Swarming• BitTorrent
• Unstructured Overlay Routing• Freenet
• Structured Overlay Routing• Distributed Hash Tables
12-05-06 Lecture 27: Research Directions 49
Napster: Publish
I have X, Y, and Z!
Publish
insert(X, 123.2.21.23)...
123.2.21.23
12-05-06 Lecture 27: Research Directions 50
Napster: Search
Where is file A?
Query Reply
search(A)-->123.2.0.18Fetch
123.2.0.18
12-05-06 Lecture 27: Research Directions 51
I have file A.
I have file A.
Search in Query Flooding
Where is file A?
Query
Reply
12-05-06 Lecture 27: Research Directions 52
Supernodes: File Insert
I have X!
Publish
insert(X, 123.2.21.23)...
123.2.21.23
12-05-06 Lecture 27: Research Directions 53
Supernodes: File Search
Where is file A?
Query
search(A)-->123.2.0.18
search(A)-->123.2.22.50
Replies
123.2.0.18
123.2.22.50
12-05-06 Lecture 27: Research Directions 54
BitTorrent: Publish/Join
Tracker
12-05-06 Lecture 27: Research Directions 55
BitTorrent: Fetch
12-05-06 Lecture 27: Research Directions 56
DHT: Consistent Hashing
N32
N90
N105
K80
K20
K5
Circular ID space
Key 5Node 105
A key is stored at its successor: node with next higher ID
12-05-06 Lecture 27: Research Directions 57
DHT: Chord Basic Lookup
N32
N90
N105
N60
N10N120
K80
“Where is key 80?”
“N90 has K80”
12-05-06 Lecture 27: Research Directions 58
DHT: Chord “Finger Table”
N80
1/21/4
1/8
1/161/321/641/128
• Entry i in the finger table of node n is the first node that succeeds or equals n + 2i
• In other words, the ith finger points 1/2n-i way around the ring
12-05-06 Lecture 27: Research Directions 59
P2P: Summary
• Many different styles; remember pros and cons of each• centralized, flooding, swarming, unstructured and structured routing
• Lessons learned:• Single points of failure are very bad• Flooding messages to everyone is bad• Underlying network topology is important• Not all nodes are equal• Need incentives to discourage freeloading• Privacy and security are important• Structure can provide theoretical bounds and guarantees
12-05-06 Lecture 27: Research Directions 60
Overview – Lec 22
• Queue management & RED
• Fair-queuing
• Why QOS?
• Integrated services
12-05-06 Lecture 27: Research Directions 61
Typical Internet Queuing
• FIFO + drop-tail• Simplest choice• Used widely in the Internet
• FIFO (first-in-first-out) • Implies single class of traffic
• Drop-tail• Arriving packets get dropped when queue is full regardless of flow
or importance
• Important distinction:• FIFO: scheduling discipline• Drop-tail: drop policy
12-05-06 Lecture 27: Research Directions 62
FIFO + Drop-tail Problems
• Full queues• Routers are forced to have have large queues to
maintain high utilizations• TCP detects congestion from loss
• Forces network to have long standing queues in steady-state
• Lock-out problem• Drop-tail routers treat bursty traffic poorly• Traffic gets synchronized easily allows a few flows to
monopolize the queue space
12-05-06 Lecture 27: Research Directions 63
RED Operation
Min threshMax thresh
Average Queue Length
minth maxth
maxP
1.0
Avg queue length
P(drop)
12-05-06 Lecture 27: Research Directions 64
Max-min Fairness
• Allocate user with “small” demand what it wants, evenly divide unused resources to “big” users
• Formally:• Resources allocated in terms of increasing demand• No source gets resource share larger than its demand• Sources with unsatisfied demands get equal share of resource
12-05-06 Lecture 27: Research Directions 65
Bit-by-bit RR Illustration
• Not feasible to interleave bits on real networks
• FQ simulates bit-by-bit RR
12-05-06 Lecture 27: Research Directions 66
Fair Queuing
• Mapping bit-by-bit schedule onto packet transmission schedule
• Transmit packet with the lowest Fi at any given time
• How do you compute Fi?
12-05-06 Lecture 27: Research Directions 67
Utility Curve Shapes
Stay to the right and youare fine for all curves
BW
U Elastic
BW
U Hard real-time
BW
U Delay-adaptive
12-05-06 Lecture 27: Research Directions 68
Admission Control
• If U is convex inelastic applications
• U(number of flows) is no longer monotonically increasing
• Need admission control to maximize total utility
• Admission control deciding when adding more people would reduce overall utility
• Basically avoids overload
BW
U Delay-adaptive
12-05-06 Lecture 27: Research Directions 69
Type of Commitments
• Guaranteed service• For hard real-time applications• Fixed guarantee, network meets commitment if clients send at
agreed-upon rate
• Predicted service• For delay-adaptive applications• Two components
• If conditions do not change, commit to current service• If conditions change, take steps to deliver consistent performance (help
apps minimize playback delay)• Implicit assumption – network does not change much over time
• Datagram/best effort service
12-05-06 Lecture 27: Research Directions 70
Scheduling for Guaranteed Traffic
• Use token bucket filter to characterize traffic• Described by rate r and bucket depth b
• Use Weighted Fair-Queueing at the routers
• Parekh’s bound for worst case queuing delay = b/r
12-05-06 Lecture 27: Research Directions 71
Token Bucket Filter
Operation:• If bucket fills, tokens are discarded• Sending a packet of size P uses P
tokens• If bucket has P tokens, packet sent
at max rate, else must wait for tokens to accumulate
Tokens enter bucket at rate r
Bucket depth b: capacity of bucket
12-05-06 Lecture 27: Research Directions 72
Lessons
• TCP can use help from routers• RED eliminate lock-out and full-queues problems• FQ heavy-weight but explicitly fair to all
• QoS• What type of applications are there? Elastic, hard
real-time and adaptive real-time• Why do we need admission control to maximize
utility• How do token buckets + WFQ provide QoS
guarantees?
12-05-06 Lecture 27: Research Directions 73
Outline – Lec 24
Yes:
1) Creating a “secure channel” for communication (today)
2) Protecting network resources and limiting connectivity (next Tuesday)
No:
1) Preventing software vulnerabilities & malware, or “social engineering”.
12-05-06 Lecture 27: Research Directions 74
What do we need for a secure communication channel?
• Authentication (Who am I talking to?)
• Confidentiality (Is my data hidden?)
• Integrity (Has my data been modified?)
• Availability (Can I reach the destination?)
12-05-06 Lecture 27: Research Directions 75
The Great Divide
Symmetric Crypto: (Private key)
Example: AES
Asymmetric Crypto:
(Public key)
Example: RSA
Requires a pre-shared secret between communicating parties?
Yes
Overall speed of cryptographic operations Slow
No
Fast
12-05-06 Lecture 27: Research Directions 76
Symmetric Key: Confidentiality
Block 4Block 3Block 2Block 1
Round #1 Round #2 Round #n
Block 1
• Block Ciphers (ex: AES)
K A-B
Alice:
Bob breaks the ciphertext into blocks, feeds it through decryption engine using KA-B to recover the message.
Block 2 Block 3 Block 4
(fixed block size, e.g. 128 bits)
12-05-06 Lecture 27: Research Directions 77
Symmetric Key: Integrity
• Hash Message Authentication Code (HMAC)
Hash FnMessage
MAC Message
Alice Transmits Message & MAC
Why is this secure? How do properties of a hash function help us?
MAC
Step #1:
Alice creates MAC
Step #2 Step #3
Bob computes MAC with message and KA-B to verify.
K A-B
12-05-06 Lecture 27: Research Directions 78
Symmetric Key: Authentication
• A “Nonce”• A random bitstring used only once. Alice sends nonce to Bob as a
“challenge”. Bob Replies with “fresh” MAC result.
Hash Nonce
B4FE64
Bob
K A-B
Nonce
B4FE64
Alice
Performs same hash with KA-B and compares results
12-05-06 Lecture 27: Research Directions 79
Symmetric Key Crypto Review
• Confidentiality: Stream & Block Ciphers• Integrity: HMAC• Authentication: HMAC and Nonce
Questions??
Are we done? Not Really:
1) Number of keys scales as O(n2)
2) How to securely share keys in the first place?
12-05-06 Lecture 27: Research Directions 80
Asymmetric Key Crypto:
• Instead of shared keys, each person has a “key pair”
Bob’s public key
Bob’s private key
KB
KB-1
• The keys are inverses, so: KB-1 (KB (m)) = m
12-05-06 Lecture 27: Research Directions 81
Asymmetric Key: Confidentiality
ciphertextencryptionalgorithm
decryption algorithm
Bob’s public key
plaintextmessage
KB (m)
Bob’s privatekey
m = KB-1 (KB (m))
KB
KB-1
12-05-06 Lecture 27: Research Directions 82
Asymmetric Key Review:
• Confidentiality: Encrypt with Public Key of Receiver
• Integrity: Sign message with private key of the sender
• Authentication: Entity being authenticated signs a nonce with private key, signature is then verified with the public key
But, these operations are computationally expensive*
12-05-06 Lecture 27: Research Directions 83
Key Distribution Center (KDC)
Aliceknows
R1
Bob knows to use R1 to
communicate with Alice
Alice and Bob communicate: using R1 as session key for shared symmetric encryption
Q: How does KDC allow Bob, Alice to determine shared symmetric secret key to communicate with each other?
KDC generates
R1
KB-KDC(A,R1)
KA-KDC(A,B)
KA-KDC(R1, KB-KDC(A,R1) )
12-05-06 Lecture 27: Research Directions 84
Certification Authorities
• Certification authority (CA): binds public key to particular entity, E.
• An entity E registers its public key with CA.• E provides “proof of identity” to CA. • CA creates certificate binding E to its public key.• Certificate contains E’s public key AND the CA’s signature of
E’s public key.
Bob’s public
key
Bob’s identifying
information
CA generates
S = Sign(KB)
CA private
key
certificate = Bob’s public key and
signature by CA
KB
K-1 CA
KB
12-05-06 Lecture 27: Research Directions 85
Setup Channel with TLS “Handshake”
Handshake Steps:
1) Clients and servers negotiate exact cryptographic protocols
2) Client’s validate public key certificate with CA public key.
3) Client encrypt secret random value with servers key, and send it as a challenge.
4) Server decrypts, proving it has the corresponding private key.
5) This value is used to derive symmetric session keys for encryption & MACs.
12-05-06 Lecture 27: Research Directions 86
What to take home?
• Internet design and growth => security challenges• Symmetric (pre-shared key, fast) and asymmetric (key
pairs, slow) primitives provide:• Confidentiality• Integrity• Authentication
• “Hybrid Encryption” leverages strengths of both.• Great complexity exists in securely acquiring keys.• Crypto is hard to get right, so use tools from others, don’t
design your own (e.g. TLS).
12-05-06 Lecture 27: Research Directions 87
Outline – Lec 25
• At every layer in the protocol stack!
• Network-layer attacks• IP-level vulnerabilities• Routing attacks
• Transport-layer attacks• TCP vulnerabilities
• Application-layer attacks
12-05-06 Lecture 27: Research Directions 88
IP-level vulnerabilities
• IP addresses are provided by the source• Spoofing attacks!
• Use of IP address for authentication• e.g., .rhosts allows remote login without explicit
password authentication
• Some IP features that have been exploited• Fragmentation • Broadcast for traffic amplification
12-05-06 Lecture 27: Research Directions 89
Routing attacks
• Divert traffic to malicious nodes• Black-hole attack• Eavesdropping
• How to implement routing attacks?• Distance-Vector
• Announce low-cost routes
• BGP vulnerabilities• Prefix hijacking• Path alteration
12-05-06 Lecture 27: Research Directions 90
TCP-level attacks
• SYN-Floods• Implementations create state at servers before connection is fully
established• Limited # slots get exhausted
• Session hijack• Pretend to be a trusted host• Sequence number guessing
• Session resets• Close a legitimate connection
12-05-06 Lecture 27: Research Directions 91
Denial of Service
• Make a service unusable, usually by overloading the server or network
• Disrupt service by taking down hosts• E.g., ping-of-death
• Consume host-level resources• E.g., SYN-floods
• Consume network resources• E.g., UDP/ICMP floods
12-05-06 Lecture 27: Research Directions 92
Backscatter Analysis
• Attacker is sending spoofed TCP SYN packets to www.haplessvictim.com
• With spoofed address chosen at random
• My network sees TCP SYN-ACKs from www.haplessvictim.com at rate R
• What is the rate of the attack?• Assuming addresses chosen are uniform• (2^32/ Network Address space) * R
12-05-06 Lecture 27: Research Directions 93
Worm Overview
• Self-propagate through network
• Typical Steps in Worm Propagation• Probe host for vulnerable software • Exploit the vulnerability
• E.g., Sends bogus input (for buffer overflow)• Attacker can do anything that the privileges of the buggy program allow
• Launches copy of itself on compromised host
• Spread at exponential rate • 10M hosts in < 5 minutes• Hard to deal with manual intervention
12-05-06 Lecture 27: Research Directions 94
Probing Techniques
• Random Scanning• Local Subnet Scanning• Routing Worm• Pre-generated Hit List• Topological
12-05-06 Lecture 27: Research Directions 95
Firewalls (contd…)
• Firewall inspects traffic through it• Allows traffic specified in the policy• Drops everything else• Two Types
• Packet Filters, Proxies
InternetInternet
Internal NetworkFirewall
12-05-06 Lecture 27: Research Directions 96
Sample Firewall Rule
Dst Port
Alow
Allow
Yes
Any
> 1023
22
TCP22
TCP> 1023
ExtIntOutSSH-2
IntExtInSSH-1
Dst Addr
ProtoAck Set?
ActionSrc PortSrc Addr
DirRule
Allow SSH from external hosts to internal hostsTwo rules
Inbound and outbound
How to know a packet is for SSH?Inbound: src-port>1023, dst-port=22Outbound: src-port=22, dst-port>1023Protocol=TCP
Ack Set?Problems?
SYN
SYN/ACK
ACK
Client Server
12-05-06 Lecture 27: Research Directions 97
Summary
• Security vulnerabilities are real!• Protocol or implementation or bad specs• Poor programming practices• At all layers in protocol stack
• DoS/DDoS• Resource utilization
• Worm• Exponential spread• Scanning strategies
• Firewall/IDS• Counter-measures to protect hosts• Fail-open vs. Fail-close?
12-05-06 Lecture 27: Research Directions 98
Outline – Lec 26
• Point to point wireless networks• Example: Your laptop to CMU wireless• Challenges:
• Poor and variable link quality (makes TCP unhappy)• Many people can hear when you talk
• Pretty well defined.• Ad hoc networks (wireless++)
• Rooftop networks (multi-hop, fixed position)• Mobile ad hoc networks• Adds challenges: routing, mobility• Some deployment + some research
• Sensor networks (ad hoc++)• Scatter 100s of nodes in a field / bridge / etc.• Adds challenge: Serious resource constraints• Current, popular, research.
12-05-06 Lecture 27: Research Directions 99
TCP Problems Over Noisy Links
• Wireless links are inherently error-prone• Fading, interference, attenuation -> Loss & errors• Errors often happen in bursts
• TCP cannot distinguish between corruption and congestion
• TCP unnecessarily reduces window, resulting in low throughput and high latency
• Burst losses often result in timeouts• What does fast retransmit need?
• Sender retransmission is the only option• Inefficient use of bandwidth
12-05-06 Lecture 27: Research Directions 100
Next: CSMA/CD Does Not Work
• Recall Aloha from many lectures ago
• Wireless precursor to Ethernet.
• Carrier sense problems• Relevant contention at the
receiver, not sender• Hidden terminal• Exposed terminal
• Collision detection problems• Hard to build a radio that
can transmit and receive at same time
A
B
C
A
B
C
D
Hidden Exposed
12-05-06 Lecture 27: Research Directions 101
Traditional Routing vs Ad Hoc
• Traditional network:• Well-structured• ~O(N) nodes & links• All links work ~= well
• Ad Hoc network• N^2 links - but many stink!• Topology may be really weird
• Reflections & multipath cause strange interference
• Change is frequent
12-05-06 Lecture 27: Research Directions 102
Sensor System Types – Smart-Dust/Motes
• Hardware• UCB motes• 4 MHz CPU• 4 kB data RAM• 128 kB code• 50 kb/sec 917 Mhz radio• Sensors: light, temp.,
• Sound, etc.,• And a battery.