Examining Session Policy Topologies

1. Examining Session Policy Topologies • Rohan Mahy • rohan@cisco.com

2. Typical Applications • Cooperative NAT and Firewall Traversal • Bandwidth / Media / Codec Policy • Logging

3. Explicit Policy Fetch atlanta.com biloxi.com • Works great when policies don’t depend on who you call, or dynamic properties like load. • Obviates the need to mucking with typical INVITE flow much of the time. Still need another solution. Alice Bob

4. Full Redirect Model atlanta.com biloxi.com • Minimal session policy possible • Doesn’t work at all through middleboxes • Doesn’t work with the GRUU mechanism Alice Bob

5. Triangle Redirect Model atlanta.com biloxi.com • Most preferred model when allowed by policy • Incompatible with policy requirements of many organizations Alice Bob

6. Trapezoid Redirect Model atlanta.com biloxi.com • Adds lots of extra RTTs • Unclear what Alice is consenting to and how she can authorize the inclusion of arbitrary opaque data if this implies her “consent” • Reveals information potentially private between Bob and biloxi.com Alice Bob

7. Foreign Piggyback Model atlanta.com biloxi.com • Meets both Alice’s and Bob’s consent requirement without leaking Bob’s data to Alice • Fewer RTTs • Requires Addition of bodies by biloxi.com. Backward compatible using “repack” option-tag (more on this later) • Security is better. Authorization by Alice is simple • Can also address AOR—Contact correlation problem Alice Bob

8. Full Piggyback Model atlanta.com biloxi.com • Doesn’t permit Alice to consent to modifications/insertions made by atlanta.com Alice Bob

9. Adding Bodies Safely:Secure and Backwards Compatible • biloxi.com may only add a body to a request when retargeting to a UAS registered in the biloxi.com domain (for example: Bob). Never responses. • Any additions are always marked as “added-by” biloxi.com. Biloxi either signs its additions with S/MIME or forwards them directly over TLS to Bob • Bob includes an option-tag in a REGISTER to indicate it supports body repacking. • Q: Is this secure? See the Contact—AOR correlation problem…

10. Contact Correlation Problem • How does Alice know that <sip:line2@17.18.32.4> (a contact) corresponds to <sip:bob@biloxi.com> (an AOR)? • Not really a problem in a triangle topology. Slightly problematic in a trapezoid if either user is roaming. (Alice is using what appears to be a hotel lobby wireless network with a mandatory SIP proxy. No way to automatically judge trust of this proxy) • Obvious solution is request history. Proxies that retarget, provided signed “cookie trail” to the eventual Contact. • Works with proposal to add/repack bodies

11. Addressing Requirements with Foreign Piggyback • Session Policies of UAC and UAS are independent (only one needs to support session policies) • Consent principle still applies • Works even better when used in concert with out-of-band mechanism (STUN for NATs, SUB/NOT for more general policies)

12. Midbox traversal–offer in INV atlanta.com biloxi.com • Alice can try to get STUN/TURN addresses • If address in offer are not valid, atlanta sends 4xx proposing new addresses; if they are valid, open pinholes/create bindings • Bob can try STUN to fetch addresses • biloxi adds proposed answer for Bob, and forwards • Bob responds with an answer for Alice, and (in NAT case) can include Bob’s actual addresses Alice Bob

13. Midbox traversal–late offer atlanta.com biloxi.com • biloxi adds either proposed generic offer for Bob or address of STUN server, and forwards • Bob responds with an offer for Alice, and (in NAT case) can include Bob’s actual addresses • Alice can try to get STUN/TURN addresses, sends addresses in answer in PRACK or ACK Alice Bob