Download PPT Version

Securely Enabling Intermediary-based
Transport Services
U. Blumenthal, I. Faynberg, S. Kasera,
S.Mizikovsky, G. Sundaram and T. Woo
Presented by Thomas Woo
Bell Labs, Lucent Technologies
Summary
 We provide motivations and problem statement of
securely enabling intermediary-based transport
services
 We present several concrete examples to highlight
the problem
 We invite discussions on further defining the
problem, and possible solutions
Motivation
 “Access’’ links mostly refer to wireless links
– 3G (UMTS, CDMA 2000)
– 802.11
– Satellite
but applies also to wireline links such as dialup and even cable
 These links exhibit many problems that affect end-to-end
transport-level performance
– High loss: up to 10-2
– High latency and variability of latency: up to 100s of ms
– Low bandwidth
– Variable bandwidth: adaptive multi-rate
– Intermittent connectivity: temporal signal lull due to mobility
Motivation (cont’d)
 Intermediary-based transport services can help
mitigate many transport-level problems of access
links
 Examples:
– TCP PEPs (RFC 3135)
– Triggers for Transport
Mobile
User
Server
Wireless
Access Link
Wired Network
Transport
Service
Intermediary
TCP Connection
Problem Statement
 To perform its function, an intermediary may need to:
– Signal to the end points
– Inspect or even modify the traffic sent between the end points
 Threats:
– An attacker can send bogus signals to end points
– Existing end-to-end security may be compromised
• An attacker can gain unauthorized access to end to end traffic
 Need to securely enable intermediary-based transport
services while minimizing impact on end-to-end security
– Solicitation and configuration of services
– Security relationships between end-points, intermediary
Solicitation and Configuration of Service
 Service discovery
– Especially important for mobile users
 Service consent
– End-points must consent to service offered
 Service configuration
– End-points, intermediary exchange parameters for
configuring services
 Transfer of state
– Transfer service related state from one intermediary to
another in the event of impending failure, load-balancing, or
due to user mobility
Security Relationships between
End-points, Intermediary
 Signaling aspect
– Establish security relationship between end-points and
intermediary
• Authenticate and authorize trusted intermediary
• One-to-one vs one-to-many
– Securely exchange control information
 Data aspect
– Securely reveal selected packet information to authorized
intermediaries for processing (inspection and/or modification as
authorized)
Example 1: TCP Enhancements
 Problem: Large wireless link delay variance causes
degradation in TCP throughput
 Solution: TCP PEP [RFC3135]
 Example: Ack Regulator [Mobicom 2002]
– regulate acks from mobile user at intermediary to account
for downlink delay variance
Mobile
User
Server
TCP
PEP
Wired Network
Data
Regulated Acks
Acks
TCP Connection
Example 1: TCP Enhancements (cont’d)
 Requirement: AR mechanism relies on TCP header
information
– TCP port numbers for flow identification
– TCP sequence number for ACK pacing
How do we securely enable TCP PEP service such as AR?
Example 2: Header Compression
 Problem: Access link bandwidth tends to be limited
 Solution: Header compression/decompression close
to access link with the help of an intermediary could
be used [RFC 1144, RFC 2507, RFC 3095, SRTP]
 An end-to-end IPsec tunnel between the two endpoints would prevent header compression at an
intermediate node
Can we support header compression and have good security
at the same time?
Example 3: Network-based Packet Filtering
 Problem: Spoofed IPsec packets to VPN client can consume valuable
transport resources, especially in bandwidth-limited wireless links
 Solution: Network-based packet filtering
 Issue: Client mobility requires dynamic configuration, invocation and
revocation of network-based filters
Attacker sends address-spoofed,
IPSec encrypted packets to mobile user
VPN
Client
Attacker
Enterprise
VPN Gateway
Wireless
Access Packet
Network Filter
End-to-End
IPSec Tunnel
Internet
Example 4: Triggers for Transport
 Problem: An access link can go up, go down and change rate
 Solution: TrigTran intermediary to notify transport end systems of
such events
 Issue: Such notifications should be performed in a secure manner
See next presentation
Issues to Explore in Architecture
 Characteristics of intermediary-based transport services
– Their need for packet processing and signaling
 Support for multiple intermediaries in an end-to-end path?
 One-to-one vs one-to-many security relationship
 Association of intermediary with “access” links
 How to minimize the impact on end-to-end security?
 Protocol Functions
– How to reliably and securely configure, invoke and revoke intermediarybased transport services from the end systems?
– How does the intermediary obtain the information needed to offer
services?
 Applicability of existing mechanisms, e.g., IKE for key exchange?
Conclusion
 Our draft:
– Describes the problem of securely enabling intermediary-based
transport services
– Identifies example scenarios
BackUps
TCP Enhancements
 Problem: Large wireless link delay variance causes
degradation in TCP throughput
TCP Enhancements (cont’d)
AR improves throughput significantly over Reno, Sack (up
to 50%)
Higher proportional improvement at smaller buffer size
AR throughput improvement robust against buffer size
Intuition
 TCP's window-based congestion control functions by estimating
the available bandwidth-delay product. A loss happens when
the congestion window exceeds the available bandwidth-delay
product (BDP)
 Large delay and/or rate variation causes the available BDP to
vary as well. Thus, TCP's window-based congestion control may
trigger a loss even when the congestion window is significantly
below the "average" BDP but larger than the instantaneous BDP
 If the instantaneous BDP shrinks by sufficiently large amount,
multiple packets can be lost at the same time, causing further
window backoff and even timeouts
Multimedia Packet Differentiation
 Example: Differentiated packet treatment based on
network congestion condition using multimedia transport
header [Keller et al (Infocom 2000)]
Video
Server
Video
Receiver
Congested Link
Packet
Filter
Drop Lower
Priority Layers
Multi-layer Video Unicast
Multimedia Packet Differentiation (cont’d)
No Differentiated Packet Treatment: plain queuing
High frequency subbands
Low frequency subbands
Differentiated Packet Treatment: dropping low priority layers
Grey level shows amount
of data received in 5 frames:
 white: nothing received
 black: everything received
time
Dramatic improvement in video quality
*slide is taken from Keller et. al.’s INFOCOM 2000 presentation
Multimedia Packet Differentiation (cont’d)
60
50
40
30
20
10
0
5000
4000
3000
2000
1000
kbps
PSNR
Reaction to bursts
Plain
Active
Burst
0
0
2
4
6
8 time 10
12
14
16
Plain – No differentiated packet filtering
Active – Differentiated dropping of low priority layers
Burst – Congestion burst
Header Compression Benefits
 TCP/IP headers reduced from 40 octets to 4 octets
(RFC 2507)
– 6% savings for 576 octet packets but 90% savings for ACK
only packets
 RTP/UDP/IP headers reduced from 40 bytes to 1
octet under steady state (RFC 3095)
– 65% savings for 60 octet speech packets