Subject: [Enum] Re: [Iptel] tel loop detection and prevention

From: "Stastny Richard" <[email-masked]>
Date: Thu, 10 Mar 2005 14:45:33 -0500

David,
 
On the counter in enumdi:
 
Basically the enumdi is used in signalling between VoIP network elements
the loop need to be detected WITHIN a VoIP network element before the
enumdi is set, so this counter does not help there
In addition the counter issue was discussed last meeting and rejected.
 
On the "magic" solution:
Please propose text to be put into the draft
and not home work for editors
 
Or should we put the following text in the I-D:
 
If you want to detect loops, go read Vol.1 of Knuth ?
 
Richard

________________________________

Von: David R Oran [mailto:oran at cisco.com]
Gesendet: Do 10.03.2005 20:32
An: Stastny Richard
Cc: iptel at ietf.org; enum at ietf.org
Betreff: Re: [Iptel] tel loop detection and prevention

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: lconroy <[email-masked]>
Date: Thu, 10 Mar 2005 15:15:31 -0500

Hi Dave, Richard, Juha, folks,
I'm also glad that someone else has finally commented on something 
that's
been in the ENUM Experiences draft since 2003 - I'm very happy if we can
improve that, as the "depth limit" of 5 is (and always has been) a 
kludge.
----
Re. the even-odd solution:
I had thought that "even-odd" required distributed control - in the case
of ENUM the nasty cases occur when the zones are under completely 
independent
control and the NAPTRs they contain may not include this flag -at all-.

I'd greatly appreciate a clarification one the use of this algorithm, 
as it
is an *awful* long time since I looked at that fine book, and I 
obviously
didn't understand it (or have miss-remembered it).

----
I'm afraid that I disagree with my learned co-author on the proposed 
text.

(i)  The broken behaviour is a proxy that does an ENUM look up when it
     receives a tel: URI but then stops and just passes the result 
onwards.
     It either handles a tel: URI or it doesn't. If it re-tried until it
     found a URI it liked, or detected a loop (NXDOMAIN is already 
covered),
     the problem wouldn't occur.

(ii) This is an ENUM "Dip" Indicator flag. It indicates that the element
     has done an ENUM query on this telephone number, or otherwise KNOWS
     that there is no useful data associated with it in ENUM. Of course,
     the sending element may always lie. It may not have done an ENUM
     query at all on the number. It might choose to do this to force the
     receiving element to place a call to the PSTN or fail. However, 
that
     is not a compliant use of this flag - you can lie, but it's a lie.

Thus, if we MUST allow broken proxies to push the problem onwards, then
I believe that the 1st paragraph for 4.3 will have to be:
------------
   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
   original "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.
------------
i.e. the proxy MUST NOT pass on a request with the TEL: URI it has 
retrieved
from ENUM with the enumdi flag set, as that would be a lie.

Instead, the original TEL: URI is passed on, with the flag set. This is 
the
number it HAS checked in ENUM.

all the best,
  Lawrence
On 10 Mar 2005, at 19:47, Stastny Richard wrote:
David,
On the counter in enumdi:
Basically the enumdi is used in signalling between VoIP network 
elements
the loop need to be detected WITHIN a VoIP network element before the
enumdi is set, so this counter does not help there
In addition the counter issue was discussed last meeting and rejected.

On the "magic" solution:

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.

---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
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

On Mar 10, 2005, at 2:47 PM, Stastny Richard wrote:
David,
On the counter in enumdi:
Basically the enumdi is used in signalling between VoIP network 
elements
the loop need to be detected WITHIN a VoIP network element before the
enumdi is set, so this counter does not help there
I disagree. If the translator does not traverse the entire cycle before 
stopping and forwarding the invite, you can still get loops. If you 
don't want to have a counter, the spec then has to say that a 
translator MUST continue doing translations until it either gets a 
non-TEL url or detects a loop and gives up.

In addition the counter issue was discussed last meeting and rejected.
I remember the discussion and recall that we did not consider the 
distributed case at that time. Now that Juha has brought up the need to 
support the distributed case, the distributed loop detect question 
needs to be revisited  since now loops are not automagically suppressed 
by a boolean dip indicator.

On the "magic" solution:
Please propose text to be put into the draft
and not home work for editors
What I suggested is that the loop max be either
a) configured on the proxy
b) rendered unnecessary by implementing a loop-detect algorithm that 
does not require configuration of a maximum degree parameter.

Or should we put the following text in the I-D:
If you want to detect loops, go read Vol.1 of Knuth ?
Sort of. Say you MUST detect loops. Say that there is no 
architecturally-mandated translation chain maximum. Say that if you can 
live with occasional false loop detections for the (hopefully uncommon) 
case of high-degree loops, you can implement a translation-max which 
you compare with the enumdi count, but that if you want to avoid false 
detections, you can implement something fancier, such as the scheme in 
Vol.1 or Knuth.

Cheers, Dave.
Richard

---

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

On Mar 10, 2005, at 3:15 PM, lconroy wrote:
Hi Dave, Richard, Juha, folks,
I'm also glad that someone else has finally commented on something 
that's
been in the ENUM Experiences draft since 2003 - I'm very happy if we 
can
improve that, as the "depth limit" of 5 is (and always has been) a 
kludge.
----
Re. the even-odd solution:
I had thought that "even-odd" required distributed control - in the 
case
It works better if you send the values of the two memory cells instead 
of the count (since the count has only tell you if you are in the even 
or odd part of the chain when you forward). Since you are in fact 
forwarding MAx-forwards will eventually suppress the chain. In the 
absence of max-forwards as a backup you would be right that a counter 
is insufficient state to encode into the forwarded message.

Sure.

Did the above help?
----

     It either handles a tel: URI or it doesn't. If it re-tried until 
it

Correct. This was the point I made in a message I sent a little while 
ago.

(ii) This is an ENUM "Dip" Indicator flag. It indicates that the 
element
     has done an ENUM query on this telephone number, or otherwise 
KNOWS
     that there is no useful data associated with it in ENUM. Of 
course,
     the sending element may always lie. It may not have done an ENUM
     query at all on the number. It might choose to do this to force 
the
     receiving element to place a call to the PSTN or fail. However, 
that
     is not a compliant use of this flag - you can lie, but it's a lie.

Unless we change it to a count...
Instead, the original TEL: URI is passed on, with the flag set. This 
is the
number it HAS checked in ENUM.

What does this mean, exactly? Your above says is means "the number in 
the uri was input to an enum query". I thought it was supposed to mean 
"the number in the uri was the RESULT of an enum query.

I don't see what good this does Juha if it's the  input, not the 
output. Or perhaps I misunderstood what Juha was asking for.

Dave.
all the best,
  Lawrence

On the "magic" solution:

directly via a dns resolver, but may result in a count higher than 1 
if

service I designed about 20 years ago, and it worked like a charm. 
It's

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

Dave.
If this is not

---

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

On Mar 10, 2005, at 14:24, David R Oran wrote:
If you want to detect loops, go read Vol.1 of Knuth ?
Sort of. Say you MUST detect loops. Say that there is no 
architecturally-mandated translation chain maximum. Say that if you 
can live with occasional false loop detections for the (hopefully 
uncommon) case of high-degree loops, you can implement a 
translation-max which you compare with the enumdi count, but that if 
you want to avoid false detections, you can implement something 
fancier, such as the scheme in Vol.1 or Knuth.
Yes.
We have to disconnect the existence of the protocol parameter enumdi 
(in the future) and the need for loop detection. Loop detection can 
possibly be done in many ways.

I.e. a network element that receive some signalling and know how to do 
ENUM lookup can use the enumdi parameter for what it is, that enum 
lookup has been done. It doesn't say doing yet another enum lookup is 
forbidden.

Loop detection is a MUST. I agree with this.
   paf
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 11 Mar 2005 01:33:52 -0500

> output. Or perhaps I misunderstood what Juha was asking for.

no you didn't misunderstood me.  i have written an enum module for a
high-performance open source sip proxy and don't want that proxy to be
subject to enum dos attacks that would force the proxy to make several
enum queries (and analyze the result) for each sip request.  i would
therefore like to be able to mark that a tel uri was a result of an enum
query and if i see that kind of tel uri, i would not do another enum
query on it.  so i very much like your count idea.

-- juha

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 11 Mar 2005 02:10:14 -0500

David R Oran writes:

and 
	juha writes:

[Messages deleted].

There are a stream of messages which needed to be approved by hand.
Probably due to the cross posting with iptel at ietf.org. Note that
these messages are easely missed due to the enormous amount of spam
to filter and/or will might be delayed because the enum maillist
admins have day job beside filtering spam from the enum list.

So please, subscribe to the enum list or don't cross post.

Thanks in advance,

	jaap