1. Securely Enabling Intermediary-based Transport Services Presented by Thomas Woo Bell Labs, Lucent Technologies U. Blumenthal, I. Faynberg, S. Kasera, S.Mizikovsky, G. Sundaram and T. Woo

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

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

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

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

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 VPN Client Enterprise VPN Gateway Wireless Access Network Internet Attacker sends address-spoofed, IPSec encrypted packets to mobile user Packet Filter Attacker 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)] Packet Filter Multi-layer Video Unicast Drop Lower Priority Layers Video Server Video Receiver Congested Link

20. Multimedia Packet Differentiation (cont’d) Dramatic improvement in video quality High frequency subbands Low frequency subbands Grey level shows amount of data received in 5 frames: l 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

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