Hi,

Not a good idea. Why should I terminate the call just because of some
attacker?
I want to know if there is any standered defined way to recover from the
error condition.

Regards,
RadhaKrishna

-----Original Message-----
From: S B, JAYANTHEESH (JAYANTHEESH)** CTR **
[mailto:[email protected]] 
Sent: Wednesday, July 14, 2010 4:13 PM
To: radhakrishna; 'Rastogi, Vipul (Vipul)';
[email protected]
Subject: RE: [Sip-implementors] How sip stack can recover from the
followingerror condition.....

Hi RadhaKrishna,

We can have a retry count [optional configuration parameter] at UAC, once if
it reaches to the configured level, we can terminate the session by sending
BYE request. 

Regards,
Jayantheesh
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
radhakrishna
Sent: Wednesday, July 14, 2010 2:35 PM
To: 'Rastogi, Vipul (Vipul)'; [email protected]
Subject: Re: [Sip-implementors] How sip stack can recover from the
followingerror condition.....

Hi,

We are already aware that this can be avoided with TLS. But how justified is
it to use TLS just for resolving this issue?
Thanks for the suggestion anyway.

Can any one else provide a solution from a different angle?

Regards,
RadhaKrishna

-----Original Message-----
From: Rastogi, Vipul (Vipul) [mailto:[email protected]] 
Sent: Wednesday, July 14, 2010 2:13 PM
To: radhakrishna; [email protected]
Subject: RE: [Sip-implementors] How sip stack can recover from the
followingerror condition.....

To hide SIP headers, there are ways like TLS, SIP/MIME (encapsulation).
May be you would like to use TLS in this particular case, which will
prevent any attacker to generate accurate UPDATE message.


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
radhakrishna
Sent: Wednesday, July 14, 2010 14:01
To: [email protected]
Subject: [Sip-implementors] How sip stack can recover from the
followingerror condition.....

Dear All,

 

I want to know if there is any way to come out of the following problem.

 

UAC                                                                 UAS

----------------------------INV (CSEQ: 1) ------------------------>

<---------------------------200 OK----------------------------------

----------------------------ACK ------------------------------------>

 

            Attacker

            ----------------Update (CSEQ: 10000) ---------->

            <------------------- 401/407 ------------------------------

 

-----------------------UPDATE (CSEQ: 2) ------------------>

<----------------------- 500 --------------------------------------

 

Now since the actual UAC is not aware of the attacker, he will keep
incrementing the CSEQ every time and will try to send the request. The
request would be successful only after trying for some 9999 times. How
do we overcome this kind of situation?

 

We suggest that RFC should have a way to convey the CSEQ value stored by
UAS in 500 response message so that UAC can come out of the loop.

Can anyone please share your opinion on this issue?

 

Regards,

RadhaKrishna

 

 

 

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to