Subject: [dispatch] Charter Proposal for Inter-Service Provider SIP Loop Detection and Mitigation WG

From: Sohel Khan <[email-masked]>
Date: Tue, 6 Mar 2012 13:49:25 -0800 (PST)

Based on the feedback received, I have updated the charter proposal for the  Inter-Service-Provider SIP Loop Detection and Mitigation WG.
Please let us know whether we would like further changes in the charter.
 Inter-Service-ProviderSIP loop 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 Inter-Service-Providers’ 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 although there are some limitations. In particular, Current SIP loop-detection mechanisms do not work effectively in large-sale Inter-service provider networks as they are now deployed.  For B2BUAs and topology-hiding techniques often defeat loop-detection.
 
Some large-service providers would like to hide internal topology; however, would like to know about loops around multiple service providers. Operation engineers from these service providers point out the limitation of current SIP headers to mitigate Inter-Service-Providers’ loop, while hiding the internal topology. For example, Max-Forwards can be used to detect too many hops by decrementing values to zero; however, 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. In addition, SIP providers do not like to disclose internal node information.
 
The purpose of the WG is to study how the existing mechanisms for loop detection work in current large-scale service provider networks, and to recommend changes (to the networks and/or the mechanisms) to provide practical and effective loop detection in Inter-Service-Provider networks. The recommended method should be such that it detects Inter-Service-Provider loops while maintaining privacy and preserving SIP flexibility such as call forwarding.

Regards,
Sohel Khan

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2012 17:21:58 -0500

On 3/6/12 4:49 PM, Sohel Khan wrote:
> Based on the feedback received, I have updated the charter proposal for
> the Inter-Service-Provider SIP Loop Detection and Mitigation WG.
> Please let us know whether we would like further changesin the charter.

> _Inter-Service-Provider_SIP loop is a growing phenomenon.

While I believe what you say above, I would hate to see the effort 
restricted to that scope. I suspect this occurs whenever messages cross 
trust boundaries. For instance, a singe SP with sip trunks to multiple 
enterprises could see the same sort of looping.

> For example,
> SIP request messages traverse various providers and loop back to
> previous providers due to the parity of the routing vectors. In another

I have no clue what "parity of routing vectors" means, and what that 
might have to do with looping.

> 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
> Inter-Service-Providers’ 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 although
> there are some limitations. In particular, Current SIP loop-detection
> mechanisms do not work effectively in large-sale Inter-service provider
> networks as they are now deployed.For B2BUAs and topology-hiding
> techniques often defeat loop-detection.

Perhaps the major problem is topology hiding. And maybe all that's 
necessary to solve the problem is to do it more carefully.

> Some large-service providers would like to hide internal topology;
> however, would like to know about loops around multiple service
> providers. Operation engineers from these service providers point out
> the limitation of current SIP headers to mitigate
> Inter-Service-Providers’ loop, while hiding the internal topology. For
> example, Max-Forwards can be used to detect too many hops by
> decrementing values to zero; however, 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

I don't believe that lack of a fixed size identifier is the problem with 
this approach. For one thing, from what I have heard, a given SP will 
only be looking for itself. And as long as it knows the size of its own 
identifier you have the same advantage. (If its an advantage.)

> 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. In addition,

As Dale has pointed out, traversing a particular SP's network multiple 
times *is not* sufficient evidence that there is a loop. And its not 
clear if topology hiding will preserve enough added data to tell those 
that are from those that aren't.

> SIP providers do not like to disclose internal node information.
> The purpose of the WG is to study how the existing mechanisms for loop
> detection work in current large-scale service provider networks, and to
> recommend changes (to the networks and/or the mechanisms) to provide
> practical and effective loop detection in _Inter-Service-Provider_
> networks.

Perhaps instead of "service provider networks" this should say "networks 
where topology hiding is used", or "networks that span SBCs".

> The recommended method should be such that it detects
> Inter-Service-Provider loops

Just omit "Inter-Service-Provider" in the above.

> while maintaining privacy and preserving
> SIP flexibility such as call forwarding.

	Thanks,
	Paul

> Regards,
> Sohel Khan
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch