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

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Nov 2005 10:14:39 -0500

I just got around to reading this draft. Excellent document, thanks for 
doing this. It points out a real issue that will one day hurt a lot if 
we don't address it proactively.

I also like the suggestion for inclusion of the request message in the 
body of the response for diagnostic purposes. One thing though - lots of 
folks use a SIP request with Max-Forwards of 0 as a single-hop ping to 
detect whether the downstream element is alive. Its really a waste to 
always include the request body in the response for these, as its not 
needed - this is truly a forced attempt at an error response.

more inline.

Paul Kyzivat wrote:

> 
> 
> Cullen Jennings wrote:
> 
>> 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.
> 
> 
> 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.

I agree with Cullen. I think that limiting registrations to "self" along 
the lines of sip-outbound is the right solution. You are correct that 
one might still have ways to configure call forwarding (as they should) 
which might have this effect. However, I might argue that if these are 
provisioned in some other way, there are several things a proxy might do 
when handling these forwarding operations:

1. disallow forwarding to more than one destination if those 
destinations are outside of the domain; if they are inside the domain 
(i.e., hunt group), you can do a loop detection at PROVISIONING time, 
and fail the provisioning requests in the first place

2. If a request is forwarded, put some kind of flag in the request which 
disables additional forwarding, much like a diversion count (whose 
limits are set MUCH lower - like 2 or 3).

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Scott Lawrence <[email-masked]>
Date: Mon, 07 Nov 2005 08:34:43 -0500

> needed - this is truly a forced attempt at an error response.

It wouldn't be all that interesting in that case, I agree - I wasn't
aware that was done.  It would perhaps be a good idea to check the
number of Vias on the message and only include the request in error
responses if there was more than one Via on it.

> the lines of sip-outbound is the right solution. 

But doesn't that prohibit functionality that we really want to have?
Suppose I'm on a network where I must relay all SIP through a local
proxy - I register with that Proxy to get a GRUU, and then register my
'home' AOR to forward to that GRUU.  The 'home' registration will to be
forwarding to my home domain, but I certainly want it to succeed.

> You are correct that 

Other than actually sending a request to the forwarded address to see if
you get it back, I don't think there is a practical way to do the loop
detection at provisioning time.  The you only need the exploding
addresses to be at either end of chain of forwarded address, which could
be in the same domain or a different one.

> limits are set MUCH lower - like 2 or 3).

But additional forwarding is exactly what often makes SIP so robust.
I've lost track of the number of times that someone asked me to look at
a system configuration and I discovered that it was only working because
addresses spiraled through some odd sequence they were not aware of
("the phone rang, so I thought the routing was correct").

-- 
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Nov 2005 09:32:25 -0500

inline.

> responses if there was more than one Via on it.

Hmm, these days thats not a good indicator that this is a one-hop 
message. Folks are frequently stripping these off and including only the 
topmost Via in the outbound request.

Perhaps a header field that explicitly says not to send the content in 
the response (an empty Accept might work too).

> forwarding to my home domain, but I certainly want it to succeed.

This is why we have Path, no?

> be in the same domain or a different one.

You can do it at provisioning time if all of the forwarding addresses 
are within the same domain and thus (presumably) in the same database. I 
agree its not possible to check this at provisioning time if it spans 
domains, which is why I suggested possibly limiting it to one forward 
outside of the domain.

> ("the phone rang, so I thought the routing was correct").

But, these kinds of things are not "forwarding" in the sense of a change 
in target - they are merely the addition of another hop in order to 
reach the same target. Those things should be covered by Max-Forwards 
and be limited to 70 (or 20 apparently) as we have it today.

-Jonathan R.

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 07 Nov 2005 16:31:45 -0800

> topmost Via in the outbound request.

Presumably they are keeping the Vias around so that they can put them
back?   The mind boggles...

> the response (an empty Accept might work too).

I don't think that an empty Accept helps - given that the proposal does
not require that there be anything in the Accept to request this in the
first place.  I don't think it's ever going to hurt (any worse than
running out of hops already does) to return the message.  I do think it
is detrimental (as is currently the case) to _not_ return the message
when returning it would have provided valuable diagnostic information.

If anyone is spending the time and bandwidth to send a PING message, I
don't think that putting a copy of it into the returned response does
any real harm.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Nov 2005 21:42:58 -0500

inline.

> back?   The mind boggles...

Well, there are two reasons they are doing this. One of them is for 
topology hiding. The other is to reduce the size of the messages to 
avoid UDP fragmentation.

> first place. 

Yeah, I realize that.

> I don't think it's ever going to hurt (any worse than

You might be right. They don't get sent that often (perhaps once a 
second or so), so this is probably no big deal.

-Jonathan R.