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

From: "Stastny Richard" <[email-masked]>
Date: Thu, 10 Mar 2005 16:27:03 -0500

Thank you  Patrik for getting this dicusion back on track,
I was getting lost already
 
I agree with you that we have to sepate the issues again and there
are three separate topics
 
1. the prorpose of the enumdi is basically  to tell the NEXT network element
that an ENUM query has been done on the E.164 number. period.
It may do another ENUM query or not. A counter does not add anything here.
 
2. Loop detection is necessary, and each network elemnt has to do this
on his own. the enumdi may just prevent the next network element to run
into a loop again, but if it chosses ignore the enumdi, it is up to this network
elemnt to detect a loop.
 
I am fine with Davids text if this is agreed
 
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.
 
option c to take the last number queried is not a good chioce, because
this may depend on the loop detection algorithm.
 
If this approach is agreed I will try tp formulate a new text proposal
 
richard

________________________________

Von: Patrik Fältström [mailto:paf at cisco.com]
Gesendet: Do 10.03.2005 21:57
An: David R Oran
Cc: Stastny Richard; iptel at ietf.org; enum at ietf.org
Betreff: 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

_______________________________________________
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:46:19 -0500

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
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 10 Mar 2005 16:47:05 -0500

On Mar 10, 2005, at 3:29 PM, Stastny Richard wrote:
Thank you  Patrik for getting this dicusion back on track,
I was getting lost already
I agree with you that we have to sepate the issues again and there
are three separate topics
1. the prorpose of the enumdi is basically  to tell the NEXT network 
element
that an ENUM query has been done on the E.164 number. period.
It may do another ENUM query or not. A counter does not add anything 
here.
I think the same
2. Loop detection is necessary, and each network elemnt has to do this
on his own. the enumdi may just prevent the next network element to run
into a loop again, but if it chosses ignore the enumdi, it is up to 
this network
elemnt to detect a loop.
I like this approach. ENUM is not the only way we can enter an endless 
loop and counting the ENUM lookups is not the solution. There are 
aliases, conditional or unconditional redirections that may be combined 
with ENUM look-ups. Each routing element should detect a loop across 
multiple type of lookups, it is up to the application to do this.

I am fine with Davids text if this is agreed
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
This is good, we use a similar setup and we currently send Loop 
detected as release status back.

Adrian

---

From: lconroy <[email-masked]>
Date: Thu, 10 Mar 2005 17:11:15 -0500

Hi Everyone,
 this is slightly tangled.
There are two cases:
(i) The application that requests the ENUM lookup(s) has to do loop  
detection if
    if chooses to re-query ENUM based on the content of an initial ENUM  
query.
    This was Juha's original issue.
(ii) The ENUM client itself has to deal with a potential loop, when  
processing
     non-final NAPTRs.

It's this second case that's covered in the ENUM Experiences draft  
already - we
recommended a Max-Queries value as a vary basic "loop quencher" for  
THIS case.
It's ugly, but it does work, and I defy anyone to produce a  
provisioning system
that handles a greater depth of ENUM domains and remain sane, so false  
positives
are unlikely and/or a sign of serious strangeness on the part of the  
ENUM zones
being searched.

----
The first case (Application using ENUM) is a separate issue - the ENUM  
client can't
really help, as it doesn't retain state beyond the end of each final  
look up.

I think that we're converging on an agreement that each individual  
element MUST deal
with this kind of loop detection on its own.

How it does loop detection is a local issue and is out of scope of the  
ENUMDI draft.

";enumdi" only states that an ENUM query has been done *on this number*  
(i.e. the
number is the input to an ENUM query).

No - it doesn't help a distributed set of elements from breaking the  
loop - but
this is not its job. Each element must do this detection. It can be  
done, and is
being done, but if an element doesn't deal with this problem, it's  
broken.

is this all correct?
all the best,
  Lawrence
------------------------------------------------------------------------ 
---------
On 10 Mar 2005, at 21:45, Adrian Georgescu wrote:
On Mar 10, 2005, at 3:29 PM, Stastny Richard wrote:
Thank you  Patrik for getting this dicusion back on track,
I was getting lost already
I agree with you that we have to sepate the issues again and there
are three separate topics
1. the prorpose of the enumdi is basically  to tell the NEXT network  
element
that an ENUM query has been done on the E.164 number. period.
It may do another ENUM query or not. A counter does not add anything  
here.
I think the same
2. Loop detection is necessary, and each network elemnt has to do this
on his own. the enumdi may just prevent the next network element to  
run
into a loop again, but if it chosses ignore the enumdi, it is up to  
this network
elemnt to detect a loop.
I like this approach. ENUM is not the only way we can enter an endless  
loop and counting the ENUM lookups is not the solution. There are  
aliases, conditional or unconditional redirections that may be  
combined with ENUM look-ups. Each routing element should detect a loop  
across multiple type of lookups, it is up to the application to do  
this.

Adrian

---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum