Subject: [Sipping] Comments on lawrence-maxforward-problems

From: Cullen Jennings <[email-masked]>
Date: Sat, 22 Oct 2005 23:01:16 -0700

My favorite solution is "Disallow registration to arbitrary contacts".
Register was meant to bind a contact to an AOR. When you use it to try and
bind an AOR to an AOR to provision a forwarding rule, it is basically
broken. I view this is the Doctor Doctor category and think that
provisioning forwarding should be done in some other way than registrations.
That way you can provide other info in the provisioning like if it should be
serial or parallel fork.

That said, another way to deal with this would be for any proxy that saw
more than 70 outstanding transactions with the same Call-ID to just reject
all the transactions. This would be easy to implement and more or less solve
the worst case of the problem.

I worry about using Max forwards as a token to limit CPU usage - it will be
hard to find a value that works well. It was basically meant to limit
latency of the call set up time which is based on the depth of the search
tree, not the number of nodes in the search tree. I doubt 70 will be large
enough with the proposal in this draft and that will result in very
difficult backwards compatibility problems.

Cullen

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Robert Sparks <[email-masked]>
Date: Sun, 23 Oct 2005 21:37:42 -0500

> the worst case of the problem.
Interesting approach, but we need to start looking at details of all  
of the possible
solutions. This one would require that you share more information  
across a
cluster of proxies you're load-leveling over than you would  
otherwise. It also
might introduce a forced shared-resource for every transaction you  
process that
you might otherwise be able to avoid.

> difficult backwards compatibility problems.
Can you be specific about those backward compatibility problems? I  
suspect
there are some, and we tried to point at easiest to see in the draft  
(that the
maximum depth may be too tightly bounded) but we also tried to start the
conversation towards analyzing the properties that make may lead to  
problems.
What application do you see specifically that this proposal will trash?

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 24 Oct 2005 07:40:16 -0400

> That way you can provide other info in the provisioning like if it should be

I don't think this problem is in any way specific to registrations.  Any
parallel fork loop can lead to the exponential increase in traffic; it
need not even be just two services - one could construct loops that are
more involved.  Add to that the difficulty of determining whether an
address is an AOR or a contact, and I don't think that it's practical to
keep the loop from being created in the first place.

> the worst case of the problem.

I think there are practical problems with detecting this in an
implementation (Robert has pointed out one).  There is also the fact
that by the time you get to 70 outstanding transactions in one
participant, the problem has already happened.

> tree, not the number of nodes in the search tree.

I don't see this so much as protection for the CPU usage as protection
for the network - the very high number of messages being injected by
services unwittingly acting on behalf of an attacker who only had to
start with a very small number of messages and/or operations.

>  I doubt 70 will be large

I think experience has shown that many implementations now use values
much lower than 70 with no ill effect.  I don't think there's much
evidence that you need to get anywhere near a depth of 70 to have
sufficient reach today.  

It's possible that the introduction of proxies which limit total
messages as suggested would reduce the effective reach of current
deployed values enough cause problems.  But if those same proxies also
returned the additional diagnostic information the draft suggests, then
diagnosing and correcting the problem is straightforward.  It may be
that UAs that currently use default Max-Forwards values of much less
than 70 now would want to raise the default value, but I doubt that it
would need to get all the way up to 70.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  Consulting Engineer - Pingtel Corp.  http://www.pingtel.com/
  sipXpbx project coordinator - SIPfoundry  http://www.sipfoundry.org/sipX

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Oct 2005 11:24:25 -0400

> That way you can provide other info in the provisioning like if it should be

I don't find this very attractive. Limiting a general mechanism to the 
usages we currently think important is a good way to screw up the protocol.

But more importantly, it wouldn't solve the problem. Other mechanisms 
will surely be available for configuring forwarding addresses, whether 
this change is made or not. And they are equally useful creating the 
scenario.

> the worst case of the problem.

While perhaps easier to implement than loop detection, that too is extra 
work for a proxy to do, and that would have to be done for every 
transaction.

> difficult backwards compatibility problems.

My favorite of the proposed solutions is the variant of that allows 
serial forking as an alternative to splitting the max forwards among the 
branches. Presumably this would require some guidelines as to when to 
give up on parallel forking in order to have reasonable scenarios 
succeed. But it seems doable.

The biggest issue I see is that any solution will require widespread 
implementation to be effective. We don't have any good mechanism to 
ensure that.

	Paul