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

From: "Stastny Richard" <[email-masked]>
Date: Thu, 10 Mar 2005 22:53:28 +0100

>Is this not a local policy that is highly dependent on context?

>I.e. that all of the above is possible.

Agree, we may also offer the two options to choose from

Richard

________________________________

Von: Patrik Fältström [mailto:[email-masked]]
Gesendet: Do 10.03.2005 22:39
An: Stastny Richard
Cc: David R Oran; [email-masked]; [email-masked]
Betreff: Re: AW: [Enum] Re: [Iptel] tel loop detection and prevention

On Mar 10, 2005, at 15:29, Stastny Richard wrote:

> 3. the last issue also mixed in was the action the network element
> should take
> if it detects a loop. If have not heard a clear answer to this yet
> I see two options here:
> a. signal back service not available
> b. take the original tel URI (the one sent in in most cases by the
> client) and act the same way as decribed for NXDOMAIN or same number.

Is this not a local policy that is highly dependent on context?

I.e. that all of the above is possible.

    paf

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 11 Mar 2005 10:39:59 -0500

Patrik,

I think we all agree that ENUM is extremely important to routing and
that loops in dereferencing ENUM dips is a very bad thing.  Thus we need
to get this right the first time.

What I haven't seen in this discussion anywhere is the notion of *Time
Scale*, that is WHEN should the resolution of the dereferencing be done.
Also, the primary purpose of ENUM was to enable an IP-based terminal to
be reached using an E.164 telephone number.  So, if a trade-off requires
something to suffer, it should be translations in the opposite
direction.

Correct me if I am wrong, but ENUM registrations are on the order of
hours or days and not likely to change often; while ENUM dips are on the
order of milliseconds.  Also, doing many ENUM dips also becomes a
"post-dial delay" issue.  That tells me that loop detection and
correction should occur during the registration process, *NOT* during
ENUM dips during session setup.  This leads me to a simple rule:

ENUM NAPTR records should be validated to ensure that an ENUM dip
against any included tel:URI results in a negative hit.

The consequence of this is that an ENUM client can safely be assured
that it need only do a single dip against a tel:URI.  

Of course, such a PSTN-based E.164 could later be migrated to an IP
terminal and an ENUM record created.  Registrars could periodically,
during off-hours, test records that have tel:URI entries by doing a
second dip.  If a hit occurs, it would be a violation and 3 actions
could be taken:
1) remove the tel:URI from the record,
2) replace the tel:URI with the results of the second ENUM dip
(optional),
3) notify the first record holder of the problem and fix made.  (That
person may have an alternate registration solution.)

Such checking is not a big deal during registration, but is during
session setup.

I found the idea that a node would do a single dip, then pass the
message on to a second node that then will do a dip because the tel:URI
would not have the ENUMDI set to be a recipe for looping via
distributing the ENUM lookup process.  To avoid this, I would suggest
that a second ENUMPDI (ENUM Parent Dip Indicator) be created.  The
intent is to tell subsequent session processing nodes that this tel:URI
resulted from an ENUM dip and should therefore be located in the PSTN.
If the second node chooses to do an ENUM dip on a tel:URI with ENUMPDI,
then it should also assume responsibility for reporting the presence of
this registration error to the ENUM police, and likely should also fail
the call until the registry is corrected.  (This may fall to PSTN GWs to
protect themselves as potential bottlenecks between the PSTN and IP
domains.)  That might also suggest an additional error or warning code
for SIP, but so be it.  Better to get the routing databases cleaned up
immediately than sit there looping ENUM dips or calls.

Mike

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Patrik Faltstrom (pfaltstr)
>Sent: Thursday, March 10, 2005 3:57 PM
>To: Dave Oran (oran)
>Cc: [email-masked]; [email-masked]; Stastny Richard
>Subject: Re: [Enum] Re: [Iptel] tel loop detection and prevention
>
>
>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
>