Examining Session Policy Topologies Rohan Mahy rohan@cisco.com

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

Explicit Policy Fetch atlanta.com biloxi.com Alice Bob 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.

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

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

Trapezoid Redirect Model atlanta.com biloxi.com Alice Bob 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

Foreign Piggyback Model atlanta.com biloxi.com Alice Bob 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

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

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…

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

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)

Midbox traversal–offer in INV atlanta.com biloxi.com Alice Bob 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

Midbox traversal–late offer atlanta.com biloxi.com Alice Bob 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