Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix

From: "Samir Srivastava" <[email-masked]>
Date: Sat, 1 Apr 2006 16:47:58 -0600

Hi Dale,

   See in line.

Thx
Samir

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: Saturday, April 01, 2006 11:16 AM
To: Sip
Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix

On Sat, 2006-04-01 at 02:27 -0600, Samir Srivastava wrote:
> These loops are caused by bad registrations at different proxies. Can 
> we change our registration process to fix this ?
> 
> At the Receipt of REGISTER, Registrar returns "202 Accepted" and then 
> it runs loop-detect (with Incrementing MAX-FORWARDS) and if there is 
> loop caused or not, it uses the Register event package to tell the 
> outcome of audit.

It might be better to not reject the REGISTER, since later actions might
cure the loop without altering *this* registration.  (Also, since a
rejected registration is not in the database, the next re-registration
attempt also appears to be new, and triggers the loop test again.)

SS>> Only later *UnRegistration or expired contact* can break the loop.
Proxy P1 is still going to forward Proxy P2, where looped contact is
gone for now, and request is not going to fullfilled with proxy P1
contact. So it good to reject this registration. And let  the
Registering end point figure out where is the loop. If an endpoint keeps
registering again and again with looped causing contacts, trigger this
to IPS/IDS and take out the endpoint. This is very similar to how
repeated 401/407 are handled.

I re-iterate the problem is with bad registrations, so it should be
fixed there instead of adding additional loop detection logic at each
node, with node Id, breadth to contain damage etc.

If there are third party registration allowed, then we don't need to run
MAX-FORWARD logic. Proxy P1 can query proxy P2 for the contact in
question. This brings a point, there are two properties in third party
registration one querying (which we need here) and another
adding/modifying registration. And unfortunately we have both clumbed
together currently.

But we could add an element to the register event package to report the
outcome of a loop-detection audit.
SS>> Okay.

Dale

_______________________________________________
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: "Dale R. Worley" <[email-masked]>
Date: Mon, 03 Apr 2006 13:21:03 -0400

> repeated 401/407 are handled.

If a registration at P1 shows up a loop, the registration for P1 may
well be correct, and the error being some configuration problem at P2.
So it is helpful to *report* the problem, but I think it is excessive to
reject the registration.

Dale