[Dundi] [RFC] GPA accountability/recourse and potential protocol addition

[Kevin P. Fleming]

Please forgive me if I'm rehashing old conversations that happened 
before this list was created; if they occurred, there are no archives, 
and I wasn't involved :-) I suspect the issues I raise are a big reason 
why the dundi-test context exists, but I want to be sure I understand 
the GPA and its terms.

We recently started peering our network with others, both for dundi-test 
and e164. We received a small number of calls today, which I suspect are 
not legitimate. The routes we publish, including the route to the TN in 
question, are marked as "no unsolicited" calls.

However, the fact that the call arrived from an unknown (to us) IP 
address, and that the call setup information is not required to contain 
any GPA-related details, means I cannot trace back these calls to their 
source. At best, I can trace them to the purported owner of the IP 
address they came from, but that is all.

It seems that the only recourse, should we receive VOIP spam or other 
abuse of our routes, is to publish the offending IP address on this list 
or the dundi IRC channel, and hope that _every_ member of the "trust 
group" looks at their systems to see if that IP address is someone they 
peer with, and then if it is, take some action to help us address the 
situation. That is an awful lot to ask of the "trust group", especially 
once it gets larger, more widespread and given the time-sensitive nature 
of the situation. Sure, I can put in an IP block to stop the calls, 
presuming that all calls from that peer should be stopped, but I still 
have no effective means of communicating with the peer that is 
originating the traffic.

For us, as an ITSP publishing routes to end-user TNs, this is not 
acceptable. If we publish the route as "no unsolicited" calls, we better 
have some means of quickly addressing an end-user's complaint about 
receiving such calls, or we are likely to lose the customer.

I don't know of a good solution to this, although I can think of one 
possibility: if there was a way to query for an _IP address_ through the 
peering network, so that any peers that are communicating with that IP 
address could supply its EID, then I can do a query on the EID to obtain 
contact information. If this IP->EID query does not result in useful 
contact information, then I won't feel bad about blocking the IP 
entirely. If it does, I can then take action to contact the peer in 
question, so that they can address the issue.

So, in summary: we need some means of identifying the source EID for 
calls that arrive at our DUNDi entry point. If it can't be done via the 
call setup protocol (which would not be easy to do), then there should 
be a way to "deduce" what the source EID is based on the evidence 
available. A simple:

cli> dundi ipquery xxx.xxx.xxx.xxx

would suffice; all peers that have that IP address currently in their 
active peer list would respond with its EID.