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

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 3 Apr 2006 13:59:26 -0500

Hi Dale,

   Thx for response. See in line.

Thx
Samir

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: Monday, April 03, 2006 10:21 AM
To: Sip
Subject: RE: [Sip] draft-ietf-sip-fork-loop-fix

On Sat, 2006-04-01 at 16:47 -0600, Samir Srivastava wrote:
> 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.

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.

SS>> This is dependent on the order of registration. If P1 got the
registration first, then keeping
P2 registration is of no value. Since it is looped contact, how one can
decide which one to keep.
Keeping looped registration alive in the hope of someone will correct
them doesn't serve much purpose, if the guy is bad and he doesn't remove
it. Time window with looped contacts is open for attackers. Here one can
say, if looped contacts are detected, then further requests will not be
catered, unless they are corrected i.e. Reject the further request with
error code " Looped Contact correction in progress". My position is "Do
not let the faults percolate, correct them at the root itself as soon as
possible".  

I am okay to finalize these minor details later, *if there is group
consensus that we should take this path*. Group ??

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: Robert Sparks <[email-masked]>
Date: Mon, 3 Apr 2006 14:49:39 -0500

Samir -

We've talked about approaches similar to this in the past and there  
is interest in
the concept of asking a registrant "Prove to me that I can reach this  
contact" before
accepting a binding. There's been discussion (and even some draft  
work) around
using the consent framework to do something similar (but with greater  
scope).

What we have right now is an agreement to talk about the possible  
mechanisms,
and general recognition that we need something more than what we have  
right now.

We do not have any consensus (IMHO) around a particular mechanism  
yet. So the
plan is to progress the fork-loop-fix draft as is and decouple work  
on these other
potential mechanisms.

One comment on the questions you've posted so far: It's unlikely we  
will be able
to create a mechanism that allows us to reject the actual REGISTER  
request. That
puts another operation in the path of a non-INVITE transaction, and  
we've learned
that's a dangerous thing. I suspect we'll end up with a mechanism  
that puts bindings
into an "unconfirmed" state. The registrar will then send something  
towards the contact
asking for proof that it knows about the binding request. Once that  
proof is obtained,
the contact would become confirmed and used by a location server.

RjS

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 3 Apr 2006 22:03:15 +0200

Robert,

Also for the connection reuse draft it seems we will need a kind of "reverse 
challenge" mechanism to verify that a client requesting an alias actually 
owns / listens on the port that it is trying to shortcut (Via port instead 
of Contact, but similar).

When you say "in the path of a non-INVITE transaction", you mean the 
following would be bad?

UAC            UAS
    |     nit          |
    |----------->|
    |       100      |        // or some other 1xx meaning "challenging..."
    |<-----------|
    |   challenge  |
    |<-----------|
    |    answer    |
    |----------->|
    |                   |
    |    ok nit      |
    |<-----------|

Regards,

Jeroen

----- Original Message ----- 
From: "Robert Sparks" <[email-masked]>
To: "Samir Srivastava" <[email-masked]>
Cc: "Sip" <[email-masked]>
Sent: Monday, April 03, 2006 9:49 PM
Subject: verifying registration bindings (was 
[Sip]draft-ietf-sip-fork-loop-fix)

> Samir -
>
> We've talked about approaches similar to this in the past and there  is 
> interest in
> accepting a binding. There's been discussion (and even some draft  work) 
> around
> We do not have any consensus (IMHO) around a particular mechanism  yet. So 
> the
> plan is to progress the fork-loop-fix draft as is and decouple work  on 
> these other
> potential mechanisms.
>
> One comment on the questions you've posted so far: It's unlikely we  will 
> be able
> puts another operation in the path of a non-INVITE transaction, and  we've 
> learned
> that's a dangerous thing. I suspect we'll end up with a mechanism  that 
> puts bindings
> asking for proof that it knows about the binding request. Once that  proof 
> is obtained,