1. Examining Session Policy Topologies
Rohan Mahy

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

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

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

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

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

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

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

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 (a contact) corresponds to (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
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

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