Subject: RE: [Sip] Update to fork-loop-fix submitted

From: <[email-masked]>
Date: Mon, 3 Jul 2006 16:09:35 +0530

Hi Robert,

I had suggested one more alternative

(http://www1.ietf.org/mail-archive/web/sip/current/msg14359.html )

Quoted from my previous mail:

<quote>
I was thinking how to reduce the impact of overhead for calculating the
digest.

If it is suggested as follows, I think it will reduce the overhead on
normal scenarios:

Proxy checks to see if its address is there in the via already. 
If it is not there, it proceeds normally without calculating the digest
and inserting Via to the outgoing request without the digest.
If it is there, then it is possible that the request is looping. So,
this time around, it calculates a digests and inserts and sends it
along.
If it is looping, the request will definitely come in again, which can
be rejected.
This way the impact of calculating the digest is required (reduced to a
smaller percent of the sessions) only when the proxy is suspicious the
request might be looping.
Of course this results in the scenarios mentioned in the id to be
successful in completing the first loop, but the second loop will be
detected and arrested. I think this can be applicable to general loop
detection, and not just fork loop fixes.
</quote>

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor
Wipro Technologies, Bangalore.
 
[email-masked]
--

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]] 
> Sent: Sunday, June 25, 2006 8:22 PM
> To: IETF SIP List
> Subject: [Sip] Update to fork-loop-fix submitted
> 
> Until it appears in the repository, see:
> http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-02.txt
> 
> This was a moderately heavy touch - based on list feedback, 
> I've moved and updated the sections covering the 
> loopdetection algorithm in from 3261. In the process of 
> writing the clarifying text, I discovered several places that 
> need clarification. They are listed as Open Issues in the 
> draft. Basically there are fields that I can't recall or 
> reconstruct how they would be useful in the part of the hash 
> used for loop-detection or spiral differentiation. If anyone 
> can remember why they need to be included, send a note to the 
> list and we'll capture that in the draft.
> 
> Please review the updated loop-detection text very carefully.
> 
> Here's the changelog from the draft:
> 
>        Integrated several editorial fixes suggested by 
> Jonathan Rosenberg
> 
>        Noted that the reduction of the attack to a single registration
>        against a single URI as documented in previous versions, is, in
>        fact, going to be effective against implementations 
> conforming to
>        the standards before this repair.
> 
>        Re-incorporated motivation from the original 
> maxforwards-problem
>        draft into the security considerations section based 
> on feedback
>        from Cullen Jennings
> 
>        Introduced replacement text for the loop detection algorithm
>        description in RFC 3261, fixing the bug 648 (the 
> topmost Via value
>        must not be included in the second part) and clarifying the
>        algorithm.  Removed several other fields suggested by 3261 and
>        placed open issues around their presence.
> 
>        Added a Notes to Implementors section capturing the 
> "common way"
>        text and pointing to the interoperability issues that have been
>        observed with loop detection at previous SIPits
> 
> 
> Thanks,
> 
> RjS
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip 
> Use [email-masked] for new developments on the application of sip
> 

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

---

From: Robert Sparks <[email-masked]>
Date: Wed, 5 Jul 2006 09:50:33 -0500

I understand the suggestion. You are trading off letting the request  
through a loop one extra cycle
for some lower amount of processing the first time the request went  
through the proxy. If you believe that
spirals are relatively rare things, this change would result in  
proxies very rarely having to build the loop/spiral
differentiation hash.

But as Jonathan points out, it's not clear that the hash computation  
is expensive enough to warrant this extra
logic and the extra network traffic it would allow. I expect that the  
hash calculation expense is small compared
to the parse/search/compare operations for "Proxy checks to see if  
its address is there in the via already".

RjS

On Jul 3, 2006, at 5:39 AM, <[email-masked]>  
<[email-masked]> wrote:

> The information contained in this electronic message and any  
> attachments to this message are intended for the exclusive use of  
> the addressee(s) and may contain proprietary, confidential or  
> privileged information. If you are not the intended recipient, you  
> should not disseminate, distribute or copy this e-mail. Please  
> notify the sender immediately and destroy all copies of this  
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The  
> recipient should check this email and any attachments for the  
> presence of viruses. The company accepts no liability for any  
> damage caused by any virus transmitted by this email.
>
> www.wipro.com

---

From: <[email-masked]>
Date: Thu, 6 Jul 2006 10:13:27 +0530

It is always better to reduce the computation in the path of normal
success case and introduce it in the path of a rarer scenario. I think
it will be a fair assumption to make that Spirals will be rarer than the
non-spiraling scenarios.

In terms of increasing logic, the increase in logic would be very small
if it all any.
It would be a trade-off that should be left to the implementer to take
if he considers that hash computation is expensive on his platform. If
this id recommends the computation of hash at the MUST strength in the
first pass of the SIP request, an implementer would not have that
freedom to make that trade-off.. 

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor

> Sent: Wednesday, July 05, 2006 8:21 PM
> To: RaviShankar Shiroor (WT01 - Product Engineering Solutions)
> Cc: [email-masked]
> Subject: Re: [Sip] Update to fork-loop-fix submitted
> 
> I understand the suggestion. You are trading off letting the 
> request through a loop one extra cycle for some lower amount 
> of processing the first time the request went through the 
> proxy. If you believe that spirals are relatively rare 
> things, this change would result in proxies very rarely 
> having to build the loop/spiral differentiation hash.
> 
> But as Jonathan points out, it's not clear that the hash 
> computation is expensive enough to warrant this extra logic 
> and the extra network traffic it would allow. I expect that 
> the hash calculation expense is small compared to the 
> parse/search/compare operations for "Proxy checks to see if 
> > I was thinking how to reduce the impact of overhead for 
> calculating  
> > the
> > digest.
> >

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 6 Jul 2006 09:50:46 +0100

Has it been discussed whether the hash function needs to be of cryptographic 
strength?

For example, hash functions used by hash tables are much simpler to compute, 
but typically have reasonable collision avoidance.  For example, one book I 
have [1] suggests a iteration step of a hash function of:

hash = hash * MULTIPLIER + data[n];

where MULTIPLIER is 31 or 37.

(This does assume that multiply is a single cycle operation - or nearly - 
which I believe it is for most modern processors.)

If you were paranoid you could compute two hashes with the different 
MULTIPLIERs and concatenate the result!

Pete.

[1] Kernigan & Pike, "The Practice of Programming", 1999
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
                         for XML to C++ data binding visit
                         http://www.tech-know-ware.com/lmx
                         (or http://www.xml2cpp.com)
=============================================

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 06, 2006 5:43 AM
Subject: RE: [Sip] Update to fork-loop-fix submitted

Regards,
Ravi.

--

Ravishankar. G. Shiroor

---

From: Robert Sparks <[email-masked]>
Date: Thu, 6 Jul 2006 12:48:34 -0500

> it will be a fair assumption to make that Spirals will be rarer  

But in this case, you are reducing computation (perhaps trivially) at  
the
cost of increased network traffic.

---

From: <[email-masked]>
Date: Fri, 7 Jul 2006 09:12:54 +0530

Comment Inline.

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor

> Sent: Thursday, July 06, 2006 11:19 PM

True, but it is not going to make it increase the traffic exponentially
which is the reason why this draft is coming out.
If the traffic were not to increase exponentially, max-forwards would be
considered sufficient to handle it right?

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 26 Jul 2006 10:16:11 +0200

> http://www.nostrum.com/~rjsparks/draft-ietf-sip-fork-loop-fix-02.txt

Robert,

With respect to Open Issue 3 (Proxy-Authorization and Proxy-Require) it is 
worth noting (restating actually, this has been pointed out before 
somewhere) that including them means that loop detection cannot be used when 
forwarding CANCEL or ACK to non-2xx:

- for both, branch must match the INVITE, so outcome of loop hash must match
- Proxy-Require/Proxy-Authorization won't appear in CANCEL or ACK to non-2xx 
(since these are generated hop-by-hop, and also because both are not allowed 
in CANCEL)

So whatever the reasons were for including them, there are reasons for *not* 
including them

Personally, I would like to separate the loop detection hash from the branch 
parameter. Can we not introduce a separate via parameter for this?

Regards,

Jeroen

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 26 Jul 2006 09:06:31 -0500

Jeroen van Bemmel wrote:
> Robert,
> 
> With respect to Open Issue 3 (Proxy-Authorization and Proxy-Require)
> it is worth noting (restating actually, this has been pointed out 
> before somewhere) that including them means that loop detection 
> cannot be used when forwarding CANCEL or ACK to non-2xx:
> 
> - Proxy-Require/Proxy-Authorization won't appear in CANCEL or ACK to
> non-2xx (since these are generated hop-by-hop, and also because both
> are not allowed in CANCEL)

Why would you want to do a loop detection for CANCELs and ACKs
to non-2xx?  In the latter case, you can't send a response anyway.
As long as the branch parameter for CANCELs and ACKs to non-2xx
matches a pending INVITE transaction, the state machines can be
updated accordingly.

> So whatever the reasons were for including them, there are reasons 
> for *not* including them

Looking at the notes from the WG, it is not apparent we know now
why we had incldued these in the first place.  FWIW, in our
loop detection code, we do not include these and the interop that
we have done with loop detection has worked without any problems.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 27 Jul 2006 08:35:19 +0200

> matches a pending INVITE transaction, the state machines can be

Because CANCEL and ACK can loop like any other request. The concern mostly 
applies to *stateless* proxies (stateful proxies mostly dont "forward" but 
"generate" CANCEL and ACK to non-2xx), but it matters also to a stateful 
proxy that receives a CANCEL with no matching INVITE ST (RFC3261 says "MUST 
forward statelessly").

For the latter case, I think it might be a good idea to create a 
servertransaction for the CANCEL, and forward statefully (using the same 
branch parameter as received) to catch any loops in an easy way

For the fork-loop-fix case I guess most concern goes to INVITEs, since they 
are the only requests that fork and thus cause amplification. But given that 
also a forking (=>stateful) proxy can receive an ACK to non-2xx or CANCEL 
with no matching INVITE servertransaction, it should be mentioned.

A looping ACK should obviously not be responded to, but it should be 
dropped.

Regards,

Jeroen

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 27 Jul 2006 17:28:08 -0500

Jeroen van Bemmel wrote:
> Because CANCEL and ACK can loop like any other request. The concern 
> mostly applies to *stateless* proxies

Ah, ok; I forgot about stateless proxies.  If you want to keep
stateless proxies simple, then just don't worry about loop
detection there.  The loop will be detected in the next stateful
proxy anyway.

> (stateful proxies mostly dont "forward" but "generate" CANCEL and ACK
> to non-2xx), but it matters also to a stateful proxy that receives a
> CANCEL with no matching INVITE ST (RFC3261 says "MUST forward
> statelessly").

Yes, I see where it says that, but my interpretation of the
phrase "MUST forward statelessly" is colored by what it says
next (see end of Section 16.10).  RFC3261 says that CANCELs MUST
be forwarded statelessly because the proxy may have statelessly
proxied the preceeding INVITE.

Assume you are a stateful proxy and never proxy an INVITE
statelessly.  When you get a CANCEL, you know for a fact that
you handle all INVITEs statefully so forwarding the CANCEL
statelessly causes needless network traffic.

Case 1: Consider the case where a stateful proxy receives a
CANCEL after just having proxied a 2xx response.  The 2xx will
put the ST in Terminated state at the proxy, whereupon it may
delete the ST, or keep it in memory for a few seconds longer.
But regardless, the proxy knows that it never sends any
INVITE transactions statelessly, so proxying a CANCEL is
pointless.

Case 2: A proxy receives a CANCEL request out of the blue.
Since it knows that it always sends INVITE statefully, proxying
the CANCEL is pointless.  Better to 481 it right there.

Ultimately, it is an implementation decision; if you ever
proxied a INV statelessly, then you must do the same for a
CANCEL.  Otherwise, statelessly proxying a CANCEL just adds
to network traffic.

Thanks.

- vijay