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

From: Cullen Jennings <[email-masked]>
Date: Sun, 5 Feb 2012 17:27:11 -0700

That makes a lot of sense to me. Do we need a proposal that shows how to do that and where to put it in SIP?

On Jan 30, 2012, at 1:14 PM, Sohel Khan wrote:

> 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
> 
> 
> 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:
> 
> > 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.
> >  
> > 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.
> >  
> > With the new method, the SIP INVITE contains the new header SPID sequence {33333333, 55555555, 77777777}.
> >  
> > 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;
> >  
> > A provider wishing not to divulge its SPID, may insert a private or a blank value.              
> > 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
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
>

---

From: Daryl Malas <[email-masked]>
Date: Tue, 7 Feb 2012 10:06:16 -0700

Cullen's point here is very valid.  Service Providers acting as an IXC
never want to indicate their service provider relationships to their
customers.  They create interconnects to many service providers to
maintain the lowest termination costs in order to increase their margins
for LD termination.  Sohel describes a real problem.

In telecommunication networks, it seems as though we have many different
carrier identification mechanisms already defined.  I am leery of creating
yet another, even if it is encrypted.  I would be more inclined to look at
existing loop detection mechanisms and see if they will work either:
- as currently defined,
- need to be extended or
- need to be enforced (aka not blocked or reset by a B2BUA).

--Daryl

On 1/27/12 11:56 AM, "Cullen Jennings" <[email-masked]> wrote:

>
>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.
>>  
>> 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:
>> 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.

---

From: "Leontsinis, Nikos" <[email-masked]>
Date: Tue, 7 Feb 2012 20:35:13 +0200

I am not 100% sure about this. On some environments say IPX this can be desirable it is written in the contract I will send you traffic to
USA FIXED and you are obliged to route it to carrier B. This is the area where the SPID could make sense.

/nikos
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Daryl Malas [[email-masked]]
Sent: Tuesday, February 07, 2012 7:06 PM
To: Cullen Jennings; Sohel Khan
Cc: [email-masked]
Subject: Re: [dispatch] SPID Sequence and Loop Detection

--Daryl

DISCLAIMER:
This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and legally privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of OTEGLOBE. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. OTEGLOBE cannot accept any responsibility for the accuracy or completeness of this message as it has been transmitted over a public network. If you suspect that the message may have been intercepted or amended in any way please contact the sender. Thank you.

---

From: Daryl Malas <[email-masked]>
Date: Tue, 7 Feb 2012 12:04:46 -0700

Notice I specifically said, "Service Providers acting as an IXC never want
to indicate their service provider relationships to their customers."
This does not preclude a contractual agreement between two SSPs.

On 2/7/12 11:35 AM, "Leontsinis, Nikos" <[email-masked]>
wrote:

>I am not 100% sure about this. On some environments say IPX this can be
>desirable it is written in the contract I will send you traffic to
>This electronic mail message is intended exclusively for the individual
>or entity to which it is addressed. This message, together with any
>attachment, may contain confidential and legally privileged information.
>Any views, opinions or conclusions expressed in this message are those of
>the individual sender and do not necessarily reflect the views of
>OTEGLOBE. Any unauthorized review, use, printing, copying, retention,
>disclosure or distribution is strictly prohibited. If you have received
>this message in error, please immediately advise the sender by reply
>email message to the sender and delete all copies of this message.
>OTEGLOBE cannot accept any responsibility for the accuracy or
>completeness of this message as it has been transmitted over a public
>network. If you suspect that the message may have been intercepted or
>amended in any way please contact the sender. Thank you.

---

From: Sohel Khan <[email-masked]>
Date: Tue, 7 Feb 2012 11:29:00 -0800 (PST)

Thanks Daryl.
The assertion may or may not be true.
In my opinion, during the trouble shooting calls operations from all providers attend the call and aware of all the service providers for a calls. In addition, please note that in my proposal, a provider not intending to disclose its information may add a random number to hide its identity.

Regards, Sohel Khan

________________________________
From: Daryl Malas <[email-masked]>
To: "Leontsinis, Nikos" <[email-masked]>; Cullen Jennings <[email-masked]>; Sohel Khan <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Tuesday, February 7, 2012 2:04 PM
Subject: Re: [dispatch] SPID Sequence and Loop Detection

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 7 Feb 2012 19:31:56 -0500

Ok .. but the basics are essential.

I want to commend to all of you the concept of a Universal SPID embodied in
this draft. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identifier
-urn-01.txt

It needs work and input from everyone here, but the core issue here is
identification of issues along the session path especially as it transits
across national boundaries or transit intermediaries.  

What is the malfunction that we can't agree on a tracing mechanism. Session
ID for goodness sake. DO IT. Charter the damn thing. 

It may seem trivial. Its not. Especially if you are a regulator looking at
how to create competitive transit markets. Do you all want another Shockey
lecture on what the national regulators are up to ???  

Sohel to his eternal credit is starting to identify the larger problem of
the End of POTS.

I've avoided proposing a RAI Directorate on End of Life (EOL) issues with
TDM but it's coming. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Daryl Malas
Sent: Tuesday, February 07, 2012 2:05 PM
To: Leontsinis, Nikos; Cullen Jennings; Sohel Khan
Cc: [email-masked]
Subject: Re: [dispatch] SPID Sequence and Loop Detection

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Fri, 17 Feb 2012 16:44:56 +0000

I've submitted a new version of the SPID I-D Rich referred to below. Per dispatch at the Quebec meeting it's for discussion on the RAI list.
It differs from the previous version in asking the RIRs rather than IANA directly to handle registrations. (This is to minimize junk registrations and provide a whois service)

Penn Pfautz
AT&T Access Management
+1-732-420-4962

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Feb 2012 17:16:15 -0700

I don't get how this is better than an ITAD formatted to be 8 digits long with leading zeros.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 23 Feb 2012 00:33:57 +0000

Because it costs money.  A small  annual fee, to keep contact freshness and discourage junk.

Sent from my iPhone

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Feb 2012 17:46:03 -0700

Well it's a lot more than costs money - when I read ARIN policy to get an AS, it not just $500 per year. I don't think I could get an AS number. 

So lets delve into this argument a bit deeper. What's the advantage in this case of no junk registrations? Who care is someone that you will never see a message from has a number? 

It seems the primary difference is that it would keep certain types of business locked out if they were unable to use protocols that needed one of these numbers and they could not get one.

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Thu, 23 Feb 2012 00:55:10 +0000

The intent is not to have a policy as restrictive as for AS numbers. What requirements should obtain beyond the fee is up for discussion which I encourage. I don't think a modest fee will discourage actual businesses as the focus is on service providers as opposed to end users. (I expect some enterprises will want to join in - I don't have a problem with that).
Penn Pfautz
AT&T Access Management
+1-732-420-4962

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Feb 2012 20:04:02 -0500

> I don't get how this is better than an ITAD formatted to be 8 digits long with leading zeros.

And I still don't see how either one is even remotely useful for loop 
detection. We have heard repeatedly that SPs feel they must keep the 
topology of their networks and the identity of their peers secret. But 
that will lead to removing/anonymizing the SPIDs in the request, just as 
Vias and Routes are anonymized. And then this won't work for loop detection.

And we already have loop detection mechanisms, so why do we need another?

Also, what is to prevent someone from forging SPIDs in a message?

	Thanks,
	Paul

>> On 2/7/12 11:35 AM, "Leontsinis, Nikos"<[email-masked]>
>> wrote:
>>
>>> On 1/27/12 11:56 AM, "Cullen Jennings"<[email-masked]>  wrote:
>>>
>>>>
>>>>> the operational engineers, we are proposing a new SIP header<SPID

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 25 Feb 2012 10:43:29 -0500

+1 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hadriel Kaplan
Sent: Wednesday, February 22, 2012 7:34 PM
To: Cullen Jennings
Cc: [email-masked] list
Subject: Re: [dispatch] SPID Sequence and Loop Detection

Because it costs money.  A small  annual fee, to keep contact freshness and
discourage junk.

Sent from my iPhone

On Feb 22, 2012, at 7:16 PM, "Cullen Jennings" <[email-masked]> wrote:

>> I've submitted a new version of the SPID I-D Rich referred to below. Per
dispatch at the Quebec meeting it's for discussion on the RAI list.
>> It differs from the previous version in asking the RIRs rather than IANA
directly to handle registrations. (This is to minimize junk registrations
and provide a whois service)

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 25 Feb 2012 10:45:10 -0500

Exactly .. no one is suggesting a restrictive policy here only a modest
level of control.  And we want a WHOIS. That is essential. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of PFAUTZ, PENN L
Sent: Wednesday, February 22, 2012 7:55 PM
To: Cullen Jennings; Hadriel Kaplan
Cc: [email-masked] list
Subject: Re: [dispatch] SPID Sequence and Loop Detection

The intent is not to have a policy as restrictive as for AS numbers. What
requirements should obtain beyond the fee is up for discussion which I
encourage. I don't think a modest fee will discourage actual businesses as
the focus is on service providers as opposed to end users. (I expect some
enterprises will want to join in - I don't have a problem with that).
Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]]
Sent: Wednesday, February 22, 2012 7:46 PM
To: Hadriel Kaplan
Cc: PFAUTZ, PENN L; [email-masked] list
Subject: Re: [dispatch] SPID Sequence and Loop Detection

Well it's a lot more than costs money - when I read ARIN policy to get an
AS, it not just $500 per year. I don't think I could get an AS number.

So lets delve into this argument a bit deeper. What's the advantage in this
case of no junk registrations? Who care is someone that you will never see a
message from has a number?

It seems the primary difference is that it would keep certain types of
business locked out if they were unable to use protocols that needed one of
these numbers and they could not get one.

>>>> USA FIXED and you are obliged to route it to carrier B. This is the
area
>>>> where the SPID could make sense.
>>>>
>>>>
>>>> /nikos
>>>> From: [email-masked] [[email-masked]] On Behalf
Of
>>>> Daryl Malas [[email-masked]]

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 25 Feb 2012 10:50:35 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Wednesday, February 22, 2012 8:04 PM
To: [email-masked]
Subject: Re: [dispatch] SPID Sequence and Loop Detection

Also, what is to prevent someone from forging SPIDs in a message?
[RS> ] 
[RS> ] One of the principal use cases for a global SPID this is
International Interconnection of E.164 traffic or even domestic traffic in
some national jurisdictions. As for forging SPID's we have the same problem
with issues of Calling Number in one way SIP traffic over the PSTN in the
US. People do bad things. The prevention mechanism is national law or
regulation that defines what is in the headers and what cannot be modified
as it might transverse a all IP Interconnected network using E.164
identifiers. Its called fines and jail. 

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 25 Feb 2012 20:15:19 -0500

> identifiers. Its called fines and jail.

There's a lot of callerid forging going on, and AFAIK nobody is going to 
jail for it.

In what countries are there laws about what sip headers can go into a 
sip message?

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Sun, 26 Feb 2012 15:36:53 -0500

There's a lot of callerid forging going on, and AFAIK nobody is going to 
jail for it.
[RS> ] Not yet , but given the level of screaming by the service providers
on the fraudulent phantom traffic issue you can assume its coming.   

In what countries are there laws about what sip headers can go into a 
sip message?
[RS> ] Right now the issue is related to traffic in both the US and Canada
but I would guess most of the PTT's are experiencing the same issue. The FCC
order on USF/ICC reform is very specific on the requirement for non
modification of charge number or calling party number in the signaling
path.. aka the SIP headers when applicable.   A fair amount of this goes
away with bill and keep but you can assume you'll see a bunch of new
"requirements" be imposed as a transition to all SIP Interconnection for
real time communications occurs over the next decade. 

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Feb 2012 13:09:57 -0500

[I've changed the subject to reflect what we are discussing]

Richard,

This is interesting, and I think more discussion is appropriate on it. 
Its not clear where this discussion should take place - probably not 
dispatch. IMO sipcore is more suitable for the discussion. So I'm cross 
posting this but bcc'ing dispatch so that replies will go to sipcore. 
(Hopefully that will work. If it doesn't, please refrain from replying 
on dispatch.)

I don't understand how a legal restriction would work.

- would it be limited to regulated carriers?

- how would this apply to the interconnect of "private" devices
   or environments to the "public" sip infrastructure?

- would this be limited to identities that are E.164 numbers?
   Or would it include other sorts of identities?

- would this apply to interconnects between private infrastructures?
   (E.g. ViPR)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 28 Feb 2012 18:17:04 +0000

I don't think it's so much that there'll be a law about what exact SIP headers must be used/included per se - it's more that they'll pass a law saying each service provider (ie, IXC/ILEC/etc.) must indicate the call request transited it, and pass on those indications it received from upstream.  How it's encoded (whether it be a SIP header, ISUP body, or for that matter not in SIP but in SS7 calls) is probably going to be left out. (I hope!)

-hadriel

On Feb 25, 2012, at 8:15 PM, Paul Kyzivat wrote:

> There's a lot of callerid forging going on, and AFAIK nobody is going to jail for it.
> 
> In what countries are there laws about what sip headers can go into a sip message?
> 
> 	Thanks,
> 	Paul