Securely Enabling Intermediary-based Transport Services

1. 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

2. 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

3. Motivation • “Access’’ links mostly refer to wireless links • 3G (UMTS, CDMA 2000) • 802.11 • Satellitebut 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

4. 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 Server Mobile User Wireless Access Link Wired Network Transport Service Intermediary TCP Connection

5. 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

6. 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

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

8. Example 1: TCP Enhancements Mobile User Server Wired Network TCP PEP Data Regulated Acks Acks TCP Connection • 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

9. 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?

10. 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 security at the same time?

11. 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 Attacker Enterprise VPN Gateway VPN Client Wireless Access Network Packet Filter Internet End-to-End IPSec Tunnel

12. 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

13. 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?

14. Conclusion • Our draft: • Describes the problem of securely enabling intermediary-based transport services • Identifies example scenarios

15. BackUps

16. TCP Enhancements • Problem: Large wireless link delay variance causes degradation in TCP throughput

17. 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

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

19. 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 Packet Filter Congested Link Drop Lower Priority Layers Multi-layer Video Unicast

20. 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 amountof 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

21. Multimedia Packet Differentiation (cont’d) Plain – No differentiated packet filtering Active – Differentiated dropping of low priority layers Burst – Congestion burst

22. 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