Subject: [dispatch] Proposal: ESPID Sequence Charter

From: Sohel Khan <[email-masked]>
Date: Thu, 1 Mar 2012 14:28:12 -0800 (PST)

We are proposing a small charter to develop a SIP standard to
add a SIP Sequence header. Kindly review the charter. appreciate your
feedback.
 
SIP Loop among SIP providers is a growing phenomenon.  For
example, SIP request messages traverse various providers and loop back to
previous providers due to the parity of the routing vectors. In another
example, SIP messages traverse multiple service providers in a loop because of
the origination-destination session forwarding to each other. SIP loops are
often amplified causing operational disruption in the SIP networks.
 
In the absence of B2BUA in session paths or a presence of a
standard SIP compliant B2BUA that does not remove/reset SIP parameters, many of
the current SIP headers can aid in detecting multi-provider loop. These headers
have some limitations. For example, an optimum default value for Max-Forwards
is hard to determine since the number of nodes in the session path is time/path
variant depending on the origination-destination route vector among SIP
providers. SIP History-Info is another header that also aid in detecting loop
among multiple SIP providers. SIP History-Info depicts node information in the
session path. The parameter in the History-Info is not often the fixed
size; thus, it is difficult to extract providers' names. A SIP request may traverse a set of nodes in a
service provider’s network, may loop around the world, and may enter the
previous SIP providers’ networks in a different set of nodes; thus, the new
nodes may not know that the call had traversed the same SIP providers'
networks in the past.
 
 The charter is to develop
an Encrypted SIP Provider Identity (ESPID) Sequence header such that a provider
can detect itself-only, while maintaining privacy and preserving SIP
flexibility such as call forwarding. The ESPID sequence contains identity of
SIP Providers in the order a session has propagated through the SIP providers.
A SIP provider shall only be able to detect its own identity in the sequence. A
SIP provider wishing not to disclose its identity to other providers shall be
able to encrypt its identity. A SIP provider not wishing to include its
information in the sequence may do so by not adding any information. Inclusion
of the ESPID header is mandatory. A SIP provider shall not remove the ESPID
header from a SIP message traversing its network.  
 
SIP Provider ID (SPID) standard development is outside the scope
of this charter.  ESPID activity will coordinate with SPID activity
developed through SPID charter.
 
Regards,
Sohel Khan

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 2 Mar 2012 00:53:45 +0000

Sohel,

Please let me know whether Session id mentions in http://tools.ietf.org/html/draft-jones-ipmc-session-id-03 helps to solve the same issue.

Because session-id also traverses through all B2BUA.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sohel Khan
Sent: Friday, March 02, 2012 3:58 AM
To: [email-masked]
Subject: [dispatch] Proposal: ESPID Sequence Charter

We are proposing a small charter to develop a SIP standard to add a SIP Sequence header. Kindly review the charter. appreciate your feedback.

SIP Loop among SIP providers is a growing phenomenon.  For example, SIP request messages traverse various providers and loop back to previous providers due to the parity of the routing vectors. In another example, SIP messages traverse multiple service providers in a loop because of the origination-destination session forwarding to each other. SIP loops are often amplified causing operational disruption in the SIP networks.

In the absence of B2BUA in session paths or a presence of a standard SIP compliant B2BUA that does not remove/reset SIP parameters, many of the current SIP headers can aid in detecting multi-provider loop. These headers have some limitations. For example, an optimum default value for Max-Forwards is hard to determine since the number of nodes in the session path is time/path variant depending on the origination-destination route vector among SIP providers. SIP History-Info is another header that also aid in detecting loop among multiple SIP providers. SIP History-Info depicts node information in the session path. The parameter in the History-Info is not often the fixed size; thus, it is difficult to extract providers' names. A SIP request may traverse a set of nodes in a service provider’s network, may loop around the world, and may enter the previous SIP providers’ networks in a different set of nodes; thus, the new nodes may not know that the call had traversed the same SIP providers' networks in the past.

 The charter is to develop an Encrypted SIP Provider Identity (ESPID) Sequence header such that a provider can detect itself-only, while maintaining privacy and preserving SIP flexibility such as call forwarding. The ESPID sequence contains identity of SIP Providers in the order a session has propagated through the SIP providers. A SIP provider shall only be able to detect its own identity in the sequence. A SIP provider wishing not to disclose its identity to other providers shall be able to encrypt its identity. A SIP provider not wishing to include its information in the sequence may do so by not adding any information. Inclusion of the ESPID header is mandatory. A SIP provider shall not remove the ESPID header from a SIP message traversing its network.

SIP Provider ID (SPID) standard development is outside the scope of this charter.  ESPID activity will coordinate with SPID activity developed through SPID charter.

Regards,
Sohel Khan

---

From: Sohel Khan <[email-masked]>
Date: Fri, 2 Mar 2012 13:13:03 -0800 (PST)

Thanks Partha.
A large SIP provider network consists of a large number of entry and exit nodes.
In an absence of B2BUA, if an unaltered session ID contains a fixed size numerical value that could be used to identify a SIP Service provider by any entry and exit nodes of the SIP provider network, then it will suffice. However, the size and value of the session id may grow as SIP request traverses through network to network adding each provider ID; thus, should we use the session ID when when its end-to-end uniqueness has importance?
 
Regards,
Sohel Khan

________________________________
 From: "Ravindran, Parthasarathi" <[email-masked]>
To: Sohel Khan <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Thursday, March 1, 2012 7:53 PM
Subject: RE: [dispatch] Proposal: ESPID Sequence Charter

Sohel,

 
Thanks
Partha
 
From:[email-masked] [mailto:[email-masked]] On Behalf Of Sohel Khan
Sent: Friday, March 02, 2012 3:58 AM
To: [email-masked]
Subject: [dispatch] Proposal: ESPID Sequence Charter

 
In the absence of B2BUA in session paths or a presence of a standard SIP compliant B2BUA that does not remove/reset SIP parameters, many of the current SIP headers can aid in detecting multi-provider loop. These headers have some limitations. For example, an optimum default value for Max-Forwards is hard to determine since the number of nodes in the session path is time/path variant depending on the origination-destination route vector among SIP providers. SIP History-Info is another header that also aid in detecting loop among multiple SIP providers. SIP History-Info depicts node information in the session path. The parameter in the History-Info is not often the fixed size; thus, it is difficult to extract providers' names. A SIP request may traverse a set of nodes in a service provider’s network, may loop around the world, and may enter the previous SIP providers’ networks in a different set of nodes; thus, the new nodes may not know that the
 call had traversed the same SIP providers' networks in the past.

 
Regards,
Sohel Khan

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Mar 2012 16:25:28 -0500

I disagree with the concept being proposed here.

I'm still waiting for an explanation for why the existing mechanisms for 
loop detection aren't sufficient to solve the problem here. But even if 
there is some inadequacy, then it should be solved in general, not just 
for loops through multiple service providers. There is really nothing 
special about loops through SPs.

	Thanks,
	Paul

On 3/1/12 5:28 PM, Sohel Khan wrote:
> We are proposing a small charter to develop a SIP standard to add a SIP
> Sequence header. Kindly review the charter. appreciate your feedback.
> SIP Loop among SIP providers is a growing phenomenon. For example, SIP
> request messages traverse various providers and loop back to previous
> providers due to the parity of the routing vectors. In another example,
> SIP messages traverse multiple service providers in a loop because of
> the origination-destination session forwarding to each other. SIP loops
> are often amplified causing operational disruption in the SIP networks.
> In the absence of B2BUA in session paths or a presence of a standard SIP
> compliant B2BUA that does not remove/reset SIP parameters, many of the
> current SIP headers can aid in detecting multi-provider loop. These
> headers have some limitations. For example, an optimum default value for
> Max-Forwards is hard to determine since the number of nodes in the
> session path is time/path variant depending on the
> origination-destination route vector among SIP providers. SIP
> History-Info is another header that also aid in detecting loop among
> multiple SIP providers. SIP History-Info depicts node information in the
> size; thus, it is difficult to extract providers' names. A SIP request
> may traverse a set of nodes in a service provider’s network, may loop
> around the world, and may enter the previous SIP providers’ networks in
> a different set of nodes; thus, the new nodes may not know that the call
> had traversed the same SIP providers' networks in the past.
> The charter is to develop an Encrypted SIP Provider Identity (ESPID)
> Sequence header such that a provider can detect itself-only, while
> maintaining privacy and preserving SIP flexibility such as call
> forwarding. The ESPID sequence contains identity of SIP Providers in the
> order a session has propagated through the SIP providers. A SIP provider
> shall only be able to detect its own identity in the sequence. A SIP
> provider wishing not to disclose its identity to other providers shall
> be able to encrypt its identity. A SIP provider not wishing to include
> its information in the sequence may do so by not adding any information.
> Inclusion of the ESPID header is mandatory. A SIP provider shall not
> remove the ESPID header from a SIP message traversing its network.
> SIP Provider ID (SPID) standard development is outside the scope of this
> charter. ESPID activity will coordinate with SPID activity developed
> through SPID charter.
> Regards,
> Sohel Khan
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 5 Mar 2012 13:04:47 -0500

> From: Paul Kyzivat [[email-masked]]
> 

I'm with Paul here.

The real problem is that the SIP loop-prevention mechanisms often
don't work when network elements:
(1) hide the path the call has traversed
(2) are B2BUAs

One consequence of this is that in many cases a call can loop between
two service providers and not be detected.  But there are many
somewhat more complex situations that also loop.

The proposed charter assumes that the desired anti-looping mechanism
would be some form of list of the service providers that the call has
traversed.

But many of the more complex scenarious would *not* be detected by a
"list of traversed service providers" mechanism (unless it was so
aggressive that it flagged similar, non-looping calls).  Here is one:

Users A and C are served by service provider P.
Users B and D are served by service provider Q.

User B has forwarded his phone to user C.
User C has forwarded his phone to user D.

User A calls user B.  The route of the call is:

A->P->Q->B->Q->P->C->P->Q->D

At D, the call has traversed P three times and has traversed Q three
times.  It has been routed based on three different phone numbers.

If user D's phone rings, this call is valid and should succeed.  If
user D has forwarded his phone to user A, the call is looped and
should fail.

No doubt the problem needs to be solved.  But we need to start by
studing it, and determining a mechanism that works in all the cases
that our customers will shortly be exercising.  The current charter
specifies a mechanism, and that mechanism will not work.

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 7 Mar 2012 09:18:06 -0700

So just throwing out straw man here ... if you took the current  VIA based looping mechanism and also included an encrypted version of the via in a separate header, 1) could you convinces the SBC not to remove the encrypted version 2) would this work to correctly detect loops yet not break spirals such as Dales example?

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 9 Mar 2012 16:10:23 -0500

\Here's one approach to loop detection in environments that involve
topology-hiding:

It exploits the fact that most of the time, a request will proceed
through a carrier's network with the request-URI remaining constant
(the destination E.164 number of the message).

Each carrier chooses a secret key which all of its proxies/B2BUAs
know.

Each proxy/B2BUA that handles a request perforce calculates a loop
detection value according to the method of RFC 5393 section 4.2.1:

   This second part MUST vary with any field used by the location
   service logic in determining where to retarget or forward this
   request.  This is necessary to distinguish looped requests from
   spirals by allowing the proxy to recognize if none of the values
   affecting the processing of the request have changed.  Hence, the
   second part MUST depend at least on the received Request-URI and any
   Route header field values used when processing the received request.
   Implementers need to take care to include all fields used by the
   location service logic in that particular implementation.

The proxy/B2BUA "encrypts" the loop detection value with the secret
key to create an "encrypted loop detection value", which it compares
to the list of values in the "ESPID" header.  There are several cases:

    The request has arrived from outside the carrier:

	The new ELDV is the same as another ELDV in ESSID:  The request
	has been in this carrier before, with the same destination, and so
	is looping.

	Otherwise:  Add this ELDV to ESSID.  Forward the request.

    The request has arrived from another proxy/B2BUA within the same
    carrier:

	The new ELDV is the same as the last ELDV in ESSID:  The request
	has been proceeding through the carrier.  Forward the request.
	(Of course, the proxy/B2BUA has to perform RFC 5393 loop detection
	to detect any loop since the ingress to the carrier.)

	The new ELDV is the same as an ELDV in ESSID that is not the last:
	The request is looping.

	Otherwise:  Add this ELDV to ESSID.  Forward the request.

The "encryption" process can be as simple as hashing the key with the
loop detection value, because there is no need to decrypt these values.

The way we have constructed ESSID, it can be much shorter than the
typical stack of Vias, because we can restrict the ELDVs to, say, 11
base64 characters, and ESSID will generally have one ELDV per carrier
transit plus one for each redirection.  E.g., the example I gave would
have only 6 ELDV values (72 characters), but probably transits 20
proxies/B2BUAs.

A carrier can change its key from time to time (perhaps to prevent any
statistical attack), perhaps by hashing a master key with the date.
As long as the change interval exceeds the lifetime of any request in
transit, the ony penalty is that near a changeover time, some looping
requests may proceed for twice as many hops as normal before being
detected.

The tricky part is that each "carrier network" must have the property
that a request will never correctly exit the network and re-enter it
without the request-URI having been changed.  In many cases, this
isn't true of a carrier:  E.g., in the US, one carrier can handle the
last-mile of a call at the origination end, the trunk part of the call
is handled by a second carrier, but the last-mile at the destination
is handled by the first carrier.  In those cases, the carrier needs to
divide its network into several sub-networks; each sub-network has its
own ELDV key for its proxies/B2BUAs.

Dale