The Domain Policy DDDS Application

1. Otmar Lendl Otmar.Lendl@enum.at The Domain Policy DDDS Application draft-lendl-domain-policy-ddds-00 draft-lendl-speermint-federations-00 Domain Policy DDDS

2. Domain Policy DDDS Introduction • Interconnect SIP-based networks (enterprise and service providers) directly via SIP • Avoid transcoding, enable wideband codecs • Avoid service limitations (presence, IM, Video, …) • Cost saving • Avoid drawbacks of the open Internet model • Spam/Spit • Lack of trusted CallerID • Selective and controlled association

3. Domain Policy DDDS Evolution (1) VoIP Service Providers interconnect via PSTN using E.164 numbers for addressing VSP VSP VSP VSP VSP PSTN Plane +4315056416

4. Domain Policy DDDS Evolution (2) User ENUM can be used to route calls over the public Internet. Public Internet User ENUM sip:office@enum.at VSP VSP VSP VSP VSP PSTN Plane

5. Domain Policy DDDS Evolution (3) The reality is more complex: Private Interconnection Network Private Interconnection Network sip:office@enum.at VSP VSP VSP VSP VSP Public Internet Closed SIP federation PSTN Plane

6. Domain Policy DDDS Problem Statement • Destination VSP • can be member of several VoIP peering fabrics. • may also accept calls over the Internet from certain parties. • Calling VSP • needs to find a path to the destination VSP. • can also be member of some (potentially different) VoIP peering fabrics. • Trial and Error during call-setup is not a good idea. • Thus he needs to discover which peering fabrics they share. • How does the calling VSP do this?

7. Domain Policy DDDS Proposed Solution • Destination VSP publishes his reachability • List of his federation memberships • Other ways of reaching him • Calling VSPs • Fetches this policy set • Compares this to his own membership list • Protocol • DDDS Application to map domains to policy sets.

8. Domain Policy DDDS Big picture E.164 based dialing starts here • Dialstring normalization • Destination URI Discovery (I-ENUM) • Destination URI Policy Discovery • Path (fabric) selection • Call setup over discovered path • Call admission • … URI based dialing starts here

9. Domain Policy DDDS Federations • A Federation is a group of VoIP service providers / enterprises which • agree to receive calls from each other via SIP • agree on a set of administrative rules for such calls (settlement, abuse-handling, ...), and • agree on specific rules for the technical details of the interconnection. • Federations have a unique identifier

10. Domain Policy DDDS Federation examples • TLS based • Public Internet, SIP over TLS, Federation acts as X.509 Certification Authority. • Private Network • Federation builds its own network (the GRX case), members connect directly over this network. • SIP Hubs / Transit networks • Calls are routed via a central SIP proxy

11. Domain Policy DDDS Domain Policy DDDS basics • The domain is the key to the destination policy • Use the DNS as rule store • No special translation rules necessary • Infrastructure is in place • Example: example.com. IN NAPTR 10 50 "U" "D2P+SIP:fed" "!^.*$!http://sipxconnect.example.org/!" . “Regarding SIP, example.com is a member of the federation identified by this URI.” • Non-terminal NAPTR for customer domains referring to provider domains • Protocol agnostic • SIP is just a special case

12. Domain Policy DDDS Policy Rule Elements • A NAPTR record contains a single policy rule • Examples • A federation membership • draft-lendl-speermint-federations-00 • A technical restriction • e.g. a specific anti-SPIT rule • examples in draft-lendl-sip-peering-policy-00 • A reference to an external policy document • e.g. SAML or XACML

13. Domain Policy DDDS Complex Rule Sets • A NAPTR RRSet defines the policy of a domain. • “order” and “preference” define a Boolean expression of individual policy rules. • Example: $ORIGIN example.com. ; order pref flags service regexp replacement (1) IN NAPTR 10 50 "U" "D2P+SIP:fed" "!^.*$!http://sipxconnect.example.org/!" . (2) IN NAPTR 20 10 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:2246!" . (3) IN NAPTR 20 15 "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3711!" . (1) OR ( (2) AND (3) )

14. Domain Policy DDDS Summary • draft-lendl-domain-policy-ddds-00 solves: • Policy announcement (“I am member of federations X and Y”) • Policy discovery (“I’ll reach the destination through federation Y”) • Enables ad-hoc peering under clearly defined rules • One step towards satisfying the requirements of draft-ietf-speermint-reqs-and-terminology-01 • Out of scope: • Peering rules within federations • It’s not about how to peer, but how to select which peering method/fabric to use.