Private ENUM Source URI draft-kaplan-enum-source-uri-00

1
Private ENUM Source URIdraft-kaplan-enum-source-u
ri-00
Hadriel Kaplan hkaplan_at_acmepacket.com Robert H.
Walter rwalter_at_netnumber.com Raja
Gopal raja.gopal_at_nominum.com Tom
Creighton tom_creighton_at_cable.comcast.com
2
The Problem

• Private ENUM is popular inside providers
• Primarily for request routing, but also for
  number portability resolution and number
  translations
• As a call routing query mechanism, it is missing
  one very popular need source-based queries
• Not based on the device doing the query, but
  based on the identity originating the application
  request (SIP/H.323/etc) which triggers the ENUM
  query
• For example if sipme_at_a.com wants to reach
  sip1234567890_at_a.com, response is NAPTR-a but
  if source sipyou_at_bar.com wants the same,
  response is NAPTR-b
• This is NOT a public ENUM issue

3
The Proposed Solution

• Add the application source URI (SIP/SIPS/TEL)
  into the ENUM DNS request, for private ENUM
• Defines an OPT-RR (EDNS0) for the source URI
  string
• ENUM server then has this information at hand, if
  it wishes to change the response based on it
• One can think of it as defining a mechanism
  similar to current use of DNS views, but much
  more flexible, or as if the ENUM server holds all
  answers and client is offering info to filter
  them
• But only within a private use model

4
Why not LDAP/SQL/whatever?

• DNS as a protocol for DB query is more efficient
• Fewer messages, simpler parsing, smaller and
  better defined schema, UDP based, anycasting
  ability, hierarchical, etc.
• Some of those are the same reasons why SIP
  Redirects arent as good as ENUM
• Private ENUM is the elephant in the room
• Its far more popular than public ENUM

5
Security Issues

• The draft ignores security that will be fixed
• But the reality is this is for a private network
  use case, where only authorized clients can make
  the requests and get responses, and the links are
  considered secure

6
Benefits

• Trivially simple
• Fairly flexible (URI format allows extensibility,
  i.e. params)
• Addresses the need, for private ENUM use only

7
Problems

• EDNS0 is not a great model for this
• It is used below the database layer, for
  generic capabilities of the client/server, not as
  application-layer info for the query lookup
  itself
• EDNS0 is hop-by-hop, but that may be the right
  semantic for this in some ways
• There is no API for this type of info in typical
  OS DNS client code
• Thats almost a benefit this is for private,
  specific use

8
Issues

• This is NOT appropriate for public ENUM, or DNS
  in general
• How do we make that clear?
• Is this a slippery slope? Source URI today,
  codec info tomorrow?
• We dont think so
• Which WG is appropriate for this? Should this be
  informational or standards track?