Subject: [Enum] tel loop detection and prevention

From: "Stastny Richard" <[email-masked]>
Date: Thu, 10 Mar 2005 09:59:58 -0500

Dear all,
 
in yesterday's ENUM wg in conjunction with the enumdi draft the
issue of loop detection and prevention with Enumservices featuring
a tel URI was raised.
 
It was decided to put some text for clarification into the enumdi draft.
 
Although I am still not 100% convinced that this is the perfect place
to clarify the issue, I myself do currently not know of a better place,
since tel URIs are dealt with in different places (msg, vovi).
(maybe it should in addition also be mentioned in the experiences)
 
So I propose to add a section 4.3 to the enumdi draft with the 
following text below:. I include also the existing text of section 4.2
to get the idea:
 
existing text in section 4.2:
 
4.2  Adding the "enumdi" parameter to URIs
   When a VoIP network element accesses ENUM in e164.arpa for a given
   E.164 number and the result of the query is NXDOMAIN, and the network
   element chooses to pass the call to the next network element by using
   a "tel" URI, the "enumdi" parameter MUST be set.
   When a VoIP network element accesses ENUM in e164.arpa for a given
   E.164 number and either:
   o  the result of the query includes a NAPTR RR containing a "tel" URI
      that has the same E.164 number, or
   o  the result of the query includes a NAPTR RR containing a "tel" URI
      with the "enumdi" parameter set,
   then if that retrieved "tel" URI is chosen to be passed to the next
   network element, the sending VoIP network element MUST pass on the
   retrieved URI with the "enumdi" parameter set.
 
New text to be added
4.3 Loop detection and prevention
 
   If the result of the query contains another tel: URI with a different
   E.164 number, the VoIP network element may either choose to pass the
   retrieved "tel:" URI to the next network element with the "enumdi" 
   indicator set or the network element may choose to make another ENUM 
   query with the "tel" URI retrieved, looking for the same Enumservice. 
 
   To prevent endless loops, the network element MUST do only up to 5 such queries 
   until the result is resolved as described in section 4.2. If this is not 
   the case, or a number already queried should be queried again, the call 
   should be dropped by the VoIP network element by signaling back service 
   not available.
 
End of new text
 
regards
Richard

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: David R Oran <[email-masked]>
Date: Thu, 10 Mar 2005 15:45:15 -0500

There are MUCH better ways to deal with the loop issue. See below.
On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote:
Dear all,
New text to be added
4.3 Loop detection and prevention
   If the result of the query contains another tel: URI with a 
different
   E.164 number, the VoIP network element may either choose to pass the
   retrieved "tel:" URI to the next network element with the "enumdi"
   indicator set or the network element may choose to make another ENUM
   query with the "tel" URI retrieved, looking for the same 
Enumservice.

   To prevent endless loops, the network element MUST do only up to 5 
such queries
   until the result is resolved as described in section 4.2.
This is unreasonable (or at least incredibly ugly). Magic numbers 
should be avoided like the plague. Not to mention that it does not 
solve the problem in the distributed case...

Two suggestions:
1) make the enumdi a counter rather than a boolean. It would hold the 
translation count. Note that this is *not* the number of calls to some 
enum resolution service, but rather then number of translations that 
have been done. This will be the same if the caller is querying 
directly via a dns resolver, but may result in a count higher than 1 if 
there is some kind of recursive lookup client API on the system doing 
the enum translations.
2) Base the loop detect on the counter.

A dumb client can just decide on a maximum value as part of its 
configuration. We could suggest a default value, but that is different 
from mandating a constant value as a magic number. However, this is 
actually not necessary - those interested read on.

I mentioned privately to a few people that there is a really elegant 
way to detect loops of the sort introduced by cyclic database pointers 
in a distributed database (like DNS). I used in a distributed naming 
service I designed about 20 years ago, and it worked like a charm. It's 
based on an algorithm in Vol.1 of Knuth which everybody reads and then 
promptly forgets in their CS training. It's called "even-odd iteration 
counting" - go look it up.

It has the following wonderful properties.
a) works in constant memory (two string variables)
b) never falsely detects a loop in a long translation chain
c) detects all loops of degree 2 immediately
d) detects all loops of degree 3 after one time around the loop
e) detects a loop of arbitrary degree after traversing the loop no more 
than 3 times.

Dave.
If this is not
   the case, or a number already queried should be queried again, the 
call
   should be dropped by the VoIP network element by signaling back 
service
   not available.

End of new text
regards
Richard
_______________________________________________
Iptel mailing list
Iptel at ietf.org
https://www1.ietf.org/mailman/listinfo/iptel
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran at cisco.com
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 10 Mar 2005 16:13:13 -0500

Good suggestion.
  paf
On Mar 10, 2005, at 13:32, David R Oran wrote:
There are MUCH better ways to deal with the loop issue. See below.
On Mar 10, 2005, at 10:01 AM, Stastny Richard wrote:
Dear all,
New text to be added
4.3 Loop detection and prevention
   If the result of the query contains another tel: URI with a 
different
   E.164 number, the VoIP network element may either choose to pass 
the
   retrieved "tel:" URI to the next network element with the "enumdi"
   indicator set or the network element may choose to make another 
ENUM
   query with the "tel" URI retrieved, looking for the same 
Enumservice.

Two suggestions:
1) make the enumdi a counter rather than a boolean. It would hold the 
translation count. Note that this is *not* the number of calls to some 
enum resolution service, but rather then number of translations that 
have been done. This will be the same if the caller is querying 
directly via a dns resolver, but may result in a count higher than 1 
if there is some kind of recursive lookup client API on the system 
doing the enum translations.
2) Base the loop detect on the counter.

I mentioned privately to a few people that there is a really elegant 
way to detect loops of the sort introduced by cyclic database pointers 
in a distributed database (like DNS). I used in a distributed naming 
service I designed about 20 years ago, and it worked like a charm. 
It's based on an algorithm in Vol.1 of Knuth which everybody reads and 
then promptly forgets in their CS training. It's called "even-odd 
iteration counting" - go look it up.

e) detects a loop of arbitrary degree after traversing the loop no 
more than 3 times.

Dave.
If this is not

End of new text
regards
Richard