Subject: Re: [dispatch] SPID Sequence and Loop Detection

From: Sohel Khan <[email-masked]>
Date: Mon, 30 Jan 2012 14:15:27 -0800 (PST)

Thanks Paul. No, I am not withdrawing the proposal.
I am modifying the proposal to mitigate concerns raised in this discussion list.
You are correct that  I proposing  a new mechanism by 
which a provider can tell that a message has returned to it after having 
been routed to some other provider. 
Assume, there are three encrypted values in a sequence. Only one proxy of a provider has to decrypt these three fixed sized encrypted values. 
Other than a looped case, the calls arriving back is most probably for call forwarding case.
Operation Engineers like to use Diversion Indication header for call forwarding although the RFC is a historical RFC.
If an INVITE contains a Diversion header, then the provider should not analyze the proposed provider sequence header.
Max-Forwards and Max-Breadths techniques also need to be implemented along with above methods since Max-Forwards and Max-Breadths have also limitations.

Sohel Khan

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jan 2012 18:12:39 -0500

On 1/30/12 5:15 PM, Sohel Khan wrote:
> Assume, there are three encrypted values in a sequence. Only one proxy
> of a provider has to decrypt these three fixed sized encrypted values.

IIUC, you proposed that each provider would insert an encrypted 
identifier for itself. To achieve your goal of not identifying the 
provider to other providers, it needs to:
- vary from call to call
- not be superficially recognizable as being from you

Thus, *somewhere* after the message enters your control you will need to 
decode all the ids based on your algorithm in order to determine which 
are yours. You will need to do that for every id in the message. (But I 
agree you can probably find a way to only do it once, regardless of how 
many of your nodes the message traverses before leaving.

I also suspect it will be difficult to find a way to construct this 
encrypted id that will achieve your objectives.

> Operation Engineers like to use Diversion Indication header for call
> forwarding although the RFC is a historical RFC.
> If an INVITE contains a Diversion header, then the provider should not
> analyze the proposed provider sequence header.

You cannot assume that other providers use Diversion.
With your approach, if a call passes through your provider, then to 
another where it is forwarded (without Diversion) back to you, then you 
will erroneously consider it a loop.

> Max-Forwards and Max-Breadths techniques also need to be implemented
> along with above methods since Max-Forwards and Max-Breadths have also
> limitations.
> Sohel Khan

I fail to see how what you propose adds anything other than problems.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 31 Jan 2012 12:15:03 +0100

If you are into anything more complicated that identifying the number of hops so far routed over, then you need to count more than the number of diversions. Some multiple diversion scenarios can be perfectly legitimate, and indeed transit multiple operators, particularly when some of those users may be roaming or on enterprise networks beyond a public network.

To do that analysis correctly you need more information akin to the History-Info header field (or at least the tree structure within it).

It seems we provide mechanisms, and then people refuse to use them because they reveal information, and we have to invent another mechanism, .... etc.

I would also note that I would oppose any chartered work investigating the applicability of the Diversion header.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: 30 January 2012 23:13
> To: Sohel Khan
> Cc: [email-masked]
> Subject: Re: [dispatch] SPID Sequence and Loop Detection
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Jan 2012 09:20:08 -0500

> It seems we provide mechanisms, and then people refuse to use them because they reveal information, and we have to invent another mechanism, .... etc.

+1

> I would also note that I would oppose any chartered work investigating the applicability of the Diversion header.

+1

	Thanks,
	Paul

---

From: Sohel Khan <[email-masked]>
Date: Tue, 31 Jan 2012 09:17:10 -0800 (PST)

Thanks Keith and Paul.
First of all, I am not proposing to start a charter at this time. 
My intention is now to have a discussion to find a best solution to detect that loop has occurred. In my opinion, the proposed SPID Sequence or Domain Sequence is analogous to the AS-PATH of BGP.  Some of you raised concern on disclosing the identity of providers; thus, I suggested that we include encrypted provider ID in the sequence. I agree with Keith that we should try to use existing mechanism (e.g., History-info) instead of re-inventing something else. The History-Info can be used for redirection related functions. The History-info also helps operation to determine the sequence of all the proxies in the call path.  We observed that fqdn of proxies are generally included in the call paths. In the peering context, it helps to analyze the entry/exit proxies of a provider’s network. Note that a large network may contain 100s of entry/exit proxies. The proxy fqdn information in the History-Info not always is fixed sized.  The history information
 may not contain the name of the provider. Sometimes, name of the provider added in the history-info by different proxies use different combinations; thus, it is difficult for an automated system in an entry/exit proxy to analyze and detect loop in real time.  On the other hand, the proposed SPID sequence/domain sequence information is planned to be fixed length; thus, easier for the entry/exit points to discover loop. Let us continue to discuss, we will appreciate your help to come up with a comprehensive solution.
 
Regards, Sohel Khan

________________________________
From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Paul Kyzivat <[email-masked]>; Sohel Khan <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Tuesday, January 31, 2012 6:15 AM
Subject: RE: [dispatch] SPID Sequence and Loop Detection

Regards

Keith