1 / 10

To add bodies or not? …that is the question

To add bodies or not? …that is the question. Rohan Mahy rohan@cisco.com. Typical Applications. Logging Bandwidth / Media / Codec Policy Cooperative NAT and Firewall Traversal Request History Location Conveyance. Explicit Policy Fetch. atlanta.com. biloxi.com.

lantaylor
Télécharger la présentation

To add bodies or not? …that is the question

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. To add bodies or not?…that is the question • Rohan Mahy • rohan@cisco.com

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

  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

More Related