>> How about adding a new header something like "Remort-CSeq: 10000" in 500 >> response?
There are two possible issues with this - 1. Attacker can sniff the response and change it to the valid value of Cseq at UAC, thus leading to call drop. 2. Attacker can now join-in within any arbitrary CSeq, coz we will offer the valid CSeq to be used. As already pointed our, IMO too by doing this we will just try to re-invent the wheel eventually, instead of borrowing the learnings from existing solutions in network such as one in internet. **************************************************************************** *********** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of radhakrishna Sent: Thursday, July 15, 2010 8:12 AM To: 'Pandurangan R S' Cc: [email protected] Subject: Re: [Sip-implementors] How sip stack can recover from the followingerror condition..... How about adding a new header something like "Remort-CSeq: 10000" in 500 response? UAC can understand that the he has to increase the CSeq value to more than 10000 and can recover easily? Regards, RadhaKrishna -----Original Message----- From: Pandurangan R S [mailto:[email protected]] Sent: Thursday, July 15, 2010 7:34 AM To: radhakrishna Cc: [email protected] Subject: Re: [Sip-implementors] How sip stack can recover from the followingerror condition..... If the attacker is able to sniff and inject messages into the channel, then there are wide variety of attacks possible, as Brett has already indicated. So it is recommended to secure the channel using TLS or anything as such. Another possible attack is attacker can inject responses once he sniffs the request and the responses cannot be authenticated. So securing the channel is a recommended way to thwart these kind of attacks. > 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. Nothing prevents the attacker from using a CSEQ of 2^32-1 (maximum possible value) On Wed, Jul 14, 2010 at 2:01 PM, radhakrishna <[email protected]> wrote: > 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
