[Dundi] iDUNDi

[John Todd]

The use of DUNDi for number lookup is a good start in the global 
scheme of route lookups.  I'm not convinced it's the last, best, or 
only protocol to do such lookups, but I'm pleased so far with most of 
the concepts that the system uses, insofar as it's actually getting 
people to think about VoIP interconnection protocols.  "Running code 
and rough consensus."

What is one of the most concerning issues about VoIP interconnection 
is authentication of origin, or at least the ability to reliably 
associate a call with an origin and then filter appropriately.  We're 
still woefully incapable of taking calls from the "wide open 
Internet" and ensuring that they are originating from a server that 
is at least in some minimal way "allowed" to send those calls.

It seems natural to me that a DUNDi speaker is well-placed to do 
inverse queries on the e.164 ANI of inbound calls, and choose to 
handle those calls based on the results.  For lack of a better term, 
I call it "inverse DUNDi", or "iDUNDi".  This is similar to RPF with 
some routers, or similar (but nowhere near equivalent) to SPF for 
email.

The tagging of outbound calls with DUNDi keys is an excellent method 
that provides some verification of origin, but it doesn't say 
anything about the origin ANI to my knowledge.  The GPA states that 
the sender must have accurate ANI, as stated in section 10.  This 
simply turns "good faith" into "must have" in circumstances where the 
receiver tries to verify the origin.

This would mean creating a new DUNDi object type, which I describe 
incompletely below:

Key in request: e.164 number request
Reply:
  - EID
  - host identification (some or all could be returned):
       - IP address list (CIDR notation)
       - domain list (regexps allowed, or specific host entries)
       - port (integer, or range)
       - protocol (integer)


So, a typical process would look like this:

Ast1:  (via DUNDi) "I have a call coming in from 448451249068.  Who 
claims responsibility for that number?"

Ast2:  (via DUNDi) "I do.  The only hosts that should be originating 
call requests using that number as an ANI should have a hostname of 
proxy1.example.com or asterisk.example.com.  The calls should be IAX 
on port 5036 or SIP on port 5060 only."

Ast1:  (to itself): "Hmm... I see this call request is coming in from 
10.10.33.12, which has reverses that map to asterisk.example.com, and 
the forwards then also map to asterisk.example.com, so I'll let the 
call proceed.  I'm configured to not really care what port or 
protocol it came in on, so I'll ignore those bits of data."


   These replies would be cached, just like the forward DUNDi lookups. 
There would be more data involved in caching these replies, which is 
a downside.

   In Asterisk, at least, this could be done I think without too much 
difficulty, and could be used as a front-end for SIP proxies that 
didn't have DUNDi capability.   This is a separate process than an 
outbound call, and could be easily used to backwards-verify calls 
that perhaps didn't even originate from a DUNDi query.  I don't quite 
have an answer on how SIP would integrate into this - the trick is 
that originating IP address of the query might not be the originating 
domain inside of the SIP message, but perhaps they'd both have to be 
in the DUNDi reply.

   Who knows?  Maybe DUNDi will see just as much (exactly as much?) 
use as a distributed filter for inbound calls as much as it is used 
for a routing protocol for forward lookups.

   This concept may have already been discussed off-line (nobody ever 
has an original idea with Asterisk, eh?) but I didn't see anything in 
public so I'll mention it here for overview and comments.

JT