RE: verifying registration bindings (was [Sip]draft-ietf-sip-fork-loop-fix)

["Samir Srivastava" <[e-mail]>]

Hi Robert,

Thx for clarifying on either / or approach for the fix which I was
thinking of.

I was suggesting for REGISTER is similar to REFER


 UA               Registrar                Registrar/Proxy for Contact
in REG
 |                    |                                |
 |---REG ------------>|                                |
 |                    |                                | 
 |<-- 202 Accepted----|                                |
 |                    |<----- Audit on Reg Contact --->|
 |                    |                                |
 |<-- NOTIFY (REG EV)-|                                |
 |                    |                                |
 |-- 200 OK (NOT)---->|                                |


 At the time Registrar/Proxy sends NOTIFY it has confirmed knowledge of
goodness of contact at that point of time. Is this bad ? REFER works
this way.

Thx
Samir

-----Original Message-----
From: Jeroen van Bemmel [mailto:[e-mail]] 
Sent: Monday, April 03, 2006 1:03 PM
To: Robert Sparks; Srivastava, Samir [SC100:8826:EXCH]
Cc: Sip
Subject: Re: verifying registration bindings (was
[Sip]draft-ietf-sip-fork-loop-fix)

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" <[e-mail]>
To: "Samir Srivastava" <[e-mail]>
Cc: "Sip" <[e-mail]>
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 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
>
> On Apr 3, 2006, at 1:59 PM, Samir Srivastava wrote:
>
>>  Hi Dale,
>>
>>    Thx for response. See in line.
>>
>> Thx
>> Samir
>>
>> -----Original Message-----
>> From: Dale R. Worley [mailto:[e-mail]]
>> 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
>> [e-mail] for questions on current sip Use
>> [e-mail] 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 [e-mail] for questions on current sip
>> Use [e-mail] 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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip