Session Border Controllers – use with caution

1. Session Border Controllers – use with caution Henning Schulzrinne Dept. of Computer Science Columbia University (SIP Summit 2005, Honolulu, Hawaii)

2. Overview • SBCs as transient phenomena? • Motivations • SBC – the cost of convenience

3. Network evolution earlier: email, IM SBC only IP-level (with filter)

4. High-level motivations • Why application-layer elements in SIP that are not quite proxies? • SMTP has various MTAs, but they are just MTAs (e.g., spam filter) • Guesses: • media vs. control separation • good idea in theory, harder in today’s limited-functionality Internet • see Asterix, Skype • proxy model of no content (SDP) inspection or modification too limited • CALEA (needs to be invisible) • charging for services • not an issue for email and web

5. Motivations • Short term (hopefully) • SIP “fix up” or “dumbing down” • brute-force NAT traversal • Long term needs • fire wall control • billing enforcement

6. The dangers • May not be present in all instances • SBCs are a box description, not a function description • Lack of visibility • cannot tell where SBC is located • hard to diagnose failures • see HTTP “transparent proxy” experience • one example: TP thought SIP was HTTP • hard to address content cryptographically to such box • Lack of transparency • not all features make it through SBC • header support • copying content • routing loops • Lack of security • Inherent conflict between need for media session inspection and session privacy • Session description modification removes accountability • Lack of scalability