Securely Enabling Intermediary-based Transport Services

Presented by Thomas WooBell Labs, Lucent Technologies

U. Blumenthal, I. Faynberg, S. Kasera, S.Mizikovsky, G. Sundaram and T. Woo

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

TransportService

Intermediary

Wired Network

TCP Connection

Mobile User

Server

Wireless Access Link

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 betweenEnd-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

TCPPEP

Wired Network

TCP Connection

Mobile User

Data

Regulated AcksAcks

Server

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 end-points would prevent header compression at an intermediate node

Can we support header compression and have good securityat 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

VPNClient

EnterpriseVPN Gateway

Wireless Access

Network

Wireless Access

NetworkInternet

Attacker sends address-spoofed, IPSec encrypted packets to mobile user

PacketFilter

Attacker

End-to-EndIPSec Tunnel

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 intermediary-based 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)]

Packet Filter

Multi-layer Video Unicast

Drop Lower Priority Layers

VideoServerVideo

Receiver

Congested Link

Multimedia Packet Differentiation (cont’d)

Dramatic improvement in video quality

High frequency subbands

Low frequency subbands

Grey level shows amountof data received in 5 frames: white: nothing received black: everything received

time

No Differentiated Packet Treatment: plain queuing

Differentiated Packet Treatment: dropping low priority layers

*slide is taken from Keller et. al.’s INFOCOM 2000 presentation

Multimedia Packet Differentiation (cont’d)

Plain – No differentiated packet filtering

Active – Differentiated dropping of low priority layers

Burst – Congestion burst

Reaction to bursts

0102030405060

0 2 4 6 8 10 12 14 16time

PS

NR

0

1000

2000

3000

4000

5000

kbps

Plain

Active

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