Subject: [dispatch] SPID Sequence and Loop Detection

From: Sohel Khan <[email-masked]>
Date: Mon, 23 Jan 2012 12:50:52 -0800 (PST)

SIP calls routing in an infinite loop in a subset of networks is a known phenomenon. 
Various SIP methods exist today may be used to detect and mitigate loops. Operational engineers would like to see a method that indicates the sequence of providers’ IDs in the call path. Based on the input from the operational engineers, we are proposing a new SIP header <SPID Sequence> to detect SIP routing loop. This method is preferred by the operational engineers of large providers’ networks.
 
If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} arrives to Alpha’s network, Alpha will detect 77777777 in the SPID sequence and conclude that a loop has occurred. 
 
In the above use case, an example “SPID-sequence”header is as follows:
SPID-Sequence:<sip:33333333>;index=1;
SPID-Sequence:<sip:55555555>;index=1.1;
SPID-Sequence:<sip:77777777>;index=1.2;
 
SPID-Sequence:<sip:33333333>;index=1;
SPID-Sequence:<sip:55555555>;index=1.1;
SPID-Sequence:<sip:77777777>;index=1.2
SPID-Sequence:<sip:PRIVATE>;index=1.3;
A provider should not delete any value from the SPID sequence unless the SPID is its own.
We had some discussion in the DISPATCH meetings on ideas such as this. We would need a broader community support and help to initiate a work in IETF RTC WG on SPID sequence.
Please let us know your opinion.

Regards, Sohel Khan
A provider wishing not to divulge its SPID, may insert a private or a blank value.               
With the new method, the SIP INVITE contains the new header SPID sequence {33333333, 55555555, 77777777}. 

Assume that a SIP call originating from provider Alpha (SPID: 77777777) and traversing through provider Bravo (SPID: 55555555), Charlie (SPID: 33333333), and looping back to Alpha.

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 23 Jan 2012 16:18:53 -0500

> From: Sohel Khan [[email-masked]]
> 
> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777}
> arrives to Alpha’s network, Alpha will detect 77777777 in the SPID
> sequence and conclude that a loop has occurred.

And that conclusion is incorrect, because at the second entry to
Alpha, Alpha has no way of knowing that the request-URI is at all the
same as the request-URI at the time of first entry to Alpha.

In practice, if user A1 on network Alpha call-forwards his phone to
user B on network Bravo, and user B call-forwards his phone to user A2
on network Alpha, all calls to A1 will be routed to B, and then to A2,
and will be rejected upon the second entry to Alpha.

Something closer to the loop detection algorithm of RFC 5393 will be
needed.

Dale

---

From: Sohel Khan <[email-masked]>
Date: Tue, 24 Jan 2012 13:59:45 -0800 (PST)

We are not discussing routing loop due to call forwarding.
Various loop mitigation mechanism may be applicable to mitigate different types of routing loops.
SPID sequence mechanism may apply to routing loops due to least cost routing 
Provider Alpha routes the call to Provider Bravo because Provider Alpha considers that Provider Bravo is a least cost route.
Provider Bravo routes the call to Provider Charlie because Provider Bravo considers that Provider Charlie is a least cost route.
Provider Charlie routes the call back to Provider Alpha because Provider Charlie considers that Provider Alpha is a least cost route. Thus, an infinite routing loop occurs.  SPID Sequence can be hypothetically viewed as the BGP AS_PATH route vector
Regards, Sohel Khan

________________________________
From: "Worley, Dale R (Dale)" <[email-masked]>
To: Sohel Khan <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Monday, January 23, 2012 4:18 PM
Subject: RE: [dispatch] SPID Sequence and Loop Detection

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jan 2012 22:21:00 -0500

> different types of routing loops.

You may not be discussing/considering those things, but you should be, 
because (as Dale explained) the mechanism you are proposing would 
*break* non-loop calls that revisit the same provider.

	Thanks,
	Paul

> Provider Alpha routes the call to Provider Bravo because Provider Alpha
> considers that Provider Bravo is a least cost route.
> Provider Bravo routes the call to Provider Charlie because Provider
> Bravo considers that Provider Charlie is a least cost route.
> Provider Charlie routes the call back to Provider Alpha because Provider
> Charlie considers that Provider Alpha is a least cost route. Thus, an
> infinite routing loop occurs. SPID Sequence can be hypothetically viewed
> as the BGP AS_PATH route vector
> Regards, Sohel Khan
> *From:* "Worley, Dale R (Dale)" <[email-masked]>
> *To:* Sohel Khan <[email-masked]>; "[email-masked]"
> <[email-masked]>
> *Sent:* Monday, January 23, 2012 4:18 PM
> *Subject:* RE: [dispatch] SPID Sequence and Loop Detection
>
>>  From: Sohel Khan [[email-masked]
> <mailto:[email-masked]>]
>>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 25 Jan 2012 13:57:12 +0100

2012/1/23 Sohel Khan <[email-masked]>:
> Various SIP methods exist today may be used to detect and mitigate loops.
> Operational engineers would like to see a method that indicates the sequence
> of providers’ IDs in the call path. Based on the input from the operational
> engineers, we are proposing a new SIP header <SPID Sequence> to detect SIP
> routing loop. This method is preferred by the operational engineers of large
> providers’ networks.

IMHO RFC 5393 is the correct way to go. Your proposal breaks valid
scenarios. Check RC 5393.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 27 Jan 2012 11:56:25 -0700

When doing least cost routing, my experience has been that if A delivers the call to B that B will then send to C, B wants to hide this fact from C and certainly wants to hide from A that they the call went to C. Otherwise B gets cut out and A and C just set up a peering deal directly. 

So I worry a scheme like this would not work as B's SBC would be configured to remove this. 

On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote:

> In the above use case, an example “SPID-sequence” header is as follows:

---

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

Thanks Cullen.
Actually, in my opinion, providers neither will add a  SPID nor will add a known deterministic number.
Instead, providers will implement a stochastic model, and will add a private encrypted number so that only a provider can decrypt its own identity in the chain.
 
 Regards, Sohel Khan

________________________________
From: Cullen Jennings <[email-masked]>
To: Sohel Khan <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Friday, January 27, 2012 1:56 PM
Subject: Re: [dispatch] SPID Sequence and Loop Detection

---

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

On 1/30/12 3:14 PM, Sohel Khan wrote:
> Instead, providers will implement a stochastic model, and will add a
> private encrypted number so that only a provider can decrypt its own
> identity in the chain.

So, are you withdrawing your proposal?
Or are you suggesting modifying it to carry these encrypted ids?

If the latter, then I guess what you are proposing is a new mechanism by 
which a provider can tell that a message has returned to it after having 
been routed to some other provider? To use that it would have to attempt 
to decrypt every value in the list. And most of the time none of those 
would turn out to be its own. And the revisit to the provider may be 
legitimate, rather than a "loop".

Rather than that, you might want to review 
draft-kaplan-dispatch-b2bua-loop-detection-00 and 
draft-jones-ipmc-session-id-reqts-01, which might serve your purpose.

	Thanks,
	Paul

> Regards, Sohel Khan
> *From:* Cullen Jennings <[email-masked]>
> *To:* Sohel Khan <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Friday, January 27, 2012 1:56 PM
> *Subject:* Re: [dispatch] SPID Sequence and Loop Detection
>
>
> When doing least cost routing, my experience has been that if A delivers
> the call to B that B will then send to C, B wants to hide this fact from
> C and certainly wants to hide from A that they the call went to C.
> Otherwise B gets cut out and A and C just set up a peering deal directly.
>
>  > Various SIP methods exist today may be used to detect and mitigate
> loops. Operational engineers would like to see a method that indicates
> the sequence of providers’ IDs in the call path. Based on the input from
> the operational engineers, we are proposing a new SIP header <SPID
> Sequence> to detect SIP routing loop. This method is preferred by the
> operational engineers of large providers’ networks.
>  >
>  > Assume that a SIP call originating from provider Alpha (SPID:
> 77777777) and traversing through provider Bravo (SPID: 55555555),
> Charlie (SPID: 33333333), and looping back to Alpha.
>  >
>  > We had some discussion in the DISPATCH meetings on ideas such as
> this. We would need a broader community support and help to initiate a
> work in IETF RTC WG on SPID sequence.
>  > [email-masked] <mailto:[email-masked]>